502 Ungültiges Gateway – unerwartetes EOF

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Die Clientanwendung ruft den HTTP-Statuscode 502 zusammen mit der Nachricht ab Bad Gateway als Antwort auf API-Aufrufe.

Der HTTP-Statuscode 502 bedeutet, dass der Client keine gültige Antwort vom die die Anfrage erfüllen sollen.

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

Ein typischer Grund für 502 Bad Gateway Error ist Unexpected EOF Fehler, der folgende Ursachen haben kann:

Ursache	Details	Angegebene Schritte für
Falsch konfigurierter Zielserver	Der Zielserver ist nicht korrekt konfiguriert und unterstützt TLS/SSL-Verbindungen.	Edge-Nutzer von öffentlichen und privaten Clouds
EOFException vom Backend-Server	Der Backend-Server sendet die EOF möglicherweise abrupt.	Nur Edge Private Cloud-Nutzer
Falsch konfiguriertes Keep-Alive-Zeitlimit	Keep-Alive-Zeitüberschreitungen, die auf Apigee und Backend-Server falsch konfiguriert sind.	Edge-Nutzer von öffentlichen und privaten Clouds

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 korrekt konfiguriert und unterstützt TLS/SSL-Verbindungen.

Diagnose

1. Verwenden Sie API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs zur Bestimmung der Nachrichten-ID, Fehlercode und Fehlerquelle für den Fehler 502.
2. Aktivieren Sie den Trace in der UI für die betroffene API.
3. Wenn der Trace für die fehlgeschlagene API-Anfrage Folgendes anzeigt: <ph type="x-smartling-placeholder">
   </ph>
   1. Der Fehler 502 Bad Gateway wird angezeigt, sobald die Zielflussanfrage gestartet wurde.
   2. error.class zeigt messaging.adaptors.http.UnexpectedEOF. an

      Dann wird dieses Problem sehr wahrscheinlich durch einen falschen Zielserver verursacht. Konfiguration.

4. Rufen Sie die Zielserverdefinition mithilfe des Aufrufs der Edge Management API ab: <ph type="x-smartling-placeholder">
   </ph>
   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 illustrierte TargetServer-Definition ist ein Beispiel für eine der typischen Fehlkonfigurationen, die wie folgt erklärt werden:

   Angenommen, der Zielserver mocktarget.apigee.net ist konfiguriert um sichere (HTTPS)-Verbindungen an Port 443 zu akzeptieren. Wenn Sie sich jedoch der Zielserverdefinition entspricht, gibt es keine anderen Attribute/Flags, die darauf hinweisen, für sichere Verbindungen. Dies führt dazu, dass Edge die API-Anfragen verarbeitet, die an die Einen bestimmten Zielserver als (nicht sichere) HTTP-Anfragen angeben. Edge kann also nicht Initiieren Sie den SSL-Handshake mit diesem Zielserver.

   Da der Zielserver so konfiguriert ist, dass er nur HTTPS-Anfragen (SSL) für 443 akzeptiert, wird er: lehnen Sie die Anfrage von Edge ab oder schließen Sie die Verbindung. Als Folge erhalten Sie eine UnexpectedEOFAtTarget-Fehler im Message Processor. Der Message Processor sendet 502 Bad Gateway als Antwort an den Client.

Auflösung

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

Wenn Sie im obigen Beispiel Anfragen an ein sicheres Ziel (HTTPS/SSL) senden möchten Server enthält, müssen Sie die SSLInfo-Attribute mit gesetztem Flag enabled einfügen an true. Die SSLInfo-Attribute für einen Zielserver im Ziel dürfen zwar hinzugefügt werden, Endpunktdefinition selbst, wird empfohlen, die SSLInfo-Attribute als Teil des Ziels hinzuzufügen. um Verwechslungen zu vermeiden.

1. Wenn der Back-End-Dienst eine einseitige SSL-Kommunikation erfordert, gilt Folgendes: <ph type="x-smartling-placeholder">
   </ph>
   1. Sie müssen TLS/SSL in der TargetServer-Definition aktivieren, indem Sie SSLInfo einschließen Attribute, bei denen das Flag enabled auf "true" gesetzt ist, wie unten gezeigt:

      <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 Schließen Sie den Truststore (mit dem Zertifikat des Zielservers) ein, 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 der Back-End-Dienst eine Zwei-Wege-SSL-Kommunikation erfordert, dann gilt: <ph type="x-smartling-placeholder">
   </ph>
   1. Sie müssen SSLInfo-Attribute mit ClientAuthEnabled haben, Keystore, KeyAlias und Truststore-Flags wurden entsprechend festgelegt, 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 auf Backend-Servern

