502 Gateway inválido EOF inesperado

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 502 com a mensagem Bad Gateway como resposta para chamadas de API.

O código de status HTTP 502 significa que o cliente não está recebendo uma resposta válida dos servidores de back-end que deveriam atender à solicitação.

Mensagens de erro

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Causas possíveis

Uma das causas típicas de 502 Bad Gateway Error é o erro Unexpected EOF, que pode ser causado pelos seguintes motivos:

Etapas comuns do diagnóstico

Para diagnosticar o erro, use um dos seguintes métodos:

• Monitoramento de APIs
• Ferramenta Trace
• Registros de acesso do NGINX

Causa: servidor de destino configurado incorretamente

O servidor de destino não está configurado corretamente para oferecer suporte a conexões TLS/SSL.

Diagnóstico

1. Use o API Monitoring, a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha do erro 502.
2. Ative o rastreamento na interface da API afetada.
3. Se o trace da solicitação de API com falha mostrar o seguinte:
   1. O erro 502 Bad Gateway aparece assim que a solicitação de fluxo de destino é iniciada.
   2. O error.class mostra messaging.adaptors.http.UnexpectedEOF.

      Então, é muito provável que esse problema seja causado por uma configuração incorreta do servidor de destino.

4. Receba a definição do servidor de destino usando a chamada de API de gerenciamento do Edge:
   1. Se você for um usuário da nuvem pública, use esta API:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. Se você for um usuário do Cloud privado, use esta API:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      Exemplo de definição de TargetServer com falha:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. A definição de TargetServer ilustrada é um exemplo de uma das configurações incorretas típicas, explicada da seguinte maneira:

   Vamos supor que o servidor de destino mocktarget.apigee.net esteja configurado para aceitar conexões seguras (HTTPS) na porta 443. No entanto, se você analisar a definição do servidor de destino, não haverá outros atributos/flags que indiquem que ele foi criado para conexões seguras. Isso faz com que o Edge trate as solicitações de API enviadas ao servidor de destino específico como solicitações HTTP (não seguras). Assim, o Edge não vai iniciar o processo de handshake SSL com esse servidor de destino.

   Como o servidor de destino está configurado para aceitar apenas solicitações HTTPS (SSL) em 443, ele vai rejeitar a solicitação do Edge ou fechar a conexão. Como resultado, você recebe um erro UnexpectedEOFAtTarget no processador de mensagens. O processador de mensagens vai enviar 502 Bad Gateway como resposta ao cliente.

Resolução

Sempre verifique se o servidor de destino está configurado corretamente de acordo com seus requisitos.

No exemplo ilustrado acima, se você quiser fazer solicitações a um servidor de destino seguro (HTTPS/SSL), inclua os atributos SSLInfo com a flag enabled definida como true. Embora seja permitido adicionar os atributos SSLInfo para um servidor de destino na própria definição do endpoint de destino, é recomendável adicionar os atributos SSLInfo como parte da definição do servidor de destino para evitar confusão.

1. Se o serviço de back-end exigir comunicação SSL unidirecional, faça o seguinte:
   1. É necessário ativar o TLS/SSL na definição TargetServer incluindo os atributos SSLInfo em que a flag enabled está definida como "true", conforme mostrado abaixo:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. Se você quiser validar o certificado do servidor de destino no Edge, também precisará incluir o truststore (que contém o certificado do servidor de destino), conforme mostrado abaixo:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. Se o serviço de back-end exigir comunicação SSL bidirecional, faça o seguinte:
   1. É necessário ter atributos SSLInfo com flags ClientAuthEnabled, Keystore, KeyAlias e Truststore definidas corretamente, conforme mostrado abaixo:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

Referências

Balanceamento de carga entre servidores de back-end

Causa: EOFException do servidor de back-end

O servidor de back-end pode enviar EOF (fim do arquivo) abruptamente.

Diagnóstico

