502 Gateway inválido EOF inesperado

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 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 deveriam realmente atender a solicitação.

Mensagens de erro

O aplicativo cliente recebe este código de resposta:

HTTP/1.1 502 Bad Gateway

Além disso, talvez você veja 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:

Causa	Detalhes	Etapas dadas para
Servidor de destino configurado incorretamente	O servidor de destino não está configurado corretamente para aceitar conexões TLS/SSL.	Usuários de nuvens públicas e privadas de borda
EOFException do servidor de back-end	O servidor de back-end pode enviar o EOF abruptamente.	Apenas usuários da nuvem privada do Edge
Tempo limite de sinal de atividade configurado incorretamente	Tempos limite de manutenção de atividade configurados incorretamente na Apigee e no servidor de back-end.	Usuários de nuvens públicas e privadas de borda

Etapas comuns do diagnóstico

Para diagnosticar o erro, você pode usar 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 APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código da falha e a origem da falha do erro 502.
2. Ativar o rastro 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 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. Confira a definição do servidor de destino usando a chamada da API de gerenciamento de borda:
   1. Se você for 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ê for 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 de TargetServer ilustrada é um exemplo de 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 há outros atributos/sinalizações que indicam que ele se destina a conexões seguras. Isso faz com que o Edge trate as solicitações de API que vão 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 encerrará 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

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 para um servidor de destino seguro (HTTPS/SSL), precisará incluir os atributos SSLInfo com a sinalização 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 qualquer confusão.

1. Se o serviço de back-end exigir comunicação SSL unidirecional, faça o seguinte:
   1. Para ativar o TLS/SSL na definição de TargetServer, inclua os atributos SSLInfo em que a sinalização enabled está definida como verdadeira, 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 será necessário 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. É preciso ter atributos SSLInfo com as sinalizações 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 o fim do arquivo (EOF, na sigla em inglês) de maneira abrupta.

Diagnóstico

1. Use o Monitoramento de APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX para determinar o ID da mensagem, o código da falha 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 se você tem eof unexpected para a API específica ou se tem o messageid exclusivo para a solicitação de API, então você pode procurá-la.

   Exemplo de stack trace de exceção no 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 está tentando ler uma resposta do servidor de back-end. Essa exceção indica que o fim do arquivo (EOF, na sigla em inglês) ou 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 de o processador de mensagens receber a resposta ou 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 de back-end a encerrar a conexão abruptamente. Se você encontrar erros/informações, acesse Resolução e corrija o problema corretamente 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 é 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 de tcpdump abaixo.

   Amostra de tcpdump feita quando 502 Bad Gateway Error (UnexpectedEOFAtTarget) ocorreu

   

6. Na saída TCPDump, você vê 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 serã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 de exceção no processador de mensagens.
7. Isso pode acontecer se houver um problema de rede no servidor de back-end. Fale com sua equipe de operações de rede para investigar esse problema mais a fundo.

Resolução

Corrija o problema no servidor de back-end adequadamente.

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

Causa: tempo limite de 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 a seguir com o padrão HTTP/1.1) usa conexões persistentes ao se comunicar com o servidor de back-end de destino. Conexões permanentes 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 de uma conexão que precisa ser mantida é controlada por meio de um tempo limite de sinal de atividade (keepalive.timeout.millis) da propriedade.

O servidor de back-end e o processador de mensagens da Apigee usam tempos limite de sinal de atividade 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 pode encerrar 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 sinal de atividade definido como 60s, a menos que sejam substituídos. Quando nenhum dado for recebido para 60s, a Apigee vai encerrar 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 ele expirar, o servidor de back-end fechará a conexão com o processador de mensagens.

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

Se a Apigee ou o servidor de back-end estiverem configurados com tempos limite incorretos de sinal de atividade, isso vai 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 recurso.

