Was bedeutet ein 500 Internal Server Error und wessen Schuld ist es

Ein 500 Internal Server Error ist der Server, der die Website betreibt, der zugibt, dass etwas in seinem eigenen Code schiefgelaufen ist, und dass er Ihnen deswegen die Seite nicht anzeigen kann. Nicht “die Seite existiert nicht”, nicht “Sie dürfen nicht rein”, nicht “kommen Sie später nochmal” - nur ein ehrliches, unhilfreiches “hier ist etwas kaputt gegangen, und das war nicht Ihre Schuld.”

Das Wichtigste ist das Wort “Internal”. Der Server spricht über sich selbst, nicht über ein Netzwerk, eine Berechtigung oder etwas, das Sie getan haben. Er hat Ihre Anfrage verarbeitet, ist auf einen Fehler gestoßen, den er nicht verarbeiten konnte, und das Einzige, das dann noch zu sagen war, war 500. Deshalb ist die Meldung so vage: Der Server versteckt die Details nicht, um schwierig zu sein, sondern er weigert sich, seine Interna vor Fremden preiszugeben.

Warum es Ihnen nichts sagt

Ein 500 ist der generischste Fehler im Web und das mit Absicht. Wenn eine Anwendung auf eine Weise ausfällt, die sie nicht vorgesehen hat - eine Exception, die niemand abgefangen hat, eine Query die platzt, ein null wo ein Objekt erwartet wurde - ist die sichere Sache, die man der Außenwelt zeigt, eine leere Wand. Die Einzelheiten, was kaputtging, der Stack-Trace, die Zeilennummer, die fehlgeschlagene Abfrage, das bleibt alles auf dem Server, in einem Log, wo nur die Leute, die die Website betreiben, es lesen können.

Die 500, die Sie sehen, und der Grund dafür sind also an zwei verschiedenen Orten. Der Browser hat den Code; der Server hat die Ursache. Diese Lücke ist die ganze Schwierigkeit eines 500, und das ist, warum “ich habe einen 500 bekommen” ein Bericht ist, der einen Entwickler allein kaum hilft.

500 gegenüber 502 und 504, die von außen gleich aussehen

Alle drei gehören zur Familie “auf unserer Seite ist etwas schiefgelaufen”, und sie auseinanderzuhalten bedeutet, auf sehr unterschiedliche Ursachen zu schauen.

500 Internal Server Error

Die Anwendung lief und ihr eigener Code versagte - eine unbehandelte Exception, ein Crash in der Anfrage. Der Server antwortete; die Antwort war ein Fehler, den er selbst verursachte

502 Bad Gateway

Ein Front-Server bekam eine unbrauchbare Antwort von der Anwendung dahinter - abgestürzt, verweigert, malformed. Der Fehler ist zwischen zwei Servern

504 Gateway Timeout

Die Anwendung antwortete überhaupt nicht rechtzeitig. Der Front-Server gab das Warten auf

Grob gesagt: ein 500 ist, dass die Anwendung ausfällt, während sie läuft, ein 502 ist ein Proxy, der keine gute Antwort davon bekommt, und ein 504 ist die Anwendung, die zu langsam zum Antworten ist. Wenn Sie einen 500 bekommen, lief der Code und brach; wenn Sie einen 502 oder 504 bekommen, endete er oft nie ganz. Dieser Unterschied ist das Erste, das wert ist zu wissen, weil er entscheidet, ob Sie in den Anwendungs-Logs oder in der Infrastruktur davor schauen.

Wenn Sie der Besucher sind

Laden Sie die Seite einmal neu, denn viele 500er entstehen nur in einem einzelnen schlechten Moment - eine Anfrage, die eine Racebedingung auslöst, eine Abfrage, die bei hoher Last ausfällt - und der nächste Versuch funktioniert einwandfrei. Wenn es klappt, gibt es nichts zu untersuchen.

Wenn es andauert, liegt der Fehler auf Seite der Website, und es gibt wirklich nichts in Ihrem Browser, das einen Bug in ihrem Code beeinflussen könnte. Den Cache zu löschen, den Inkognito-Modus zu versuchen, Browser zu wechseln - nichts davon berührt den Server, und jedes kostet häufig eine halbe Stunde, in der man einen 500 behandelt, als wäre es ein Problem, das man von seinem Platz aus beheben könnte. Die eine sinnvolle Sache, die Sie tun können, ist ihnen zu sagen, mit ausreichend Detail, damit sie die entsprechende Zeile in ihrem Log finden können: was Sie getan haben, und ungefähr wann.

