Esta página foi traduzida pela API Cloud Translation.

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

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Sintoma

O aplicativo cliente recebe um código de status HTTP de 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ê receberá o seguinte código de status HTTP:

HTTP/1.1 404 Not Found

Você também vai notar 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 conseguiu encontrar o proxy de API para o host virtual default e o caminho /oauth2/token.

Causas possíveis

Algumas das possíveis causas para esse erro estão listadas abaixo:

Causa	Descrição	Instruções de solução de problemas aplicáveis para
Proxy de API não associado ao host virtual específico	O proxy de API específico não está configurado para aceitar solicitações no host virtual especificado na mensagem de erro.	Usuários de nuvens públicas e privadas de borda
Host virtual removido em uma revisão recém-implantada do proxy de API	Remover o host virtual da revisão recém-implantada enquanto o cliente ainda está usando o host virtual específico pode causar esse problema.	Usuários de nuvens públicas e privadas de borda
Caminho não associado a nenhum proxy de API	O proxy de API específico não está configurado para aceitar solicitações no caminho especificado na mensagem de erro.	Usuários de nuvens públicas e privadas de borda
Proxy de API não implantado em um ambiente	O proxy de API específico não é implantado no ambiente em que você está tentando fazer as solicitações de API.	Usuários de nuvens públicas e privadas de borda
Ambiente não carregado no processador de mensagens	O ambiente específico (em que você está tentando fazer as solicitações de API) não foi carregado nos processadores de mensagens devido a um erro.	Usuários da nuvem privada do Edge
O proxy de API não foi implantado em um ou mais processadores de mensagens	O proxy de API pode não ser implantado em um ou mais processadores de mensagens devido à ausência de notificação de eventos durante a implantação.	Usuários da nuvem privada do Edge

Etapas comuns do diagnóstico

Os registros do NGINX e do Processador de mensagens serão úteis na solução de problemas do erro 404. Siga estas etapas para verificar os registros:

Acesse os registros do NGINX usando o seguinte comando:

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

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 dos registros.

Verifique os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ver se você tem messaging.adaptors.http.flow.ApplicationNotFound para a API específica ou se tem o ID da 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 a seguir:

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

Observação:o url e o host acima podem variar dependendo do proxy de API em que você está tendo problemas.

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

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

Diagnóstico

Verifique a configuração do Endpoint de proxy para o proxy de API e veja se ele está configurado para aceitar as solicitações para o host virtual especificado no erro. Isso é indicado pelo elemento VirtualHost. Veja um exemplo de configuração de ProxyEndpoint para entender isso.
Exemplo de configuração de endpoint do proxy mostrando que o proxy de API aceita solicitações em um host virtual seguro

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

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

Você faz uma solicitação de API para default VirtualHost usando o URL http://myorg-prod.apigee.net/weather

Como ProxyEndpoint não tem default VirtualHost, como 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"}}}

Consulte a seção Resolução abaixo para resolver esse problema.
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

Adicione a VirtualHost ausente à configuração ProxyEndpoint para resolver o problema. No exemplo mostrado acima, é possível adicionar o VirtualHost padrão à configuração ProxyEndpoint da seguinte maneira:
```
<VirtualHost>default</VirtualHost>
```
Exemplo de configuração do endpoint de proxy mostrando o padrão> VirtualHost> sendo adicionado
Como alternativa, no exemplo mencionado acima, se você pretende usar apenas o secure VirtualHost para este proxy de API específico, faça as solicitações de API somente para o secure VirtualHost usando o protocolo HTTPS:
```
https://myorg-prod.apigee.net/weather
```

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

Se uma nova revisão de um proxy de API for implantada após a remoção de um host virtual específico (que fazia parte da revisão implantada anteriormente), que ainda estiver sendo usado pelos clientes para fazer solicitações de API, isso poderá causar esse problema.

Diagnóstico

