502 Ungültiges Gateway – unerwartetes EOF

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

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

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

Fehlermeldungen

Die Clientanwendung ruft den folgenden Antwortcode ab:

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:

Ursache	Details	Schritte für
Falsch konfigurierter Zielserver	Der Zielserver ist nicht ordnungsgemäß für die Unterstützung von TLS/SSL-Verbindungen konfiguriert.	Nutzer von Edge Public und Private Cloud
EOFException vom Back-End-Server	Der Back-End-Server kann EOF abrupt senden.	Nur Edge Private Cloud-Nutzer
Falsch konfiguriertes Keep-Alive-Zeitlimit	Falsch konfigurierte Keep-Alive-Zeitüberschreitungen auf Apigee und Back-End-Server.	Nutzer von Edge Public und Private Cloud

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-Zugriffslogs, um die Nachrichten-ID, den Fehlercode und die Fehlerquelle für den Fehler 502 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 anzeigt:
   1. Der Fehler 502 Bad Gateway wird angezeigt, sobald die Zielablaufanfrage gestartet wurde.
   2. Im error.class wird messaging.adaptors.http.UnexpectedEOF. angezeigt

      Dann ist es sehr wahrscheinlich, dass dieses Problem durch eine falsche Zielserverkonfiguration verursacht wird.

4. Rufen Sie die Zielserverdefinition mithilfe des Edge-Management-API-Aufrufs 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 dargestellte TargetServer-Definition ist ein Beispiel für eine der typischen Fehlkonfigurationen, die so erläutert wird:

   Angenommen, der Zielserver mocktarget.apigee.net ist so konfiguriert, dass sichere (HTTPS) Verbindungen an Port 443 akzeptiert werden. In der Definition des Zielservers sehen Sie jedoch keine anderen Attribute/Flags, die darauf hinweisen, dass sie für sichere Verbindungen vorgesehen sind. Dies führt dazu, dass Edge die API-Anfragen, die an den spezifischen Zielserver gehen, als HTTP-Anfragen (nicht sicher) behandelt. Daher initiiert Edge den SSL-Handshake mit diesem Zielserver nicht.

   Da der Zielserver so konfiguriert ist, dass er nur HTTPS (SSL)-Anfragen unter 443 akzeptiert, lehnt er die Anfrage von Edge ab oder beendet die Verbindung. In diesem Fall wird auf dem Message Processor der Fehler UnexpectedEOFAtTarget angezeigt. Der Message Processor sendet 502 Bad Gateway als Antwort an den Client.

Auflösung

Achten Sie immer darauf, dass der Zielserver entsprechend Ihren Anforderungen konfiguriert ist.

Wenn Sie im obigen Beispiel Anfragen an einen sicheren Zielserver (HTTPS/SSL) senden möchten, müssen Sie die SSLInfo-Attribute hinzufügen und das Flag enabled auf true setzen. Das Hinzufügen der SSLInfo-Attribute für einen Zielserver in der Definition des Zielendpunkts ist zwar zulässig, es wird jedoch empfohlen, die SSLInfo-Attribute als Teil der Zielserverdefinition hinzuzufügen, um Verwechslungen zu vermeiden.

1. Wenn der Back-End-Dienst eine Einweg-SSL-Kommunikation erfordert, dann gilt:
   1. Aktivieren Sie TLS/SSL in der TargetServer-Definition. Binden Sie dazu die SSLInfo-Attribute ein, bei denen das Flag enabled auf „true“ gesetzt ist (siehe unten):

      <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) einbeziehen, 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 Back-End-Dienst eine Zwei-Wege-SSL-Kommunikation erforderlich ist, gilt Folgendes:
   1. Sie müssen die SSLInfo-Attribute mit den Flags ClientAuthEnabled, Keystore, KeyAlias und Truststore entsprechend festgelegt haben, wie unten gezeigt:

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

Ursache: EOFException vom Back-End-Server

Der Back-End-Server kann das Ende der Datei (EOF) abrupt senden.