Wenn es Ihre Website ist

Ein 500 bedeutet, dass Ihr Code etwas geworfen hat, das er nicht verarbeitet, also ist die Frage nur, was, und die Antwort ist in Ihren Logs statt in der Antwort, die der Benutzer sah. Einige wenige Ursachen machen die meisten davon aus.

Eine unbehandelte Exception in der Anfrage. Bei Weitem die häufigste. Eine Methode auf nil aufgerufen, ein Schlüssel, der nicht vorhanden war, ein Typ, der nicht das war, was der Code annahm. Die Anfrage erreichte Ihren Code, Ihr Code warf einen Fehler, und nichts fing ihn auf. Ihr Anwendungs-Log hat den Stack-Trace; der 500 des Benutzers nicht.

Ein fehlgeschlagener Datenbankaufruf. Eine Abfrage gegen eine Spalte, die umbenannt wurde, ein Verbindungs-Pool, der unter Last erschöpft ist, eine Migration, die auf einem Server lief und auf einem anderen nicht. Diese treten häufig in Schüben auf, weil sie Last oder einen Deploy verfolgen statt einer einzelnen Eingabe.

Ein Konfigurations- oder Umgebungsproblem. Eine fehlende Umgebungsvariable, ein Secret, das nicht gesetzt wurde, ein Service, den die App erreichen möchte und nicht kann. Dies sind diejenigen, die jede Anfrage sofort zu einem 500 machen, normalerweise gleich nach einem Deploy oder einer Infrastrukturänderung, und sie wirken beängstigend, genau weil sich nichts im Code geändert hat - aber der Grund darunter schon.

Ein schlechter Deploy. Neuer Code, der auf einem Pfad einen Fehler auslöst, den die Tests nicht abdeckten, oder startet gegen ein Schema, das noch nicht vorhanden ist. Wenn die 500er bei einem Release begannen, ist das der erste Ort zum Schauen, und ein Rollback ist schneller als eine Diagnose.

Der Grund, warum es so schwer ist, einen 500 nachträglich zu verfolgen

Der Fehler, den der Benutzer sah, trägt keine Ursache mit sich, also ist ein 500, der eine Stunde später aus dem Gedächtnis gemeldet wird, nahezu unbrauchbar: Sie haben einen generischen Code und eine ungefähre Zeit, und Sie durchsuchen ein Log nach einer Nadel, die Sie nur als “ungefähr um drei Uhr” beschreiben können. Der Stack-Trace, der den Bug genannt hätte, steht in einer Log-Zeile, die niemand gegen die Anfrage erfasste, die ihn produzierte.

Was einen 500 schnell behebt, ist die Anfrage, die ihn verursachte, seine genaue Zeit, und was die Person tat - erfasst, während es passierte, so dass Sie es mit der einen Log-Zeile abgleichen können, die den echten Fehler enthält. Das ist der Unterschied zwischen einem Bug, den Sie in einer Minute finden, und einem Log, das Sie einen Nachmittag durchsuchen.

Das Netzwerk-Protokoll enthält die fehlgeschlagene Anfrage mit ihrem 500 und den genauen Moment, in dem es geschah, so dass jeder, der den Bericht aufnimmt, ihn mit dem Server-Log abgleichen und den echten Fehler lesen kann - statt das Ganze erst zu reproduzieren, um herauszufinden, was ein generischer Code versteckt hatte.

In einem Absatz

Ein 500 Internal Server Error bedeutet, dass die Anwendung Ihre Anfrage ausführte und ihr eigener Code auf eine Weise versagte, die sie nicht verarbeitete, also zeigte sie die eine sichere, generische Antwort, die sie hatte - was sie von einem 502 unterscheidet, wo ein Proxy keine gute Antwort von der App bekam, und von einem 504, wo die App überhaupt zu langsam zum Antworten war. Wenn Sie ein Besucher sind, laden Sie die Seite einmal neu und nehmen dann an, dass es auf ihrer Seite liegt. Wenn es Ihre Website ist, liegt die Ursache in Ihren Logs, nicht in der Antwort: vermuten Sie eine unbehandelte Exception, eine fehlgeschlagene Abfrage, eine fehlende Konfiguration oder einen letzten Deploy - und erfassen Sie die fehlgeschlagene Anfrage, während Sie sie haben, denn ein 500 sagt Ihnen nichts für sich allein.