502 Error de puerta de enlace inesperado EOF

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente obtiene un código de estado HTTP 502 con el mensaje Bad Gateway como respuesta a las llamadas a la API.

El código de estado HTTP 502 significa que el cliente no recibe una respuesta válida de los servidores de backend que deberían satisfacer la solicitud.

Mensajes de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 502 Bad Gateway

Además, es posible que observes el siguiente mensaje de error:

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

Causas posibles

Una de las causas típicas de 502 Bad Gateway Error es el error Unexpected EOF, que puede deberse a los siguientes motivos:

Pasos comunes de diagnóstico

Para diagnosticar el error, puedes usar cualquiera de los siguientes métodos:

• Supervisión de API
• Herramienta de Trace
• Registros de acceso de NGINX

Causa: Servidor de destino configurado de forma incorrecta

El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL.

Diagnóstico

1. Usa API Monitoring, la herramienta de Trace o los registros de acceso de NGINX para determinar el ID del mensaje, el código de error y la fuente del error 502.
2. Habilita el registro en la IU para la API afectada.
3. Si el registro de seguimiento de la solicitud a la API con errores muestra lo siguiente:
   1. El error 502 Bad Gateway se muestra en cuanto se inicia la solicitud de flujo de destino.
   2. El error.class muestra messaging.adaptors.http.UnexpectedEOF..

      Entonces, es muy probable que este problema se deba a una configuración incorrecta del servidor de destino.

4. Obtén la definición del servidor de destino con la llamada a la API de administración de Edge:
   1. Si eres usuario de la nube pública, usa esta API:

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

   2. Si eres usuario de Private Cloud, usa esta API:

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

      Ejemplo de definición de TargetServer defectuosa:

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

5. La definición de TargetServer ilustrada es un ejemplo de una de las configuraciones incorrectas típicas, que se explica de la siguiente manera:

   Supongamos que el servidor de destino mocktarget.apigee.net está configurado para aceptar conexiones seguras (HTTPS) en el puerto 443. Sin embargo, si observas la definición del servidor de destino, no hay otros atributos o marcas que indiquen que está destinado a conexiones seguras. Esto hace que Edge trate las solicitudes a la API que se dirigen al servidor de destino específico como solicitudes HTTP (no seguras). Por lo tanto, Edge no iniciará el proceso de protocolo de enlace SSL con este servidor de destino.

   Dado que el servidor de destino está configurado para aceptar solo solicitudes HTTPS (SSL) en 443, rechazará la solicitud de Edge o cerrará la conexión. Como resultado, recibirás un error UnexpectedEOFAtTarget en Message Processor. El Message Processor enviará 502 Bad Gateway como respuesta al cliente.

Solución

Siempre asegúrate de que el servidor de destino esté configurado correctamente según tus requisitos.

En el ejemplo ilustrado anterior, si deseas realizar solicitudes a un servidor de destino seguro (HTTPS/SSL), debes incluir los atributos SSLInfo con la marca enabled establecida en true. Si bien se permite agregar los atributos SSLInfo para un servidor de destino en la definición del extremo de destino, se recomienda agregar los atributos SSLInfo como parte de la definición del servidor de destino para evitar confusiones.

1. Si el servicio de backend requiere comunicación SSL unidireccional, haz lo siguiente:
   1. Debes habilitar TLS/SSL en la definición de TargetServer incluyendo los atributos SSLInfo donde la marca enabled esté establecida como verdadera, como se muestra a continuación:

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

   2. Si deseas validar el certificado del servidor de destino en Edge, también debemos incluir el almacén de certificados de confianza (que contiene el certificado del servidor de destino), como se muestra a continuación:

      <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. Si el servicio de backend requiere comunicación SSL bidireccional, haz lo siguiente:
   1. Debes tener atributos SSLInfo con las marcas ClientAuthEnabled, Keystore, KeyAlias y Truststore configuradas de forma adecuada, como se muestra a continuación:

      <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 >

Referencias

Balanceo de cargas entre servidores de backend

Causa: EOFException del servidor de backend

El servidor de backend puede enviar EOF (fin de archivo) de forma abrupta.

Diagnóstico

