404 No se pudo identificar el proxy para el host: <nombre de host virtual> and url: <path>

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 404 con el mensaje Not Found y el mensaje de error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH como respuesta a las llamadas a la API.

Este error significa que Edge no pudo encontrar el proxy de API para el host virtual y la ruta de acceso especificados.

Mensaje de error

Obtendrás el siguiente código de estado HTTP:

HTTP/1.1 404 Not Found

También verás un mensaje de error similar al que se muestra a continuación:

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

El mensaje de error anterior indica que Edge no pudo encontrar el proxy de API para la ruta /oauth2/token y el host virtual default.

Causas posibles

A continuación, se indican algunas de las posibles causas de este error:

Pasos comunes de diagnóstico

Los registros de NGINX y de Message Processor serán útiles para solucionar el error 404. Sigue estos pasos para verificar los registros:

1. Consulta los registros de NGINX con el siguiente comando:

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

2. Verifica los siguientes campos en las entradas de registro:

   Campo	Valor
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Anota el ID del mensaje de los registros.

3. Verifica los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para ver si tienes messaging.adaptors.http.flow.ApplicationNotFound para la API específica o si tienes el ID de mensaje único del paso 2 para la solicitud a la API.

   Ejemplo de mensaje de error del registro de Message Processor

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)

En el registro anterior, se muestran el código y el mensaje de error de la siguiente manera:

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

Causa: El proxy de API no está asociado con el host virtual específico

Si el proxy de API no está configurado para aceptar las solicitudes del host virtual específico, podemos obtener una respuesta 404 Not Found con el mensaje de error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnóstico

1. Verifica la configuración del Proxy Endpoint para el proxy de API y comprueba si el proxy de API está configurado para aceptar las solicitudes del host virtual especificado en el error. Esto se indica con el elemento VirtualHost. Veamos una configuración de ProxyEndpoint de ejemplo para comprender esto.

   Ejemplo de configuración de ProxyEndpoint que muestra que el proxy de API acepta solicitudes en un host virtual seguro

   

2. Supongamos que los hosts virtuales se definen en el entorno específico de la siguiente manera:

   Nombre	Puerto	Alias del host
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Realizas una solicitud a la API de default VirtualHost con la URL http://myorg-prod.apigee.net/weather
4. Dado que ProxyEndpoint no tiene default VirtualHost, como se muestra en el ejemplo anterior, obtienes el código de respuesta 404 con el siguiente mensaje de error:

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

5. Consulta la sección Resolución a continuación para solucionar este problema.
6. Si ProxyEndpoint está configurado para aceptar las solicitudes en default VirtualHost, ve a la siguiente causa: La ruta de acceso no está asociada a ningún proxy de API.

Solución

1. Agrega el VirtualHost faltante a la configuración de ProxyEndpoint para solucionar el problema. En el ejemplo anterior, puedes agregar el VirtualHost predeterminado a la configuración de ProxyEndpoint de la siguiente manera:

   <VirtualHost>default</VirtualHost>

   Ejemplo de configuración de ProxyEndpoint que muestra el VirtualHost predeterminado que se agrega

   

2. Como alternativa, en el ejemplo anterior, si tenías la intención de usar solo secure VirtualHost para este proxy de API específico, realiza las solicitudes a la API solo a secure VirtualHost con el protocolo HTTPS:

   https://myorg-prod.apigee.net/weather

Causa: Se quitó el host virtual en una revisión implementada recientemente del proxy de API

Si se implementa una revisión nueva de un proxy de API después de quitar un host virtual específico (que formaba parte de la revisión implementada anteriormente) y los clientes siguen usando ese host para realizar solicitudes a la API, se puede producir este problema.

Diagnóstico

1. Verifica la configuración del Proxy Endpoint del proxy de API para ver si está configurado para aceptar las solicitudes del host virtual especificado en el error. Esto se indica con el elemento VirtualHost en la configuración de ProxyEndpoint.
2. Si el host virtual especificado en el error no existe en la configuración de ProxyEndpoint, realiza los siguientes pasos. De lo contrario, ve a la siguiente causa: La ruta no está asociada a ningún proxy de API.
3. Compara la configuración de ProxyEndpoint de la revisión implementada anteriormente con la revisión implementada actualmente.
   1. Por ejemplo, supongamos que tu revisión implementada anteriormente era 5 y tu revisión implementada actualmente es 6:
      • Hosts virtuales configurados en el extremo de proxy en la revisión 5

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>

      • Hosts virtuales configurados en el extremo de proxy en la revisión 6

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>

   2. En el ejemplo anterior, VirtualHost vh1 existía en revision 5,, pero se quitó en revision 6 y se reemplazó por VirtualHost secure.
   3. Por lo tanto, si tú o tus clientes realizan solicitudes a este proxy de API con VirtualHost vh1 (que formaba parte de revision 5), recibirán el código de respuesta 404 con el siguiente mensaje de error:

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

