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

Para diagnosticar o erro usando o API Monitoring:

Usando o Monitoramento de API, é possível investigar os erros 502 seguindo as etapas conforme explicado em Investigar problemas. Ou seja:

  1. Acesse o painel Investigar.
  2. Selecione o Código de status no menu suspenso e verifique se o período correto está selecionado quando os erros 502 ocorreram.
  3. Clique na caixa na matriz quando você vir um grande número de erros 502.
  4. No lado direito, clique em Ver registros para ver os erros 502 que seriam semelhantes aos seguintes:
  5. Aqui podemos ver as seguintes informações:

    • Origem da falha é target
    • Código de falha é messaging.adaptors.http.UnexpectedEOFAtTarget

Isso indica que o erro 502 é causado pelo destino devido a EOF inesperado.

Além disso, anote o Request Message ID do erro 502 para uma investigação mais detalhada.

Ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e faça a chamada da API para reproduzir o problema 502 Bad Gateway.
  2. Selecione uma das solicitações com falha e examine o trace.
  3. Navegue pelas diversas fases do trace e localize onde a falha ocorreu.
  4. Você verá a falha após o envio da solicitação ao servidor de destino, conforme mostrado abaixo:

    alt_text

    alt_text

  5. Determine o valor de X-Apigee.fault-source e X-Apigee.fault-code na Fase AX (Analytics Data Recorded) no trace.

    Se os valores de X-Apigee.fault-source e X-Apigee.fault-code corresponderem aos valores mostrados na tabela a seguir, será possível confirmar que o erro 502 está vindo do servidor de destino:

    Cabeçalhos de resposta Valor
    X-Apigee.fault-source target
    X-Apigee.Código da falha messaging.adaptors.http.flow.UnexpectedEOFAtTarget

    Além disso, anote o X-Apigee.Message-ID do erro 502 para uma investigação mais aprofundada.

Registros de acesso do NGINX

Para diagnosticar o erro usando o NGINX:

Você também pode consultar os registros de acesso do NGINX para determinar a causa do código de status 502. Isso é particularmente útil se o problema tiver ocorrido no passado ou se for intermitente e você não conseguir capturar o trace na IU. Use as etapas a seguir para determinar essas informações nos registros de acesso do NGINX:

  1. Verifique os registros de acesso do NGINX.
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. Procure erros 502 do proxy de API específico durante um período específico (se o problema tiver ocorrido anteriormente) ou procure solicitações que ainda falham com 502.
  3. Se houver algum erro 502, verifique se ele é causado pelo destino que envia um Unexpected EOF. Se os valores de X-Apigee.fault-source e X- Apigee.fault-code corresponderem aos valores mostrados na tabela abaixo, o erro 502 será causado pelo destino que fecha inesperadamente a conexão:
    Cabeçalhos de resposta Valor
    X-Apigee.fault-source target
    X-Apigee.Código da falha messaging.adaptors.http.flow.UnexpectedEOFAtTarget

    Veja um exemplo de entrada que mostra o erro 502 causado pelo servidor de destino:

Além disso, anote os IDs de mensagem dos erros 502 para uma investigação mais detalhada.

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.