Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Sintomo
L'applicazione client riceve un codice di stato HTTP 502
con il messaggio
Bad Gateway
come risposta per le chiamate API.
Il codice di stato HTTP 502
indica che il client non riceve una risposta valida dai server di backend che dovrebbero effettivamente soddisfare la richiesta.
Messaggi di errore
L'applicazione client riceve il seguente codice di risposta:
HTTP/1.1 502 Bad Gateway
Inoltre, potresti visualizzare il seguente messaggio di errore:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Possibili cause
Una delle cause tipiche di 502 Bad Gateway Error
è l'errore Unexpected EOF
, che può essere causato dai seguenti motivi:
Causa | Dettagli | Passi indicati per |
---|---|---|
Server di destinazione configurato in modo errato | Il server di destinazione non è configurato correttamente per supportare le connessioni TLS/SSL. | Utenti di cloud pubblico e privato perimetrale |
EOFEccezione dal server di backend | Il server di backend potrebbe inviare EOF in modo improvviso. | Solo utenti Edge Private Cloud |
Timeout di keep-alive configurato in modo errato | Mantieni i timeout attivi configurati in modo errato su Apigee e sul server di backend. | Utenti di cloud pubblico e privato perimetrale |
Passaggi di diagnosi più comuni
Per diagnosticare l'errore, puoi utilizzare uno dei seguenti metodi:
Monitoraggio delle API
Per diagnosticare l'errore utilizzando il monitoraggio delle API:
Con Monitoraggio API puoi esaminare gli errori 502
seguendo la procedura descritta in Esaminare i problemi. Ossia:
- Vai alla dashboard di indagine.
- Seleziona il Codice di stato nel menu a discesa e assicurati che sia selezionato il periodo di tempo corretto quando si sono verificati gli errori
502
. - Fai clic sulla casella nella matrice quando noti un numero elevato di
502
errori. - Sul lato destro, fai clic su Visualizza log per gli errori
502
, che avranno il seguente aspetto: - L'origine dell'errore è
target
- Il codice di errore è
messaging.adaptors.http.UnexpectedEOFAtTarget
Qui possiamo vedere le seguenti informazioni:
Indica che l'errore 502
è causato dal target a causa di una EOF imprevista.
Inoltre, prendi nota del Request Message ID
per l'errore 502
per ulteriori
indagini.
Strumento Traccia
Per diagnosticare l'errore utilizzando lo strumento Trace:
- Abilita la
sessione di traccia ed effettua la chiamata API per riprodurre il problema
502 Bad Gateway
. - Seleziona una delle richieste non riuscite ed esamina la traccia.
- Naviga tra le varie fasi della traccia e individua il punto in cui si è verificato l'errore.
-
Dovresti vedere l'errore dopo che la richiesta è stata inviata al server di destinazione, come mostrato di seguito:
-
Determinare il valore di X-Apigee.fault-source e X-Apigee.fault-code nella fase AX (Analytics Data Recorded) dell'analisi.
Se i valori di X-Apigee.fault-source e X-Apigee.fault-code corrispondono ai valori mostrati nella seguente tabella, puoi confermare che l'errore
502
provenga dal server di destinazione:Intestazioni della risposta Valore X-Apigee.fault-source target
X-Apigee messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Inoltre, per ulteriori indagini, prendi nota del
X-Apigee.Message-ID
per l'errore502
.
Log degli accessi NGINX
Per diagnosticare l'errore utilizzando NGINX:
Puoi anche fare riferimento ai log degli accessi NGINX per determinare la causa del codice di stato 502
. Questa operazione è particolarmente utile se il problema si è verificato in passato o se è intermittente e non riesci ad acquisire la traccia nell'interfaccia utente. Segui questi passaggi per determinare queste informazioni dai log degli accessi di NGINX:
- Controlla i log degli accessi di NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Cerca eventuali errori
502
per il proxy API specifico durante un periodo di tempo specifico (se il problema si è verificato in passato) o per eventuali richieste che continuano a non funzionare con502
. - Se sono presenti errori
502
, controlla se l'errore è causato dall'invio di unUnexpected EOF
da parte del target. Se i valori di X-Apigee.fault-source e X- Apigee.fault-code corrispondono ai valori mostrati nella tabella seguente, l'errore502
è causato dalla chiusura imprevista della connessione da parte del target:Intestazioni della risposta Valore X-Apigee.fault-source target
X-Apigee messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Ecco una voce di esempio che mostra l'errore
502
causato dal server di destinazione:
Inoltre, prendi nota degli ID messaggio degli errori 502
per effettuare ulteriori accertamenti.
Causa: server di destinazione configurato in modo errato
Il server di destinazione non è configurato correttamente per supportare le connessioni TLS/SSL.
Diagnostica
- Usa il monitoraggio delle API, lo strumento Trace o i log di accesso NGINX per determinare l'ID messaggio, il codice di errore e l'origine dell'errore per l'errore
502
. - Abilita la traccia nell'interfaccia utente per l'API interessata.
- Se la traccia della richiesta API in errore mostra quanto segue:
- L'errore
502 Bad Gateway
viene visualizzato non appena viene avviata la richiesta del flusso di destinazione. - L'
error.class
mostramessaging.adaptors.http.UnexpectedEOF.
Quindi è molto probabile che il problema sia causato da una configurazione errata del server di destinazione.
- L'errore
- Ottieni la definizione del server di destinazione utilizzando la chiamata API Edge Management:
- Se sei un utente del cloud pubblico, utilizza questa API:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Se sei un utente Private Cloud, utilizza questa API:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Esempio di definizione di
TargetServer
errata:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Se sei un utente del cloud pubblico, utilizza questa API:
-
La definizione illustrata di
TargetServer
è un esempio di uno degli errori di configurazione tipici, spiegato come segue:Supponiamo che il server di destinazione
mocktarget.apigee.net
sia configurato per accettare connessioni protette (HTTPS) sulla porta443
. Tuttavia, se guardi la definizione del server di destinazione, non ci sono altri attributi/flag che indicano che è destinato a connessioni sicure. In questo modo Edge tratta le richieste API che arrivano al server di destinazione specifico come richieste HTTP (non sicure). Di conseguenza, Edge non avvierà il processo di handshake SSL con questo server di destinazione.Poiché il server di destinazione è configurato per accettare solo richieste HTTPS (SSL) su
443
, rifiuterà la richiesta da Edge o chiuderà la connessione. Di conseguenza, viene visualizzato un erroreUnexpectedEOFAtTarget
nel processore di messaggi. Il processore di messaggi invierà502 Bad Gateway
in risposta al client.
Risoluzione
Assicurati sempre che il server di destinazione sia configurato correttamente in base ai tuoi requisiti.
Per l'esempio illustrato sopra, se vuoi effettuare richieste a un server di destinazione sicuro (HTTPS/SSL), devi includere gli attributi SSLInfo
con il flag enabled
impostato su true
. Anche se è consentito aggiungere gli attributi SSLInfo
per un server di destinazione nella definizione stessa dell'endpoint di destinazione, è consigliabile aggiungere gli attributi SSLInfo
come parte della definizione del server di destinazione per evitare confusione.
- Se il servizio di backend richiede una comunicazione SSL unidirezionale:
- Devi attivare TLS/SSL nella definizione di
TargetServer
includendo gli attributiSSLInfo
in cui il flagenabled
è impostato su true, come mostrato di seguito:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Se vuoi convalidare il certificato del server di destinazione in Edge, dobbiamo includere anche l'archivio attendibilità (contenente il certificato del server di destinazione) come mostrato di seguito:
<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>
- Devi attivare TLS/SSL nella definizione di
- Se il servizio di backend richiede una comunicazione SSL bidirezionale:
- Gli attributi
SSLInfo
con i flagClientAuthEnabled
,Keystore
,KeyAlias
eTruststore
devono essere impostati correttamente, come mostrato di seguito:<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 >
- Gli attributi
Riferimenti
Bilanciamento del carico tra server di backend
Causa: EOFException del server di backend
Il server di backend potrebbe inviare all'improvviso EOF (End of File).
Diagnostica
- Usa il monitoraggio delle API, lo strumento Trace o i log di accesso NGINX per determinare l'ID messaggio, il codice di errore e l'origine dell'errore per l'errore
502
. - Controlla i log del processore di messaggi (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) e cerca per vedere se haieof unexpected
per l'API specifica o se hai ilmessageid
univoco per la richiesta API, puoi cercarlo.Esempio di analisi dello stack di eccezioni dal log del processore di messaggi
"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]"
Nell'esempio precedente, puoi vedere che si è verificato l'errore
java.io.EOFException: eof unexpected
mentre il processore di messaggi sta tentando di leggere una risposta dal server di backend. Questa eccezione indica la fine del file (EOF) o è stata raggiunta inaspettatamente la fine del flusso.In altre parole, il processore di messaggi ha inviato la richiesta API al server di backend ed era in attesa o lettura della risposta. Tuttavia, il server di backend ha terminato bruscamente la connessione prima che il processore di messaggi ricevesse la risposta o potesse leggere la risposta completa.
- Controlla i log del server di backend e verifica se sono presenti errori o informazioni che potrebbero aver portato il server di backend a terminare improvvisamente la connessione. Se trovi errori/informazioni, vai a Risoluzione e correggi il problema in modo appropriato nel tuo server di backend.
- Se non trovi errori o informazioni nel tuo server di backend, raccogli l'output
tcpdump
nei processori di messaggi:- Se l'host del server di backend ha un singolo indirizzo IP, utilizza il seguente comando:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Se l'host del server di backend ha più indirizzi IP, utilizza il seguente comando:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
In genere, questo errore è causato dal fatto che il server di backend risponde con
[FIN,ACK]
non appena il processore di messaggi invia la richiesta al server di backend.
- Se l'host del server di backend ha un singolo indirizzo IP, utilizza il seguente comando:
-
Considera il seguente esempio di
tcpdump
.Esempio di
tcpdump
acquisito quando si è verificato il problema502 Bad Gateway Error
(UnexpectedEOFAtTarget
) - Nell'output TCPDump, noterai la seguente sequenza di eventi:
- Nel pacchetto
985
, il processore di messaggi invia la richiesta API al server di backend. - Nel pacchetto
986
, il server di backend risponde immediatamente con[FIN,ACK]
. - Nel pacchetto
987
, il processore di messaggi risponde con[FIN,ACK]
al server di backend. - Alla fine i collegamenti vengono chiusi con
[ACK]
e[RST]
da entrambi i lati. - Poiché il server di backend invia
[FIN,ACK]
, ricevi l'eccezionejava.io.EOFException: eof unexpected
sul processore di messaggi.
- Nel pacchetto
- Questo può accadere se si verifica un problema di rete a livello di server di backend. Coinvolgi il team delle operazioni di rete per esaminare ulteriormente il problema.
Risoluzione
Risolvi il problema sul server di backend in modo appropriato.
Se il problema persiste e hai bisogno di aiuto per risolvere 502 Bad Gateway Error
o se sospetti che si tratti di un problema in Edge, contatta l'assistenza Apigee Edge.
Causa: timeout keep-alive configurato in modo errato
Prima di diagnosticare se questa è la causa degli errori 502
, leggi i seguenti concetti.
Connessioni permanenti in Apigee
Per impostazione predefinita, Apigee (e in seguito con lo standard HTTP/1.1) utilizza connessioni permanenti durante la comunicazione con il server di backend di destinazione. Le connessioni permanenti possono aumentare le prestazioni consentendo il riutilizzo di una connessione TCP e (se applicabile) TLS/SSL già stabilita, riducendo in questo modo i costi di latenza. La durata per cui una connessione deve essere persistente viene controllata
tramite un timeout keep-alive (keepalive.timeout.millis
) della proprietà.
Sia il server di backend che il processore di messaggi Apigee utilizzano i timeout keep-alive per mantenere aperte le connessioni l'una con l'altra. Se non vengono ricevuti dati entro il periodo di timeout keep-alive, il server di backend o il Elaboratore dei messaggi può chiudere la connessione con l'altro.
Per impostazione predefinita, per i proxy API di cui è stato eseguito il deployment in un processore di messaggi in Apigee, il timeout di keep-alive è impostato su
60s
, a meno che non venga eseguito l'override. Quando non vengono ricevuti dati per 60s
, Apigee chiude la connessione con il server di backend. Il server di backend manterrà anche un timeout keep-alive e, una volta scaduto, il server di backend chiuderà la connessione con il processore di messaggi.
Implicazione di una configurazione errata del timeout di keep-alive
Se Apigee o il server di backend sono configurati con timeout keep-alive errati, si verifica una condizione di gara che fa sì che il server di backend invii un End Of File
(FIN)
imprevisto in risposta a una richiesta di una risorsa.
Ad esempio, se il timeout di keep-alive è configurato nel proxy API o nel processore di messaggi con un valore maggiore o uguale al timeout del server di backend a monte, può verificarsi la seguente race condizione. In altre parole, se il processore di messaggi non riceve dati finché non si avvicina molto alla soglia del timeout di attività del server di backend, arriva una richiesta che viene inviata al server di backend utilizzando la connessione esistente. Questo può determinare
502 Bad Gateway
a causa di un errore EOF imprevisto, come spiegato di seguito:
- Supponiamo che il timeout di keep-alive impostato sia sul processore di messaggi che sul server di backend sia di 60 secondi e che non sia arrivata alcuna nuova richiesta fino a 59 secondi dopo che la richiesta precedente è stata fornita dallo specifico processore di messaggi.
- Il processore di messaggi elabora la richiesta pervenuta al 59° secondo utilizzando la connessione esistente (poiché il timeout di keep-alive non è ancora trascorso) e invia la richiesta al server di backend.
- Tuttavia, prima che la richiesta arrivi al server di backend, la soglia di timeout keep-alive è stata superata sul server di backend.
- La richiesta del processore di messaggi per una risorsa è in corso, ma il server di backend tenta di chiudere la connessione inviando un pacchetto
FIN
al processore di messaggi. - Mentre il processore di messaggi è in attesa di ricevere i dati, riceve invece l'errore
FIN
imprevisto e la connessione viene terminata. - Ne consegue un
Unexpected EOF
, che poi restituisce al client un502
dal processore di messaggi.
In questo caso, abbiamo notato che si è verificato l'errore 502
perché lo stesso valore di timeout keep-alive di 60 secondi è stato configurato sia sul processore di messaggi che sul server di backend. Analogamente, questo problema può verificarsi anche se sul processore di messaggi viene configurato un valore più alto per il timeout keep-alive rispetto al server di backend.
Diagnostica
- Se sei un utente del cloud pubblico:
- Utilizza lo strumento API Monitoring o Trace (come spiegato nella sezione
Passaggi comuni di diagnosi) e verifica di disporre di entrambe le seguenti
impostazioni:
- Codice di errore:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Origine errore:
target
- Codice di errore:
- Vai a Utilizzare tcpdump per ulteriori indagini.
- Utilizza lo strumento API Monitoring o Trace (come spiegato nella sezione
Passaggi comuni di diagnosi) e verifica di disporre di entrambe le seguenti
impostazioni:
- Se sei un utente Private Cloud:
- Usa lo strumento Traccia o i
log di accesso NGINX per determinare l'ID messaggio,
il codice di errore e l'origine dell'errore
502
. - Cerca l'ID messaggio nel log del processore di messaggi
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Vedrai
java.io.EOFEXception: eof unexpected
come mostrato di seguito: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)
- L'errore
java.io.EOFException: eof unexpected
indica che il processore di messaggi ha ricevuto un messaggioEOF
mentre era ancora in attesa di leggere una risposta dal server di backend. - L'attributo
useCount=7
nel messaggio di errore riportato sopra indica che il processore di messaggi ha riutilizzato questa connessione circa sette volte e l'attributobytesWritten=159
indica che il processore di messaggi ha inviato un payload della richiesta di159
byte al server di backend. Tuttavia, ha ricevuto zero byte quando si è verificato l'erroreEOF
imprevisto. -
Ciò mostra che il Responsabile del trattamento dei messaggi ha riutilizzato la stessa connessione più volte e in questa occasione ha inviato dati, ma poco dopo ha ricevuto un
EOF
prima della ricezione di qualsiasi dato. Ciò significa che è molto probabile che il timeout di keep-alive del server di backend sia inferiore o uguale a quello impostato nel proxy API.Puoi effettuare ulteriori accertamenti con l'aiuto di
tcpdump
, come spiegato di seguito.
- Usa lo strumento Traccia o i
log di accesso NGINX per determinare l'ID messaggio,
il codice di errore e l'origine dell'errore
Utilizzo di tcpdump
- Acquisisci un elemento
tcpdump
sul server di backend con il seguente comando:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Analizza gli
tcpdump
acquisiti:Ecco un output di tcpdump di esempio:
Nell'esempio
tcpdump
sopra, puoi vedere quanto segue:- Nel pacchetto
5992,
il server di backend ha ricevuto una richiestaGET
. - Nel pacchetto
6064
, risponde con200 OK.
- Nel pacchetto
6084
, il server di backend ha ricevuto un'altra richiestaGET
. - Nel pacchetto
6154
, risponde con200 OK
. - Nel pacchetto
6228
, il server di backend ha ricevuto una terza richiestaGET
. - Questa volta, il server di backend restituisce un
FIN, ACK
al processore di messaggi (pacchetto6285
) che avvia la chiusura della connessione.
In questo esempio, la stessa connessione è stata riutilizzata due volte con esito positivo, ma nella terza richiesta il server di backend avvia una chiusura della connessione, mentre il processore di messaggi attende i dati dal server di backend. Questo suggerisce che il timeout di keep-alive del server di backend è molto probabilmente più breve o uguale al valore impostato nel proxy API. Per convalidare ciò, consulta Confronta il timeout di keep-alive su Apigee e sul server di backend.
- Nel pacchetto
Confronta il timeout keep-alive su Apigee e sul server di backend
- Per impostazione predefinita, Apigee utilizza un valore di 60 secondi per la proprietà di timeout keep-alive.
-
Tuttavia, è possibile che tu abbia ignorato il valore predefinito nel proxy API. Puoi verificare controllando la definizione specifica di
TargetEndpoint
nel proxy API con errori che restituisce502
errori.Esempio di configurazione di TargetEndpoint:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
Nell'esempio precedente, la proprietà di timeout keep-alive viene sostituita con un valore di 30 secondi (
30000
millisecondi). - Successivamente, verifica la proprietà di timeout keep-alive configurata sul tuo server di backend. Supponiamo che il tuo server di backend sia configurato con un valore di
25 seconds
. - Se determini che il valore della proprietà di timeout keep-alive su Apigee è superiore al valore della proprietà di timeout keep-alive sul server di backend come nell'esempio precedente, questa è la causa degli errori
502
.
Risoluzione
Assicurati che la proprietà di timeout keep-alive sia sempre inferiore su Apigee (nel componente proxy API e processore di messaggi) rispetto a quella sul server di backend.
- Determina il valore impostato per il timeout keep-alive sul server di backend.
- Configura un valore appropriato per la proprietà di timeout keep-alive nel proxy API o nel processore di messaggi, in modo che la proprietà di timeout keep-alive sia inferiore al valore impostato sul server di backend, seguendo i passaggi descritti in Configurare il timeout di keep-alive sui processori di messaggi.
Se il problema persiste, vai alla pagina Devi raccogliere dati diagnostici.
Best practice
Consigliamo vivamente che i componenti downstream abbiano sempre una soglia di timeout di keep-alive inferiore
rispetto a quella configurata sui server upstream per evitare questo tipo di condizioni di gara e
errori 502
. Ogni hop downstream deve essere inferiore a ogni hop upstream. In Apigee Edge, è buona norma utilizzare le seguenti linee guida:
- Il timeout keep-alive del client deve essere inferiore al timeout keep-alive del router Edge.
- Il timeout di keep-alive del router Edge deve essere inferiore al timeout di keep-alive del processore di messaggi.
- Il timeout di keep-alive del processore di messaggi deve essere inferiore al timeout di keep-alive del server di destinazione.
- Se sono presenti altri hop prima o dopo Apigee, deve essere applicata la stessa regola. Dovresti lasciare sempre la responsabilità del client downstream di chiudere la connessione con l'upstream.
Devi raccogliere dati diagnostici
Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee Edge.
Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
- Nome dell'organizzazione.
- Nome ambiente
- Nome proxy API
- Completa il comando
curl
per riprodurre l'errore502
- File di traccia contenente le richieste con l'errore
502 Bad Gateway - Unexpected EOF
- Se al momento gli errori
502
non si verificano, fornisci il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati502
errori in passato.
Se sei un utente Private Cloud, fornisci le seguenti informazioni:
- Messaggio di errore completo osservato per le richieste non riuscite
- Organizzazione, nome dell'ambiente e nome del proxy API per cui stai osservando
502
errori - Bundle del proxy API
- File di traccia contenente le richieste con l'errore
502 Bad Gateway - Unexpected EOF
- Log degli accessi NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Log del processore di messaggi
/opt/apigee/var/log/edge-message-processor/logs/system.log
- Il periodo di tempo con le informazioni sul fuso orario in cui si è verificato l'errore
502
Tcpdumps
raccolto sui processori di messaggi, sul server di backend o su entrambi quando si è verificato l'errore