Verifique a configuração do Endpoint de proxy do proxy de API para ver se ele está configurado para aceitar as solicitações para o host virtual especificado no erro. Isso é indicado pelo elemento VirtualHost na configuração ProxyEndpoint.
Se o host virtual especificado no erro não existir na configuração do ProxyEndpoint, execute as etapas a seguir. Caso contrário, vá para a próxima causa: Caminho não associado a nenhum proxy de API.
Compare a configuração ProxyEndpoint da revisão implantada anteriormente com a revisão implantada atualmente.
1. Por exemplo, digamos que a revisão implantada anteriormente seja 5 e que a atualmente implantada seja 6:
  - Hosts virtuais configurados no endpoint do proxy na revisão 5
  - Hosts virtuais configurados no endpoint do proxy na revisão 6
2. No exemplo acima, VirtualHost vh1 existia em revision 5,, mas foi removido em revision 6 e substituído por VirtualHost secure.
3. Se você ou seus clientes estiverem fazendo as solicitações a esse proxy de API usando VirtualHost vh1 (que fazia parte de revision 5), você 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"}}}
```
Verifique se a alteração do host virtual foi feita intencionalmente ou não intencional na revisão implantada no momento e tome as medidas apropriadas, conforme explicado na seção Resolução.

Resolução

Se você identificar que os hosts virtuais foram removidos em uma nova revisão, isso pode ter sido intencional ou por acidente. Em cada caso, siga as etapas de resolução/recomendadas abaixo para resolver a situação.

Cenário 1: mudança intencional

Se a remoção do host virtual for intencional, você poderá escolher uma das seguintes opções, sendo que a primeira é a abordagem recomendada:

Crie um novo proxy com um caminho base diferente e use um host virtual diferente (que não exista na revisão implantada anteriormente).
Se você quiser continuar usando o proxy de API atual, mas usar um host virtual diferente, é melhor manter o host virtual atual e adicionar outro.

Isso garante que os usuários desse proxy de API não sejam afetados pela mudança.
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 alteração 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 a esse proxy de API. Portanto, eles não serão afetados pela mudança.

Cenário n.o 2: mudança involuntária

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

Atualize a configuração ProxyEndpoint na revisão implantada atualmente para usar os mesmos hosts virtuais que foram utilizados na revisão implantada anteriormente. No exemplo acima, altere a seguinte seção de:

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

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

Implante a revisão novamente.

Práticas recomendadas

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

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

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

Diagnóstico

Observe a configuração ProxyEndpoint do proxy de API específico que será usado para fazer as solicitações de API.
Verifique se o proxy de API está configurado para aceitar as solicitações para o caminho específico indicado na mensagem de erro. Para isso, execute as etapas do Cenário 1 e do Cenário 2.

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

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 basepath, essa pode ser a causa do erro.
Vamos dar um exemplo para explicar isso:

O basepath do proxy de API pretendido é /weather
O URL da solicitação de API é https://myorg-prod.apigee.net/climate. Isso significa que o caminho usado no URL da solicitação da API é /climate..

Nesse exemplo, path não é o mesmo que basepath e não começa com basepath. Portanto, você recebe o seguinte erro:

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

Resolução

Verifique se o path usado no URL de solicitação de API é o mesmo que o basepath do proxy de API específico.
No exemplo acima, o URL da solicitação de API é:
```
{
https://myorg-prod.apigee.net/weather
```

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

Se o path usado no URL de solicitação de API começar com basepath, é possível que a path suffix (a parte que vem depois do basepath) indicada na mensagem de erro não corresponda a nenhum dos fluxos condicionais, o que pode causar o erro 404.
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 da solicitação da API é /weather/Delhi..
Neste exemplo, a path começa com o basepath /weather. Além disso, ela tem um path suffix de /Delhi.
Agora, verifique se há fluxos condicionais em ProxyEndpoint.
Se não houver fluxos condicionais ou alguns fluxos não condicionais, siga para a próxima causa: proxy de API não implantado em um ambiente.
Se 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 caminho base).
2. E se o path suffix especificado no URL de solicitação de API não corresponder a nenhuma das condições, esse será o motivo do erro.
Digamos que temos dois fluxos em 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 mostrado acima, temos dois fluxos condicionais, um que corresponde a proxy.pathsuffix (caminho após o caminho base) a /Bangalore e o outro corresponde a /Chennai. Mas não há nenhuma que corresponda a /Delhi, que é o path suffix transmitido no URL de solicitação de API.
2. Essa é a causa do erro 404. Portanto, você receberia 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

Verifique se path suffix corresponde a pelo menos um dos fluxos condicionais no endpoint do proxy.
No exemplo acima, é possível usar as seguintes abordagens para resolver o erro:
1. Se você quiser executar qualquer 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 uma /proxy.pathsuffix genérica. Ou seja, ele permitiria qualquer caminho depois de 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, siga para a próxima causa: proxy de API não implantado em um ambiente.

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

Diagnóstico

Determine o ambiente para o qual existe o alias do host usado no seu URL de solicitação de API. Para isso, verifique os detalhes de todos os hosts virtuais em cada um dos ambientes da sua organização na IU 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 está configurado como parte de um dos hosts virtuais no ambiente prod da sua organização.
Verifique se o proxy de API específico está implantado no ambiente específico determinado na etapa 1 acima.
Se o proxy de API não for implantado no ambiente específico, essa será a causa do erro 404.
1. Portanto, no exemplo usado na etapa 1 acima, digamos que o proxy de API não esteja implantado no ambiente prod, então essa é a causa do erro.
2. Vá para a seção Resolução abaixo.
Se o proxy de API estiver implantado no ambiente específico, siga para a próxima causa: Ambiente não 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: ambiente não carregado nos processadores de mensagens

Diagnóstico

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
```
Se o ambiente específico estiver listado como parte do comando acima, vá para a próxima causa: proxy de API não implantado em um ou mais processadores de mensagens.
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 ver se há erros durante o carregamento de ambientes.
Pode haver muitos erros diferentes que podem levar à falha de carregamento de um ambiente no processador de mensagens. A resolução depende do erro que ocorreu.

Resolução

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

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

Erro 1: java.security.KeyStoreException: não é possível substituir o próprio 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

Erro 2: java.security.KeyStoreException: não é possível substituir a chave 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

Consulte os detalhes do keystore/truststore especificados na mensagem de erro mostrada na etapa anterior usando a seguinte chamada de API de gerenciamento:

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"
}

