502 Ungültiges Gateway – unerwartetes EOF

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

Die Clientanwendung erhält als Antwort auf API-Aufrufe den HTTP-Statuscode 502 mit der Meldung Bad Gateway.

Der HTTP-Statuscode 502 bedeutet, dass der Client keine gültige Antwort von den Backend-Servern erhält, die die Anfrage eigentlich ausführen sollten.

Fehlermeldungen

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 502 Bad Gateway

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Mögliche Ursachen

Eine der typischen Ursachen für 502 Bad Gateway Error ist der Fehler Unexpected EOF, der folgende Ursachen haben kann:

Allgemeine Diagnoseschritte

Zur Diagnose des Fehlers können Sie eine der folgenden Methoden verwenden:

• API-Monitoring
• Trace-Tool
• NGINX-Zugriffslogs

Ursache: Falsch konfigurierter Zielserver

Der Zielserver ist nicht ordnungsgemäß für die Unterstützung von TLS/SSL-Verbindungen konfiguriert.

Diagnose

1. Verwenden Sie API-Monitoring, das Trace-Tool oder NGINX-Zugriffsprotokolle, um die Nachrichten-ID, den Fehlercode und die Fehlerquelle für den 502-Fehler zu ermitteln.
2. Aktivieren Sie den Trace in der Benutzeroberfläche für die betroffene API.
3. Wenn der Trace für die fehlgeschlagene API-Anfrage Folgendes zeigt:
   1. Der Fehler 502 Bad Gateway wird angezeigt, sobald die Anfrage für den Zielfluss gestartet wurde.
   2. Auf dem error.class wird messaging.adaptors.http.UnexpectedEOF. angezeigt.

      Dann ist es sehr wahrscheinlich, dass dieses Problem durch eine falsche Konfiguration des Zielservers verursacht wird.

4. Rufen Sie die Zielserverdefinition mit dem Edge Management API-Aufruf ab:
   1. Wenn Sie ein Public Cloud-Nutzer sind, verwenden Sie diese API:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. Wenn Sie ein Private Cloud-Nutzer sind, verwenden Sie diese API:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      Beispiel für eine fehlerhafte TargetServer-Definition:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. Die abgebildete TargetServer-Definition ist ein Beispiel für eine der typischen Fehlkonfigurationen, die so erklärt werden:

   Angenommen, der Zielserver mocktarget.apigee.net ist so konfiguriert, dass er sichere (HTTPS) Verbindungen über Port 443 akzeptiert. Wenn Sie sich jedoch die Definition des Zielservers ansehen, gibt es keine anderen Attribute/Flags, die darauf hinweisen, dass er für sichere Verbindungen vorgesehen ist. Dadurch behandelt Edge die API-Anfragen, die an den jeweiligen Zielserver gesendet werden, als HTTP-Anfragen (nicht sicher). Edge initiiert daher keinen SSL-Handshake mit diesem Zielserver.

   Da der Zielserver so konfiguriert ist, dass er nur HTTPS-Anfragen (SSL) auf 443 akzeptiert, wird die Anfrage von Edge abgelehnt oder die Verbindung geschlossen. Daher erhalten Sie im Message Processor den Fehler UnexpectedEOFAtTarget. Der Message Processor sendet 502 Bad Gateway als Antwort an den Client.

Auflösung

Achten Sie immer darauf, dass der Zielserver gemäß Ihren Anforderungen konfiguriert ist.

Wenn Sie im obigen Beispiel Anfragen an einen sicheren (HTTPS/SSL) Zielserver senden möchten, müssen Sie die SSLInfo-Attribute mit dem Flag enabled auf true festlegen. Es ist zwar zulässig, die Attribute SSLInfo für einen Zielserver in der Zielendpunktdefinition selbst hinzuzufügen, es wird jedoch empfohlen, die Attribute SSLInfo als Teil der Zielserverdefinition hinzuzufügen, um Verwirrung zu vermeiden.

