502 Gateway inválido EOF inesperado

Você está vendo a documentação do Apigee Edge.
Veja a documentação da Apigee X.

Sintoma

O aplicativo cliente recebe um código de status HTTP de 502 com a mensagem Bad Gateway como uma 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 precisam 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ê poderá ver a seguinte mensagem de erro:

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

Causas possíveis

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

Causa	Detalhes	Etapas indicadas para
Servidor de destino configurado incorretamente	O servidor de destino não está configurado corretamente para aceitar conexões TLS/SSL.	Usuários de nuvem pública e privada do Edge
EOFException do servidor de back-end	O servidor de back-end pode enviar EOF abruptamente.	Somente usuários da nuvem privada do Edge
Tempo limite do sinal de atividade configurado incorretamente	Mantenha os tempos limite configurados incorretamente na Apigee e no servidor de back-end.	Usuários de nuvem pública e privada do Edge

Etapas comuns do diagnóstico

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

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

Causa: Servidor de destino configurado incorretamente

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

Diagnóstico

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

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

4. Veja a definição do servidor de destino usando a chamada da API Edge Management:
   1. Se você é um usuário de 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ê é um usuário de nuvem privada, 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 ilustrada de TargetServer é um exemplo para uma das configurações incorretas típicas, que é 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ê observar a definição do servidor de destino, não haverá outros atributos/sinalizações que indiquem que ele se destina a conexões seguras. Isso faz com que o Edge trate as solicitações de API direcionadas para o servidor de destino específico como solicitações HTTP (não seguras). Portanto, o Edge não iniciará o processo de handshake de SSL com esse servidor de destino.

   Como o servidor de destino está configurado para aceitar apenas solicitações HTTPS (SSL) em 443, ele 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 enviará 502 Bad Gateway como uma resposta ao cliente.

Resolução

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

Para o exemplo ilustrado acima, se você quiser fazer solicitações para um servidor de destino seguro (HTTPS/SSL), será necessário incluir os atributos SSLInfo com a sinalização enabled definida como true. Embora seja possível adicionar os atributos SSLInfo para um servidor de destino na 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 de TargetServer incluindo os atributos SSLInfo, em que a sinalização enabled está definida como verdadeira, como 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 precisaremos 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:
   1. Você precisa ter atributos SSLInfo com as sinalizações ClientAuthEnabled, Keystore, KeyAlias e Truststore definidas corretamente, como 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 (End of File) abruptamente.

Diagnóstico

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

   Exemplo de rastreamento de pilha 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, você pode ver que o erro java.io.EOFException: eof unexpected ocorreu enquanto o Processador de mensagens está tentando ler uma resposta do servidor de back-end. Essa exceção indica que o fim do arquivo (EOF) ou que o fim do stream foi atingido inesperadamente.

   Ou seja, o processador de mensagens enviou a solicitação de API para o servidor de back-end e estava aguardando ou lendo a resposta. No entanto, o servidor de back-end encerrou a conexão abruptamente antes do Processador de mensagens receber a resposta ou podia ler a resposta completa.

3. Verifique os registros do servidor de back-end e veja se há erros ou informações que possam ter levado o servidor a encerrar a conexão abruptamente. Se você encontrar erros/informações, acesse a Resolução e corrija o problema no servidor de back-end.
4. Se você não encontrar erros ou informações no seu servidor de back-end, colete a saída do 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 é causado 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. Considere o exemplo tcpdump a seguir.

   Exemplo de tcpdump usado quando 502 Bad Gateway Error (UnexpectedEOFAtTarget) ocorreu

   

6. Na saída TCPDump, você percebe a seguinte sequência de eventos:
   1. No pacote 985, o processador de mensagens envia a solicitação de API para o 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. Por fim, 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. Envolva sua equipe de operações de rede para investigar o problema mais a fundo.

Resolução

Corrija o problema no servidor de back-end.

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

Causa: tempo limite do sinal de atividade configurado incorretamente

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

Conexões permanentes na Apigee

Por padrão, a Apigee (e após o padrão HTTP/1.1) usa conexões permanentes ao se comunicar com o servidor de back-end de destino. As conexões permanentes podem melhorar o desempenho, permitindo que uma conexão TCP/SSL já estabelecida e, se aplicável, seja reutilizada, o que reduz as sobrecargas de latência. O período em que uma conexão precisa ser mantida é controlado por uma propriedade keep alive timeout (keepalive.timeout.millis).

Tanto o servidor de back-end quanto o Processador de mensagens da Apigee usam tempos limite ativos para manter as conexões abertas entre si. Quando nenhum dado é recebido dentro do tempo limite do sinal de atividade, o servidor de back-end ou o processador de mensagens podem fechar a conexão com o outro.

Os proxies de API implantados em um processador de mensagens na Apigee, por padrão, têm um tempo limite de sinal de atividade definido como 60s, a menos que sejam modificados. Depois que nenhum dado for recebido para 60s, a Apigee fechará a conexão com o servidor de back-end. O servidor de back-end também manterá um tempo limite de sinal de atividade e, quando isso expirar, o servidor de back-end fechará a conexão com o processador de mensagens.

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