4. Verifica si el cambio de host virtual se realizó intencionalmente o sin intención en la revisión implementada actualmente y toma las medidas adecuadas, como se explica en la sección Resolución.

Solución

Si identificas que se quitaron los hosts virtuales en una revisión nueva, es posible que haya sido intencional o por accidente. En cada caso, realiza los siguientes pasos recomendados o de resolución para solucionar el problema.

Situación 1: Cambio intencional

En el caso de que la eliminación del host virtual sea intencional, puedes elegir una de las siguientes opciones. La primera es el enfoque recomendado:

1. Crea un proxy nuevo con una ruta base diferente y usa un host virtual diferente (que no exista en la revisión implementada anteriormente).

2. Si deseas seguir usando el proxy de API existente, pero con un host virtual diferente, es mejor conservar el host virtual existente y agregar el host virtual adicional.

   Esto garantizará que el cambio no afecte a los usuarios de este proxy de API.

3. Si deseas usar el proxy de API existente y solo tienes un host virtual diferente, informa a los usuarios con anticipación y realiza este cambio durante un período de mantenimiento.

   Esto garantizará que los usuarios de este proxy de API conozcan el cambio y puedan usar un host virtual diferente para realizar las llamadas a este proxy de API. Por lo tanto, el cambio no los afectará.

Situación 2: Cambio no intencional

En el caso de que la eliminación del host virtual se haya realizado por error y no de forma intencional,haz lo siguiente:

1. Actualiza la configuración de ProxyEndpoint en la revisión implementada actualmente para usar los mismos hosts virtuales que se usaron en la revisión implementada anteriormente. En el ejemplo anterior, cambia la siguiente sección de:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>

   a

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>

2. Vuelve a implementar la revisión.

Prácticas recomendadas

Siempre es recomendable implementar proxies nuevos o revisiones nuevas durante un período de mantenimiento o cuando se espera la menor cantidad de tráfico posible, de modo que se puedan evitar los problemas que surjan durante la implementación o se pueda minimizar el efecto en el tráfico.

Causa: La ruta no está asociada a ningún proxy de API

Si el proxy de API no está configurado para aceptar las solicitudes de la ruta específica que se usa en la URL de la solicitud a la API, podemos obtener una respuesta 404 Not Found con el mensaje de error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnóstico

1. Consulta la configuración de ProxyEndpoint para el proxy de API específico para el que tenías la intención de realizar las solicitudes a la API.
2. Verifica si el proxy de API está configurado para aceptar las solicitudes de la ruta de acceso específica que se indica en el mensaje de error. Para ello, sigue los pasos que se indican en el escenario 1 y el escenario 2.

Situación 1: La ruta no coincide con la ruta base del proxy de API

1. Si el path indicado en el mensaje de error no es el mismo que el basepath del proxy de API específico o no comienza con el basepath, esa podría ser la causa del error.
2. Veamos un ejemplo para explicar esto:
1. El basepath del proxy de API deseado es /weather.
2. La URL de solicitud de la API es https://myorg-prod.apigee.net/climate. Esto significa que la ruta de acceso que se usa en la URL de la solicitud a la API es /climate..
3. En este ejemplo, el path no es el mismo que el basepath y no comienza con el basepath. Por lo tanto, verás el siguiente error:

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

Solución

