Estás consultando la documentación de Apigee Edge.
Consulta la
documentación de Apigee X. Información
Síntoma
La aplicación cliente obtiene un código de estado HTTP de 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 está recibiendo una respuesta válida de los servidores de backend que realmente deba completar 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 veas el siguiente mensaje de error:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Causas posibles
Una de las causas típicas de 502 Bad Gateway Error
es el error Unexpected EOF
, que puede deberse a los siguientes motivos:
Causa | Detalles | Pasos dados para |
---|---|---|
El servidor de destino está configurado incorrectamente | El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL. | Usuarios de la nube pública y privada de Edge |
EOFException del servidor de backend | El servidor de backend puede enviar EOF de forma abrupta. | Solo usuarios de la nube privada perimetral |
Se configuró incorrectamente el tiempo de espera de mantenimiento en vivo. | Tiempos de espera de mantenimiento activos configurados incorrectamente en Apigee y en el servidor de backend. | Usuarios de la nube pública y privada de Edge |
Pasos comunes de diagnóstico
Para diagnosticar el error, puedes usar cualquiera de los siguientes métodos:
Supervisión de API
Para diagnosticar el error con la supervisión de la API, sigue estos pasos:
Con la supervisión de API, puedes investigar los errores 502
si sigues los pasos que se explican en Investigar problemas. Es decir:
- Ve al panel Investigate (Investigate).
- Selecciona Status Code en el menú desplegable y asegúrate de que esté seleccionado el período correcto cuando se produjeron los errores
502
. - Haz clic en el cuadro de la matriz cuando veas una gran cantidad de errores
502
. - En el lado derecho, haz clic en Ver registros para ver los errores
502
, que se verían de la siguiente manera: - Fuente de errores es
target
- Código de fallas es
messaging.adaptors.http.UnexpectedEOFAtTarget
Aquí podemos ver la siguiente información:
Esto indica que el objetivo causa el error 502
debido a un EOF inesperado.
Además, toma nota de Request Message ID
para el error 502
a fin de realizar una investigación más detallada.
Herramienta de seguimiento
Para diagnosticar el error con la herramienta Trace, sigue estos pasos:
- Habilita la
sesión de registro y realiza la llamada a la API para reproducir el problema
502 Bad Gateway
. - Selecciona una de las solicitudes con errores y examina el seguimiento.
- Navega por las distintas fases del seguimiento y localiza dónde ocurrió la falla.
-
Deberías ver el error después de que la solicitud se haya enviado al servidor de destino, como se muestra a continuación:
-
Determina el valor de X-Apigee.fault-source y X-Apigee.fault-code en la fase AX (datos de Analytics registrados) en el seguimiento.
Si los valores de X-Apigee.fault-source y X-Apigee.fault-code coinciden con los valores que se muestran en la siguiente tabla, puedes confirmar que el error
502
provenga del servidor de destino:Encabezados de respuesta Valor Fuente de X-Apigee.fault target
Código X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Además, toma nota de
X-Apigee.Message-ID
para el error502
a fin de realizar una investigación más detallada.
Registros de acceso de NGINX
Para diagnosticar el error con NGINX, sigue estos pasos:
También puedes consultar los registros de acceso de NGINX para determinar la causa del código de estado 502
. Esto es muy útil si el problema ocurrió en el pasado o si es intermitente y no puedes capturar el registro en la IU. Sigue estos pasos para determinar esta información a partir de los registros de acceso de NGINX:
- Verifica los registros de acceso de NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Busca cualquier error
502
del proxy de API específico durante un período específico (si el problema ocurrió en el pasado) o cualquier solicitud que aún falla con502
. - Si hay algún error
502
, verifica si la causa del destino es el envío deUnexpected EOF
. Si los valores de X-Apigee.fault-source y X-Apigee.fault-code coinciden con los valores que se muestran en la siguiente tabla, el error502
se produce porque el destino cierra la conexión de forma inesperada:Encabezados de respuesta Valor Fuente de X-Apigee.fault target
Código X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Esta es una entrada de ejemplo que muestra el error
502
causado por el servidor de destino:
Además, toma nota de los IDs de los mensajes de los errores 502
para realizar una investigación más detallada.
Causa: El servidor de destino no se configuró correctamente
El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL.
Diagnóstico
- Usa la supervisión de la API, la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código de falla y la fuente de la falla del error
502
. - Habilita el registro en la IU de la API afectada.
- Si el seguimiento de la solicitud a la API fallida muestra lo siguiente:
- El error
502 Bad Gateway
se observa en cuanto se inicia la solicitud de flujo de destino. - El
error.class
muestramessaging.adaptors.http.UnexpectedEOF.
Entonces, es muy probable que este problema se deba a una configuración incorrecta del servidor de destino.
- El error
- Obtén la definición del servidor de destino mediante la llamada a la API de Edge Management:
- Si eres un usuario de la nube pública, usa esta API:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Si eres un usuario de la nube privada, usa esta API:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Ejemplo de definición de
TargetServer
defectuosa:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Si eres un usuario de la nube pública, usa esta API:
-
La definición
TargetServer
ilustrada es un ejemplo de una de las configuraciones incorrectas típicas que se explica de la siguiente manera:Supongamos que el servidor de destino
mocktarget.apigee.net
está configurado para aceptar conexiones seguras (HTTPS) en el puerto443
. Sin embargo, si observas la definición del servidor de destino, no hay otros atributos o marcas que indiquen que está destinado a conexiones seguras. Esto hace que Edge trate las solicitudes a la API que se dirigen al servidor de destino específico como solicitudes HTTP (no seguras). Por lo tanto, Edge no iniciará el proceso de protocolo de enlace SSL con este servidor de destino.Dado que el servidor de destino está configurado solo para aceptar solicitudes HTTPS (SSL) en
443
, rechazará la solicitud de Edge o cerrará la conexión. Como resultado, obtendrás un errorUnexpectedEOFAtTarget
en Message Processor. Message Processor enviará502 Bad Gateway
como respuesta al cliente.
Resolución
Asegúrate siempre de que el servidor de destino esté configurado de forma correcta según tus requisitos.
En el ejemplo anterior, si quieres realizar solicitudes a un servidor de destino seguro (HTTPS/SSL), debes incluir los atributos SSLInfo
con la marca enabled
establecida en true
. Si bien se permite agregar los atributos SSLInfo
para un servidor de destino en la propia definición del extremo de destino, se recomienda agregar los atributos SSLInfo
como parte de la definición del servidor de destino para evitar confusiones.
- Si el servicio de backend requiere comunicación SSL unidireccional, haz lo siguiente:
- Debes habilitar TLS/SSL en la definición de
TargetServer
. Para ello, debes incluir los atributosSSLInfo
en los que la marcaenabled
está configurada como verdadera, como se muestra a continuación:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Si quieres validar el certificado del servidor de destino en Edge, también debemos
incluir el almacén de confianza (que contiene el certificado del servidor de destino) como se muestra a continuación:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- Debes habilitar TLS/SSL en la definición de
- Si el servicio de backend requiere comunicación SSL bidireccional, haz lo siguiente:
- Debes tener los atributos
SSLInfo
con las marcasClientAuthEnabled
,Keystore
,KeyAlias
yTruststore
configuradas correctamente, como se muestra a continuación:<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- Debes tener los atributos
Referencias
Balanceo de cargas entre servidores de backend
Causa: EOFException del servidor de backend
El servidor de backend puede enviar EOF (final de archivo) de forma abrupta.
Diagnóstico
- Usa la supervisión de la API, la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código de falla y la fuente de la falla del error
502
. - Revisa los registros de Message Processor (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) y busca si tieneseof unexpected
para la API específica o si tienes elmessageid
único de la solicitud a la API, puedes buscarlo.Ejemplo de seguimiento de pila de excepciones del registro de Message Processor
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
En el ejemplo anterior, puedes ver que se produjo el error
java.io.EOFException: eof unexpected
mientras Message Processor intenta leer una respuesta del servidor de backend. Esta excepción indica el final del archivo (EOF) o el final de la transmisión se alcanzó de forma inesperada.Es decir, Message Processor envió la solicitud a la API al servidor de backend y estaba esperando o leyendo la respuesta. Sin embargo, el servidor de backend finalizó la conexión de forma abrupta antes de que Message Processor recibiera la respuesta o pudiera leer la respuesta completa.
- Verifica los registros del servidor de backend y comprueba si hay algún error o información que podría haber provocado que el servidor de backend finalice la conexión de forma abrupta. Si encuentras información o error, ve a Resolución y corrige el problema de forma adecuada en tu servidor de backend.
- Si no encuentras errores ni información en tu servidor de backend, recopila el resultado de
tcpdump
en Message Processor:- Si el host de tu servidor de backend tiene una sola dirección IP, usa el siguiente comando:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Si el host de tu servidor de backend tiene varias direcciones IP, usa el siguiente comando:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
Por lo general, este error se produce porque el servidor de backend responde con
[FIN,ACK]
en cuanto Message Processor envía la solicitud al servidor de backend.
- Si el host de tu servidor de backend tiene una sola dirección IP, usa el siguiente comando:
-
Considera el siguiente ejemplo de
tcpdump
.Ejemplo de
tcpdump
tomada cuando ocurrió502 Bad Gateway Error
(UnexpectedEOFAtTarget
) - En el resultado de TCPDump, observas la siguiente secuencia de eventos:
- En el paquete
985
, Message Processor envía la solicitud a la API al servidor de backend. - En el paquete
986
, el servidor de backend responde de inmediato con[FIN,ACK]
. - En el paquete
987
, Message Processor responde con[FIN,ACK]
al servidor de backend. - Finalmente, las conexiones se cierran con
[ACK]
y[RST]
de ambos lados. - Dado que el servidor de backend envía
[FIN,ACK]
, obtendrás la excepciónjava.io.EOFException: eof unexpected
en el procesador de mensajes.
- En el paquete
- Esto puede ocurrir si hay un problema de red en el servidor de backend. Comunícate con tu equipo de operaciones de red para investigar este problema más a fondo.
Resolución
Soluciona el problema en el servidor de backend de forma adecuada.
Si el problema persiste y necesitas ayuda para solucionar problemas 502 Bad Gateway Error
o
sospechas que es un problema de Edge, comunícate con el equipo de asistencia de Apigee Edge.
Causa: Se configuró incorrectamente el tiempo de espera de mantenimiento en vivo.
Antes de diagnosticar si esta es la causa de los errores 502
, lee los siguientes conceptos.
Conexiones persistentes en Apigee
De forma predeterminada (y con el estándar HTTP/1.1), Apigee usa conexiones persistentes cuando se comunica con el servidor de backend de destino. Las conexiones persistentes pueden aumentar el rendimiento, ya que permiten que se reutilicen una conexión TCP y TLS/SSL ya establecida (si corresponde), lo que reduce las sobrecargas de latencia. La duración de la persistencia de una conexión se controla mediante una propiedad tiempo de espera de keep-alive (keepalive.timeout.millis
).
El servidor de backend y el procesador de mensajes de Apigee usan tiempos de espera de mantenimiento de inactividad para mantener las conexiones abiertas entre sí. Una vez que no se reciben datos dentro del tiempo de espera de mantenimiento de actividad, el servidor de backend o el procesador de mensajes pueden cerrar la conexión con el otro.
De forma predeterminada, los proxies de API implementados en Message Processor en Apigee tienen un tiempo de espera de keep-alive establecido en 60s
, a menos que se anule. Una vez que no se reciban datos para 60s
, Apigee cerrará la conexión con el servidor de backend. El servidor de backend también mantendrá un tiempo de espera de mantenimiento de actividad y,
una vez que este venza, el servidor de backend cerrará la conexión con Message Processor.
Implica una configuración incorrecta del tiempo de espera de mantenimiento de actividad
Si Apigee o el servidor de backend están configurados con tiempos de espera de mantenimiento en funcionamiento incorrectos, se genera una condición de carrera que hace que el servidor de backend envíe un End Of File
(FIN)
inesperado en respuesta a una solicitud de un recurso.
Por ejemplo, si el tiempo de espera de keepalive se configura en el proxy de API o en el procesador de mensajes con un valor mayor o igual que el tiempo de espera del servidor de backend ascendente, puede ocurrir la siguiente condición de carrera. Es decir, si el Message Processor no recibe ningún dato hasta muy cerca del umbral del tiempo de espera de mantenimiento del servidor de backend, entonces se procesa una solicitud y se envía al servidor de backend con la conexión existente. Esto puede generar 502 Bad Gateway
debido a un error de EOF inesperado, como se explica a continuación:
- Supongamos que el tiempo de espera de keep-alive configurado en el procesador de mensajes y en el servidor de backend es de 60 segundos y no se recibió ninguna solicitud nueva hasta 59 segundos después de que el Message Processor específico entregó la solicitud anterior.
- El Message Processor continúa y procesa la solicitud que se recibió en el segundo 59 mediante la conexión existente (ya que aún no ha transcurrido el tiempo de espera de mantenimiento en vivo) y envía la solicitud al servidor de backend.
- Sin embargo, antes de que la solicitud llegue al servidor de backend, se superó el umbral de tiempo de espera de mantenimiento en funcionamiento en el servidor de backend.
- La solicitud de Message Processor para un recurso está en curso, pero el servidor de backend intenta cerrar la conexión mediante el envío de un paquete
FIN
a Message Processor. - Mientras Message Processor espera la recepción de los datos, recibe el
FIN
inesperado y finaliza la conexión. - Esto da como resultado una
Unexpected EOF
y, luego, Message Processor al cliente muestra una502
.
En este caso, observamos que se produjo el error 502
porque se configuró el mismo valor de tiempo de espera de keepalive de 60 segundos en el procesador de mensajes y en el servidor de backend. Del mismo modo, este problema puede ocurrir si se configura un valor más alto para el tiempo de espera de mantenimiento de actividad en el procesador de mensajes que en el servidor de backend.
Diagnóstico
- Si eres un usuario de la nube pública, haz lo siguiente:
- Usa la herramienta de supervisión de API o de Trace (como se explica en Pasos comunes de diagnóstico) y verifica que cuentas con las siguientes opciones de configuración:
- Código de falla:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Fuente de errores:
target
- Código de falla:
- Ve a Cómo usar tcpdump para obtener más información.
- Usa la herramienta de supervisión de API o de Trace (como se explica en Pasos comunes de diagnóstico) y verifica que cuentas con las siguientes opciones de configuración:
- Si eres un usuario de la nube privada, sigue estos pasos:
- Usa la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código y la fuente de las fallas del error
502
. - Busca el ID del mensaje en el registro de Message Processor
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Verás el elemento
java.io.EOFEXception: eof unexpected
como se muestra a continuación:2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- El error
java.io.EOFException: eof unexpected
indica que Message Processor recibió unEOF
mientras se esperaba la lectura de una respuesta del servidor de backend. - El atributo
useCount=7
del mensaje de error anterior indica que Message Processor reutilizó esta conexión unas siete veces, y el atributobytesWritten=159
indica que Message Processor envió la carga útil de la solicitud de159
bytes al servidor de backend. Sin embargo, recibió cero bytes cuando se produjo el errorEOF
inesperado. -
Esto muestra que el procesador de mensajes volvió a usar la misma conexión varias veces y, en esta ocasión, envió datos, pero poco después recibió un
EOF
antes de que se recibiran los datos. Esto significa que hay una alta probabilidad de que el tiempo de espera de mantenimiento en funcionamiento del servidor de backend sea menor o igual que el establecido en el proxy de API.Puedes investigar más a fondo con la ayuda de
tcpdump
, como se explica a continuación.
- Usa la herramienta de seguimiento o los registros de acceso de NGINX para determinar el ID del mensaje, el código y la fuente de las fallas del error
Usa tcpdump
- Captura un
tcpdump
en el servidor de backend con el siguiente comando:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Analiza los
tcpdump
capturados:Este es un ejemplo de resultado de tcpdump:
En el
tcpdump
de muestra anterior, puedes ver lo siguiente:- En el paquete
5992,
, el servidor de backend recibió una solicitudGET
. - En el paquete
6064
, responde con200 OK.
. - En el paquete
6084
, el servidor de backend recibió otra solicitudGET
. - En el paquete
6154
, responde con200 OK
. - En el paquete
6228
, el servidor de backend recibió una tercera solicitudGET
. - Esta vez, el servidor de backend muestra un
FIN, ACK
al Message Processor (paquete6285
) que inicia el cierre de la conexión.
En este ejemplo, la misma conexión se volvió a usar dos veces de forma correcta, pero en la tercera solicitud, el servidor de backend inicia un cierre de la conexión, mientras que Message Processor espera los datos del servidor de backend. Esto sugiere que el tiempo de espera de mantenimiento del servidor de backend probablemente sea menor o igual que el valor establecido en el proxy de API. Para validar esto, consulta Compara el tiempo de espera de mantenimiento de actividad en Apigee y el servidor de backend.
- En el paquete
Compara el tiempo de espera de mantenimiento en funcionamiento en Apigee y el servidor de backend
- Según la configuración predeterminada, Apigee usa un valor de 60 segundos para la propiedad de tiempo de espera de keepalive.
-
Sin embargo, es posible que hayas anulado el valor predeterminado en el proxy de API. Para verificar esto, revisa la definición específica de
TargetEndpoint
en el proxy de API que falla y que genera errores502
.Ejemplo de configuración de TargetEndpoint:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
En el ejemplo anterior, la propiedad de tiempo de espera de keep alive se anula con un valor de 30 segundos (
30000
milisegundos). - A continuación, verifica la propiedad de tiempo de espera de keep-alive configurada en tu servidor de backend. Supongamos que tu servidor de backend está configurado con un valor de
25 seconds
. - Si determinas que el valor de la propiedad de tiempo de espera de keep alive en Apigee es mayor que el valor de la propiedad de tiempo de espera de keep alive en el servidor de backend, como en el ejemplo anterior, esa es la causa de los errores
502
.
Resolución
Asegúrate de que la propiedad de tiempo de espera de keepalive siempre sea más baja en Apigee (en el componente proxy de API y procesador de mensajes) en comparación con la del servidor de backend.
- Determina el valor establecido para el tiempo de espera de keep-alive en el servidor de backend.
- Configura un valor adecuado para la propiedad de tiempo de espera de keep alive en el proxy de API o en el procesador de mensajes, de modo que esta propiedad sea menor que el valor establecido en el servidor de backend mediante los pasos que se describen en Configura el tiempo de espera de keep-alive en Message Processor.
Si el problema persiste, consulta Recopila información de diagnóstico.
Práctica recomendada
Se recomienda que los componentes descendentes siempre tengan un umbral de tiempo de espera de mantenimiento en vivo menor que el configurado en los servidores upstream para evitar estos tipos de condiciones de carrera y errores 502
. Cada salto descendente debe ser menor que cada salto ascendente. En Apigee Edge, se recomienda usar los siguientes lineamientos:
- El tiempo de espera de mantenimiento en funcionamiento del cliente debe ser inferior al tiempo de espera de la conservación del router perimetral.
- El tiempo de espera de activación del router perimetral debe ser menor que el tiempo de espera de la operación de mantenimiento del procesador de mensajes.
- El tiempo de espera de activación del procesador de mensajes debe ser menor que el tiempo de espera de la operación de mantenimiento del servidor de destino.
- Si hay otros saltos delante o detrás de Apigee, se debe aplicar la misma regla. Siempre debes dejar que el cliente descendente sea responsable de cerrar la conexión con el upstream.
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 y, luego, comunícate con el equipo de asistencia de Apigee Edge.
Si eres un usuario de la nube pública, proporciona la siguiente información:
- Nombre de la organización
- Nombre del entorno
- Nombre del proxy de API
- Completa el comando
curl
para reproducir el error502
- Archivo de seguimiento que contiene las solicitudes con el error
502 Bad Gateway - Unexpected EOF
- Si en este momento no se producen los errores
502
, proporciona el período con la información de la zona horaria cuando se produjeron errores502
en el pasado.
Si eres un usuario de la nube privada, proporciona la siguiente información:
- Mensaje de error completo observado para las solicitudes con errores
- Organización, nombre del entorno y nombre del proxy de API para los que observas
errores
502
- Paquete de proxy de API
- Archivo de seguimiento que contiene las solicitudes con el error
502 Bad Gateway - Unexpected EOF
- Registros de acceso de NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Registros de Message Processor
/opt/apigee/var/log/edge-message-processor/logs/system.log
- El período con la información de zona horaria en el que se produjeron los errores
502
- Se recopilaron
Tcpdumps
en los procesadores de mensajes o el servidor de backend, o en ambos cuando se produjo el error.