Se a Apigee ou o servidor de back-end estiver configurado com tempos limite de sinal de atividade incorretos, isso resultará em uma 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 sinal de atividade estiver 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, a seguinte condição de corrida pode ocorrer. Ou seja, se o processador de mensagens não receber nenhum dado até que esteja muito próximo do limite do servidor de back-end, ele atingirá o tempo limite, então uma solicitação será enviada e enviada ao servidor de back-end usando a conexão atual. Isso pode levar a 502 Bad Gateway devido a um erro inesperado de EOF, 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 chegado até 59 segundos depois que a solicitação anterior foi veiculada pelo processador de mensagens específico.
2. O Processador de mensagens avança e processa a solicitação que chegou no 59o segundo usando a conexão existente (porque o tempo limite do sinal de atividade ainda não expirou) e envia a solicitação para o servidor de back-end.
3. No entanto, antes que a solicitação chegue ao servidor de back-end, o limite de tempo limite de sinal de atividade foi excedido no servidor de back-end.
4. A solicitação de um recurso 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 os dados serem recebidos, 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 do sinal de atividade de 60 segundos foi configurado no processador de mensagens e no servidor de back-end. Da mesma forma, esse problema também pode acontecer se um valor mais alto estiver configurado para o tempo limite de sinal de atividade no processador de mensagens do que no servidor de back-end.

Diagnóstico

1. Se você é um usuário de nuvem pública:
   1. Use a ferramenta API Monitoring ou Trace (conforme explicado em Etapas de diagnóstico comuns) e verifique se você tem as duas configurações a seguir:
      • Código de falha: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Origem da falha: target
   2. Acesse Como usar o tcpdump para uma investigação mais detalhada.
2. Se você é um usuário de nuvem privada:
   1. Use a ferramenta Trace ou os registros de acesso NGINX para determinar o ID da mensagem, o código e a origem da falha para o erro 502.
   2. Pesquise o ID da mensagem no registro do processador de mensagens
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Você verá 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 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 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, enviou dados, mas logo depois recebeu um EOF antes de receber qualquer dado. Isso significa que há uma grande probabilidade de que o tempo limite de sinal de atividade do servidor de back-end seja menor ou igual ao definido no proxy de API.

      Você pode investigar mais 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:

   Este é um exemplo de saída do tcpdump:

   

   Na amostra tcpdump acima, é possível 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 de 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 para o Processador de mensagens (pacote 6285) iniciando o fechamento da conexão.

   A mesma conexão foi reutilizada com sucesso neste exemplo, mas, na terceira solicitação, o servidor de back-end inicia um encerramento da conexão, enquanto o Processador de mensagens está aguardando os dados do servidor de back-end. Isso sugere que o tempo limite de sinal 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 sinal de atividade na Apigee e o servidor de back-end.

Comparar o tempo limite do sinal de atividade 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 do sinal de atividade.

2. No entanto, é possível que você tenha substituído o valor padrão no proxy de API. Para isso, verifique a definição TargetEndpoint específica no proxy de API com falha que está apresentando 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 sinal de atividade está substituída por um valor de 30 segundos (30000 milissegundos).

3. Em seguida, verifique a propriedade do tempo limite do sinal de atividade configurada no servidor de back-end. Digamos que seu servidor de back-end esteja configurado com o valor 25 seconds.
4. Se você determinar que o valor da propriedade de tempo limite de sinal de atividade na Apigee é maior que o valor da propriedade de tempo limite de sinal de atividade no servidor de back-end, como no exemplo acima, isso é a causa dos erros 502.

Resolução

Certifique-se de que a propriedade de tempo limite de sinal de atividade esteja sempre menor na Apigee (no componente Proxy de API e Processador de mensagens) em comparação à propriedade no servidor de back-end.

1. Determine o valor definido para o tempo limite do sinal de atividade no servidor de back-end.
2. Configure um valor apropriado para a propriedade de tempo limite do sinal de atividade no proxy da API ou no processador de mensagens, de modo que a propriedade do tempo limite do sinal de atividade seja menor que o valor definido no servidor de back-end, usando as etapas descritas em Como configurar o tempo limite do sinal de atividade nos processadores de mensagens.

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

Prática recomendada

É altamente recomendável que os componentes downstream tenham sempre um limite de tempo limite de sinal de atividade menor do que o configurado nos servidores upstream para evitar esses tipos de condições de corrida e erros 502. Cada salto downstream deve ser menor que cada salto ascendente. No Apigee Edge, é recomendável usar as seguintes diretrizes:

1. O tempo limite de sinal de atividade do cliente deve ser menor que o tempo limite de sinal de atividade do roteador.
2. O tempo limite de sinal de atividade do roteador de borda precisa ser menor que o tempo limite de sinal de atividade do processador de mensagens.
3. O tempo limite de sinal de atividade do processador de mensagens precisa ser menor que o tempo limite de sinal de atividade do servidor de destino.
4. Se você tiver outros saltos na frente ou atrás da Apigee, a mesma regra deverá ser aplicada. Deixe sempre como responsabilidade do cliente downstream fechar a conexão com o upstream.

É 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 da Apigee Edge.

Se você é um usuário de nuvem pública, forneça as seguintes informações:

• Nome da organização
• Nome do ambiente
• Nome do proxy da API
• Conclua o comando curl para reproduzir o erro 502
• Arquivo de rastreamento contendo as solicitações com erro 502 Bad Gateway - Unexpected EOF
• Se os erros 502 não estiverem ocorrendo no momento, forneça as informações de fuso horário ao período em que os erros 502 ocorreram no passado.

Se você é um usuário de 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 502
• Pacote de proxy de API
• Arquivo de rastreamento contendo 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 502 erros ocorreram
• Tcpdumps reunidos nos processadores de mensagens ou no servidor de back-end, ou ambos, quando o erro tiver ocorrido.