502 Error de puerta de enlace inesperado EOF

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 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 está recibiendo una respuesta válida de los servidores de backend que realmente deba completar 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 veas 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:

Causa	Detalles	Pasos dados para
El servidor de destino está configurado incorrectamente	El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL.	Usuarios de la nube pública y privada de Edge
EOFException del servidor de backend	El servidor de backend puede enviar EOF de forma abrupta.	Solo usuarios de la nube privada perimetral
Se configuró incorrectamente el tiempo de espera de mantenimiento en vivo.	Tiempos de espera de mantenimiento activos configurados incorrectamente en Apigee y en el servidor de backend.	Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

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

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

Causa: El servidor de destino no se configuró correctamente

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

Diagnóstico

1. Usa la supervisión de la API, la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código de falla y la fuente de la falla del error 502.
2. Habilita el registro en la IU de la API afectada.
3. Si el seguimiento de la solicitud a la API fallida muestra lo siguiente:
   1. El error 502 Bad Gateway se observa 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 mediante la llamada a la API de Edge Management:
   1. Si eres un 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 un usuario de la nube privada, 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 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 solo para aceptar solicitudes HTTPS (SSL) en 443, rechazará la solicitud de Edge o cerrará la conexión. Como resultado, obtendrás un error UnexpectedEOFAtTarget en Message Processor. Message Processor enviará 502 Bad Gateway como respuesta al cliente.

Resolución

Asegúrate siempre de que el servidor de destino esté configurado de forma correcta según tus requisitos.

En el ejemplo anterior, si quieres 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 propia 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. Para ello, debes incluir los atributos SSLInfo en los que la marca enabled está configurada 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 quieres validar el certificado del servidor de destino en Edge, también debemos incluir el almacén 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 los atributos SSLInfo con las marcas ClientAuthEnabled, Keystore, KeyAlias y Truststore configuradas correctamente, 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 (final de archivo) de forma abrupta.

Diagnóstico

1. Usa la supervisión de la API, la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código de falla y la fuente de la falla del error 502.
2. Revisa los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) y busca si tienes eof unexpected para la API específica o si tienes el messageid único de la solicitud a la API, 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 se produjo el error java.io.EOFException: eof unexpected mientras Message Processor intenta leer una respuesta del servidor de backend. Esta excepción indica el final del archivo (EOF) o el final de la transmisión se alcanzó de forma inesperada.

   Es decir, 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 Message Processor recibiera la respuesta o pudiera leer la respuesta completa.

3. Verifica los registros del servidor de backend y comprueba si hay algún error o información que podría haber provocado que el servidor de backend finalice la conexión de forma abrupta. Si encuentras información o error, 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 Message Processor:
   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 Message Processor envía la solicitud al servidor de backend.

5. Considera el siguiente ejemplo de tcpdump.

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

   

6. En el resultado de TCPDump, observas la siguiente secuencia de eventos:
   1. En el paquete 985, 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] de ambos lados.
   5. Dado que el servidor de backend envía [FIN,ACK], obtendrás 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. Comunícate con tu equipo de operaciones de red para investigar este problema más a fondo.

Resolución

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

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

Causa: Se configuró incorrectamente el tiempo de espera de mantenimiento en vivo.

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

Conexiones persistentes en Apigee

