502 Erro de tempo limite de gateway inválido

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

Sintoma

O aplicativo cliente recebe um erro 502 Bad Gateway. O processador de mensagens retorna esse erro ao aplicativo cliente quando não recebe uma resposta de um servidor de back-end.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 502 Bad Gateway

Além disso, você pode observar a seguinte mensagem de erro:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Possível causa

A possível causa desse problema está listada na tabela a seguir:

Causa Descrição Etapas de solução de problemas podem ser realizadas por
Tempo limite do handshake de TLS/SSL Ocorre um tempo limite durante o handshake de TLS/SSL entre o processador de mensagens e o servidor de back-end. Usuários da nuvem pública e privada do Edge

Causa: tempo limite do handshake de TLS/SSL

No Apigee Edge, é possível configurar uma conexão TLS/SSL com o servidor de back-end para ativar a comunicação TLS entre o processador de mensagens do Edge e um servidor de back-end.

Um handshake de TLS/SSL envolve várias etapas. Esse erro geralmente ocorre quando o handshake de TLS/SSL entre o processador de mensagens e um servidor de back-end atinge o tempo limite.

Diagnóstico

Esta seção explica como diagnosticar corretamente um tempo limite de handshake de TLS/SSL. As instruções para a nuvem pública e privada do Edge estão listadas.

Investigar a saída da sessão de trace

As etapas a seguir explicam como fazer um diagnóstico preliminar do problema usando a ferramenta de trace do Apigee Edge.

  1. Na interface do Edge, ative uma sessão de trace para o proxy de API afetado.

  2. Se o trace da solicitação de API com falha mostrar o seguinte, é provável que tenha ocorrido um erro de tempo limite do handshake de TLS/SSL. A causa provável do erro é que o firewall do servidor de back-end está bloqueando o tráfego da Apigee.

    1. Determine se o erro 502 Bad Gateway ocorre após 55 segundos, que é o período de tempo limite padrão definido no processador de mensagens. Se você notar que o erro ocorreu após 55 segundos, isso indica que um tempo limite foi a causa provável do problema.
    2. Determine se o erro mostra a falha: messaging.adaptors.http.BadGateway. Novamente, esse erro geralmente indica que ocorreu um tempo limite.

    3. Se você estiver na nuvem privada do Edge, anote o valor do X-Apigee.Message-ID campo na saída do trace, conforme mostrado abaixo. Um usuário da nuvem privada pode usar esse valor de ID para fazer mais solução de problemas, conforme explicado mais adiante.

      1. Clique no ícone Dados de análise registrados no caminho do trace:

      2. Role para baixo e anote o valor do campo chamado X-Apigee.Message-ID.

Para confirmar se o tempo limite do handshake de TLS/SSL foi a causa do erro, siga as etapas nas seções a seguir, dependendo se você está na nuvem pública ou privada.

Outras etapas de diagnóstico apenas para usuários da nuvem privada do Edge

Se você estiver na nuvem privada do Apigee Edge, siga as etapas abaixo para verificar a causa do erro de handshake. Nesta etapa, você inspeciona o arquivo de registro do processador de mensagens para encontrar informações relevantes. Se você estiver na nuvem pública do Edge, pule esta seção e acesse Outras etapas de diagnóstico para usuários da nuvem pública e privada.

  1. Verifique se é possível se conectar diretamente ao servidor de back-end específico de cada um dos processadores de mensagens usando o comando telnet:

    1. Se o servidor de back-end for resolvido em um único endereço IP, use este comando:

      telnet BackendServer-IPaddress 443

    2. Se o servidor de back-end for resolvido em vários endereços IP, use o nome do host do servidor de back-end no comando telnet, conforme mostrado abaixo:

      telnet BackendServer-HostName 443

    Se você conseguir se conectar ao servidor de back-end sem erros, siga para a próxima etapa.

    Se o comando telnet falhar, trabalhe com sua equipe de rede para verificar a conectividade entre o processador de mensagens e o servidor de back-end.

  2. Verifique o arquivo de registro do processador de mensagens em busca de evidências de uma falha de handshake. Abra o arquivo:

    /opt/apigee/var/log/edge-message-processor/system.log

    e pesquise o ID exclusivo da mensagem (o valor de X-Apigee.Message-ID encontrado no arquivo de trace). Determine se você vê uma mensagem de erro de handshake associada ao ID da mensagem, conforme mostrado abaixo:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

Se você encontrar esse erro no arquivo de registro do processador de mensagens, continue a investigação. Acesse Outras etapas de diagnóstico para usuários da nuvem pública e privada do Edge.

