Cette page a été traduite par l'API Cloud Translation.

404 Hôtes virtuels multiples avec le même alias d'hôte

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit un code d'état HTTP 404 avec le message Not Found et le message d'erreur Unable to identify proxy for host: VIRTUAL_HOST and url: PATH comme réponse aux appels d'API.

Cette erreur signifie que Edge n'a pas pu trouver le proxy d'API pour l'hôte virtuel et le chemin d'accès spécifiés.

Message d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 404 Not Found

En outre, un message d'erreur semblable à celui présenté ci-dessous peut s'afficher:

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Causes possibles

Cause	Description	Instructions de dépannage applicables
Hôte virtuel avec alias d'hôte en double	Plusieurs hôtes virtuels ont le même alias d'hôte et le même numéro de port.	Utilisateurs Edge de cloud public et privé

Étapes de diagnostic courantes

Les journaux de NGINX et du processeur de messages seront utiles pour résoudre l'erreur 404. Pour vérifier les journaux, procédez comme suit:

Affichez les journaux NGINX à l'aide de la commande suivante:

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

Vérifiez les champs suivants dans les entrées de journal:

Champ	Valeur
`Upstream_status, status`	`404`
`X-Apigee-fault-code`	`messaging.adaptors.http.flow.ApplicationNotFound`

Notez l'ID du message à partir des journaux.

Vérifier les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour voir si vous avez messaging.adaptors.http.flow.ApplicationNotFound pour l'API spécifique ou, si vous disposez de l'étape 2 pour la requête API.
Exemple de message d'erreur du journal du processeur de messages

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST,
uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{
code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for
host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b
input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443
Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms
lastIO=0ms  isOpen=true)

Le journal ci-dessus affiche le code et le message d'erreur suivants:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Remarque:Les champs url et host ci-dessus peuvent varier en fonction du proxy d'API. pour laquelle vous rencontrez le problème.

Cause: plusieurs hôtes virtuels avec le même alias d'hôte et le même numéro de port

Les routeurs et processeurs de messages Apigee Edge utilisent à la fois l'en-tête de l'hôte, le numéro de port et les chemins d'URI pour acheminer le trafic vers le proxy d'API approprié. Avoir des définitions ambiguës, telles que la présence de multiples avec le même alias d'hôte et le même numéro de port, est documenté anti-pattern et peut entraîner des comportements inattendus. L'une des erreurs courantes que vous observerez est un Erreur 404 avec le message Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

En général, si plusieurs hôtes virtuels avec le même alias d'hôte existent, vous observez alors erreurs 404 intermittentes. En effet, le proxy d'API spécifique peut être configuré pour accepter les demandes sur un seul des hôtes virtuels. Lorsque les requêtes API sont acheminées vers un hôte virtuel spécifique configuré dans le proxy d'API, vous obtiendrez une réponse positive. Toutefois, lorsque les requêtes API sont acheminées vers les autres hôtes virtuels auxquels le proxy d'API est n'est pas configurée pour accepter les requêtes, les API échouent avec ces 404 les erreurs.

Suivez les instructions fournies dans <ph type="x-smartling-placeholder"></ph> 404 Impossible d'identifier le proxy pour l'hôte : <nom d'hôte virtuel> et url: <path> et résoudre cette erreur. Si aucune des causes ne provoque cette erreur, suivez les étapes ci-dessous ci-dessous pour déterminer si les hôtes virtuels avec des alias d'hôte en double sont à l'origine du problème 404 les erreurs.

Diagnostic

Utilisez l'une des méthodes suivantes pour déterminer s'il existe plusieurs hôtes virtuels ayant le même alias d'hôte/numéro de port, ce qui entraîne des erreurs 404:

Interface utilisateur périphérique
API de gestion

Interface utilisateur périphérique

Suivez ces instructions pour déterminer si plusieurs hôtes virtuels possèdent le même hôte. alias/numéro de port à l'aide de l'interface utilisateur Edge.

Par exemple, si vous avez observé l'erreur 404 avec l'URL http://example.com:9001/proxy1, vous devez alors trouver quels hôtes virtuels ont l'alias d'hôte example.com et le port 9001.