1. Wenn für den Backend-Dienst unidirektionale SSL-Kommunikation erforderlich ist, gilt Folgendes:
   1. Sie müssen TLS/SSL in der TargetServer-Definition aktivieren, indem Sie die SSLInfo-Attribute einfügen, bei denen das Flag enabled auf „true“ gesetzt ist, wie unten dargestellt:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. Wenn Sie das Zertifikat des Zielservers in Edge validieren möchten, müssen wir auch den Truststore (mit dem Zertifikat des Zielservers) einfügen, wie unten gezeigt:

      <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>

2. Wenn für den Backend-Dienst bidirektionale SSL-Kommunikation erforderlich ist, gilt Folgendes:
   1. Sie benötigen SSLInfo-Attribute mit den Flags ClientAuthEnabled, Keystore, KeyAlias und Truststore, die wie unten dargestellt richtig festgelegt sind:

      <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 >

Verweise

Load-Balancing über Back-End-Server

Ursache: EOFException vom Backend-Server

Der Backend-Server sendet möglicherweise abrupt EOF (End of File).

Diagnose

1. Verwenden Sie API-Monitoring, das Trace-Tool oder NGINX-Zugriffsprotokolle, um die Nachrichten-ID, den Fehlercode und die Fehlerquelle für den 502-Fehler zu ermitteln.
2. Sehen Sie sich die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) an und suchen Sie nach eof unexpected für die jeweilige API oder nach der eindeutigen messageid für die API-Anfrage.

   Beispiel für einen Ausnahme-Stacktrace aus dem Message Processor-Log

   "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]"

   Im obigen Beispiel sehen Sie, dass der Fehler java.io.EOFException: eof unexpected aufgetreten ist, als der Message Processor versucht hat, eine Antwort vom Backend-Server zu lesen. Diese Ausnahme weist auf das Dateiende (End of File, EOF) oder das unerwartete Ende des Streams hin.

   Das bedeutet, dass der Message Processor die API-Anfrage an den Back-End-Server gesendet und auf die Antwort gewartet oder sie gelesen hat. Der Backend-Server hat die Verbindung jedoch abrupt beendet, bevor der Message Processor die Antwort erhalten oder die vollständige Antwort lesen konnte.

3. Prüfen Sie die Protokolle Ihres Backend-Servers auf Fehler oder Informationen, die dazu geführt haben könnten, dass der Backend-Server die Verbindung abrupt beendet hat. Wenn Sie Fehler oder Informationen finden, gehen Sie zum Abschnitt Lösung und beheben Sie das Problem auf Ihrem Backend-Server.
4. Wenn Sie auf Ihrem Backend-Server keine Fehler oder Informationen finden, erfassen Sie die tcpdump-Ausgabe auf den Message Processors:
   1. Wenn Ihr Backend-Serverhost eine einzelne IP-Adresse hat, verwenden Sie den folgenden Befehl:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. Wenn der Host Ihres Back-End-Servers mehrere IP-Adressen hat, verwenden Sie den folgenden Befehl:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      Normalerweise wird dieser Fehler dadurch verursacht, dass der Backend-Server mit [FIN,ACK] antwortet, sobald der Message Processor die Anfrage an den Backend-Server sendet.

5. Dazu ein Beispiel für tcpdump:

   Stichprobe tcpdump wurde bei 502 Bad Gateway Error (UnexpectedEOFAtTarget) entnommen.

   

6. In der TCPDump-Ausgabe sehen Sie die folgende Ereignissequenz:
   1. Im Paket 985 sendet der Message Processor die API-Anfrage an den Backend-Server.
   2. Im Paket 986 antwortet der Back-End-Server sofort mit [FIN,ACK].
   3. Im Paket 987 antwortet der Message Processor mit [FIN,ACK] auf den Backend-Server.
   4. Die Verbindungen werden schließlich mit [ACK] und [RST] von beiden Seiten geschlossen.
   5. Da der Backend-Server [FIN,ACK] sendet, erhalten Sie die Ausnahme java.io.EOFException: eof unexpected im Message Processor.
7. Dies kann passieren, wenn auf dem Backend-Server ein Netzwerkproblem vorliegt. Wenden Sie sich an Ihr Netzwerkbetriebsteam, um das Problem genauer zu untersuchen.

Auflösung

Beheben Sie das Problem auf dem Backend-Server.