1. Asegúrate de que el path que se usa en la URL de la solicitud a la API sea el mismo que el basepath del proxy de API específico.
2. En el ejemplo anterior, la URL de la solicitud de API debería ser la siguiente:

   {
   https://myorg-prod.apigee.net/weather

Situación 2: La ruta no coincide con ninguno de los flujos condicionales disponibles

1. Si el path que se usa en la URL de la solicitud a la API comienza con basepath, es posible que el path suffix (la parte que viene después de basepath) indicado en el mensaje de error no coincida con ninguno de los flujos condicionales, lo que podría causar el error 404.
2. Veamos un ejemplo para explicar esto:
   1. El basepath del proxy de API deseado es /weather.
   2. La URL de solicitud de la API es https://myorg-prod.apigee.net/weather/Delhi. Esto significa que la ruta de acceso que se usa en la URL de la solicitud a la API es /weather/Delhi..
3. En este ejemplo, el path comienza con el basepath /weather. Además, tiene un path suffix de /Delhi.
4. Ahora verifica si hay flujos condicionales en ProxyEndpoint.
5. Si no hay flujos condicionales o hay algunos flujos no condicionales, ve a la siguiente causa: El proxy de API no se implementó en un entorno.
6. Si el elemento ProxyEndpoint solo tiene flujos condicionales, verifica lo siguiente:
   1. Si las condiciones de todos estos flujos condicionales verifican un proxy.pathsuffix específico (la ruta después de la ruta base)
   2. Si el path suffix especificado en la URL de la solicitud de API no coincide con ninguna de las condiciones, esa es la causa del error.
7. Supongamos que tenemos dos flujos en ProxyEndpoint y ambos son flujos condicionales, como se muestra a continuación:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>

   1. En el ejemplo anterior, tenemos dos flujos condicionales, uno que coincide con proxy.pathsuffix (ruta de acceso después de la ruta de acceso base) con /Bangalore y el otro que coincide con /Chennai. Pero no hay ninguna que coincida con /Delhi, que es el path suffix que se pasó en la URL de la solicitud de la API.
   2. Esta es la causa del error 404. Por lo tanto, recibirás el siguiente error:

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

Solución

1. Asegúrate de que path suffix coincida con al menos uno de los flujos condicionales en tu extremo de proxy.
2. En el ejemplo anterior, puedes usar uno de los siguientes enfoques para resolver el error:
   1. Si deseas ejecutar un conjunto específico de políticas para la ruta de acceso /Delhi, agrega un flujo independiente con el conjunto de políticas requerido y asegúrate de que haya una condición que coincida con /proxy.pathsuffix /Delhi, como se muestra a continuación:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. Si deseas ejecutar un conjunto común de políticas para la ruta de acceso /Delhi, asegúrate de que, en el flujo común, haya una condición que permita un /proxy.pathsuffix genérico. Es decir, permitiría cualquier ruta después de basepath /weather, como se muestra a continuación:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Si el ProxyEndpoint tiene el basepath correcto y el path suffix especificado en la URL de la API coincide con uno de los flujos condicionales, pasa a la siguiente causa: El proxy de API no se implementó en un entorno.

Causa: El proxy de API no se implementó en un entorno

Diagnóstico

1. Determina el entorno en el que existe el alias de host que se usa en la URL de la solicitud a la API. Para ello, verifica los detalles de todos los hosts virtuales en cada uno de los entornos de tu organización en la IU de Edge.

   Por ejemplo, supongamos que tienes la siguiente configuración:

   • Si http://myorg-prod.apigee.net/weather es tu URL, entonces myorg-prod.apigee.net es el alias del host.
   • El alias de host myorg-prod.apigee.net se configura como parte de uno de los hosts virtuales en el entorno prod de tu organización.
2. Verifica si el proxy de API específico se implementó en el entorno específico determinado en el paso 1 anterior.
3. Si el proxy de API no se implementa en el entorno específico, esa es la causa del error 404.
   1. Por lo tanto, en el ejemplo que se usó en el paso 1 anterior, supongamos que el proxy de API no se implementó en el entorno prod. Entonces, esa es la causa del error.
   2. Ve a la sección Resolución que se encuentra a continuación.
4. Si el proxy de API se implementa en el entorno específico, ve a la siguiente causa: El entorno no se cargó en los procesadores de mensajes.

Solución

Implementa el proxy de API en el entorno específico en el que piensas realizar solicitudes a la API.

Causa: No se cargó el entorno en los Message Processors

Diagnóstico

1. Accede a cada uno de los Message Processors y verifica si el entorno específico en el que realizas la solicitud a la API se cargó en el Message Processor con el siguiente comando:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Si el entorno específico aparece en el comando anterior, ve a la siguiente causa: El proxy de API no se implementó en uno o más procesadores de mensajes.
3. Si el entorno específico no aparece en la lista, verifica /opt/apigee/var/log/edge-message-processor/logs/system.log y /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log en los procesadores de mensajes para detectar errores durante la carga de los entornos.
4. Puede haber muchos errores diferentes que podrían provocar la falla en la carga de un entorno en el procesador de mensajes. La resolución depende del error que se produjo.

Solución

Es posible que el entorno no se cargue en el Message Processor por varios motivos. En esta sección, se ilustran algunos motivos posibles que pueden generar este problema y se explica cómo resolverlo.

1. Si ves uno de los siguientes errores en el registro del Message Processor, se debe a un problema con los certificados o las claves que se agregaron al almacén de claves o almacén de certificados de confianza especificados en el entorno especificado.

   Error 1: java.security.KeyStoreException: No se puede reemplazar el propio certificado

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
   …
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

   ... 20 common frames omitted

   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

   Error núm. 2: java.security.KeyStoreException: No se puede reemplazar la clave secreta

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   ...
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

2. Obtén los detalles del almacén de claves o almacén de certificados de confianza especificado en el mensaje de error que se muestra en el paso anterior con la siguiente llamada a la API de administración:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   Resultado de ejemplo:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }

