404 Não foi possível identificar o proxy do host: <nome do host virtual> e URL: <caminho>

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de status HTTP 404 com a mensagem Not Found e a mensagem de erro Unable to identify proxy for host: VIRTUAL_HOST and url: PATH como resposta às chamadas de API.

Esse erro significa que o Edge não conseguiu encontrar o proxy de API para o host virtual e o caminho especificados.

Mensagem de erro

Você vai receber o seguinte código de status HTTP:

HTTP/1.1 404 Not Found

Você também vai ver uma mensagem de erro semelhante a esta:

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

A mensagem de erro acima indica que o Edge não encontrou o proxy de API para o host virtual default e o caminho /oauth2/token.

Causas possíveis

Confira abaixo algumas das possíveis causas para esse erro:

Etapas comuns do diagnóstico

Os registros do NGINX e do processador de mensagens ajudam a resolver o erro 404. Siga estas etapas para verificar os registros:

1. Use o comando a seguir para ver os registros do NGINX:

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

2. Verifique os seguintes campos nas entradas de registro:

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

   Anote o ID da mensagem nos registros.

3. Verifique os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para saber se você tem messaging.adaptors.http.flow.ApplicationNotFound para a API específica ou se tem o ID de mensagem exclusivo da etapa 2 para a solicitação de API.

   Exemplo de mensagem de erro do registro do processador de mensagens

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)

O registro acima mostra o código e a mensagem de erro da seguinte forma:

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

Causa: o proxy de API não está associado ao host virtual específico

Se o proxy de API não estiver configurado para aceitar as solicitações do host virtual específico, vamos receber uma resposta 404 Not Found com a mensagem de erro Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnóstico

1. Verifique a configuração do endpoint de proxy do proxy de API e confira se ele está configurado para aceitar as solicitações do host virtual especificado no erro. Isso é indicado pelo elemento VirtualHost. Vamos analisar uma configuração de ProxyEndpoint de exemplo para entender isso.

   Exemplo de configuração de endpoint de proxy mostrando que o proxy de API aceita solicitações em um host virtual seguro

   

2. Digamos que os hosts virtuais sejam definidos no ambiente específico da seguinte maneira:

   Nome	Porta	Alias de host
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Você faz uma solicitação de API para default VirtualHost usando o URL http://myorg-prod.apigee.net/weather
4. Como o ProxyEndpoint não tem default VirtualHost, conforme mostrado no exemplo acima, você recebe o código de resposta 404 com a seguinte mensagem de erro:

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

5. Acesse a seção Resolução abaixo para resolver esse problema.
6. Se o ProxyEndpoint estiver configurado para aceitar as solicitações no default VirtualHost, vá para a próxima causa: Caminho não associado a nenhum proxy de API.

Resolução

1. Adicione o VirtualHost ausente à configuração ProxyEndpoint para resolver o problema. No exemplo acima, é possível adicionar o VirtualHost padrão à configuração ProxyEndpoint da seguinte maneira:

   <VirtualHost>default</VirtualHost>

   Exemplo de configuração do endpoint do proxy mostrando o VirtualHost padrão sendo adicionado

   

2. Como alternativa, no exemplo acima, se você pretendia usar apenas o secure VirtualHost para esse proxy de API específico, faça as solicitações de API apenas para o secure VirtualHost usando o protocolo HTTPS:

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

Causa: host virtual removido em uma revisão recém-implantada do proxy de API

Se uma nova revisão de um proxy de API for implantada depois da remoção de um host virtual específico (que fazia parte da revisão implantada anteriormente) e ainda estiver sendo usada pelos clientes para fazer solicitações de API, isso pode causar o problema.

Diagnóstico