Ursache: EOFException vom Back-End-Server

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

Diagnose

1. Verwenden Sie API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs zur Bestimmung der Nachrichten-ID, Fehlercode und Fehlerquelle für den Fehler 502.
2. Message Processor-Logs prüfen (/opt/apigee/var/log/edge-message-processor/logs/system.log) und suche, um zu sehen, ob du Sie benötigen eof unexpected für die jeweilige API oder wenn Sie die eindeutige messageid für die API haben suchen, können Sie danach suchen.

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

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

3. Überprüfe deine Backend-Serverprotokolle auf Fehler oder Informationen, die möglicherweise haben den Back-End-Server dazu veranlasst, die Verbindung abrupt zu beenden. Wenn Sie Fehler/Informationen und gehe zu Lösung und beheben Sie das Problem entsprechend in Ihrem Backend-Server.
4. Wenn Sie keine Fehler oder Informationen auf Ihrem Backend-Server finden, erfassen Sie die tcpdump-Ausgabe in den Message Processors: <ph type="x-smartling-placeholder">
   </ph>
   1. Wenn Ihr Back-End-Serverhost nur eine 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], sobald der Message Processor die Anfrage an den Back-End-Server sendet.

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

   Stichprobe tcpdump, aufgenommen bei 502 Bad Gateway Error (UnexpectedEOFAtTarget)

   

6. In der Ausgabe von TCPDump sehen Sie die folgende Abfolge von Ereignissen: <ph type="x-smartling-placeholder">
   </ph>
   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 das Back-End Server.
   4. Schließlich werden die Verbindungen mit [ACK] und [RST] auf beiden Seiten geschlossen.
   5. Da der Backend-Server [FIN,ACK] sendet, erhalten Sie die Ausnahme java.io.EOFException: eof unexpected Ausnahme für die Nachricht Prozessor.
7. Dies kann passieren, wenn ein Netzwerkproblem mit dem Backend-Server vorliegt. Mit deinem Netzwerk interagieren dieses Problem weiter untersuchen.

Auflösung

Beheben Sie das Problem auf dem Backend-Server entsprechend.

Wenn das Problem weiterhin besteht und du Hilfe bei der Fehlerbehebung benötigst, 502 Bad Gateway Error oder du Wenn Sie ein Problem in Edge vermuten, wenden Sie sich an den Apigee Edge-Support.

Ursache: Falsch konfiguriertes Keep-Alive-Zeitlimit

Bevor Sie herausfinden, ob dies die Ursache für den 502-Fehler ist, lesen Sie sich die folgenden Konzepte.

Persistente Verbindungen in Apigee

Apigee verwendet standardmäßig persistente Verbindungen (und im Folgenden mit dem HTTP/1.1-Standard). beim Kommunizieren mit dem Ziel-Back-End-Server. Persistente Verbindungen können die Leistung steigern durch Wiederverwendung einer bereits hergestellten TCP- und (falls zutreffend) TLS/SSL-Verbindung, die den Latenz-Overhead. Die Dauer, für die eine Verbindung aufrechterhalten werden muss, über ein Keep-Alive-Zeitlimit (keepalive.timeout.millis) der Property.

Sowohl der Back-End-Server als auch der Apigee Message Processor verwenden Keep-Alive-Zeitüberschreitungen, um und Verbindungen öffnen. Wenn innerhalb des Keep-Alive-Zeitlimits keine Daten empfangen werden kann der Back-End-Server oder Message Processor die Verbindung mit dem jeweils anderen trennen.

Für API-Proxys, die für einen Message Processor in Apigee bereitgestellt werden, ist standardmäßig ein Keep-Alive-Zeitlimit festgelegt auf 60s, sofern nicht überschrieben. Wenn für 60s keine Daten empfangen werden, führt Apigee die Verbindung mit dem Backend-Server schließen. Der Back-End-Server hält auch ein Keep-Alive-Zeitlimit ein, Nach Ablauf dieser Zeit schließt der Backend-Server die Verbindung mit dem Message Processor.