1. Use o API Monitoring, a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha do erro 502.
2. Verifique os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) e pesquise para ver se você tem eof unexpected para a API específica ou se tem o messageid exclusivo para a solicitação de API. Se tiver, pesquise.

   Exemplo de stack trace de exceção do registro do processador de mensagens

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   No exemplo acima, é possível ver que o erro java.io.EOFException: eof unexpected ocorreu enquanto o processador de mensagens tentava ler uma resposta do servidor de back-end. Essa exceção indica o fim do arquivo (EOF) ou que o fim do fluxo foi atingido inesperadamente.

   Ou seja, o processador de mensagens enviou a solicitação de API ao servidor de back-end e estava aguardando ou lendo a resposta. No entanto, o servidor de back-end encerrou a conexão abruptamente antes que o processador de mensagens recebesse ou pudesse ler a resposta completa.

3. Verifique os registros do servidor de back-end para saber se há erros ou informações que possam ter levado o servidor de back-end a encerrar a conexão abruptamente. Se você encontrar erros ou informações, acesse Resolução e corrija o problema adequadamente no servidor de back-end.
4. Se você não encontrar erros ou informações no servidor de back-end, colete a saída tcpdump nos processadores de mensagens:
   1. Se o host do servidor de back-end tiver um único endereço IP, use o seguinte comando:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. Se o host do servidor de back-end tiver vários endereços IP, use o seguinte comando:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      Normalmente, esse erro ocorre porque o servidor de back-end responde com [FIN,ACK] assim que o processador de mensagens envia a solicitação ao servidor de back-end.

5. Confira o exemplo tcpdump a seguir.

   Amostra tcpdump coletada quando 502 Bad Gateway Error (UnexpectedEOFAtTarget) ocorreu

   

6. Na saída do TCPDump, observe a seguinte sequência de eventos:
   1. No pacote 985, o processador de mensagens envia a solicitação de API ao servidor de back-end.
   2. No pacote 986, o servidor de back-end responde imediatamente com [FIN,ACK].
   3. No pacote 987, o Processador de mensagens responde com [FIN,ACK] ao servidor de back-end.
   4. Eventualmente, as conexões são fechadas com [ACK] e [RST] dos dois lados.
   5. Como o servidor de back-end envia [FIN,ACK], você recebe a exceção java.io.EOFException: eof unexpected no processador de mensagens.
7. Isso pode acontecer se houver um problema de rede no servidor de back-end. Peça à equipe de operações de rede para investigar mais esse problema.

Resolução

Corrija o problema no servidor de back-end adequadamente.

Se o problema persistir e você precisar de ajuda para resolver problemas com 502 Bad Gateway Error ou suspeitar que é um problema no Edge, entre em contato com o suporte do Apigee Edge.

Causa: tempo limite de manutenção ativa configurado incorretamente

Antes de diagnosticar se essa é a causa dos erros 502, leia os conceitos a seguir.

Conexões persistentes na Apigee

Por padrão, a Apigee (e de acordo com o padrão HTTP/1.1) usa conexões persistentes ao se comunicar com o servidor de back-end de destino. As conexões persistentes podem aumentar o desempenho permitindo que uma conexão TCP e (se aplicável) TLS/SSL já estabelecida seja reutilizada, o que reduz as sobrecargas de latência. A duração em que uma conexão precisa ser mantida é controlada por uma propriedade tempo limite de keep-alive (keepalive.timeout.millis).

O servidor de back-end e o processador de mensagens da Apigee usam tempos limite de atividade em tempo real para manter conexões abertas entre si. Quando nenhum dado é recebido durante o tempo limite de manutenção da conexão ativa, o servidor de back-end ou o processador de mensagens podem fechar a conexão com o outro.

Por padrão, os proxies de API implantados em um processador de mensagens na Apigee têm um tempo limite de manutenção de atividade definido como 60s, a menos que seja substituído. Quando nenhum dado for recebido por 60s, a Apigee vai fechar a conexão com o servidor de back-end. O servidor de back-end também vai manter um tempo limite de keep-alive, e quando ele expirar, o servidor de back-end vai fechar a conexão com o processador de mensagens.

Implicação da configuração incorreta do tempo limite de manutenção da atividade

Se a Apigee ou o servidor de back-end estiverem configurados com tempos limite de manutenção ativos incorretos, isso resultará em uma condição de disputa que fará com que o servidor de back-end envie um End Of File (FIN) inesperado em resposta a uma solicitação de um recurso.

