Was ist ein 502 Bad Gateway und wer trägt die Schuld?

Ein 502 Bad Gateway ist ein Server, der Sie darauf hinweist, dass ein anderer Server, auf den er angewiesen war, mit etwas antwortet hat, das er nicht verwenden konnte. Nicht „die Website ist offline”, genau gesagt, und auch nicht „Sie haben etwas falsch gemacht”: Eine Maschine in der Mitte hat die Maschine dahinter um Ihre Seite gebeten, und was zurückkam, war Müll, eine verschlossene Tür oder etwas, das keinen Sinn ergab.

Das Wort Gateway ist der Schlüssel. Der Server, den Sie erreicht haben, ist nicht der, der Ihre Seite erstellt; es ist eine Front, ein Reverse Proxy oder ein Load Balancer, der vor der Anwendung steht, die die eigentliche Arbeit leistet. Wenn diese Front eine fehlerhafte Antwort von hinten erhält, ist das Einzige, das sie ehrlich für Sie berichten kann, dass die Antwort fehlerhaft war. Und genau das bedeutet 502.

Das Zwei-Server-Modell

Fast jede Website mit nennenswerten Ausmaßen besteht aus mindestens zwei Maschinen. Es gibt diejenige, mit der sich Ihr Browser zuerst verbindet – nginx, einen CDN Edge, einen Cloud Load Balancer – und dahinter den Application Server, der den Code ausführt und die Seite erstellt.

Die Front nimmt Ihre Anfrage und leitet sie weiter. Meistens antwortet die Anwendung sauber und die Front reicht Ihnen diese Antwort unsichtbar weiter. Ein 502 ist das, was Sie sehen, wenn dieser zweite Schritt fehlschlägt: Die Front hat gefragt, und die Antwort, die sie erhielt, war keine gültige HTTP-Antwort, die sie weiterleiten konnte.

Ein 502 ist also nie wirklich über den Server, den Sie erreicht haben. Es ist eine Nachricht über den, den Sie nicht erreicht haben.

502 gegen 504, die ständig verwechselt werden

Sie kommen von der gleichen Stelle – dem Front-Server, der über den dahinter liegenden berichtet – und eine Unterscheidung zwischen ihnen grenzt die Ursache stark ein.

502 Bad Gateway

Der Upstream antwortet, aber die Antwort war unbrauchbar – Verbindung verweigert, ein abgestürzter Prozess, Müll auf der Leitung. Normalerweise schnell

504 Gateway Timeout

Der Upstream antwortet überhaupt nicht innerhalb der zulässigen Zeit. Normalerweise langsam, und die Pausierung vor dem Fehler ist selbst ein Hinweis

Vereinfacht gesagt: 502 bedeutet „es hat etwas Falsches gesagt”, 504 bedeutet „es hat noch gar nichts gesagt”. Ein 502 kommt schnell an und weist auf etwas Kaputtes, Abgestürztes oder auf Verbindungsablehnung hin; ein 504 kommt langsam an und weist auf etwas Hängengebliebenes oder Überlastetes hin. Wenn der Fehler fast sofort zurückkam, ist es weit wahrscheinlicher ein 502 als ein 504, egal was die Seite sagt.

Ein Punkt, den die meisten Artikel übersehen: Anbieter beschriften das um. Cloudflare liefert sein eigenes 502, wenn Ihr Origin eine ungültige Antwort sendet, und sein eigenes 520, wenn eine Antwort so fehlerhaft ist, dass sie in keinen Standardcode passt. Hinter einem CDN kann die Nummer, die Sie sehen, das CDN-Verständnis desselben Ereignisses sein, nicht unbedingt das Ihres Servers.

Wenn Sie der Besucher sind

Laden Sie die Seite einmal neu, denn ein 502 ist oft nur ein einzelner abgestürzter Worker oder ein Prozess, der mitten im Neustart unterbrochen wurde, und die nächste Anfrage landet auf einem gesunden. Wenn es sich klärt, gibt es nichts weiter zu verfolgen.

Wenn es weiterhin vorhanden ist, liegt der Fehler auf der Seite der Website, und Sie können ehrlich gesagt nicht viel mehr tun, als sie darauf hinzuweisen, da keine Einstellung in Ihrem Browser einen kaputten Prozess auf ihrem Server erreicht. Bevor Sie annehmen, dass es an Ihnen liegt, bestätigen Sie, dass es nicht lokal ist: Die schnellste Überprüfung ist, den HTTP-Statusprüfer auf die Adresse zu richten, der die Seite von unserem Server anfordert, nicht von Ihrem, und meldet den zurückkommenden Code. Wenn er auch den 502 sieht, liegt das Problem nicht an Ihrer Verbindung.