1. Verifique a configuração do Endpoint do proxy para o proxy de API e confira se ele está configurado para aceitar as solicitações do host virtual especificado no erro. Isso é indicado pelo elemento VirtualHost na configuração ProxyEndpoint.
2. Se o host virtual especificado no erro não existir na configuração do ProxyEndpoint, siga estas etapas. Caso contrário, vá para a próxima causa: Caminho não associado a nenhum proxy de API.
3. Compare a configuração ProxyEndpoint da revisão implantada anteriormente com a revisão implantada no momento.
   1. Por exemplo, digamos que a revisão implantada anteriormente era 5 e a revisão implantada atualmente é 6:
      • Hosts virtuais configurados no endpoint do proxy na revisão 5

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

      • Hosts virtuais configurados no endpoint de proxy na revisão 6

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

   2. No exemplo acima, VirtualHost vh1 existia em revision 5,, mas foi removido em revision 6 e substituído por VirtualHost secure.
   3. Portanto, se você ou seus clientes estiverem fazendo solicitações para esse proxy de API usando VirtualHost vh1 (que fazia parte de revision 5), você vai receber o código de resposta 404 com a seguinte mensagem de erro:

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

4. Verifique se a mudança de host virtual foi feita intencionalmente ou não intencionalmente na revisão implantada no momento e tome as medidas adequadas, conforme explicado na seção Resolução.

Resolução

Se você identificar que o host ou os hosts virtuais foram removidos em uma nova revisão, isso pode ter sido intencional ou acidental. Para cada caso, siga as etapas recomendadas para resolver o problema.

Cenário 1: mudança intencional

Se a remoção do host virtual for intencional, escolha uma das seguintes opções. A primeira é a abordagem recomendada:

1. Crie um novo proxy com um caminho de base diferente e use um host virtual diferente (que não existe na revisão implantada anteriormente).

2. Se você quiser continuar usando o proxy de API atual, mas com um host virtual diferente, é melhor manter o host virtual atual e adicionar o outro.

   Isso garante que os usuários desse proxy de API não sejam afetados pela mudança.

3. Se você quiser usar o proxy de API atual e tiver apenas um host virtual diferente, informe seus usuários com antecedência e faça essa mudança durante um período de manutenção.

   Isso garante que os usuários desse proxy de API estejam cientes da mudança e possam usar um host virtual diferente para fazer as chamadas. Portanto, eles não serão afetados pela mudança.

Cenário 2: mudança não intencional

Se a remoção do host virtual foi feita por engano e não intencionalmente,faça o seguinte:

1. Atualize a configuração ProxyEndpoint na revisão implantada no momento para usar os mesmos hosts virtuais usados na revisão implantada anteriormente. No exemplo acima, mude a seguinte seção de:

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

   a

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

2. Reimplante a revisão.

Práticas recomendadas

É sempre recomendável implantar novos proxies ou revisões durante um período de manutenção ou quando o tráfego é esperado para que qualquer problema que surja durante a implantação possa ser evitado ou o efeito no tráfego possa ser minimizado.

Causa: o caminho não está associado a nenhum proxy de API

Se o proxy de API não estiver configurado para aceitar as solicitações do caminho específico usado no URL de solicitação de API, vamos receber uma resposta 404 Not Found com a mensagem de erro Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnóstico

1. Confira a configuração ProxyEndpoint do proxy de API específico para o qual você pretendia fazer as solicitações de API.
2. Verifique se o proxy de API está configurado para aceitar as solicitações do caminho específico indicado na mensagem de erro. Para isso, siga as etapas nos Cenários 1 e 2.

Cenário 1: o caminho não corresponde ao caminho base do proxy de API

1. Se o path indicado na mensagem de erro não for igual ao basepath do proxy de API específico ou não começar com o basepath, essa pode ser a causa do erro.
2. Vamos usar um exemplo para explicar isso:
1. O basepath do proxy de API pretendido é /weather
2. O URL da solicitação de API é https://myorg-prod.apigee.net/climate. Isso significa que o caminho usado no URL de solicitação de API é /climate.
3. Neste exemplo, o path não é o mesmo que o basepath e não começa com o basepath. Portanto, você vai receber o seguinte erro:

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

Resolução

1. Verifique se o path usado no URL de solicitação da API é o mesmo que o basepath do proxy de API específico.
2. No exemplo acima, o URL da solicitação da API deve ser o seguinte:

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

Cenário 2: o caminho não corresponde a nenhum dos fluxos condicionais disponíveis