1. Usa API Monitoring, la herramienta de Trace o los registros de acceso de NGINX para determinar el ID del mensaje, el código de error y la fuente del error 502.
2. Revisa los registros del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) y busca para ver si tienes eof unexpected para la API específica o si tienes el messageid único para la solicitud a la API. Luego, puedes buscarlo.

   Ejemplo de seguimiento de pila de excepciones del registro de Message Processor

   "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]"

   En el ejemplo anterior, puedes ver que el error java.io.EOFException: eof unexpected ocurrió mientras el Message Processor intentaba leer una respuesta del servidor de backend. Esta excepción indica el final del archivo (EOF) o que se alcanzó el final de la transmisión de forma inesperada.

   Es decir, el Message Processor envió la solicitud a la API al servidor de backend y estaba esperando o leyendo la respuesta. Sin embargo, el servidor de backend finalizó la conexión de forma abrupta antes de que el Message Processor recibiera la respuesta o pudiera leer la respuesta completa.

3. Revisa los registros del servidor de backend y comprueba si hay errores o información que podrían haber provocado que el servidor de backend finalizara la conexión de forma abrupta. Si encuentras errores o información, ve a Resolución y corrige el problema de forma adecuada en tu servidor de backend.
4. Si no encuentras errores ni información en tu servidor de backend, recopila el resultado de tcpdump en los procesadores de mensajes:
   1. Si el host de tu servidor de backend tiene una sola dirección IP, usa el siguiente comando:

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

   2. Si el host de tu servidor de backend tiene varias direcciones IP, usa el siguiente comando:

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

      Por lo general, este error se produce porque el servidor de backend responde con [FIN,ACK] en cuanto el Message Processor envía la solicitud al servidor de backend.

5. Considera el siguiente ejemplo de tcpdump.

   Muestra tcpdump tomada cuando ocurrió 502 Bad Gateway Error (UnexpectedEOFAtTarget)

   

6. En el resultado de TCPDump, notarás la siguiente secuencia de eventos:
   1. En el paquete 985, el Message Processor envía la solicitud a la API al servidor de backend.
   2. En el paquete 986, el servidor de backend responde de inmediato con [FIN,ACK].
   3. En el paquete 987, Message Processor responde con [FIN,ACK] al servidor de backend.
   4. Finalmente, las conexiones se cierran con [ACK] y [RST] desde ambos lados.
   5. Dado que el servidor de backend envía [FIN,ACK], obtienes la excepción java.io.EOFException: eof unexpected en el procesador de mensajes.
7. Esto puede ocurrir si hay un problema de red en el servidor de backend. Pídele a tu equipo de operaciones de red que investigue más a fondo este problema.

Solución

Corrige el problema en el servidor de backend de forma adecuada.

Si el problema persiste y necesitas ayuda para solucionar problemas relacionados con 502 Bad Gateway Error o sospechas que se trata de un problema en Edge, comunícate con el equipo de asistencia de Apigee Edge.

Causa: Tiempo de espera de conexión activa configurado de forma incorrecta

Antes de diagnosticar si esta es la causa de los errores de 502, lee los siguientes conceptos.

Conexiones persistentes en Apigee

De forma predeterminada (y de acuerdo con el estándar HTTP/1.1), Apigee usa conexiones persistentes cuando se comunica con el servidor de backend de destino. Las conexiones persistentes pueden aumentar el rendimiento, ya que permiten reutilizar una conexión TCP y (si corresponde) TLS/SSL ya establecida, lo que reduce la sobrecarga de latencia. La duración durante la que se debe mantener una conexión se controla a través de una propiedad tiempo de espera de keep-alive (keepalive.timeout.millis).

Tanto el servidor de backend como el Message Processor de Apigee usan tiempos de espera de keep-alive para mantener las conexiones abiertas entre sí. Una vez que no se reciben datos dentro del tiempo de espera de keep-alive, el servidor de backend o el Message Processor pueden cerrar la conexión con el otro.

De forma predeterminada, los proxies de API implementados en un Message Processor en Apigee tienen un tiempo de espera de keep-alive establecido en 60s, a menos que se anule. Una vez que no se reciban datos durante 60s, Apigee cerrará la conexión con el servidor de backend. El servidor de backend también mantendrá un tiempo de espera de conexión activa y, una vez que este expire, el servidor de backend cerrará la conexión con el procesador de mensajes.

Implicación de una configuración incorrecta del tiempo de espera de Keep-Alive