Por exemplo, se o tempo limite de atividade for configurado no proxy de API ou no processador de mensagens com um valor maior ou igual ao tempo limite do servidor de back-end upstream, poderá ocorrer a seguinte condição de disputa. Ou seja, se o processador de mensagens não receber dados até muito perto do limite de tempo limite de manutenção da conexão do servidor de back-end, uma solicitação será enviada ao servidor de back-end usando a conexão atual. Isso pode resultar em 502 Bad Gateway devido a um erro de EOF inesperado, conforme explicado abaixo:

1. Digamos que o tempo limite de sinal de atividade definido no processador de mensagens e no servidor de back-end seja de 60 segundos, e nenhuma nova solicitação tenha sido feita até 59 segundos após a solicitação anterior ser atendida pelo processador de mensagens específico.
2. O processador de mensagens continua e processa a solicitação recebida no 59º segundo usando a conexão atual (já que o tempo limite de keep-alive ainda não expirou) e envia a solicitação ao servidor de back-end.
3. No entanto, antes que a solicitação chegue ao servidor de back-end, o limite de tempo limite de manutenção de atividade já foi excedido no servidor de back-end.
4. A solicitação de um recurso pelo processador de mensagens está em andamento, mas o servidor de back-end tenta fechar a conexão enviando um pacote FIN ao processador de mensagens.
5. Enquanto o processador de mensagens aguarda o recebimento dos dados, ele recebe o FIN inesperado, e a conexão é encerrada.
6. Isso resulta em um Unexpected EOF e, posteriormente, um 502 é retornado ao cliente pelo processador de mensagens.

Nesse caso, observamos que o erro 502 ocorreu porque o mesmo valor de tempo limite de manutenção ativa de 60 segundos foi configurado no processador de mensagens e no servidor de back-end. Da mesma forma, esse problema também pode ocorrer se um valor maior for configurado para o tempo limite de manutenção da conexão ativa no processador de mensagens do que no servidor de back-end.

Diagnóstico

1. Se você for um usuário da nuvem pública:
   1. Use o API Monitoring ou a ferramenta Trace (conforme explicado em Etapas comuns de diagnóstico) e verifique se você tem as seguintes configurações:
      • Código da falha:messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Origem da falha:target
   2. Acesse Como usar o tcpdump para mais detalhes.
2. Se você for um usuário da nuvem privada:
   1. Use a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código e a origem da falha do erro 502.
   2. Procure o ID da mensagem no registro do processador de mensagens
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Você vai encontrar o java.io.EOFEXception: eof unexpected, conforme mostrado abaixo:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. O erro java.io.EOFException: eof unexpected indica que o Processador de mensagens recebeu um EOF enquanto ainda aguardava a leitura de uma resposta do servidor de back-end.
   5. O atributo useCount=7 na mensagem de erro acima indica que o processador de mensagens reutilizou essa conexão cerca de sete vezes, e o atributo bytesWritten=159 indica que o processador de mensagens enviou o payload da solicitação de 159 bytes para o servidor de back-end. No entanto, ele recebeu zero bytes de volta quando o EOF inesperado ocorreu.

   6. Isso mostra que o processador de mensagens reutilizou a mesma conexão várias vezes, e, nessa ocasião, ele enviou dados, mas logo depois recebeu um EOF antes que qualquer dado fosse recebido. Isso significa que há uma alta probabilidade de que o tempo limite de atividade do servidor de back-end seja menor ou igual ao definido no proxy de API.

      Você pode investigar mais a fundo com a ajuda de tcpdump, conforme explicado abaixo.

Como usar o tcpdump

