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 viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. info

Síntoma

La aplicación cliente recibe un error de puerta de enlace incorrecta 502. El procesador de mensajes 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 se pueden realizar
Tiempo de espera del protocolo de enlace TLS/SSL	Se produce un 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: 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 el procesador de mensajes perimetrales 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 procesador de mensajes y un servidor de backend.

Diagnóstico

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

Investiga el resultado 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.

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 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 Puerta de enlace incorrecta ocurre después de 55 segundos, que es el tiempo de espera predeterminado configurado en el procesador de mensajes. Si ves que el error ocurrió después de 55 segundos, esto te indica que el tiempo de espera fue el causa probable del problema.
2. Determina si el error muestra el error messaging.adaptors.http.BadGateway. Una vez más, este error suele indicar que se produjo un tiempo de espera.
3. Si usas 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 Private Cloud puede usar este valor de ID para solucionar más 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 error se debe al tiempo de espera del protocolo de enlace TLS/SSL, sigue los pasos que se indican en las siguientes secciones dependiendo de si te encuentras en una nube pública o en una privada.

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

Si usas la nube privada de Apigee Edge, puedes seguir los pasos que se indican a continuación para verificar la causa del error de enlace. En este paso, inspeccionarás el archivo de registro del procesador de mensajes en busca de información relevante. Si usas la nube perimetral pública, puedes omitir esta sección y pasar a Otros pasos de diagnóstico para usuarios de nubes privadas y públicas.

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 tener errores, continúa con el paso siguiente.

Si el comando telnet falla, debes trabajar con tu equipo de red para verificar la conectividad entre el procesador de mensajes y el servidor de backend.
Revisa el archivo de registro del procesador de mensajes para ver si hay evidencia de un error 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 registro). Determina si ves un mensaje de error 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 Otros pasos de diagnóstico para usuarios de la nube pública y privada de Edge.

Si no ves el mensaje de enlace de manos en el archivo de registro, consulta Debes recopilar información de diagnóstico.

Más pasos de diagnóstico para los usuarios de la nube pública y privada perimetral

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

Si eres un usuario de la nube privada, puedes capturar los paquetes de TCP/IP en la de backend o Message Processor. Preferentemente, capturarlos en el backend porque los paquetes se desencriptan en el servidor de backend.
Si eres un usuario de Public Cloud, 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.
Después de decidir dónde capturar los paquetes TCP/IP, usa el siguiente comando tcpdump 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 el Dirección IP del procesador de mensajes en el comando tcpdump. Si necesitas ayuda para usar el 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 necesitas ayuda para usar el comando para examinar el tráfico del procesador de mensajes, consulta tcpdump.
- Si hay varias direcciones IP para el servidor de backend o 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.
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 en 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, el procesador de mensajes envía el mensaje "Client Hello" en el paquete n° 4.
Como no hay una 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.
Cuando el procesador de mensajes 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 viste en la sesión de Wireshark de ejemplo, la conexión al backend funciona correctamente (paso no 1); sin embargo, se agotó el tiempo de espera del protocolo de enlace SSL porque el backend servidor nunca respondió.

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

Usa la supervisión de API para identificar un problema

La supervisión de API te permite aislar las áreas problemáticas con rapidez 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.

Analizar una situación de ejemplo que demuestra cómo solucionar problemas 5xx con tus APIs con la supervisión de API. Por ejemplo, quizás quieres configurar una alerta para que se te notifique cuando la cantidad de messaging.adaptors.http.BadGateway supera un determinado umbral.

Solución

Normalmente, el tiempo de espera del protocolo de enlace SSL se produce por restricciones del firewall en el servidor de backend que bloquea el tráfico de Apigee Edge. Si seguiste los pasos de diagnóstico y determinaste que la causa del error 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 quitar las restricciones en todas las capas de red a las IP del procesador de mensajes 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 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 comparte los datos con ellos:

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. 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 la 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 rápidamente este problema.