Wenn es Ihre Website ist

Ein 502 bedeutet, dass die Front das, was die Anwendung gesendet hat, nicht verwenden konnte, also ist die Frage, was die Anwendung getan hat. Es gibt nur wenige häufige Antworten.

Der Anwendungsprozess ist offline oder stürzt ab. Die bei weitem häufigste Ursache. Die Front versucht sich zu verbinden und erhält „Verbindung verweigert”, weil nichts zuhört, oder der Prozess akzeptiert die Anfrage und stürzt mitten in der Antwort ab. Überprüfen Sie, ob die App tatsächlich läuft, und lesen Sie ihre eigenen Protokolle nach einem Absturz oder einer Out-of-Memory-Terminierung zum Zeitpunkt des Fehlers – die Protokolle der Front sagen nur, dass der Upstream fehlgeschlagen ist, nie warum.

Ein Timeout-Mismatch zwischen den Ebenen. Wenn die Anwendung länger antwortet, als die Front bereit ist zu warten, melden einige Proxies das als 502 statt als 504, schließen die Verbindung und nennen die halbfertige Antwort fehlerhaft. Wenn ein 502 eher mit langsamen Anfragen korreliert als mit Abstürzen, schauen Sie hier hin.

Ein schlechtes Deployment. Ein neuer Build, der nicht startet, auf dem falschen Port lauscht oder mit Headern antwortet, die die Front ablehnt, wird jede Anfrage zu einem 502, sobald sie live geht. Wenn die Fehler mit einem Deployment begannen, ist das der erste Ort zum Nachschauen, und ein Rollback ist schneller als eine Diagnose.

Etwas zwischen den Ebenen. Ein fehlkonfigurierter proxy_pass, ein Upstream-Hostname, der nicht mehr aufgelöst wird, eine Sicherheitsgruppe, die leise aufgehört hat, der Front zu erlauben, die App zu erreichen – die Verbindung wird nie abgeschlossen und die Front meldet ein schlechtes Gateway. Diese sind am schwierigsten zu finden, da nichts abgestürzt ist; ein Glied in der Kette hat einfach aufgehört, Traffic zu tragen.

Warum diese später so schwer zu verfolgen sind

Ein 502 ist oft weg, bevor jemand hinschaut. Der abgestürzte Worker startet neu, das Deployment wird zurückgerollt, der Verkehrsspitzenbetrieb vergeht, und das Protokoll der Front sagt nur, dass eine Upstream-Anfrage um 09:14 Uhr fehlgeschlagen ist – nicht, was der Upstream sagte, nicht welcher Prozess, nicht warum.

Was es schließlich regelt, ist Beweis, der erfasst wird, während es passiert: die fehlgeschlagene Anfrage, der genaue Status, die Uhrzeit und was die Person tat, als es erschien. Ein 502, das ein Benutzer eine Stunde später aus dem Gedächtnis berichtet, ist eine Vermutung. Ein 502 mit der fehlgeschlagenen Anfrage und ihrem Zeitstempel ist eine Zeile, die Sie gegen das Anwendungsprotokoll und die Deployment-Historie abgleichen und schließen können.

Das Netzwerkprotokoll enthält die fehlgeschlagene Anfrage mit ihrem 502 und den Moment, in dem es passierte, gespeichert wie es schiefging, nicht erinnert später – was der Unterschied ist zwischen einem Bericht, auf den jemand handeln kann, und einem, den sie zuerst nachstellen müssen.

In einem Absatz

Ein 502 Bad Gateway ist ein Front-Server, der sagt, der Server dahinter hat eine Antwort gegeben, die er nicht verwenden konnte – abgestürzt, verweigert oder fehlerhaft – und es kommt schnell an, was es von der langsamen 504 unterscheidet. Wenn Sie die Seite besuchen, laden Sie einmal neu und nehmen Sie dann an, dass es auf deren Seite liegt. Wenn es Ihre ist, überprüfen Sie, ob die Anwendung läuft und was sie geprotokolliert hat, vermuten Sie das letzte Deployment, wenn die Uhrzeit passt, und erfassen Sie die fehlgeschlagene Anfrage, während Sie sie haben, denn ein 502 ist fast unmöglich zu verfolgen, sobald es vergangen ist.