1. Capture um tcpdump no servidor de back-end com o seguinte comando:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Analise o tcpdump capturado:

   Confira um exemplo de saída do tcpdump:

   

   No exemplo tcpdump acima, você pode ver o seguinte:

   1. No pacote 5992,, o servidor de back-end recebeu uma solicitação GET.
   2. No pacote 6064, ele responde com 200 OK.
   3. No pacote 6084, o servidor de back-end recebeu outra solicitação GET.
   4. No pacote 6154, ele responde com 200 OK.
   5. No pacote 6228, o servidor de back-end recebeu uma terceira solicitação GET.
   6. Desta vez, o servidor de back-end retorna um FIN, ACK ao processador de mensagens (pacote 6285), iniciando o encerramento da conexão.

   A mesma conexão foi reutilizada duas vezes neste exemplo, mas na terceira solicitação, o servidor de back-end inicia um encerramento da conexão enquanto o processador de mensagens aguarda os dados do servidor de back-end. Isso sugere que o tempo limite de atividade do servidor de back-end provavelmente é menor ou igual ao valor definido no proxy de API. Para validar isso, consulte Comparar o tempo limite de keep-alive no Apigee e no servidor de back-end.

Comparar o tempo limite de manutenção ativa na Apigee e no servidor de back-end

1. Por padrão, a Apigee usa um valor de 60 segundos para a propriedade de tempo limite de manutenção da conexão.

2. No entanto, é possível que você tenha substituído o valor padrão no proxy de API. Para verificar isso, confira a definição específica de TargetEndpoint no proxy de API com falha que está gerando erros 502.

   Exemplo de configuração do TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   No exemplo acima, a propriedade de tempo limite de keep-alive é substituída por um valor de 30 segundos (30000 milissegundos).

3. Em seguida, verifique a propriedade de tempo limite de manutenção ativa configurada no servidor de back-end. Suponha que o servidor de back-end esteja configurado com um valor de 25 seconds.
4. Se você determinar que o valor da propriedade de tempo limite de manutenção ativa na Apigee é maior do que o valor da propriedade de tempo limite de manutenção ativa no servidor de back-end, como no exemplo acima, essa é a causa dos erros 502.

Resolução

Verifique se a propriedade de tempo limite de sinal de atividade é sempre menor na Apigee (no proxy de API e no componente Processador de mensagens) em comparação com o servidor de back-end.

1. Determine o valor definido para o tempo limite de manutenção da conexão ativa no servidor de back-end.
2. Configure um valor adequado para a propriedade de tempo limite de sinal de atividade no proxy de API ou processador de mensagens, de modo que a propriedade de tempo limite de sinal de atividade seja menor que o valor definido no servidor de back-end, usando as etapas descritas em Configurar o tempo limite de sinal de atividade nos processadores de mensagens.

Se o problema persistir, acesse Precisa de informações de diagnóstico.

Prática recomendada

É altamente recomendável que os componentes downstream sempre tenham um limite de tempo limite de manutenção ativo menor do que o configurado nos servidores upstream para evitar esse tipo de condição de disputa e erros 502. Cada salto downstream precisa ser menor que cada salto upstream. No Apigee Edge, é recomendável usar as seguintes diretrizes:

1. O tempo limite de manutenção da conexão do cliente precisa ser menor que o do roteador de borda.
2. O tempo limite de manutenção da atividade do roteador do Edge precisa ser menor que o do processador de mensagens.
3. O tempo limite de manutenção da atividade do processador de mensagens precisa ser menor que o do servidor de destino.
4. Se houver outros saltos antes ou depois da Apigee, a mesma regra será aplicada. Sempre deixe a responsabilidade de fechar a conexão com o upstream para o cliente downstream.

É 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 e entre em contato com o Suporte do Apigee Edge.

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 502
• Arquivo de rastreamento que contém as solicitações com erro 502 Bad Gateway - Unexpected EOF
• Se os erros 502 não estiverem ocorrendo no momento, informe o período com as informações de fuso horário em que eles 502 ocorreram no passado.

Se você for um usuário da nuvem privada, forneça as seguintes informações:

• Mensagem de erro completa observada para as solicitações com falha
• Organização, nome do ambiente e nome do proxy de API para os quais você está observando erros de 502
• Pacote de proxy de API
• Arquivo de rastreamento que contém as solicitações com erro 502 Bad Gateway - Unexpected EOF
• Registros de acesso do NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Registros do processador de mensagens
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• O período com as informações de fuso horário em que os erros de 502 ocorreram
• Tcpdumps coletadas nos processadores de mensagens ou no servidor de back-end, ou ambos quando o erro ocorreu