Si Apigee o el servidor de backend están configurados con tiempos de espera keep-alive incorrectos, se produce una condición de carrera que hace que el servidor de backend envíe un End Of File (FIN) inesperado en respuesta a una solicitud de un recurso.

Por ejemplo, si el tiempo de espera de keep-alive se configura dentro del proxy de API o del procesador de mensajes con un valor mayor o igual que el tiempo de espera del servidor de backend upstream, puede ocurrir la siguiente condición de carrera. Es decir, si el Message Processor no recibe datos hasta muy cerca del umbral de tiempo de espera de conexión activa del servidor de backend, se recibe una solicitud y se envía al servidor de backend a través de la conexión existente. Esto puede generar un 502 Bad Gateway debido a un error de EOF inesperado, como se explica a continuación:

1. Supongamos que el tiempo de espera de Keep-Alive establecido tanto en el Message Processor como en el servidor de backend es de 60 segundos y no llegó ninguna solicitud nueva hasta 59 segundos después de que el Message Processor específico atendió la solicitud anterior.
2. El Message Processor continúa y procesa la solicitud que llegó en el segundo 59 con la conexión existente (ya que aún no transcurrió el tiempo de espera de keep-alive) y envía la solicitud al servidor de backend.
3. Sin embargo, antes de que la solicitud llegue al servidor de backend, ya se superó el umbral de tiempo de espera de conexión persistente en el servidor de backend.
4. La solicitud de un recurso del procesador de mensajes está en curso, pero el servidor de backend intenta cerrar la conexión enviando un paquete FIN al procesador de mensajes.
5. Mientras el Message Processor espera recibir los datos, recibe el FIN inesperado y se cierra la conexión.
6. Esto genera un Unexpected EOF y, luego, el Message Processor devuelve un 502 al cliente.

En este caso, observamos que el error 502 se produjo porque se configuró el mismo valor de tiempo de espera de keep-alive de 60 segundos tanto en el Message Processor como en el servidor de backend. Del mismo modo, este problema también puede ocurrir si se configura un valor más alto para el tiempo de espera de conexión activa en el procesador de mensajes que en el servidor de backend.

Diagnóstico

1. Si eres usuario de la nube pública, haz lo siguiente:
   1. Usa la herramienta de supervisión de API o Trace (como se explica en los pasos de diagnóstico comunes) y verifica que tengas ambos parámetros de configuración siguientes:
      • Código de falla: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Fuente del error: target
   2. Consulta Cómo usar tcpdump para realizar una investigación más detallada.
2. Si eres usuario de la nube privada, haz lo siguiente:
   1. Usa la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código de error y la fuente del error 502.
   2. Busca el ID del mensaje en el registro del Message Processor
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Verás el java.io.EOFEXception: eof unexpected como se muestra a continuación:

      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. El error java.io.EOFException: eof unexpected indica que el Message Processor recibió un EOF mientras aún esperaba leer una respuesta del servidor de backend.
   5. El atributo useCount=7 en el mensaje de error anterior indica que el Message Processor había reutilizado esta conexión unas siete veces, y el atributo bytesWritten=159 indica que el Message Processor había enviado la carga útil de la solicitud de 159 bytes al servidor de backend. Sin embargo, no recibió ningún byte cuando se produjo el EOF inesperado.

   6. Esto muestra que el Message Processor había reutilizado la misma conexión varias veces y, en esta ocasión, envió datos, pero poco después recibió un EOF antes de que se recibieran datos. Esto significa que hay una alta probabilidad de que el tiempo de espera de keep-alive del servidor de backend sea menor o igual al establecido en el proxy de API.

      Puedes investigar más a fondo con la ayuda de tcpdump, como se explica a continuación.

Cómo usar tcpdump

1. Captura un tcpdump en el servidor de backend con el siguiente comando:

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

2. Analiza los datos de tcpdump capturados:

   Este es un ejemplo de resultado de tcpdump:

   

   En la muestra tcpdump anterior, puedes ver lo siguiente:

   1. En el paquete 5992,, el servidor de backend recibió una solicitud GET.
   2. En el paquete 6064, responde con 200 OK.
   3. En el paquete 6084, el servidor de backend recibió otra solicitud GET.
   4. En el paquete 6154, responde con 200 OK.
   5. En el paquete 6228, el servidor de backend recibió una tercera solicitud GET.
   6. Esta vez, el servidor de backend devuelve un FIN, ACK al Message Processor (paquete 6285) que inicia el cierre de la conexión.

   En este ejemplo, la misma conexión se reutilizó dos veces correctamente, pero en la tercera solicitud, el servidor de backend inicia el cierre de la conexión, mientras el procesador de mensajes espera los datos del servidor de backend. Esto sugiere que el tiempo de espera de keep-alive del servidor de backend probablemente sea más corto o igual al valor establecido en el proxy de API. Para validar esto, consulta Compara el tiempo de espera de Keep-Alive en Apigee y el servidor de backend.

