Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

502 Bad Gateway

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

Síntoma

La aplicación cliente obtiene un código de estado HTTP 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 recibe una respuesta válida de los servidores de backend que deberían cumplir con 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 observes los siguientes mensajes de error:

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Si el error proviene del servidor de backend, es posible que veas algo como esto. El mensaje de error del backend depende por completo de su implementación.

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Causas posibles

Estas son algunas de las posibles causas que pueden generar el error 502 Bad Gateway para las APIs que pasan por Apigee Edge:

Causa	Descripción	Instrucciones de solución de problemas aplicables para
No hay MPs disponibles en el grupo	Este error se observa si todos los MPs del grupo no están disponibles, es decir, están inactivos o ocupados y, por lo tanto, no responden.	Usuarios de la nube privada de Edge
Configuración incorrecta de SSL entre routers y MPs	Este error se observa si falta el certificado raíz firmado por la CA del cliente en el almacén de certificados de confianza del router de Edge.	Usuarios de la nube privada de Edge
Error del servidor de backend	Este error se observará si el servidor de backend falla y envía esta respuesta.	Usuarios de la nube pública y privada de Edge

Causa: No hay MPs disponibles en el grupo

Este error se producirá si el router descubre que todos los Message Processors de una región o centro de datos determinados no están disponibles (por ejemplo, si todos están inactivos).

Apigee Edge está configurado de tal manera que el tráfico de API entrante (solicitudes) en una región o centro de datos determinados siempre se enruta desde los routers a los Message Processors (MPs) en la misma región o centro de datos. En algunos casos, los componentes de Apigee Edge se pueden configurar en una sola región o centro de datos y, en otros casos, en más de una región o centro de datos. En cada región o centro de datos, se configurarán dos o más routers y Message Processors.

Diagnóstico

Determina la región o el centro de datos en los que fallan las solicitudes a la API con el error 502 Bad Gateway, si hay más de una región o centro de datos. Para ello, identifica la región en la que los usuarios observan errores 502 o verifica los registros de acceso de NGINX en el directorio /opt/apigee/var/log/edge-router/nginx/ en cada uno de los routers que pertenecen a diferentes regiones.

Verás el siguiente error en los registros de errores de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)

2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

Situación 1: Todos los Message Processors están inactivos

Verifica si los Message Processors de la región o el centro de datos específicos están en funcionamiento.
Si todos los Message Processors están inactivos, reinícialos.

Solución

Reinicia todos los Message Processors con el siguiente comando:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Situación 2: Todos los Message Processors están ocupados procesando solicitudes en curso

Este error se producirá si los routers descubren que todos los Message Processors de una región o centro de datos determinados no están disponibles, ya que todos están ocupados procesando solicitudes en curso.

Verifica si los Message Processors de la región o el centro de datos específicos están en funcionamiento.
Si todos los Message Processors están activos, verifica si el Message Processor tiene un uso elevado de CPU y, luego, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:
```
<JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
Si el Message Processor tiene un uso elevado de memoria, genera un volcado de montón con el siguiente comando:
```
sudo -u apigee /bin/jmap -dump:live,format=b,file= 
```
Reinicia el Message Processor con el siguiente comando. Debería reducir la CPU y la memoria:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Supervisa las llamadas a la API para confirmar si el problema persiste.
Comunícate con la Asistencia de Apigee y proporciona los volcados de subprocesos, el volcado de montón y los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) para ayudar a investigar la causa del uso elevado de CPU o memoria.

Causa: Configuración incorrecta de SSL entre routers y MPs

Diagnóstico

Verifica los registros de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Verás la respuesta 502 como se muestra a continuación:

    2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-

Verifica los registros de errores de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Verás errores como este:

	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"

Esto muestra que falla el protocolo de enlace SSL entre el router y el Message Processor.
Si observas con atención el mensaje de error en los pasos 1 y 2, el puerto que se usa para comunicarse con el Message Processor es 8998, que es un puerto no seguro, pero el protocolo es SSL (https). Por lo general, el puerto seguro que se usa es 8443. Dado que se usa un puerto no seguro para la comunicación segura, se produce la falla del protocolo de enlace SSL.
Por lo general, esto puede suceder si omitiste algún paso o estableciste valores incorrectos mientras configurabas SSL entre el router y el Message Processor. Consulta los pasos que se describen aquí.
Por ejemplo, este error puede ocurrir en los siguientes casos:
1. El puerto se especifica como 8998 en lugar de 8443 en /opt/apigee/customer/application/message-processor.properties as shown below
```
        conf/message-processor-communication.properties+local.http.port=8998
```
2. Los archivos de configuración del router en el directorio /opt/nginx/conf.d/* no se borran y el router no se reinicia mientras se realiza la configuración de SSL. En este caso, puedes observar que el puerto de los Message Processors seguirá siendo 8998 en los archivos de configuración.

Solución

Asegúrate de seguir correctamente todos los pasos que se proporcionan en Configura TLS entre un router y un Message Processor.
Si el problema persiste, consulta Recopila información de diagnóstico.

Causa: Error del servidor de backend

Diagnóstico

Si el error se produce cada vez, puedes capturar el seguimiento de la IU para las solicitudes con errores. Selecciona una solicitud con errores y navega por las distintas fases del seguimiento. Si observas que obtienes el mensaje “502 Bad Gateway” del propio servidor de backend, el problema podría deberse a que se produjo alguna falla en el servidor de backend.
Seguimiento que muestra el mensaje 502 Bad Gateway que proviene del servidor de backend
Si el problema es intermitente y no puedes capturar el seguimiento,
1. Si eres usuario de la nube pública, puedes usar Supervisión de API y verificar los detalles sobre los errores 502.
  1. Si observas que el código de falla es messaging.adaptors.http.flow.ErrorResponseCode y la fuente de la falla es target, el error se debe al servidor de backend.
2. Si eres usuario de la nube privada, puedes analizar los registros de acceso de NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
  Verás la entrada de la solicitud con errores de la siguiente manera:
```
2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
```
  1. Si observas que el código de falla es messaging.adaptors.http.flow.ErrorResponseCode y la fuente de la falla es target, el error se debe al servidor de backend.

Solución

Trabaja con tu equipo del servidor de backend para solucionar este problema en el backend.

Recopila información de diagnóstico

Registros de acceso de NGINX
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
y registros de errores
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
Registros de Message Processor
(/opt/apigee/var/log/edge-message-processor/logs/system.log).