Errore di timeout del gateway non valido (502)

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Sintomo

L'applicazione client riceve un errore 502 Bad Gateway. Il processore di messaggi restituisce questo errore all'applicazione client quando non riceve una risposta da un server di backend.

Messaggio 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":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Possibile causa

La possibile causa di questo problema è elencata nella tabella seguente:

Causa Descrizione Passaggi per la risoluzione dei problemi che possono essere eseguiti da
Timeout dell'handshake TLS/SSL Si verifica un timeout durante l'handshake TLS/SSL tra il processore di messaggi e il server di backend. Utenti di Edge Private Cloud e Public Cloud

Causa: timeout dell'handshake TLS/SSL

In Apigee Edge, puoi configurare una connessione TLS/SSL al server di backend per abilitare la comunicazione TLS tra il processore di messaggi Edge e un server di backend.

Un handshake TLS/SSL prevede più passaggi. Questo errore si verifica in genere quando si verifica il timeout dell'handshake TLS/SSL tra il processore di messaggi e un server di backend.

Diagnosi

Questa sezione spiega come diagnosticare correttamente un timeout dell'handshake TLS/SSL. Sono elencate le istruzioni per Edge Private Cloud e Public Cloud.

Esaminare l'output della sessione di traccia

I passaggi seguenti spiegano come eseguire una diagnosi preliminare del problema utilizzando lo strumento di traccia di Apigee Edge.

  1. Nell'interfaccia utente di Edge, abilita una sessione di traccia per il proxy API interessato.

  2. Se la traccia della richiesta API non riuscita mostra quanto segue, è probabile che si sia verificato un errore di timeout dell'handshake TLS/SSL. La causa probabile dell'errore è che il firewall del server di backend blocca il traffico da Apigee.

    1. Determina se l'errore 502 Bad Gateway si verifica dopo 55 secondi, che è il periodo di timeout predefinito impostato sul processore di messaggi. Se vedi che l'errore si è verificato dopo 55 secondi, significa che la causa probabile del problema è un timeout.
    2. Determina se l'errore mostra il guasto: messaging.adaptors.http.BadGateway. Anche in questo caso, l'errore indica in genere che si è verificato un timeout.

    3. Se utilizzi Edge Private Cloud, prendi nota del valore del campo X-Apigee.Message-ID nell'output della traccia, come mostrato di seguito. Un utente di Private Cloud può utilizzare questo valore ID per eseguire un'ulteriore risoluzione dei problemi, come spiegato di seguito.

      1. Fai clic sull'icona Dati di analisi registrati nel percorso della traccia:

      2. Scorri verso il basso e prendi nota del valore del campo denominato X-Apigee.Message-ID.

Per verificare che il timeout dell'handshake TLS/SSL sia la causa dell'errore, segui i passaggi nelle sezioni seguenti, a seconda che tu utilizzi Public Cloud o Private Cloud.

Passaggi diagnostici aggiuntivi solo per gli utenti di Edge Private Cloud

Se utilizzi Apigee Edge Private Cloud, puoi seguire questi passaggi per verificare la causa dell'errore di handshake. In questo passaggio, esamina il file di log del processore di messaggi per trovare informazioni pertinenti. Se utilizzi Edge Public Cloud, puoi saltare questa sezione e andare a Passaggi diagnostici aggiuntivi per gli utenti di Private Cloud e Public Cloud.

  1. Verifica se riesci a connetterti al server di backend specifico direttamente da ciascuno dei processori di messaggi utilizzando il comando telnet:

    1. Se il server di backend viene risolto in un singolo indirizzo IP, utilizza questo comando:

      telnet BackendServer-IPaddress 443

    2. Se il server di backend viene risolto in più indirizzi IP, utilizza il nome host del server di backend nel comando telnet, come mostrato di seguito:

      telnet BackendServer-HostName 443

    Se riesci a connetterti al server di backend senza errori, vai al passaggio successivo.

    Se il comando telnet non riesce, devi collaborare con il tuo team di rete per verificare la connettività tra il processore di messaggi e il server di backend.

  2. Controlla il file di log del processore di messaggi per verificare se è presente un errore di handshake. Apri il file:

    /opt/apigee/var/log/edge-message-processor/system.log

    e cerca l'ID messaggio univoco (il valore di X-Apigee.Message-ID che hai trovato nel file di traccia). Determina se viene visualizzato un messaggio di errore di handshake associato all'ID messaggio, come mostrato di seguito:

    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

Se vedi questo errore nel file di log del processore di messaggi, continua a indagare. Vai a Passaggi diagnostici aggiuntivi per gli utenti di Edge Private Cloud e Public Cloud.

Se non vedi il messaggio di handshake nel file di log, vai a Informazioni diagnostiche da raccogliere

Passaggi diagnostici aggiuntivi per gli utenti di Edge Private Cloud e Public Cloud