Folge einer falschen Konfiguration für das Keep-Alive-Zeitlimit

Wenn entweder Apigee oder der Backend-Server mit falschen Keep-Alive-Zeitüberschreitungen konfiguriert sind, führt zu einer Race-Bedingung, die dazu führt, dass der Back-End-Server als Antwort auf eine Ressourcenanfrage ein unerwartetes End Of File (FIN) sendet.

Wenn beispielsweise das Keep-Alive-Zeitlimit im API-Proxy oder in der Nachricht Für Prozessor mit einem Wert größer oder gleich dem Zeitlimit des Upstream-Back-End-Servers, dann folgende Race-Bedingung auftreten kann. Wenn der Message Processor also keine bis der Grenzwert des Back-End-Servers Alive bleibt, wird eine Anfrage gesendet, durchläuft und wird über die bestehende Verbindung an den Backend-Server gesendet. Dies kann zu 502 Bad Gateway aufgrund eines unerwarteten EOF-Fehlers, wie unten erläutert:

1. Nehmen wir an, das Keep-Alive-Zeitlimit, das sowohl für den Message Processor als auch für den Back-End-Server festgelegt ist 60 Sekunden und es werden keine neuen -Anfrage erst 59 Sekunden, nachdem die vorherige Anfrage vom spezifischen Message Processor.
2. Der Message Processor verarbeitet die Anfrage, die in der 59. Sekunde eingegangen ist. über die vorhandene Verbindung (da das Keep-Alive-Zeitlimit noch nicht abgelaufen ist) und sendet den -Anfrage an den Back-End-Server.
3. Bevor die Anfrage beim Back-End-Server eingeht, gilt jedoch das Keep-Alive-Zeitlimit. Grenzwert auf dem Backend-Server überschritten wurde.
4. Die Anfrage des Message Processor für eine Ressource ist in Bearbeitung, aber der Back-End-Server versucht, die Verbindung durch Senden eines FIN-Pakets an die Nachricht zu schließen Prozessor.
5. Während der Message Processor auf den Empfang der Daten wartet, empfängt er stattdessen den unerwarteten FIN, und die Verbindung wird beendet.
6. Dies führt zu einem Unexpected EOF und dementsprechend ist ein 502 vom Message Processor an den Client zurückgegeben.

In diesem Fall ist der Fehler 502 aufgetreten, weil dasselbe Keep-Alive-Zeitlimit sowohl auf dem Message Processor als auch auf dem Back-End-Server konfiguriert wurde. In ähnlicher Weise Dieses Problem kann auch auftreten, wenn für das Keep-Alive-Zeitlimit in der Nachricht ein höherer Wert festgelegt ist. Prozessor als auf dem Backend-Server.

Diagnose

1. Wenn Sie ein Public Cloud-Nutzer sind: <ph type="x-smartling-placeholder">
   </ph>
   1. Verwenden Sie das API-Überwachungs- oder Trace-Tool (wie unter Häufige Diagnoseschritte) und prüfen Sie, ob die beiden folgenden Voraussetzungen erfüllt sind: Einstellungen: <ph type="x-smartling-placeholder">
      </ph>
      • Fehlercode: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Fehlerquelle: target
   2. Weitere Informationen finden Sie unter tcpdump verwenden.
2. Wenn Sie ein Private Cloud-Nutzer sind: <ph type="x-smartling-placeholder">
   </ph>
   1. Verwenden Sie das Trace-Tool oder NGINX-Zugriffslogs zur Bestimmung der Nachrichten-ID, Fehlercode und Fehlerquelle für den Fehler 502.
   2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID.
      (/opt/apigee/var/log/edge-message-processor/logs/system.log)
   3. Sie sehen das 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 Der Message Processor hat eine EOF erhalten, während er noch auf das Lesen eines Antwort vom Back-End-Server.
   5. Das Attribut useCount=7 in der obigen Fehlermeldung gibt an, dass das Attribut Message Processor hat diese Verbindung etwa sieben Mal wiederverwendet und das Attribut bytesWritten=159 gibt an, dass der Message Processor die Anfrage gesendet hat. Nutzlast von 159 Byte zum Back-End-Server. Er hat jedoch null Byte empfangen. zurück, als das unerwartete EOF-Ereignis aufgetreten ist.

   6. Dies zeigt, dass der Message Processor dieselbe Verbindung mehrmals verwendet hat, und diesmal Daten gesendet, aber kurz danach wurde eine EOF bevor Daten empfangen wurden. Das bedeutet, dass die Wahrscheinlichkeit hoch ist, Das Keep-Alive-Zeitlimit des Servers ist kürzer oder gleich dem im API-Proxy festgelegten Timeout.

      Du kannst das Problem mithilfe von tcpdump wie unten beschrieben weiter untersuchen.