3. El resultado de ejemplo muestra que hay dos certificados y una clave en el almacén de confianza myTruststore. Por lo general, el almacén de certificados de confianza no contiene una clave. Si es así, es mejor tener un solo certificado y una sola clave.
4. Obtén los detalles sobre los dos certificados con la siguiente API:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. Verifica la fecha de vencimiento de cada uno de los certificados y determina cuál es el certificado vencido o más antiguo.
6. Borra el certificado vencido o no deseado del almacén de confianza myTruststore.

Si el problema persiste o ves algún error que no se mencionó en el paso 1, consulta Recopila información de diagnóstico.

Causa: El proxy de API no se implementó en uno o más Message Processors

Es posible que el proxy de API no esté implementado en uno o más procesadores de mensajes. Este problema ocurre muy rara vez y se debe principalmente a una falta de notificación de evento del servidor de administración al Message Processor durante la implementación del proxy de API específico. En este caso, tampoco podrás crear la sesión de registro en la IU de Edge.

Diagnóstico

1. Accede a cada uno de los procesadores de mensajes y verifica si la revisión específica del proxy de API está implementada o no con el siguiente comando:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. Si la revisión específica del proxy de API no aparece como resultado del comando mencionado en el paso 1 anterior, reinicia el Message Processor específico como se explica en Resolución.
3. Repite los pasos 1 y 2 para todos los Message Processors.
4. Si la revisión específica del proxy de API se implementó en todos los procesadores de mensajes, entonces este no es el motivo del problema. Consulta Se debe recopilar información de diagnóstico.

Solución

Reinicia los Message Processors específicos en los que no se implementó la revisión específica del proxy de API.

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Diagnostica problemas con la supervisión de API

La supervisión de API te permite aislar rápidamente las áreas con problemas para diagnosticar problemas de errores, rendimiento y latencia, y su fuente, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Para este problema, puedes navegar a la página API Monitoring > Investigate, elegir la fecha, el proxy, etcétera, y ver los siguientes detalles:

• Código de falla: messaging.adaptors.http.flow.ApplicationNotFound
• Código de estado: 404
• Fuente del error: Apigee o MP

Además, puedes hacer clic en Ver registros, como se muestra en la captura de pantalla anterior, y realizar más verificaciones.

En Analiza un caso de ejemplo, se muestra cómo solucionar problemas de 5xx con tus APIs usando API Monitoring. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 404 supere un umbral determinado.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico. Comunícate con el equipo de asistencia de Apigee Edge y comparte esta información.

1. Si eres usuario de la nube pública, proporciona la siguiente información:
   • Nombre de la organización
   • Nombre del entorno
   • Nombre del proxy de API
   • Comando curl completo para reproducir el error
2. Si eres usuario de Private Cloud, proporciona la siguiente información:
   • Mensaje de error completo observado
   • Nombre del entorno
   • Paquete de proxy de API
   • Registros de Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Resultado de los siguientes comandos en cada uno de los procesadores de mensajes

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

3. Detalles sobre qué secciones de este manual probaste y cualquier otra información que nos ayude a acelerar la resolución de este problema.