Per individuare ulteriormente il problema, puoi utilizzare lo strumento tcpdump per analizzare i pacchetti TCP/IP e verificare se si è verificato un timeout durante l'handshake TLS/SSL.

  1. Se sei un utente di Private Cloud, puoi acquisire i pacchetti TCP/IP sul server di backend o sul processore di messaggi. È preferibile acquisirli sul server di backend, perché i pacchetti vengono decriptati sul server di backend.
  2. Se sei un utente di Public Cloud, non hai accesso al processore di messaggi ; tuttavia, l'acquisizione dei pacchetti TCP/IP sul server di backend può aiutarti a individuare un problema.

  3. Dopo aver deciso dove acquisire i pacchetti TCP/IP, utilizza il seguente tcpdump comando per acquisire i pacchetti TCP/IP.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Se stai acquisendo i pacchetti TCP/IP sul server di backend, utilizza l'indirizzo IP pubblico del processore di messaggi nel comando tcpdump. Per assistenza sull'utilizzo del comando per esaminare il traffico del server di backend, consulta tcpdump.

    • Se stai acquisendo i pacchetti TCP/IP sul processore di messaggi, utilizza l'indirizzo IP pubblico del server di backend nel comando tcpdump. Per assistenza sull'utilizzo del comando per esaminare il traffico del processore di messaggi, consulta tcpdump.

    • Se sono presenti più indirizzi IP per il server di backend/il processore di messaggi, devi provare un altro utilizzo del comando tcpdump. Per ulteriori informazioni su questo strumento e su altre varianti di questo comando, consulta tcpdump.

  4. Analizza i pacchetti TCP/IP utilizzando lo strumento Wireshark o uno strumento simile. Lo screenshot seguente mostra i pacchetti TCP/IP in Wireshark.

  5. Nell'output di Wireshark, nota che l'handshake TCP a tre vie viene completato correttamente nei primi 3 pacchetti.

  6. Il processore di messaggi invia quindi il messaggio "Client Hello" nel pacchetto n. 4.

  7. Poiché non è presente alcun riconoscimento da parte del server di backend, il processore di messaggi ritrasmette più volte il messaggio "Client Hello" nei pacchetti 5, 6 e 7 dopo aver atteso un intervallo di tempo predefinito.

  8. Quando il processore di messaggi non riceve alcun riconoscimento dopo 3 tentativi, invia il messaggio FIN, ACK al server di backend per indicare che sta chiudendo la connessione.

  9. Come mostrato nella sessione di Wireshark di esempio, la connessione al backend è riuscita (passaggio 1), ma si è verificato il timeout dell'handshake SSL perché il server di backend non ha mai risposto.

Se hai eseguito i passaggi per la risoluzione dei problemi descritti in questa guida e hai stabilito che un timeout ha causato l'errore di handshake TLS/SSL, vai alla sezione Risoluzione.

Utilizzare il monitoraggio delle API per identificare un problema

Il monitoraggio delle API ti consente di isolare rapidamente le aree problematiche per diagnosticare i problemi di errore, prestazioni e latenza e la relativa origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Segui un esempio di scenario che mostra come risolvere i problemi 5xx con le API utilizzando il monitoraggio delle API. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di guasti messaging.adaptors.http.BadGateway supera una determinata soglia.

Risoluzione

In genere, i timeout dell'handshake SSL si verificano a causa delle limitazioni del firewall sul server di backend che bloccano il traffico da Apigee Edge. Se hai seguito i passaggi diagnostici e hai stabilito che la causa dell'errore di handshake è un timeout, devi coinvolgere il tuo team di rete per identificare la causa e correggere le limitazioni del firewall.

Tieni presente che le limitazioni del firewall potrebbero essere imposte a livelli di rete diversi. È importante assicurarsi che le limitazioni a tutti i livelli di rete vengano rimosse in relazione agli IP del processore di messaggi per garantire un flusso di traffico regolare tra Apigee Edge e il server di backend.

Se non sono presenti limitazioni del firewall e/o il problema persiste, vai a Informazioni diagnostiche da raccogliere.

Informazioni diagnostiche da raccogliere

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contatta l'assistenza di Apigee Edge e condividile:

  1. Se sei un utente di Public Cloud, fornisci le seguenti informazioni:
    1. Nome dell'organizzazione
    2. Nome ambiente
    3. Nome proxy API
    4. Comando curl completo per riprodurre l'errore
    5. File di traccia che mostra l'errore
    6. Pacchetti TCP/IP acquisiti sul server di backend
  2. Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
    1. Messaggio di errore completo osservato
    2. Bundle proxy API
    3. File di traccia che mostra l'errore
    4. Log del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Pacchetti TCP/IP acquisiti sul server di backend o sul processore di messaggi.
  3. Dettagli sulle sezioni di questa guida che hai provato e su eventuali altre informazioni che ci aiuteranno ad accelerare la risoluzione di questo problema.