Wenn das Problem weiterhin besteht und Sie Unterstützung bei der Fehlerbehebung für 502 Bad Gateway Error benötigen oder vermuten, dass es sich um ein Problem in Edge handelt, wenden Sie sich an den Apigee Edge-Support.

Ursache: Falsch konfiguriertes Keep-Alive-Zeitlimit

Bevor Sie prüfen, ob dies die Ursache für die 502-Fehler ist, lesen Sie bitte die folgenden Konzepte.

Persistente Verbindungen in Apigee

Apigee verwendet standardmäßig (und gemäß dem HTTP/1.1-Standard) persistente Verbindungen für die Kommunikation mit dem Ziel-Backend-Server. Nichtflüchtige Verbindungen können die Leistung steigern, da eine bereits hergestellte TCP- und (falls zutreffend) TLS/SSL-Verbindung wiederverwendet werden kann. Dadurch wird der Latenzaufwand verringert. Die Dauer, für die eine Verbindung aufrechterhalten werden muss, wird über die Property keep alive timeout (keepalive.timeout.millis) gesteuert.

Sowohl der Backend-Server als auch der Apigee Message Processor verwenden Keep-Alive-Timeouts, um Verbindungen zueinander offen zu halten. Wenn innerhalb des Keep-Alive-Timeouts keine Daten empfangen werden, kann der Backend-Server oder Message Processor die Verbindung zum anderen schließen.

Für API-Proxys, die auf einem Message Processor in Apigee bereitgestellt werden, ist standardmäßig ein Keep-Alive-Zeitlimit von 60s festgelegt, sofern es nicht überschrieben wird. Wenn 60s lang keine Daten empfangen werden, schließt Apigee die Verbindung zum Backend-Server. Der Backend-Server behält auch ein Keep-Alive-Zeitlimit bei. Wenn dieses abläuft, schließt der Backend-Server die Verbindung zum Message Processor.

Auswirkungen einer falschen Konfiguration des Keep-Alive-Timeouts

Wenn entweder Apigee oder der Backend-Server mit falschen Keep-Alive-Zeitüberschreitungen konfiguriert ist, führt dies zu einer Race-Bedingung, bei der der Backend-Server als Reaktion auf eine Anfrage für eine Ressource einen unerwarteten End Of File (FIN)-Statuscode sendet.

Wenn das Keep-Alive-Zeitlimit beispielsweise im API-Proxy oder im Message Processor mit einem Wert konfiguriert wird, der größer oder gleich dem Zeitlimit des Upstream-Backend-Servers ist, kann die folgende Race-Bedingung auftreten. Wenn der Message Processor also erst kurz vor dem Schwellenwert für das Keep-Alive-Zeitlimit des Backend-Servers Daten empfängt, wird eine Anfrage über die vorhandene Verbindung an den Backend-Server gesendet. Dies kann zu 502 Bad Gateway führen, da ein unerwarteter EOF-Fehler auftritt, wie unten beschrieben:

1. Angenommen, das Keep-Alive-Zeitlimit, das sowohl für den Message Processor als auch für den Backend-Server festgelegt ist, beträgt 60 Sekunden und bis 59 Sekunden nach der Verarbeitung der vorherigen Anfrage durch den jeweiligen Message Processor ist keine neue Anfrage eingegangen.
2. Der Message Processor verarbeitet die Anfrage, die in der 59. Sekunde eingegangen ist, über die bestehende Verbindung (da das Keep-Alive-Zeitlimit noch nicht abgelaufen ist) und sendet die Anfrage an den Backend-Server.
3. Bevor die Anfrage jedoch beim Backend-Server eingeht, wurde der Keep-Alive-Timeout-Grenzwert auf dem Backend-Server überschritten.
4. Die Anfrage des Message Processors für eine Ressource ist unterwegs, aber der Backend-Server versucht, die Verbindung zu schließen, indem er ein FIN-Paket an den Message Processor sendet.
5. Während der Message Processor auf den Empfang der Daten wartet, empfängt er stattdessen das unerwartete FIN und die Verbindung wird beendet.
6. Dies führt zu einem Unexpected EOF und anschließend wird ein 502 vom Message Processor an den Client zurückgegeben.