Diagnose

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

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

   "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 ist der Fehler java.io.EOFException: eof unexpected aufgetreten, während der Message Processor versucht, eine Antwort vom Back-End-Server zu lesen. Diese Ausnahme gibt das Ende der Datei (EOF) an oder das Ende des Streams wurde unerwartet erreicht.

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

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

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

   2. Wenn Ihr Back-End-Serverhost mehrere IP-Adressen hat, verwenden Sie den folgenden Befehl:

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

      Dieser Fehler wird in der Regel dadurch verursacht, dass der Back-End-Server mit [FIN,ACK] antwortet, sobald der Message Processor die Anfrage an den Back-End-Server sendet.

5. Sehen Sie sich das folgende tcpdump-Beispiel an.

   Beispiel tcpdump aufgenommen, als 502 Bad Gateway Error (UnexpectedEOFAtTarget) aufgetreten ist

   

6. In der Ausgabe von TCPDump sehen Sie die folgende Ereignisabfolge:
   1. Im Paket 985 sendet der Message Processor die API-Anfrage an den Back-End-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] an den Back-End-Server.
   4. Schließlich werden die Verbindungen mit [ACK] und [RST] auf beiden Seiten geschlossen.
   5. Da der Back-End-Server [FIN,ACK] sendet, erhalten Sie die Ausnahme java.io.EOFException: eof unexpected für den Message Processor.
7. Das kann passieren, wenn ein Netzwerkproblem auf dem Back-End-Server vorliegt. Beauftragen Sie Ihr Network Operations-Team damit, dieses Problem weiter zu untersuchen.

Auflösung

Beheben Sie das Problem auf dem Back-End-Server entsprechend.

Wenn das Problem weiterhin besteht und Sie Hilfe 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 herausfinden, ob dies die Ursache für die Fehler 502 ist, lesen Sie sich die folgenden Konzepte durch.

Persistente Verbindungen in Apigee

Apigee (und im Folgenden dem HTTP/1.1-Standard) verwendet standardmäßig persistente Verbindungen für die Kommunikation mit dem Ziel-Back-End-Server. Persistente Verbindungen können die Leistung steigern, da sie die Wiederverwendung einer bereits hergestellten TCP- und (falls zutreffend) TLS/SSL-Verbindung zulassen. Dadurch wird der Latenzaufwand reduziert. Die Dauer, für die eine Verbindung bestehen muss, wird durch ein Keep-Alive-Zeitlimit für das Attribut (keepalive.timeout.millis) gesteuert.

Sowohl der Back-End-Server als auch der Apigee Message Processor verwenden Keep-Alive-Zeitlimits, um Verbindungen untereinander offen zu halten. Sobald keine Daten mehr innerhalb des Keep-Alive-Zeitlimits empfangen werden, kann der Back-End-Server oder Message Processor die Verbindung mit dem anderen Server beenden.

Für API-Proxys, die für einen Message Processor in Apigee bereitgestellt werden, ist standardmäßig ein Keep-Alive-Zeitlimit auf 60s festgelegt, sofern diese Einstellung nicht überschrieben wird. Sobald keine Daten für 60s empfangen werden, beendet Apigee die Verbindung mit dem Back-End-Server. Der Back-End-Server unterhält auch ein Keep-Alive-Zeitlimit. Sobald dieses abläuft, schließt der Back-End-Server die Verbindung mit dem Message Processor.

Folgen einer falschen Konfiguration für ein Keep-Alive-Zeitlimit

Wenn entweder Apigee oder der Back-End-Server mit falschen Keep-Alive-Zeitüberschreitungen konfiguriert ist, führt dies zu einer Race-Bedingung, die dazu führt, dass der Back-End-Server als Antwort auf eine Anfrage für eine Ressource eine unerwartete End Of File (FIN) sendet.

Wenn beispielsweise das Keep-Alive-Zeitlimit im API-Proxy oder im Message Processor mit einem Wert konfiguriert wird, der größer oder gleich dem Zeitlimit des Upstream-Back-End-Servers ist, kann die folgende Race-Bedingung eintreten. Das heißt, wenn der Message Processor keine Daten empfängt, bis sehr nahe am Grenzwert des Keep-Alive-Zeitlimits des Back-End-Servers, dann kommt eine Anfrage durch und wird über die vorhandene Verbindung an den Back-End-Server gesendet. Dies kann aufgrund eines unerwarteten EOF-Fehlers zu 502 Bad Gateway führen, wie unten erläutert:

1. Nehmen wir an, das für den Message Processor und den Back-End-Server festgelegte Keep-Alive-Zeitlimit beträgt 60 Sekunden und es kam erst 59 Sekunden, nachdem die vorherige Anfrage vom jeweiligen Message Processor verarbeitet wurde, keine neue Anfrage ein.
2. Der Message Processor fährt fort und verarbeitet die in der 59. Sekunde eingegangene Anfrage unter Verwendung der vorhandenen Verbindung (da das Keep-Alive-Zeitlimit noch nicht verstrichen ist) und sendet die Anfrage an den Back-End-Server.
3. Bevor die Anfrage beim Back-End-Server ankommt, wurde der Zeitlimitgrenzwert für das Keep-Alive-Zeitlimit auf dem Back-End-Server jedoch inzwischen überschritten.
4. Die Anfrage des Message Processor für eine Ressource ist noch in Bearbeitung, aber der Back-End-Server versucht, die Verbindung durch Senden eines FIN-Pakets an den Message Processor zu beenden.
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 vom Message Processor ein 502 an den Client zurückgegeben.

In diesem Fall haben wir den Fehler 502 beobachtet, weil auf dem Message Processor- als auch auf dem Back-End-Server dasselbe Keep-Alive-Zeitlimit von 60 Sekunden konfiguriert wurde. Ebenso kann dieses Problem auftreten, wenn für das Keep-Alive-Zeitlimit auf dem Message Processor ein höherer Wert als auf dem Back-End-Server konfiguriert ist.

Diagnose

1. Wenn Sie ein Public Cloud-Nutzer sind:
   1. Verwenden Sie das API-Monitoring oder das Trace-Tool (wie unter Allgemeine Diagnoseschritte erläutert) und prüfen Sie, ob die beiden folgenden Einstellungen vorhanden sind:
      • Fehlercode: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Fehlerquelle: target
   2. Weitere Informationen finden Sie im Hilfeartikel tcpdump verwenden.
2. Wenn Sie ein Private Cloud-Nutzer sind:
   1. Verwenden Sie das Trace-Tool oder die NGINX-Zugriffslogs, um die Nachrichten-ID, den Fehlercode und die Fehlerquelle für den Fehler 502 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 gibt an, dass der Message Processor eine EOF empfangen hat, während noch auf das Lesen einer Antwort vom Back-End-Server gewartet wurde.
   5. Das Attribut useCount=7 in der obigen Fehlermeldung gibt an, dass der Message Processor diese Verbindung etwa siebenmal wiederverwendet hat, und das Attribut bytesWritten=159 gibt an, dass der Message Processor die Anfragenutzlast von 159 Byte an den Back-End-Server gesendet hat. Beim Auftreten des unerwarteten EOF wurden jedoch keine Byte zurückgeschickt.

   6. Dies zeigt, dass der Message Processor dieselbe Verbindung mehrmals verwendet hat und in diesem Fall Daten gesendet hat, aber kurz darauf ein EOF erhalten hat, bevor Daten empfangen wurden. Das bedeutet, dass das Keep-Alive-Zeitlimit des Back-End-Servers mit hoher Wahrscheinlichkeit kürzer oder gleich dem im API-Proxy festgelegten Wert ist.

      Mit tcpdump kannst du der Sache auf den Grund gehen (siehe unten).

„tcpdump“ verwenden

1. Erfassen Sie tcpdump auf dem Back-End-Server mit dem folgenden Befehl:

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

