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 502 Bad Gateway. 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 al servidor de backend para habilitar la comunicación TLS entre el procesador de mensajes 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 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 protocolo de enlace TLS/SSL. Se incluyen instrucciones para la nube privada y pública de Edge.

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 Trace para el proxy de API afectado.
Si el registro de la solicitud a la API que falla 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 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 se produjo después de 55 segundos, significa que un tiempo de espera fue la causa probable del problema.
2. Determina si el error muestra la falla: messaging.adaptors.http.BadGateway. Nuevamente, este error, por lo general, indica que se agotó el 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 tiempo de espera de la negociación TLS/SSL fue la causa del error, sigue los pasos que se indican en las siguientes secciones según si usas la nube pública o la privada.

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

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 pública perimetral, puedes omitir esta sección y dirigirte a Pasos adicionales de diagnóstico para los 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 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 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. Consulta Más pasos de diagnóstico para usuarios de nubes públicas y privadas perimetrales.

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 usuarios de Edge Private y Public Cloud

Para identificar mejor 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 Private Cloud, puedes capturar los paquetes TCP/IP en el servidor de backend o el procesador de mensajes. De preferencia, captúralos en el servidor de backend, ya que los paquetes se desencriptan en él.
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 la dirección IP pública 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 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 se muestra en la sesión de ejemplo de Wireshark, la conexión al backend es correcta (paso 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 este libro de jugadas y determinaste que un tiempo de espera causó el error de protocolo de enlace TLS/SSL, ve a la sección Resolución.

Usar 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, de rendimiento y latencia y sus fuentes, como las apps para desarrolladores, los proxies de API, los objetivos de backend o la plataforma de API.

Revisa una situación de ejemplo que muestra cómo solucionar problemas de 5xx con tus APIs mediante el monitoreo de APIs. 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 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 del protocolo de enlace es un tiempo de espera, debes comunicarte con tu equipo de red para identificar la causa y corregir las restricciones de firewall.

Ten en cuenta que las restricciones del firewall se pueden imponer en diferentes capas de red. Es importante asegurarse de quitar las restricciones de todas las capas de red relacionadas con 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, consulta 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 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 registro 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 acelerar la resolución de este problema