In diesem Fall ist der Fehler 502 aufgetreten, weil sowohl auf dem Message Processor als auch auf dem Backend-Server derselbe Keep-Alive-Zeitüberschreitungswert von 60 Sekunden konfiguriert war. Dieses Problem kann auch auftreten, wenn für das Keep-Alive-Zeitlimit im Message Processor ein höherer Wert konfiguriert ist als auf dem Backend-Server.

Diagnose

1. Wenn Sie ein Public Cloud-Nutzer sind:
   1. Verwenden Sie API Monitoring oder das Trace-Tool (wie unter Häufige Diagnoseschritte beschrieben) und prüfen Sie, ob Sie beide der folgenden Einstellungen haben:
      • Fehlercode:messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Fehlerquelle: target
   2. Weitere Informationen finden Sie unter „tcpdump“ verwenden.
2. Wenn Sie Private Cloud-Nutzer sind:
   1. Verwenden Sie das Trace-Tool oder NGINX-Zugriffsprotokolle, um die Nachrichten-ID, den Fehlercode und die Fehlerquelle für den 502-Fehler zu ermitteln.
   2. Suchen Sie im Message Processor-Log
      (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der Nachrichten-ID.
   3. Sie sehen dann java.io.EOFEXception: eof unexpected wie unten dargestellt:

      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)

   4. Der Fehler java.io.EOFException: eof unexpected weist darauf hin, dass der Message Processor ein EOF empfangen hat, während er noch auf eine Antwort vom Backend-Server gewartet hat.
   5. Das Attribut useCount=7 in der obigen Fehlermeldung gibt an, dass der Message Processor diese Verbindung etwa sieben Mal wiederverwendet hat. Das Attribut bytesWritten=159 gibt an, dass der Message Processor die Anfragenutzlast von 159 Bytes an den Backend-Server gesendet hat. Es wurden jedoch null Byte zurückgegeben, als der unerwartete Fehler EOF auftrat.

   6. Das zeigt, dass der Message Processor dieselbe Verbindung mehrmals wiederverwendet hat. Bei dieser Gelegenheit wurden Daten gesendet, aber kurz danach wurde ein EOF empfangen, bevor Daten empfangen wurden. Das bedeutet, dass das Keep-Alive-Zeitlimit des Backend-Servers mit hoher Wahrscheinlichkeit kürzer oder gleich dem im API-Proxy festgelegten Zeitlimit ist.

      Mit tcpdump können Sie das Problem weiter untersuchen.

„tcpdump“ verwenden

1. Erfassen Sie mit dem folgenden Befehl einen tcpdump auf dem Backend-Server:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Analysieren Sie die erfassten tcpdump:

   Hier ist ein Beispiel für eine tcpdump-Ausgabe:

   

   Im obigen Beispiel tcpdump sehen Sie Folgendes:

   1. Im Paket 5992, hat der Backend-Server eine GET-Anfrage erhalten.
   2. Im Paket 6064 antwortet es mit 200 OK.
   3. Im Paket 6084 hat der Backend-Server eine weitere GET-Anfrage erhalten.
   4. Im Paket 6154 antwortet es mit 200 OK.
   5. Im Paket 6228 hat der Backend-Server eine dritte GET-Anfrage erhalten.
   6. Diesmal gibt der Backend-Server ein FIN, ACK an den Message Processor zurück (Paket 6285), wodurch die Verbindung geschlossen wird.

   Dieselbe Verbindung wurde in diesem Beispiel zweimal erfolgreich wiederverwendet. Bei der dritten Anfrage leitet der Backend-Server jedoch das Schließen der Verbindung ein, während der Message Processor auf die Daten vom Backend-Server wartet. Das deutet darauf hin, dass das Keep-Alive-Zeitlimit des Backend-Servers höchstwahrscheinlich kürzer oder gleich dem im API-Proxy festgelegten Wert ist. Eine Anleitung dazu finden Sie unter Keep-Alive-Zeitüberschreitung auf Apigee und dem Backend-Server vergleichen.

Keep-Alive-Zeitüberschreitung auf Apigee- und Backend-Server vergleichen