Dans le cloud public et la nouvelle interface utilisateur Edge sur le cloud privé: <ph type="x-smartling-placeholder">
1. Sélectionnez Admin.
2. Sélectionnez Virtual Hosts (Hôtes virtuels).
3. Pour chaque environnement, utilisez le filtre de recherche pour déterminer le type d'environnement Virtual Hôtes correspondant à l'alias d'hôte spécifique avec lequel l'API requêtes ont été appelées.
4. Si plusieurs hôtes virtuels utilisent le même alias d'hôte, accédez à Solution pour résoudre ce problème.
Exemples :
Dans l'UI classique sur un cloud privé: <ph type="x-smartling-placeholder">
1. Sélectionnez l'onglet API .
2. Sélectionnez Configuration de l'environnement.
3. Sélectionnez Virtual Hosts (Hôtes virtuels).
4. Pour chaque environnement, affichez la liste des hôtes virtuels afin de voir s'il y a des correspondances. L'alias d'hôte spécifique avec lequel les requêtes API ont été appelées.
5. Si plusieurs hôtes virtuels correspondent au même alias d'hôte, accédez à Solution pour résoudre ce problème.
Exemple:

API de gestion

Suivez ces instructions pour déterminer si plusieurs hôtes virtuels possèdent le même hôte. d'alias ou de numéro de port à l'aide des API Management.

Obtenez la définition de chacun des hôtes virtuels dans chacun des environnements de votre organisations pour voir quels hôtes virtuels ont le même alias d'hôte et le même numéro de port:

Par exemple, si vous avez observé l'erreur 404 avec l'URL http://example.com:9001/proxy1, vous devez identifier les hôtes disposent de l'alias example.com et du port 9001.

Obtenir la liste des environnements

Utilisateur du cloud public:

curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments -u USERNAME

Utilisateur Private Cloud:

curl -v -X GET http://MANAGEMENT_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments -u USERNAME

Où :

ORGANIZATION_NAME est le nom de l'organisation.

Exemple :

curl http://127.0.0.1:8080/v1/organizations/myorg/environments -u USERNAME

[ "prod", "test", "dev" ]

Obtenir la liste des hôtes virtuels d'un environnement

Utilisateur du cloud public:

curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts -u USERNAME

Utilisateur Private Cloud:

curl -v -X GET http://MANAGEMENT_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts -u USERNAME

Où :

ORGANIZATION_NAME est le nom de l'organisation.

ENVIRONMENT_NAME est le nom de l'environnement.

Exemple :

curl http://127.0.0.1:8080/v1/organizations/myorg/environments/test/virtualhosts -u USERNAME

[ "default" ]

Obtenez la définition de chacun des hôtes virtuels de l'environnement.

Utilisateur du cloud public:

curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUAL_HOST_NAME  -u USERNAME

Utilisateur Private Cloud:

curl -v -X GET http://MANAGEMENT_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUAL_HOST_NAME -u USERNAME

Où :

ORGANIZATION_NAME est le nom de l'organisation.

ENVIRONMENT_NAME est le nom de l'environnement.

VIRTUAL_HOST_NAME est le nom de l'hôte virtuel.

Exemple :

curl http://127.0.0.1:8080/v1/organizations/myorg/environments/test/virtualhosts/default -u USERNAME

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [ ],
  "listenOptions" : [ ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [ ]
}

Répétez les deux étapes ci-dessus pour les autres environnements de votre organisation.

Dans cet exemple, répétez les étapes pour l'environnement dev:
```
curl http://127.0.0.1:8080/v1/organizations/myorg/environments/dev/virtualhosts -u USERNAME
```
```
[ "default" ]
```
```
curl http://127.0.0.1:8080/v1/organizations/myorg/environments/dev/virtualhosts/default -u USERNAME
```
```
{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [ ],
  "listenOptions" : [ ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [ ]
}
```
Dans cet exemple, vous pouvez voir que les deux hôtes virtuels default dans deux environnements différents, test et dev, tous deux contiennent le même alias d'hôte example.com et le même numéro de port. 9001 C'est la cause des erreurs 404.
Si plusieurs hôtes virtuels correspondent au même alias d'hôte, accédez à Solution pour résoudre ce problème.