O exemplo de saída mostra que há dois certificados e uma chave no myTruststore do truststore. Em geral, o truststore não contém uma chave. Caso isso aconteça, é melhor ter apenas um certificado e uma chave.

Acesse 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>

Verifique a data de validade de cada um dos certificados e determine qual deles expirou/antigo.
Exclua o certificado expirado ou indesejado do truststore myTruststore.

Se o problema persistir ou se você encontrar algum erro diferente dos mencionados na etapa 1 acima, acesse É necessário coletar informações de diagnóstico.

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

O proxy de API não pode ser 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 IU do Edge.

Diagnóstico

Faça login em cada um dos processadores de mensagens e verifique se a revisão específica do proxy de API foi implantada ou não usando o seguinte comando:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
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.
Repita as etapas 1 e 2 para todos os processadores de mensagens.
Se a revisão específica do proxy de API estiver implantada em todos os processadores de mensagens, essa não será a causa do problema. Acesse Precisamos coletar 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 o monitoramento de APIs

Com o Monitoramento de API, é possível isolar áreas problemáticas para diagnosticar erros, desempenho e latência rapidamente, além da origem, como apps de desenvolvedores, proxies de API, destinos de back-end ou a plataforma de API.

Para esse problema, acesse a página API Monitoring > Investigar e escolha a data, o proxy e assim por diante. Você verá os seguintes detalhes:

Código de falha e código de status na interface

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

Além disso, você pode clicar em Ver registros, como mostrado na captura de tela acima, e conferir mais detalhes.

ver registros

Consulte um exemplo de cenário que demonstra como solucionar problemas de 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, é possível configurar um alerta para ser notificado quando o número de códigos de status 404 exceder um limite específico.

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

Se o problema persistir mesmo depois de seguir as instruções acima, colete as informações de diagnóstico abaixo. Entre em contato com o suporte do Apigee Edge e compartilhe essas informações.

Se você é usuário da nuvem pública, forneça as seguintes informações:
- Nome da organização
- Nome do ambiente
- Nome do proxy da API
- Concluir o comando curl para reproduzir o erro
Se você é 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 comandos a seguir em cada um dos processadores de mensagens.
Detalhes sobre quais seções deste manual você experimentou e quaisquer outros insights que possam nos ajudar a acelerar a resolução desse problema.