Estás viendo la documentación de Apigee Edge.
Ve a 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 del
los servidores de backend
que deben 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, puedes observar 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 Unexpected EOF
.
de errores, que puede deberse a los siguientes motivos:
Causa | Detalles | Pasos dados para |
---|---|---|
El servidor de destino está configurado de forma incorrecta | El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL. | Usuarios perimetrales de nubes públicas y privadas |
EOFException del servidor backend | Es posible que el servidor de backend envíe EOF de manera abrupta. | Solo usuarios de la nube privada perimetral |
Tiempo de espera de keep alive configurado de forma incorrecta | Los tiempos de espera de mantener activos están configurados de forma incorrecta en Apigee y el servidor de backend. | Usuarios perimetrales de nubes públicas y privadas |
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 API, haz lo siguiente:
Con la supervisión de API puedes investigar
los errores 502
siguiendo los pasos que se explican en
Investiga los problemas. Es decir:
- Ve al panel Investigar.
- Selecciona el Código de estado en el menú desplegable y asegúrate de que
se selecciona el período cuando se producen los errores
502
. - Haz clic en la casilla 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 verse de la siguiente manera: - La fuente del error es
target
. - El código de error 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 del Request Message ID
del error 502
para obtener más
durante tu investigación.
Herramienta de seguimiento
Para diagnosticar el error con la herramienta Trace, sigue estos pasos:
- Habilita el
de registro y realiza la llamada a la API para reproducir el problema
502 Bad Gateway
. - Selecciona una de las solicitudes fallidas y examina el seguimiento.
- Navega por las diferentes fases del seguimiento y localiza dónde se produjo la falla.
-
Deberías ver el error después de que se haya enviado la solicitud 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 AX (datos de Analytics registrados) Fase del seguimiento.
Si los valores de X-Apigee.fault-source y X-Apigee.fault-code coinciden con valores que se muestran en la siguiente tabla, puedes confirmar que el error
502
está provenientes del servidor de destino:Encabezados de respuesta Valor X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Además, toma nota del
X-Apigee.Message-ID
del error502
. para profundizar la investigación.
Registros de acceso de NGINX
Para diagnosticar el error con NGINX, haz lo siguiente:
También puedes consultar los registros de acceso de NGINX para determinar la causa del estado 502
.
código. Esto es muy útil si el problema ocurrió en el pasado o si
intermitente y no podrás 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 errores
502
para el proxy de API específico durante un período específico. (si el problema ocurrió en el pasado) o de las solicitudes que aún fallan con502
. - Si hay algún error
502
, verifica si el error lo causó el destino enviando unUnexpected 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 causado que el destino cierre la conexión de forma inesperada:Encabezados de respuesta Valor X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
A continuación, se incluye una entrada de ejemplo en la que se muestra el error
502
que causó 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 configurado es incorrecto
El servidor de destino no está configurado correctamente para admitir conexiones TLS/SSL.
Diagnóstico
- Usas la supervisión de API, la herramienta Trace o
Registros de acceso de NGINX para determinar el ID del mensaje
el código y la fuente del error
502
. - Habilita el seguimiento en la IU de la API afectada.
- Si el seguimiento de la solicitud a la API con errores muestra lo siguiente:
- El error
502 Bad Gateway
se muestra en cuanto se inicia la solicitud de flujo de destino. - El elemento
error.class
muestramessaging.adaptors.http.UnexpectedEOF.
Es muy probable que este problema se deba a un servidor de destino incorrecto. configuración.
- 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 ilustrada de
TargetServer
es un ejemplo de una de las opciones de configuración incorrecta, que se explica de la siguiente manera:Supongamos que se configuró el servidor de destino
mocktarget.apigee.net
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á para 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 para aceptar solo solicitudes HTTPS (SSL) en
443
, rechazar la solicitud de Edge o cerrar la conexión. Como resultado, obtienes un Se produjo un errorUnexpectedEOFAtTarget
en el procesador de mensajes. El procesador de mensajes enviará502 Bad Gateway
como respuesta al cliente.
Solución
Siempre asegúrate de que el servidor de destino esté configurado correctamente según tus requisitos.
En el ejemplo anterior, si quieres realizar solicitudes a un destino seguro (HTTPS/SSL)
debes incluir los atributos SSLInfo
con la marca enabled
configurada
a true
. Si bien se permite agregar los atributos SSLInfo
para un servidor de destino en el destino
definición del extremo, se recomienda agregar los atributos SSLInfo
como parte del destino
del servidor web para evitar confusiones.
- Si el servicio de backend requiere comunicación SSL unidireccional, haz lo siguiente:
- Debes habilitar TLS/SSL en la definición
TargetServer
. Para ello, incluye elSSLInfo
atributos en los que la marcaenabled
se establece en true, 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 debes
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
- Si el servicio de backend requiere comunicación SSL bidireccional, entonces:
- Debes tener atributos
SSLInfo
conClientAuthEnabled
,Keystore
,KeyAlias
y Las marcasTruststore
se configuraron 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 atributos
Referencias
Balanceo de cargas en servidores de backend
Causa: EOFException del servidor de backend
Es posible que el servidor de backend envíe EOF (fin de archivo) de manera abrupta.
Diagnóstico
- Usas la supervisión de API, la herramienta Trace o
Registros de acceso de NGINX para determinar el ID del mensaje
el código y la fuente del error
502
. - Revisa los registros de Message Processor
(
/opt/apigee/var/log/edge-message-processor/logs/system.log
) y busca para ver si Tenereof unexpected
para la API específica o si tienes elmessageid
único para la API la solicitud, puedes buscarla.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 el error
java.io.EOFException: eof unexpected
se produjo mientras el procesador de mensajes intentaba leer una respuesta de el servidor de backend. Esta excepción indica el final del archivo (EOF) o de la transmisión se haya alcanzado de forma inesperada.Es decir, Message Processor envió la solicitud a la API al servidor de backend y esperó o leer la respuesta. Sin embargo, el servidor backend finalizó la conexión de forma abrupta antes de que el procesador de mensajes recibiera la respuesta o pudiera leer la respuesta completa.
- Revisa los registros del servidor de backend y fíjate si hay algún error o información que pueda que hicieron que el servidor backend finalizara la conexión de forma abrupta. Si encuentras información o errores, ve a Resolución. y solucionar el problema correctamente en tu servidor de backend.
- Si no encuentras ningún error 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
Generalmente, este error se produce porque el servidor de backend responde con
[FIN,ACK]
tan pronto como el Message Processor envíe 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
.Muestra de
tcpdump
tomada cuando502 Bad Gateway Error
(UnexpectedEOFAtTarget
) ocurrió - 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 backend servidor. - Eventualmente, las conexiones se cierran con
[ACK]
y[RST]
en ambos lados. - Dado que el servidor de backend envía
[FIN,ACK]
, obtendrás la excepción Excepciónjava.io.EOFException: eof unexpected
en el mensaje Procesador.
- En el paquete
- Esto puede suceder si hay un problema de red en el servidor backend. Interactúa con tu red con el equipo de operaciones de analizar el problema en profundidad.
Solución
Soluciona el problema en el servidor de backend de manera adecuada.
Si el problema persiste y necesitas asistencia para solucionar el problema 502 Bad Gateway Error
o tú
Si sospechas que se trata de un problema en Edge, comunícate con el equipo de asistencia de Apigee Edge.
Causa: Tiempo de espera de keep alive configurado de forma incorrecta
Antes de diagnosticar si esta es la causa de los errores 502
, lee detenidamente
los siguientes conceptos.
Conexiones persistentes en Apigee
De forma predeterminada, Apigee (y en adelante con el estándar HTTP/1.1) usa conexiones persistentes
cuando se comunica con el servidor
backend de destino. Las conexiones persistentes pueden aumentar el rendimiento
permitiendo que se reutilice una conexión TCP y (si corresponde) TLS/SSL ya establecida, lo que
reduce las sobrecargas de latencia. Se controla el tiempo de persistencia de una conexión
a través de un tiempo de espera keep alive de la propiedad (keepalive.timeout.millis
)
Tanto el servidor backend como el Apigee Message Processor usan tiempos de espera de keep alive para mantener conexiones abiertas unas con otras. Una vez que no se reciben datos dentro del tiempo de espera de keep alive el servidor de backend o Message Processor puede cerrar la conexión con el otro.
Los proxies de API implementados en un procesador de mensajes en Apigee, de forma predeterminada, tienen un tiempo de espera de keep alive establecido en
60s
a menos que se anule. Una vez que no se reciban datos de 60s
, Apigee
y cerrar la conexión
con el servidor backend. El servidor backend también mantendrá
un tiempo de espera de keep alive
Cuando esto ocurra, el servidor backend cerrará la conexión con Message Processor.
Implicación de una configuración incorrecta del tiempo de espera de keep alive
Si Apigee o el servidor de backend se configuran con tiempos de espera incorrectos de keep alive,
da como resultado una condición de carrera que hace que el servidor de backend envíe un End Of File
(FIN)
inesperado en respuesta a la solicitud de un recurso.
Por ejemplo, si el tiempo de espera de keep alive se configura dentro del proxy de API o en el campo Message
Procesador con un valor mayor o igual que el tiempo de espera del servidor de backend upstream y, luego,
puede ocurrir la siguiente condición de carrera. Es decir, si el Encargado del tratamiento de datos no recibe
muy cerca del umbral del tiempo de espera
de keep alive del servidor de backend y, luego,
se envía y se envía al servidor
de backend con la conexión existente. Esto puede producir
502 Bad Gateway
debido a un error inesperado de EOF como se explica a continuación:
- Supongamos que se estableció el tiempo de espera de keep alive en Message Processor y en el servidor de backend es de 60 segundos y no hay nuevas la solicitud llegó hasta 59 segundos después de que el responsable Message Processor.
- El procesador de mensajes continúa y procesa la solicitud que llegó en el segundo 59. mediante la conexión existente (ya que aún no transcurrió el tiempo de espera de keep alive) y envía al servidor de backend.
- Sin embargo, antes de que la solicitud llegue al servidor de backend, el tiempo de espera de keep alive se superó el umbral en el servidor de backend.
- La solicitud del procesador de mensajes para un recurso está en tránsito, pero el servidor backend
intenta cerrar la conexión enviando un paquete
FIN
al Message Procesador. - Mientras el procesador de mensajes espera a que se reciban los datos, recibe
el
FIN
inesperado, y la conexión finaliza. - Esto da como resultado una
Unexpected EOF
y, luego, una502
. que muestra Message Processor al cliente.
En este caso, observamos que se produjo el error 502
porque el mismo tiempo de espera de keep alive
de 60 segundos se configuró en el Message Processor y en el servidor backend. De forma similar,
este problema también puede ocurrir si se configura un valor más alto para el tiempo de espera de keep alive en el mensaje
más reciente que en el servidor de backend.
Diagnóstico
- Si eres un usuario de la nube pública, ten en cuenta lo siguiente:
- Utiliza la herramienta Trace o Monitoring de API (como se explica en
Pasos comunes del diagnóstico) y verifique que cumple con los siguientes dos requisitos:
configuración:
- Código de error:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Fuente del error:
target
- Código de error:
- Para obtener más información, ve a Cómo usar tcpdump.
- Utiliza la herramienta Trace o Monitoring de API (como se explica en
Pasos comunes del diagnóstico) y verifique que cumple con los siguientes dos requisitos:
configuración:
- Si eres un usuario de la nube privada, ten en cuenta lo siguiente:
- Usa la herramienta Trace o
los registros de acceso de NGINX para determinar el ID del mensaje
el código y la fuente 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
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 El procesador de mensajes recibió unEOF
mientras aún esperaba leer un respuesta del servidor de backend. - El atributo
useCount=7
en el mensaje de error anterior indica que el El procesador de mensajes volvió a usar esta conexión unas siete veces y el atributobytesWritten=159
indica que Message Processor envió la solicitud de159
bytes al servidor de backend. Sin embargo, recibió cero bytes cuando se produjo elEOF
inesperado. -
Aquí se muestra que Message Processor volvió a usar la misma conexión varias veces y, en esta ocasión, envió datos, pero poco tiempo después recibió una
EOF
antes de recibir los datos. Esto significa que hay una alta probabilidad de que el backend que el tiempo de espera de keep alive del servidor 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 Trace o
los registros de acceso de NGINX para determinar el ID del mensaje
el código y la fuente del error
Cómo usar 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 el
tcpdump
capturado:Este es un resultado de tcpdump de muestra:
En el
tcpdump
de ejemplo 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 reutilizó dos veces, pero en la tercera solicitud, el servidor de backend inicia un cierre de la conexión, mientras que Message Processor que espera los datos del servidor backend. Esto sugiere que la clave del servidor tiempo de espera de vida activa sea más corto o igual al valor establecido en el proxy de API. Para validar Consulta Comparación del tiempo de espera de keep alive en Apigee y el servidor de backend.
- En el paquete
Compara el tiempo de espera de keep alive en Apigee y el servidor de backend
- De forma predeterminada, Apigee usa un valor de 60 segundos para la propiedad de tiempo de espera de keep alive.
-
Sin embargo, es posible que haya anulado el valor predeterminado en el proxy de API. Para comprobarlo, revisa la definición específica de
TargetEndpoint
en el Proxy de API con fallas que arrojan 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 mantenimiento de funcionamiento 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. Digamos
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
por ejemplo, esa es la causa de los errores
502
.
Solución
Asegúrate de que la propiedad de tiempo de espera de keep alive sea siempre menor en Apigee (en el proxy de API y el componente Message Processor) en comparación con el del servidor 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 keep alive en el proxy de API. Message Processor, de modo que la propiedad de tiempo de espera keep alive sea menor que el valor establecido en de backend, con los pasos que se describen en Configura el tiempo de espera de keep alive en los procesadores de mensajes.
Si el problema persiste, consulta Recopila información de diagnóstico.
Práctica recomendada
Se recomienda que los componentes descendentes siempre tengan un tiempo de espera menor de keep-alive
que los configurados en los servidores ascendentes para evitar este tipo de condiciones de carrera y
502
de errores. Cada salto descendente debe ser menor que cada salto upstream. En Apigee
Edge, se recomienda usar los siguientes lineamientos:
- El tiempo de espera de mantenimiento activo del cliente debe ser menor que el del router perimetral.
- El tiempo de espera de mantenimiento del router perimetral debe ser menor que el del procesador de mensajes.
- El tiempo de espera de keep alive del procesador de mensajes debe ser menor que el tiempo de espera de keep alive del servidor de destino.
- Si tienes otros saltos delante o detrás de Apigee, se debe aplicar la misma regla. Siempre debes dejar la responsabilidad del cliente downstream para cerrar la con el upstream.
Se debe recopilar información de diagnóstico
Si el problema persiste, incluso después de seguir las instrucciones anteriores, reúne la siguiente información de diagnóstico y, luego, comunícate con el equipo de asistencia de Apigee Edge.
Si eres 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 registro que contiene las solicitudes con el error
502 Bad Gateway - Unexpected EOF
- Si los errores
502
no se producen actualmente, 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 fallidas
- Organización, nombre del entorno y nombre del proxy de API que está observando
502
de errores - Paquete de proxy de API
- Archivo de registro 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 del procesador de mensajes
/opt/apigee/var/log/edge-message-processor/logs/system.log
- El período con la información de la zona horaria en el que se produjeron los errores
502
Tcpdumps
recopilados en los procesadores de mensajes o en el servidor backend, o en ambos cuando se produce ocurrió