Solution

Assurez-vous que chaque hôte virtuel ne contient que des combinaisons d'alias d'hôte et de port uniques.
Si vous avez identifié plusieurs hôtes virtuels avec les mêmes combinaisons alias d'hôte et de port vous devez les mettre à jour avec un alias d'hôte unique.
Vous pouvez les mettre à jour à l'aide de l'interface utilisateur Edge ou de l'API de gestion. Vous trouverez les instructions correspondantes moins de Modifier un hôte virtuel
Vérifiez que chaque alias d'hôte dispose d'une entrée DNS appropriée. <ph type="x-smartling-placeholder">
</ph> Remarque : Si l'alias d'hôte dupliqué a été trouvé dans un hôte virtuel configuré sur secure tel que 443, vous devez vous procurer un certificat correspondant au nouvel hôte nom d'alias ou du nouvel alias d'hôte dans le SAN (Subject Alternative Name) d'un certificat existant utilisées dans le keystore.

Dans l'exemple mentionné ci-dessus, si notre configuration se présente comme suit:

curl -X GET http://localhost:8080/v1/organizations/myorg/environments -u user

[ "prod", "test", "dev" ]

curl -X GET http://localhost:8080/v1/organizations/myorg/environments/test/virtualhosts/default -u user

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}

curl -X GET http://localhost:8080/v1/organizations/myorg/environments/dev/virtualhosts/default -u user

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}

Vous pouvez mettre à jour les hôtes virtuels incorrects afin qu'ils ne se chevauchent pas.
Autrement dit, remplacez l'alias d'hôte par example2.com.

Assurez-vous que le nouvel alias d'hôte possède une entrée DNS semblable à celle de l'alias d'hôte précédent.

curl -X GET http://localhost:8080/v1/organizations/myorg/environments/dev/virtualhosts/default -u user -H 'Content-Type: application/json' -d '{
  "hostAliases" : [ "example2.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}' -i

HTTP/1.1 200 OK
Date: Tue, 02 Feb 2021 20:54:29 GMT
Content-Type: application/json
X-Apigee.user: user
X-Apigee.organization: myorg
X-Apigee.environment: dev
X-Apigee.backends: management-server
Date: Tue, 02 Feb 2021 20:54:29 GMT
Content-Length: 152

{
  "hostAliases" : [ "example2.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}

Effectuez à nouveau les appels d'API vers le proxy et vérifiez que vous obtenez régulièrement des réponses positives:

curl http://example.com:9001/proxy1

{
    "slideshow": {
	    "author": "Yours Truly",
		"date": "date of publication",
		"slides": [
		    {
			    "title": "Wake up to WonderWidgets!",
				"type:": "all"
			},
			{
			    "items": [
				    "Why WonderWidgets are great",
					"Who buys WonderWidgets"
				],
				"title": "Overview",
				"type": "all"
			}
		],
		"title": "Sample Slide Show"
    }

}

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, rassemblez les informations suivantes : de diagnostic, puis contactez l'assistance Apigee Edge:

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:

Nom de l'organisation
Nom de l'environnement
Nom du proxy d'API
Exécutez la commande curl pour reproduire l'erreur 404.
Si les erreurs 404 ne se produisent pas actuellement, indiquez la période avec les informations de fuseau horaire lorsque 404 erreurs se sont produites dans le passé.

Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:

Message d'erreur complet observé pour les requêtes en échec
Nom de l'organisation, de l'environnement et du proxy d'API que vous observez 404 erreur
Groupe de proxys d'API
Journaux d'accès NGINX
/opt/apigee/var/log/edge-router/nginx/ORGANIZATION_NAME~ENVIRONMENT_NAME.PORT#_access_log
Journaux du processeur de messages
/opt/apigee/var/log/edge-message-processor/logs/system.log
Période avec les informations de fuseau horaire au cours de laquelle les erreurs 404 se sont produites