Por exemplo, se o tempo limite de sinal de atividade for configurado no proxy da API ou no processador de mensagens com um valor maior ou igual ao tempo limite do servidor de back-end upstream, a seguinte disputa poderá ocorrer. Ou seja, se o processador de mensagens não receber nenhum dado até perto do limite do tempo limite de manutenção do servidor de back-end, uma solicitação será enviada ao servidor de back-end usando a conexão existente. 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 sido enviada até 59 segundos após a solicitação anterior ter sido atendida pelo processador de mensagens específico.
2. O processador de mensagens processa a solicitação que chegou ao 59o segundo usando a conexão existente (já que o tempo limite de sinal de atividade ainda não passou) 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 sinal de atividade foi excedido no servidor de back-end.
4. A solicitação do processador de mensagens para um recurso está em andamento, mas o servidor de back-end tenta encerrar a conexão enviando um pacote FIN para o 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, em seguida, um 502 é retornado ao cliente pelo processador de mensagens.

Nesse caso, observamos a ocorrência do erro 502 porque o mesmo valor de tempo limite de 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 manter o tempo limite ativo no processador de mensagens do que no servidor de back-end.

Diagnóstico

1. Se você for um usuário de nuvem pública:
   1. Use a ferramenta de monitoramento de API ou trace, conforme explicado em Etapas comuns de diagnóstico, e verifique se você tem estas duas configurações:
      • 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ê 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ê verá o java.io.EOFEXception: eof unexpected como 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 estava aguardando 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 payload da solicitação de 159 bytes foi enviado ao servidor de back-end. No entanto, ele não recebeu nenhum bytes de volta quando ocorreu o EOF inesperado.

   6. Isso mostra que o processador de mensagens reutilizou a mesma conexão várias vezes e, nessa ocasião, enviou dados, mas recebeu um EOF pouco depois antes de receber os dados. Isso significa que há uma alta probabilidade de que o tempo limite de sinal de atividade do servidor de back-end seja menor ou igual ao definido no proxy da 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 as tcpdump capturadas:

   Veja um exemplo de saída do tcpdump:

   

   No exemplo de tcpdump acima, você pode conferir 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 fechamento da conexão, enquanto o processador de mensagens aguarda 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 no servidor de back-end.

Comparar o tempo limite de sinal de atividade na Apigee e no servidor de back-end

1. Por padrão, a Apigee usa o 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 da API. É possível verificar isso conferindo a definição TargetEndpoint específica no proxy da 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 sinal de atividade é substituída por um valor de 30 segundos (30000 milissegundos).

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

Resolução

Garanta que a propriedade de tempo limite de sinal de atividade seja sempre menor na Apigee (no componente de proxy de API e no processador de mensagens) em comparação com o servidor de back-end.

1. Determine o valor definido para o tempo limite de 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 de API ou no processador de mensagens, de modo que essa propriedade 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 de informações de diagnóstico.

Prática recomendada

É altamente recomendável que os componentes downstream sempre tenham um limite de tempo limite de sinal de atividade menor do que o configurado nos servidores upstream para evitar esses tipos de disputas e erros de 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 sinal de atividade do cliente deve ser menor que o tempo limite de sinal de atividade do roteador de borda.
2. O tempo limite de sinal de atividade do roteador de borda deve ser menor que o tempo limite de manutenção do processador de mensagens.
3. O tempo limite de sinal de atividade do processador de mensagens deve ser menor que o tempo limite de sinal de atividade do servidor de destino.
4. Se você tiver qualquer outro salto na frente ou atrás da Apigee, a mesma regra deverá ser aplicada. Sempre deixe que o cliente downstream seja responsável pelo encerramento da 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, colete as informações de diagnóstico a seguir 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
• 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 o período com as informações de fuso horário em que os erros 502 ocorreram no passado.

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

• Concluir a mensagem de erro observada para as solicitações com falha
• Organização, nome do ambiente e nome do proxy de API em que 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 ocorreram os erros 502
• Tcpdumps coletado nos processadores de mensagens ou no servidor de back-end, ou ambos quando o erro ocorreu