Compara el tiempo de espera de Keep-Alive en Apigee y el servidor de backend

1. De forma predeterminada, Apigee usa un valor de 60 segundos para la propiedad de tiempo de espera de keep-alive.

2. Sin embargo, es posible que hayas anulado el valor predeterminado en el proxy de API. Puedes verificarlo si revisas la definición específica de TargetEndpoint en el proxy de API que falla y muestra errores de 502.

   Ejemplo de configuración de TargetEndpoint:

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

   En el ejemplo anterior, la propiedad de tiempo de espera de Keep-Alive se anula con un valor de 30 segundos (30000 milisegundos).

3. A continuación, verifica la propiedad de tiempo de espera de Keep-Alive configurada en tu servidor de backend. Supongamos que tu servidor de backend está configurado con un valor de 25 seconds.
4. Si determinas que el valor de la propiedad de tiempo de espera de Keep-Alive en Apigee es mayor que el valor de la propiedad de tiempo de espera de Keep-Alive en el servidor de backend, como en el ejemplo anterior, esa es la causa de los errores 502.

Solución

Asegúrate de que la propiedad de tiempo de espera de keep-alive sea siempre menor en Apigee (en el proxy de API y el componente Message Processor) en comparación con la del servidor de backend.

1. Determina el valor establecido para el tiempo de espera de Keep-Alive en el servidor de backend.
2. Configura un valor adecuado para la propiedad de tiempo de espera de keep-alive en el proxy de API o el Message Processor, de modo que la propiedad de tiempo de espera de keep-alive sea inferior al valor establecido en el servidor de backend, siguiendo los pasos que se describen en Configuración del tiempo de espera de keep-alive en Message Processors.

Si el problema persiste, consulta Recopila información de diagnóstico.

Práctica recomendada

Se recomienda encarecidamente que los componentes de nivel inferior siempre tengan un umbral de tiempo de espera de conexión activa menor que el configurado en los servidores de nivel superior para evitar este tipo de condiciones de carrera y errores 502. Cada salto de transmisión debe ser inferior a cada salto de transmisión anterior. En Apigee Edge, es una práctica recomendada seguir los siguientes lineamientos:

1. El tiempo de espera de conexión activa del cliente debe ser inferior al tiempo de espera de conexión activa del router perimetral.
2. El tiempo de espera de conexión activa del router perimetral debe ser inferior al tiempo de espera de conexión activa del Message Processor.
3. El tiempo de espera de keep-alive del Message Processor debe ser inferior al tiempo de espera de keep-alive del servidor de destino.
4. Si tienes otros saltos delante o detrás de Apigee, se debe aplicar la misma regla. Siempre debes dejar que el cliente de nivel inferior sea el responsable de cerrar la conexión con el nivel superior.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con el equipo de asistencia de Apigee Edge.

Si eres usuario de la nube pública, proporciona la siguiente información:

• Nombre de la organización
• Nombre del entorno
• Nombre del proxy de API
• Comando curl completo para reproducir el error 502
• Archivo de registro que contiene las solicitudes con el error 502 Bad Gateway - Unexpected EOF
• Si los errores de 502 no se producen actualmente, proporciona el período con la información de la zona horaria en la que se produjeron los errores de 502 en el pasado.

Si eres usuario de la nube privada, proporciona la siguiente información:

• Mensaje de error completo observado para las solicitudes con errores
• Organización, nombre del entorno y nombre del proxy de API para los que observas errores de 502
• Paquete de proxy de API
• Archivo de registro que contiene las solicitudes con el error 502 Bad Gateway - Unexpected EOF
• Registros de acceso de NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Registros de Message Processor
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Período con la información de zona horaria en el que se produjeron los errores de 502
• Tcpdumps recopilados en los procesadores de mensajes o en el servidor de backend, o en ambos cuando se produjo el error