De forma predeterminada (y 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 que se reutilicen una conexión TCP y TLS/SSL ya establecida (si corresponde), lo que reduce las sobrecargas de latencia. La duración de la persistencia de una conexión se controla mediante una propiedad tiempo de espera de keep-alive (keepalive.timeout.millis).

El servidor de backend y el procesador de mensajes de Apigee usan tiempos de espera de mantenimiento de inactividad para mantener las conexiones abiertas entre sí. Una vez que no se reciben datos dentro del tiempo de espera de mantenimiento de actividad, el servidor de backend o el procesador de mensajes pueden cerrar la conexión con el otro.

De forma predeterminada, los proxies de API implementados en 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 para 60s, Apigee cerrará la conexión con el servidor de backend. El servidor de backend también mantendrá un tiempo de espera de mantenimiento de actividad y, una vez que este venza, el servidor de backend cerrará la conexión con Message Processor.

Implica una configuración incorrecta del tiempo de espera de mantenimiento de actividad

Si Apigee o el servidor de backend están configurados con tiempos de espera de mantenimiento en funcionamiento incorrectos, se genera 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 keepalive se configura en el proxy de API o en el procesador de mensajes con un valor mayor o igual que el tiempo de espera del servidor de backend ascendente, puede ocurrir la siguiente condición de carrera. Es decir, si el Message Processor no recibe ningún dato hasta muy cerca del umbral del tiempo de espera de mantenimiento del servidor de backend, entonces se procesa una solicitud y se envía al servidor de backend con la conexión existente. Esto puede generar 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 configurado en el procesador de mensajes y en el servidor de backend es de 60 segundos y no se recibió ninguna solicitud nueva hasta 59 segundos después de que el Message Processor específico entregó la solicitud anterior.
2. El Message Processor continúa y procesa la solicitud que se recibió en el segundo 59 mediante la conexión existente (ya que aún no ha transcurrido el tiempo de espera de mantenimiento en vivo) y envía la solicitud al servidor de backend.
3. Sin embargo, antes de que la solicitud llegue al servidor de backend, se superó el umbral de tiempo de espera de mantenimiento en funcionamiento en el servidor de backend.
4. La solicitud de Message Processor para un recurso está en curso, pero el servidor de backend intenta cerrar la conexión mediante el envío de un paquete FIN a Message Processor.
5. Mientras Message Processor espera la recepción de los datos, recibe el FIN inesperado y finaliza la conexión.
6. Esto da como resultado una Unexpected EOF y, luego, Message Processor al cliente muestra una 502.

En este caso, observamos que se produjo el error 502 porque se configuró el mismo valor de tiempo de espera de keepalive de 60 segundos en el procesador de mensajes y en el servidor de backend. Del mismo modo, este problema puede ocurrir si se configura un valor más alto para el tiempo de espera de mantenimiento de actividad en el procesador de mensajes que en el servidor de backend.

Diagnóstico

1. Si eres un usuario de la nube pública, haz lo siguiente:
   1. Usa la herramienta de supervisión de API o de Trace (como se explica en Pasos comunes de diagnóstico) y verifica que cuentas con las siguientes opciones de configuración:
      • Código de falla: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Fuente de errores: target
   2. Ve a Cómo usar tcpdump para obtener más información.
2. Si eres un usuario de la nube privada, sigue estos pasos:
   1. Usa la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código y la fuente de las fallas del error 502.
   2. Busca el ID del mensaje en el registro de Message Processor
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Verás el elemento 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 Message Processor recibió un EOF mientras se esperaba la lectura de una respuesta del servidor de backend.
   5. El atributo useCount=7 del mensaje de error anterior indica que Message Processor reutilizó esta conexión unas siete veces, y el atributo bytesWritten=159 indica que Message Processor envió la carga útil de la solicitud de 159 bytes al servidor de backend. Sin embargo, recibió cero bytes cuando se produjo el error EOF inesperado.

   6. Esto muestra que el procesador de mensajes volvió a usar la misma conexión varias veces y, en esta ocasión, envió datos, pero poco después recibió un EOF antes de que se recibiran los datos. Esto significa que hay una alta probabilidad de que el tiempo de espera de mantenimiento en funcionamiento del servidor de backend sea menor o igual que el establecido en el proxy de API.

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

Usa 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 tcpdump capturados:

   Este es un ejemplo de resultado de tcpdump:

   

   En el tcpdump de muestra 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 muestra un FIN, ACK al Message Processor (paquete 6285) que inicia el cierre de la conexión.

   En este ejemplo, la misma conexión se volvió a usar dos veces de forma correcta, pero en la tercera solicitud, el servidor de backend inicia un cierre de la conexión, mientras que Message Processor espera los datos del servidor de backend. Esto sugiere que el tiempo de espera de mantenimiento del servidor de backend probablemente sea menor o igual que el valor establecido en el proxy de API. Para validar esto, consulta Compara el tiempo de espera de mantenimiento de actividad en Apigee y el servidor de backend.

Compara el tiempo de espera de mantenimiento en funcionamiento en Apigee y el servidor de backend

1. Según la configuración predeterminada, Apigee usa un valor de 60 segundos para la propiedad de tiempo de espera de keepalive.

2. Sin embargo, es posible que hayas anulado el valor predeterminado en el proxy de API. Para verificar esto, revisa la definición específica de TargetEndpoint en el proxy de API que falla y que genera errores 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.

Resolución

Asegúrate de que la propiedad de tiempo de espera de keepalive siempre sea más baja en Apigee (en el componente proxy de API y procesador de mensajes) 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 en el procesador de mensajes, de modo que esta propiedad sea menor que el valor establecido en el servidor de backend mediante los pasos que se describen en Configura el tiempo de espera de keep-alive en Message Processor.

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

Práctica recomendada

Se recomienda que los componentes descendentes siempre tengan un umbral de tiempo de espera de mantenimiento en vivo menor que el configurado en los servidores upstream para evitar estos tipos de condiciones de carrera y errores 502. Cada salto descendente debe ser menor que cada salto ascendente. En Apigee Edge, se recomienda usar los siguientes lineamientos:

1. El tiempo de espera de mantenimiento en funcionamiento del cliente debe ser inferior al tiempo de espera de la conservación del router perimetral.
2. El tiempo de espera de activación del router perimetral debe ser menor que el tiempo de espera de la operación de mantenimiento del procesador de mensajes.
3. El tiempo de espera de activación del procesador de mensajes debe ser menor que el tiempo de espera de la operación de mantenimiento del servidor de destino.
4. Si hay otros saltos delante o detrás de Apigee, se debe aplicar la misma regla. Siempre debes dejar que el cliente descendente sea responsable de cerrar la conexión con el upstream.

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 un usuario de la nube pública, proporciona la siguiente información:

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

Si eres un 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 502
• Paquete de proxy de API
• Archivo de seguimiento 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
• El período con la información de zona horaria en el que se produjeron los errores 502
• Se recopilaron Tcpdumps en los procesadores de mensajes o el servidor de backend, o en ambos cuando se produjo el error.