Se usó la API de Cloud Translation para traducir esta página.

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

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

Síntoma

La aplicación cliente recibe un error 502 Bad Gateway. 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 veas el siguiente mensaje de error:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Causa posible

En la siguiente tabla, se indica la posible causa de este problema:

Causa	Descripción	Sigue estos pasos para solucionar el problema
Tiempo de espera del protocolo de enlace TLS/SSL	Se agota el tiempo de espera durante el protocolo de enlace TLS/SSL entre el procesador de mensajes y el servidor de backend.	Usuarios de la nube pública y privada de Edge

Causa: Se agotó el tiempo de espera del protocolo de enlace TLS/SSL

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

Un protocolo de enlace TLS/SSL implica varios pasos. Este error suele ocurrir 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 de protocolo de enlace TLS/SSL. Allí encontrarás las instrucciones para la nube privada perimetral y la nube pública.

Cómo investigar los resultados de una sesión de Trace

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

En la IU de Edge, habilita una sesión de seguimiento para el proxy de API afectado.
Si el seguimiento de la solicitud a la API fallida 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 está bloqueando el tráfico de Apigee.
1. Determina si el error 502 Bad Gateway ocurre después de 55 segundos, que es el tiempo de espera predeterminado establecido en Message Processor. Si ves que el error ocurrió después de 55 segundos, esto indica que la causa probable del problema fue que se agotó el tiempo de espera.
2. Determina si el error muestra la falla: messaging.adaptors.http.BadGateway. Nuevamente, este error suele indicar que se agotó el tiempo de espera.
3. Si estás en Edge Private Cloud, 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 solucionar otros problemas, como se explica más adelante.
  1. Haz clic en el ícono de datos de Analytics registrados en la ruta del seguimiento:
  2. Desplácese hacia abajo y observe 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 te encuentras en una nube pública o en una nube privada.

Pasos de diagnóstico adicionales solo para usuarios de Edge Private Cloud

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, inspeccionarás el archivo de registro de Message Processor para obtener información relevante. Si estás en la nube pública de Edge, puedes omitir esta sección y dirigirte a Pasos de diagnóstico adicionales para usuarios de la nube pública y privada.

Verifica 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 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 el comando telnet falla, debes trabajar con tu equipo de redes para verificar la conectividad entre el procesador de mensajes y el servidor de backend.
Revisa el archivo de registro de 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 del mensaje único (el valor de X-Apigee.Message-ID que encontraste en el archivo de seguimiento). Determina si ves un mensaje de error de protocolo de enlace asociado con el ID del 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 Otros pasos de diagnóstico para usuarios de Edge Private y Public Cloud.

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

Pasos de diagnóstico adicionales para usuarios de Edge Private y Public Cloud

Para identificar aún más el problema, puedes usar la herramienta tcpdump a fin de analizar los paquetes TCP/IP y confirmar si se agotó el tiempo de espera durante el protocolo de enlace TLS/SSL.

Si eres un usuario de la nube privada, puedes capturar los paquetes TCP/IP en el servidor de backend o en el procesador de mensajes. Es preferible capturarlos en el servidor de backend, ya que los paquetes se desencriptan en este.
Si eres un usuario de la nube pública, no tienes acceso al procesador de mensajes. Sin embargo, capturar los paquetes de TCP/IP en el servidor de backend puede ayudar a identificar un problema.
Después de decidir dónde capturar los paquetes de TCP/IP, usa el siguiente comando tcpdump para capturar los paquetes de TCP/IP.
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
- Si tomas los paquetes de TCP/IP en el servidor de backend, usa la dirección IP pública del Message Processor en el comando tcpdump. Si deseas obtener ayuda con el uso del comando para examinar el tráfico del servidor de backend, consulta tcpdump.
- Si tomas los paquetes TCP/IP en el procesador de mensajes, usa la dirección IP pública del servidor de backend en el comando tcpdump. Si quieres obtener ayuda con el comando para examinar el tráfico de Message Processor, consulta tcpdump.
- Si hay varias direcciones IP para el servidor de backend o el procesador de mensajes, debes probar otro uso del comando tcpdump. Consulta tcpdump para obtener más información sobre esta herramienta y otras variantes de este comando.
Analiza los paquetes TCP/IP con la herramienta de Wireshark o una herramienta similar. En la siguiente captura de pantalla, se muestran los paquetes TCP/IP de Wireshark.
Observa en el resultado de Wireshark que el protocolo de enlace TCP de tres vías se completa correctamente en los primeros 3 paquetes.
Luego, Message Processor envía el mensaje “Client Hello” en el paquete n.o 4.
Debido a que no hay una confirmación del servidor de backend, el Message Processor retransmite el mensaje “Client Hello” varias veces en los paquetes 5, 6 y 7 después de esperar un intervalo de tiempo predefinido.
Cuando 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 está cerrando la conexión.
Como se mostró en la sesión de Wireshark de ejemplo, la conexión al backend es exitosa (paso 1). Sin embargo, se agotó el tiempo de espera del protocolo de enlace SSL porque el servidor de backend nunca respondió.

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

Uso de la supervisión de API para identificar un problema

La supervisión de API te permite aislar las áreas problemáticas con rapidez a fin de diagnosticar problemas de error, rendimiento y latencia y su fuente, como apps para desarrolladores, proxies de API, objetivos de backend o la plataforma de API.

Analiza una situación de muestra en la que se demuestra cómo solucionar problemas 5xx de tus APIs con la supervisión de APIs. Por ejemplo, es posible que desees configurar una alerta para que se te notifique cuando la cantidad de fallas de messaging.adaptors.http.BadGateway supere un umbral determinado.

Resolución

Por lo general, los tiempos de espera del protocolo de enlace SSL se producen debido a 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 de 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 de firewall podrían imponerse en diferentes capas de red. Es importante asegurarse de que se quiten las restricciones en todas las capas de red relacionadas con las IP de 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 el problema persiste, ve a Debes 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 ellos y compártelos en el equipo de asistencia de Apigee Edge:

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 de proxy de API
4. Completa el comando curl para reproducir el error
5. Archivo de seguimiento que muestra el error
6. Paquetes TCP/IP capturados en el servidor de backend
Si eres usuario de una nube privada, proporciona la siguiente información:
1. Se observó un mensaje de error completo
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 en el procesador de mensajes
Detalles sobre las secciones de esta Guía que probaste y cualquier otra información que nos ayude a resolver este problema rápidamente.