Error 502: Error de tiempo de espera de puerta de enlace incorrecta

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

Síntoma

La aplicación cliente recibe un error de 502 Bad Gateway. El Message Processor muestra este error a la aplicación cliente cuando no recibe una respuesta de un servidor de backend.

Mensaje de error

La aplicación cliente recibe 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":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Causa posible

La posible causa de este problema se indica en la siguiente tabla:

Causa Descripción Los pasos para solucionar problemas pueden ser realizados por
Tiempo de espera del protocolo de enlace TLS/SSL Se produce un tiempo de espera durante el protocolo de enlace TLS/SSL entre el Message Processor y el servidor de backend. Usuarios de la nube pública y privada de Edge

Causa: Tiempo de espera del protocolo de enlace TLS/SSL

En Apigee Edge, puedes configurar una conexión TLS/SSL al servidor de backend para habilitar la comunicación TLS entre el Message Processor de Edge y un servidor de backend.

Un protocolo de enlace TLS/SSL implica varios pasos. Por lo general, este error ocurre cuando se agota el tiempo de espera del protocolo de enlace TLS/SSL entre el Message Processor y un servidor de backend.

Diagnóstico

En esta sección, se explica cómo diagnosticar correctamente un tiempo de espera del protocolo de enlace TLS/SSL. Se incluyen instrucciones para la nube pública y privada de Edge.

Investiga la salida de la sesión de seguimiento

En los siguientes pasos, se explica cómo realizar un diagnóstico preliminar del problema con la herramienta de seguimiento de Apigee Edge.

  1. En la IU de Edge, habilita una sesión de seguimiento para el proxy de API afectado.

  2. Si el seguimiento de la solicitud a la API con errores muestra lo siguiente, es probable que se haya producido un error de tiempo de espera del protocolo de enlace TLS/SSL. La causa probable del error es que el firewall del servidor de backend bloquea el tráfico de Apigee.

    1. Determina si el error 502 Bad Gateway ocurre después de 55 segundos, que es el período de tiempo de espera predeterminado establecido en el Message Processor. Si ves que el error ocurrió después de 55 segundos, esto te indica que un tiempo de espera fue la causa probable del problema.
    2. Determina si el error muestra la falla: messaging.adaptors.http.BadGateway. De nuevo, este error suele indicar que se produjo un tiempo de espera.

    3. Si estás en la nube privada de Edge, anota el valor del campo X-Apigee.Message-ID en el resultado del seguimiento, como se muestra a continuación. Un usuario de la nube privada puede usar este valor de ID para realizar más pasos para solucionar problemas, como se explica más adelante.

      1. Haz clic en el ícono Analytics Data Recorded en la ruta de seguimiento:

      2. Desplázate hacia abajo y anota el valor del campo llamado X-Apigee.Message-ID.

Para confirmar que el tiempo de espera del protocolo de enlace TLS/SSL fue la causa del error, sigue los pasos de las siguientes secciones según si estás en la nube pública o privada.

Pasos de diagnóstico adicionales solo para usuarios de la nube privada de Edge

Si estás en la nube privada de Apigee Edge, puedes realizar los siguientes pasos para verificar la causa del error del protocolo de enlace. En este paso, inspeccionas el archivo de registro del Message Processor para obtener información pertinente. Si estás en la nube pública de Edge, puedes omitir esta sección y pasar a Pasos de diagnóstico adicionales para usuarios de la nube pública y privada.

  1. Comprueba si puedes conectarte al servidor de backend específico directamente desde cada uno de los procesadores de mensajes con el comando telnet:

    1. Si el servidor de backend se resuelve en una sola dirección IP, usa este comando:

      telnet BackendServer-IPaddress 443

    2. Si el servidor de backend se resuelve en varias direcciones IP, usa el nombre de host del servidor de backend en el comando telnet, como se muestra a continuación:

      telnet BackendServer-HostName 443

    Si puedes conectarte al servidor de backend sin errores, continúa con el siguiente paso.

    Si falla el comando telnet, debes trabajar con tu equipo de red para verificar la conectividad entre el procesador de mensajes y el servidor de backend.

  2. Revisa el archivo de registro del Message Processor para obtener evidencia de una falla del protocolo de enlace. Abre el archivo:

    /opt/apigee/var/log/edge-message-processor/system.log

    y busca el ID de mensaje único (el valor de X-Apigee.Message-ID que encontraste en el archivo de seguimiento). Determina si ves un mensaje de error del protocolo de enlace asociado con el ID de mensaje, como se muestra a continuación:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

Si ves este error en el archivo de registro del procesador de mensajes, continúa con la investigación. Ve a Pasos de diagnóstico adicionales para usuarios de la nube pública y privada de Edge.

Si no ves el mensaje del protocolo de enlace en el archivo de registro, ve a Se debe recopilar información de diagnóstico