1. Se o path usado no URL da solicitação da API começar com o basepath, é possível que o path suffix (a parte que vem depois do basepath) indicado na mensagem de erro não corresponda a nenhum dos fluxos condicionais, o que pode causar o erro 404.
2. Vamos usar um exemplo para explicar isso:
   1. O basepath do proxy de API pretendido é /weather
   2. O URL da solicitação de API é https://myorg-prod.apigee.net/weather/Delhi. Isso significa que o caminho usado no URL de solicitação de API é /weather/Delhi.
3. Neste exemplo, o path começa com o basepath /weather. Além disso, ele tem um path suffix de /Delhi.
4. Agora, verifique se há fluxos condicionais no ProxyEndpoint.
5. Se não houver fluxos condicionais ou houver alguns fluxos não condicionais, vá para a próxima causa: proxy de API não implantado em um ambiente.
6. Se o ProxyEndpoint tiver apenas fluxos condicionais, verifique o seguinte:
   1. Se as condições em todos esses fluxos condicionais verificarem um proxy.pathsuffix específico (o caminho após o basepath).
   2. Se o path suffix especificado no URL da solicitação de API não corresponder a nenhuma das condições, essa será a causa do erro.
7. Digamos que temos dois fluxos no ProxyEndpoint e ambos são fluxos condicionais, conforme mostrado abaixo:

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

   1. No exemplo acima, temos dois fluxos condicionais. Um corresponde a proxy.pathsuffix (caminho após o caminho base) para /Bangalore, e o outro corresponde a /Chennai. Mas não há nenhum que corresponda a /Delhi, que é o path suffix transmitido no URL de solicitação da API.
   2. Essa é a causa do erro 404. Portanto, você receberá o seguinte erro:

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

Resolução

1. Verifique se o path suffix corresponde a pelo menos um dos fluxos condicionais no endpoint de proxy.
2. No exemplo acima, você pode usar uma das seguintes abordagens para resolver o erro:
   1. Se você quiser executar um conjunto específico de políticas para o caminho /Delhi, adicione um fluxo separado com o conjunto de políticas necessário e verifique se há uma condição que corresponda a /proxy.pathsuffix /Delhi, conforme mostrado abaixo:

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

   2. Se você quiser executar um conjunto comum de políticas para o caminho /Delhi, no fluxo comum, verifique se há uma condição que permita um /proxy.pathsuffix genérico. Ou seja, ele permitiria qualquer caminho após o basepath /weather, conforme mostrado abaixo:

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

Se o ProxyEndpoint tiver o basepath correto e o path suffix especificado no URL da API corresponder a um dos fluxos condicionais, passe para a próxima causa: O proxy de API não foi implantado em um ambiente.

Causa: o proxy de API não foi implantado em um ambiente

Diagnóstico

1. Determine o ambiente em que o alias de host usado no URL da solicitação de API existe. Para isso, verifique os detalhes de todos os hosts virtuais em cada um dos ambientes da sua organização na interface do Edge.

   Por exemplo, suponha a seguinte configuração:

   • Se http://myorg-prod.apigee.net/weather for seu URL, myorg-prod.apigee.net será o alias do host.
   • O alias de host myorg-prod.apigee.net é configurado como parte de um dos hosts virtuais no ambiente prod da sua organização.
2. Verifique se o proxy de API específico está implantado no ambiente determinado na etapa 1 acima.
3. Se o proxy de API não estiver implantado no ambiente específico, essa será a causa do erro 404.
   1. Então, no exemplo usado na etapa 1 acima, digamos que o proxy de API não esteja implantado no ambiente prod. Essa é a causa do erro.
   2. Acesse a seção Resolução abaixo.
4. Se o proxy de API estiver implantado no ambiente específico, vá para a próxima causa: O ambiente não foi carregado nos processadores de mensagens.

Resolução

Implante o proxy de API no ambiente específico em que você pretende fazer solicitações de API.

Causa: o ambiente não foi carregado nos processadores de mensagens

Diagnóstico

1. Faça login em cada um dos processadores de mensagens e verifique se o ambiente específico em que você está fazendo a solicitação de API está carregado no processador de mensagens usando o seguinte comando:

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