Se você não encontrar a mensagem de handshake no arquivo de registro, acesse É necessário coletar informações de diagnóstico

Outras etapas de diagnóstico para usuários da nuvem pública e privada do Edge

Para identificar melhor o problema, use a ferramenta tcpdump para analisar pacotes TCP/IP e confirmar se ocorreu um tempo limite durante o handshake de TLS/SSL.

  1. Se você for um usuário da nuvem privada, poderá capturar os pacotes TCP/IP no servidor de back-end ou no processador de mensagens. De preferência, capture-os no servidor de back-end, porque os pacotes são descriptografados nele.
  2. Se você for um usuário da nuvem pública, não terá acesso ao processador de mensagens. No entanto, a captura dos pacotes TCP/IP no servidor de back-end pode ajudar a identificar um problema.

  3. Depois de decidir onde capturar os pacotes TCP/IP, use o comando tcpdump a seguir para capturar pacotes TCP/IP.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Se você estiver usando os pacotes TCP/IP no servidor de back-end, use o endereço IP público do processador de mensagens no comando tcpdump. Para receber ajuda sobre como usar o comando para examinar o tráfego do servidor de back-end, consulte tcpdump.

    • Se você estiver usando os pacotes TCP/IP no processador de mensagens, use o endereço IP público do servidor de back-end no comando tcpdump. Para receber ajuda sobre como usar o comando para examinar o tráfego do processador de mensagens, consulte tcpdump.

    • Se houver vários endereços IP para o servidor de back-end/processador de mensagens, será necessário tentar outro uso do comando tcpdump. Consulte tcpdump para mais informações sobre essa ferramenta e outras variantes desse comando.

  4. Analise os pacotes TCP/IP usando a ferramenta Wireshark ou uma ferramenta semelhante. A captura de tela a seguir mostra pacotes TCP/IP no Wireshark.

  5. Observe na saída do Wireshark que o handshake TCP de três vias é concluído com êxito nos três primeiros pacotes.

  6. O processador de mensagens envia a mensagem "Client Hello" no pacote nº 4.

  7. Como não há confirmação do servidor de back-end, o processador de mensagens retransmite a mensagem "Client Hello" várias vezes nos pacotes 5, 6 e 7 após aguardar um intervalo de tempo predefinido.

  8. Quando o processador de mensagens não recebe nenhuma confirmação após três novas tentativas, ele envia a mensagem FIN, ACK para o servidor de back-end para indicar que está fechando a conexão.

  9. Como mostrado no exemplo de sessão do Wireshark, a conexão com o back-end é bem-sucedida (etapa 1). No entanto, o handshake SSL atingiu o tempo limite porque o servidor de back-end nunca respondeu.

Se você seguiu as etapas de solução de problemas neste manual e determinou que um tempo limite causou o erro de handshake de TLS/SSL, acesse a seção Resolução.

Como usar o monitoramento de APIs para identificar um problema

O monitoramento de APIs permite isolar as áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem delas, como aplicativos de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Siga um cenário de exemplo que demonstra como solucionar problemas 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, você pode configurar um alerta para ser notificado quando o número de falhas messaging.adaptors.http.BadGateway exceder um limite específico.

Resolução

Normalmente, os tempos limite de handshake SSL ocorrem devido a restrições de firewall no servidor de back-end que bloqueiam o tráfego do Apigee Edge. Se você seguiu as etapas de diagnóstico e determinou que a causa do erro de handshake é um tempo limite, é necessário envolver sua equipe de rede para identificar a causa e corrigir as restrições de firewall.

As restrições de firewall podem ser impostas em diferentes camadas de rede. É importante garantir que as restrições em todas as camadas de rede sejam removidas em relação aos IPs do processador de mensagens para garantir um fluxo de tráfego suave entre o Apigee Edge e o servidor de back-end.

Se não houver restrições de firewall e/ou o problema persistir, acesse É necessário coletar informações de diagnóstico.

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

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

  1. Se você for um usuário da nuvem pública, forneça as seguintes informações:
    1. Nome da organização
    2. Nome do ambiente
    3. Nome do proxy de API
    4. Comando curl completo para reproduzir o erro
    5. Arquivo de trace mostrando o erro
    6. Pacotes TCP/IP capturados no servidor de back-end
  2. Se você for um usuário da nuvem privada, forneça as seguintes informações:
    1. Mensagem de erro completa observada
    2. Pacote de proxy de API
    3. Arquivo de trace mostrando o erro
    4. Registros do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Pacotes TCP/IP capturados no servidor de back-end ou no processador de mensagens.
  3. Detalhes sobre quais seções deste manual você tentou e outras informações que nos ajudarão a acelerar a resolução desse problema.