Pasos de diagnóstico adicionales para usuarios de la nube pública y privada de Edge

Para identificar el problema, puedes usar la herramienta tcpdump para analizar paquetes TCP/IP y confirmar si se produjo un tiempo de espera durante el protocolo de enlace TLS/SSL.

  1. Si eres usuario de la nube privada, puedes capturar los paquetes TCP/IP en el servidor de backend o el Message Processor. Es preferible capturarlos en el servidor de backend, ya que los paquetes se desencriptan en el servidor de backend.
  2. Si eres usuario de la nube pública, no tienes acceso al procesador de mensajes . Sin embargo, capturar los paquetes TCP/IP en el servidor de backend puede ayudar a identificar un problema .

  3. Después de decidir dónde capturar los paquetes TCP/IP, usa el siguiente tcpdump comando para capturarlos.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Si tomas los paquetes TCP/IP en el servidor de backend, usa la dirección IP pública del Message Processor en el comando tcpdump. Para obtener ayuda para usar el comando para examinar el tráfico del servidor de backend, consulta tcpdump.

    • Si tomas los paquetes TCP/IP en el Message Processor, usa la dirección IP pública del servidor de backend en el comando tcpdump. Para obtener ayuda para usar el comando para examinar el tráfico del Message Processor, consulta tcpdump.

    • Si hay varias direcciones IP para el servidor de backend o el Message Processor, debes probar otro uso del comando tcpdump. Consulta tcpdump para obtener más información sobre esta herramienta y otras variantes de este comando.

  4. Analiza los paquetes TCP/IP con la herramienta Wireshark o una similar. En la siguiente captura de pantalla, se muestran los paquetes TCP/IP en Wireshark.

  5. Observa en el resultado de Wireshark que el protocolo de enlace TCP de tres vías se completa correctamente en los primeros 3 paquetes.

  6. Luego, el Message Processor envía el mensaje "Client Hello" en el paquete n.° 4.

  7. Como no hay confirmación del servidor de backend, el procesador de mensajes retransmite el mensaje "Client Hello" varias veces en los paquetes 5, 6 y 7 después de esperar un intervalo de tiempo predefinido.

  8. Cuando el Message Processor no recibe ninguna confirmación después de 3 reintentos, envía el mensaje FIN, ACK al servidor de backend para indicar que cerrará la conexión.

  9. Como se muestra en la sesión de Wireshark de ejemplo, la conexión al backend es exitosa (paso n.° 1). Sin embargo, se agotó el tiempo de espera del protocolo de enlace SSL porque el servidor de backend nunca respondió.

Si realizaste los pasos para solucionar problemas de esta guía y determinaste que un tiempo de espera causó el error del protocolo de enlace TLS/SSL, ve a la sección Solución.

Usa API Monitoring para identificar un problema

API Monitoring te permite aislar las áreas con problemas rápidamente para diagnosticar problemas de errores, rendimiento y latencia, y su fuente, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Sigue un ejemplo de situación que muestra cómo solucionar problemas 5xx con tus APIs mediante API Monitoring. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de fallas de messaging.adaptors.http.BadGateway supere un umbral determinado.

Solución

Por lo general, los tiempos de espera del protocolo de enlace SSL ocurren debido a las restricciones de firewall en el servidor de backend que bloquean el tráfico de Apigee Edge. Si seguiste los pasos de diagnóstico y determinaste que la causa del error del protocolo de enlace es un tiempo de espera, debes comunicarte con tu equipo de red para identificar la causa y corregir las restricciones del firewall.

Ten en cuenta que las restricciones del firewall se pueden imponer en diferentes capas de red. Es importante asegurarse de que se quiten las restricciones en todas las capas de red relacionadas con las IPs del Message Processor para garantizar un flujo de tráfico fluido entre Apigee Edge y el servidor de backend.

Si no hay restricciones de firewall o si el problema persiste, ve a Se debe recopilar información de diagnóstico.

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. Comunícate con el equipo de asistencia de Apigee Edge y compártela:

  1. Si eres usuario de la nube pública, proporciona la siguiente información:
    1. Nombre de la organización
    2. Nombre del entorno
    3. Nombre del proxy de API
    4. Comando curl completo para reproducir el error
    5. Archivo de seguimiento que muestra el error
    6. Paquetes TCP/IP capturados en el servidor de backend
  2. Si eres usuario de la nube privada, proporciona la siguiente información:
    1. Mensaje de error completo observado
    2. Paquete de proxy de API
    3. Archivo de seguimiento que muestra el error
    4. Registros del procesador de mensajes /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Paquetes TCP/IP capturados en el servidor de backend o el Message Processor
  3. Detalles sobre las secciones de esta guía que probaste y cualquier otra información que nos ayude a acelerar la resolución de este problema