1. Standardmäßig verwendet Apigee einen Wert von 60 Sekunden für das Keep-Alive-Zeitlimit.

2. Es ist jedoch möglich, dass Sie den Standardwert im API-Proxy überschrieben haben. Sie können dies überprüfen, indem Sie die spezifische TargetEndpoint-Definition im fehlerhaften API-Proxy prüfen, der 502-Fehler ausgibt.

   Beispiel für eine TargetEndpoint-Konfiguration:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   Im obigen Beispiel wird das Keep-Alive-Zeitlimitattribut mit dem Wert 30 Sekunden (30000 Millisekunden) überschrieben.

3. Prüfen Sie als Nächstes die auf Ihrem Backend-Server konfigurierte Keep-Alive-Zeitüberschreitung. Angenommen, Ihr Backend-Server ist mit dem Wert 25 seconds konfiguriert.
4. Wenn Sie feststellen, dass der Wert der Keep-Alive-Zeitüberschreitungseigenschaft in Apigee höher ist als der Wert der Keep-Alive-Zeitüberschreitungseigenschaft auf dem Backend-Server (wie im obigen Beispiel), ist dies die Ursache für 502-Fehler.

Auflösung

Achten Sie darauf, dass das Keep-Alive-Zeitlimit-Attribut auf Apigee (im API-Proxy und in der Message Processor-Komponente) immer niedriger ist als auf dem Backend-Server.

1. Ermitteln Sie den Wert, der für das Keep-Alive-Zeitlimit auf dem Backend-Server festgelegt ist.
2. Konfigurieren Sie einen geeigneten Wert für das Keep-Alive-Zeitlimitattribut im API-Proxy oder Message Processor, sodass das Keep-Alive-Zeitlimitattribut niedriger ist als der auf dem Backend-Server festgelegte Wert. Folgen Sie dazu der Anleitung unter Keep-Alive-Zeitlimit für Message Processors konfigurieren.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Best Practice

Es wird dringend empfohlen, dass die Downstream-Komponenten immer einen niedrigeren Keep-Alive-Zeitüberschreitungsschwellenwert haben als auf den Upstream-Servern konfiguriert, um diese Art von Race-Bedingungen und 502-Fehlern zu vermeiden. Jeder Downstream-Hop sollte niedriger sein als jeder Upstream-Hop. In Apigee Edge sollten Sie die folgenden Richtlinien beachten:

1. Das Keep-Alive-Zeitlimit des Clients sollte kürzer sein als das Keep-Alive-Zeitlimit des Edge-Routers.
2. Die Edge-Router-Keep-Alive-Zeitüberschreitung sollte kürzer sein als die Keep-Alive-Zeitüberschreitung des Nachrichtenprozessors.
3. Die Keep-Alive-Zeitüberschreitung des Message Processors sollte kürzer sein als die Keep-Alive-Zeitüberschreitung des Zielservers.
4. Wenn Sie andere Hops vor oder nach Apigee haben, sollte dieselbe Regel angewendet werden. Es sollte immer in der Verantwortung des Downstream-Clients liegen, die Verbindung zum Upstream zu schließen.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support.

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Name der Organisation
• Name der Umgebung
• Name des API-Proxys
• Vollständiger curl-Befehl zum Reproduzieren des 502-Fehlers
• Trace-Datei mit den Anfragen mit dem Fehler 502 Bad Gateway - Unexpected EOF
• Wenn die 502-Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit den Zeitzoneninformationen an, in dem 502-Fehler in der Vergangenheit aufgetreten sind.

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

• Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
• Name der Organisation, Umgebung und des API-Proxys, für die Sie 502-Fehler beobachten
• API-Proxy-Bundle
• Trace-Datei mit den Anfragen mit dem Fehler 502 Bad Gateway - Unexpected EOF
• NGINX-Zugriffslogs
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Message Processor-Logs
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Der Zeitraum mit den Zeitzoneninformationen, in dem die 502-Fehler aufgetreten sind
• Tcpdumps, die auf den Message Processors oder dem Backend-Server oder beiden erfasst wurden, als der Fehler aufgetreten ist