2. Analysieren Sie die erfassten tcpdump:

   Beispiel für eine tcpdump-Ausgabe:

   

   Im obigen Beispiel-tcpdump wird Folgendes angezeigt:

   1. Im Paket 5992, hat der Back-End-Server eine GET-Anfrage erhalten.
   2. Im Paket 6064 antwortet er mit 200 OK..
   3. Im Paket 6084 hat der Back-End-Server eine weitere GET-Anfrage erhalten.
   4. Im Paket 6154 antwortet es mit 200 OK.
   5. Im Paket 6228 hat der Back-End-Server eine dritte GET-Anfrage erhalten.
   6. Dieses Mal gibt der Back-End-Server ein FIN, ACK an den Message Processor (Paket 6285) zurück, das das Schließen der Verbindung initiiert.

   Dieselbe Verbindung wurde in diesem Beispiel zweimal erfolgreich wiederverwendet, aber bei der dritten Anfrage initiiert der Back-End-Server eine Beendigung der Verbindung, während der Message Processor auf die Daten vom Back-End-Server wartet. Dies deutet darauf hin, dass das Keep-Alive-Zeitlimit des Back-End-Servers höchstwahrscheinlich kürzer oder gleich dem im API-Proxy festgelegten Wert ist. Informationen dazu finden Sie unter Keep-Alive-Zeitlimit auf Apigee und Back-End-Server vergleichen.

Keep-Alive-Zeitlimit auf Apigee und Back-End-Server vergleichen

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

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

   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 Attribut für die Keep-Alive-Zeitüberschreitung mit einem Wert von 30 Sekunden (30000 Millisekunden) überschrieben.

3. Prüfen Sie als Nächstes das Attribut für das Keep-Alive-Zeitlimit, das auf Ihrem Back-End-Server konfiguriert ist. Angenommen, Ihr Back-End-Server ist mit dem Wert 25 seconds konfiguriert.
4. Wenn Sie feststellen, dass der Wert des Keep-Alive-Zeitlimits in Apigee höher ist als der Wert des Keep-Alive-Zeitlimits auf dem Back-End-Server wie im obigen Beispiel, dann ist dies die Ursache für 502-Fehler.

Auflösung

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

1. Legen Sie den Wert für das Keep-Alive-Zeitlimit auf dem Back-End-Server fest.
2. Konfigurieren Sie einen geeigneten Wert für das Keep-Alive-Zeitlimit im API-Proxy oder im Message Processor, sodass das Keep-Alive-Zeitlimitattribut niedriger ist als der Wert, der auf dem Back-End-Server festgelegt wurde. Folgen Sie dazu der Anleitung unter Keep-Alive-Zeitlimit bei Message Processorn konfigurieren.

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

Best Practices

Es wird dringend empfohlen, dass die nachgelagerten Komponenten immer einen niedrigeren Wert für das Keep-Alive-Zeitlimit haben als auf den Upstream-Servern konfiguriert, um diese Art von Race-Bedingungen und 502-Fehlern zu vermeiden. Jeder nachgelagerte Hop sollte kleiner sein als jeder Upstream-Hop. In Apigee Edge empfiehlt es sich, die folgenden Richtlinien zu verwenden:

1. Das Keep-Alive-Zeitlimit des Clients sollte kleiner als das Keep-Alive-Zeitlimit des Edge Routers sein.
2. Das Keep-Alive-Zeitlimit des Edge Routers sollte kleiner als das Keep-Alive-Zeitlimit des Message Processor sein.
3. Das Keep-Alive-Zeitlimit des Message Processor sollte unter dem Keep-Alive-Zeitlimit des Zielservers liegen.
4. Wenn sich andere Hops vor oder hinter Apigee befinden, sollte dieselbe Regel angewendet werden. Sie sollten es immer in der Verantwortung des nachgelagerten Clients liegen, die Verbindung mit dem Upstream zu schließen.

Erfassen von Diagnoseinformationen erforderlich

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

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

• Name der Organisation
• Name der Umgebung
• API-Proxy-Name
• Führen Sie den Befehl curl aus, um den Fehler 502 zu reproduzieren.
• Trace-Datei, die die Anfragen mit dem Fehler 502 Bad Gateway - Unexpected EOF enthält
• Wenn die 502-Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit den Zeitzoneninformationen an, in denen 502-Fehler in der Vergangenheit aufgetreten sind.

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

• Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
• Organisation, Umgebungsname und API-Proxy-Name, für die Sie 502 Fehler beobachten
• API-Proxy-Bundle
• Trace-Datei, die die Anfragen mit dem Fehler 502 Bad Gateway - Unexpected EOF enthält
• 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 von den Message Processors oder dem Back-End-Server oder in beiden Fällen erfasst wurden, als der Fehler aufgetreten ist