„tcpdump“ verwenden

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

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

2. Analysieren Sie die erfassten tcpdump:

   Hier ein Beispiel für eine tcpdump-Ausgabe:

   

   In der obigen Beispiel-tcpdump sehen Sie Folgendes:

   1. Im Paket 5992, hat der Back-End-Server eine GET-Anfrage empfangen.
   2. Im Paket 6064 antwortet es 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 Backend-Server eine FIN, ACK an den Message Processor zurück. (Paket 6285), das die Schließung der Verbindung einleitet.

   In diesem Beispiel wurde dieselbe Verbindung zweimal erfolgreich wiederverwendet, aber bei der dritten Anfrage der Backend-Server die Beendigung der Verbindung initiiert, während der Message Processor beim Warten auf Daten vom Back-End-Server. Dies deutet darauf hin, dass die Back-End-Server Alive-Zeitüberschreitung ist höchstwahrscheinlich kürzer oder gleich dem im API-Proxy festgelegten Wert. Zur Validierung Weitere Informationen finden Sie unter Keep-Alive-Zeitlimit auf Apigee und Back-End-Server vergleichen.

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

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

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

   TargetEndpoint-Beispielkonfiguration:

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

3. Prüfen Sie als Nächstes die Eigenschaft für die Keep-Alive-Zeitüberschreitung, die auf Ihrem Back-End-Server konfiguriert ist. Nehmen wir an, 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 Back-End-Server (siehe oben). Beispiel: Dies ist die Ursache für 502-Fehler.

Auflösung

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

1. Ermitteln Sie den für das Keep-Alive-Zeitlimit auf dem Back-End-Server eingestellten Wert.
2. Konfigurieren Sie einen geeigneten Wert für die Eigenschaft Keep-Alive-Zeitüberschreitung im API-Proxy oder Message Processor, sodass die Eigenschaft für das Keep-Alive-Zeitlimit niedriger ist als der Wert, der auf der Back-End-Server zu generieren, indem Sie die Schritte in <ph type="x-smartling-placeholder"></ph> Keep-Alive-Zeitüberschreitung bei 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 ein geringeres Keep-Alive-Zeitlimit haben Grenzwert als auf den Upstream-Servern konfiguriert, um diese Art von Race-Bedingungen und 502 Fehler. Jeder Downstream-Hop muss kleiner sein als jeder Upstream-Hop. In Apigee Edge handelt, sollten Sie sich an die folgenden Richtlinien halten:

1. Das Keep-Alive-Zeitlimit des Clients muss kleiner sein als das Keep-Alive-Zeitlimit des Edge Routers.
2. Das Keep-Alive-Zeitlimit des Edge Routers sollte kleiner als das Keep-Alive-Zeitlimit des Message Processor sein.
3. Das Keep-Alive-Zeitlimit für den Message Processor sollte kleiner sein als das Keep-Alive-Zeitlimit des Zielservers.
4. Wenn Sie weitere Hops vor oder hinter Apigee haben, sollte dieselbe Regel angewendet werden. Sie sollten es immer dem Downstream-Client überlassen, den Verbindung zu den vorgelagerten Emissionen.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung der obigen Anleitung weiterhin besteht, stellen Sie Folgendes zusammen: 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
• API-Proxy-Name
• Führen Sie den curl-Befehl aus, um den 502-Fehler zu reproduzieren
• Ablaufdatei mit den Anfragen mit dem Fehler 502 Bad Gateway - Unexpected EOF
• Falls die 502 Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit Die Zeitzoneninformationen, wenn 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 fehlgeschlagene Anfragen
• Organisation, Umgebungsname und API-Proxy-Name, den Sie beobachten 502 Fehler
• API-Proxy-Bundle
• Ablaufdatei 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 wurde auf den Message Processors oder auf dem Backend-Server oder in beiden erfasst, wenn der Fehler aufgetreten