2. Se o ambiente específico estiver listado como parte do comando acima, vá para a próxima causa: O proxy de API não foi implantado em um ou mais processadores de mensagens.
3. Se o ambiente específico não estiver listado, verifique /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log nos processadores de mensagens para conferir se há erros durante o carregamento de ambientes.
4. Pode haver muitos erros diferentes que levam à falha ao carregar um ambiente no processador de mensagens. A resolução depende do erro ocorrido.

Resolução

O ambiente pode não ser carregado no processador de mensagens por vários motivos. Esta seção ilustra alguns motivos possíveis que podem levar a esse problema e explica como resolvê-lo.

1. Se você encontrar um dos seguintes erros no registro do processador de mensagens, isso significa que ele foi causado por um problema encontrado com os certificados/chaves adicionados ao keystore/truststore especificado no ambiente especificado.

   Erro 1: java.security.KeyStoreException: Cannot overwrite own certificate

   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

   Erro nº 2: java.security.KeyStoreException: Cannot overwrite secret key

   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. Para conferir os detalhes do keystore/truststore especificado na mensagem de erro mostrada na etapa anterior, use a seguinte chamada de API Management:

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

   
   

   Exemplo de saída:

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

3. O exemplo de saída mostra que há dois certificados e uma chave no truststore myTruststore. Normalmente, o truststore não contém uma chave. Se for, é melhor ter um único certificado e uma única chave.
4. Receba os detalhes sobre os dois certificados usando a seguinte API:

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

5. Verifique a data de validade de cada certificado e determine qual deles expirou ou é mais antigo.
6. Exclua o certificado expirado ou indesejado do truststore myTruststore.

Se o problema persistir ou se você encontrar um erro diferente dos mencionados na etapa 1 acima, acesse Precisa de informações de diagnóstico.

Causa: o proxy de API não foi implantado em um ou mais processadores de mensagens

O proxy de API pode não estar implantado em um ou mais processadores de mensagens. Esse problema ocorre muito raramente e acontece principalmente devido a uma notificação de evento ausente do servidor de gerenciamento para o processador de mensagens durante a implantação do proxy de API específico. Nesse caso, também não será possível criar a sessão de rastreamento na interface do Edge.

Diagnóstico

1. Faça login em cada um dos processadores de mensagens e verifique se a revisão específica do proxy de API está implantada ou não usando o seguinte comando:

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

2. Se a revisão específica do proxy de API não aparecer como a saída do comando mencionado na etapa 1 acima, reinicie o processador de mensagens específico conforme explicado em Resolução.
3. Repita as etapas 1 e 2 para todos os processadores de mensagens.
4. Se a revisão específica do proxy de API estiver implantada em todos os processadores de mensagens, esse não será o motivo do problema. Acesse Precisa de informações de diagnóstico.

Resolução

Reinicie os processadores de mensagens específicos em que a revisão específica do proxy de API não está implantada.

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

Diagnosticar problemas usando a API Monitoring

Com a API Monitoring, é possível isolar as áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem deles, como apps de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Para resolver esse problema, acesse a página Monitoramento de API > Investigar e escolha a data, o proxy etc. adequados. Talvez você veja os seguintes detalhes:

• Código de falha:messaging.adaptors.http.flow.ApplicationNotFound
• Código de status:404
• Origem da falha:Apigee ou MP

Além disso, clique em Ver registros, conforme mostrado na captura de tela acima, e verifique mais detalhes.

Analise um cenário de exemplo para saber como resolver problemas de 5xx com suas APIs usando o API Monitoring. Por exemplo, você pode configurar um alerta para receber uma notificação quando o número de códigos de status 404 exceder um determinado limite.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico. Entre em contato e compartilhe essas informações com o suporte da Apigee Edge.

1. Se você for um usuário da nuvem pública, forneça as seguintes informações:
   • Nome da organização
   • Nome do ambiente
   • Nome do proxy de API
   • Comando curl completo para reproduzir o erro
2. Se você for um usuário da nuvem privada, forneça as seguintes informações:
   • Mensagem de erro completa observada
   • Nome do ambiente
   • Pacote de proxy de API
   • Registros do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Saída dos seguintes comandos em cada um dos processadores de mensagens.

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

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

3. Detalhes sobre quais seções deste manual você tentou e outros insights que vão nos ajudar a acelerar a resolução do problema.