Filtere nginx-Fehler nach Statuscode oder Hinweis im Log und finde Ursache samt passender Konfigurationsänderung. Für 502, 504, 403, 404 und 413.
Nginx liefert 502 Bad Gateway, wenn es als Proxy arbeitet und die App dahinter keine gültige Antwort gibt: Die App läuft nicht, lauscht auf einem anderen Port oder Socket oder ist mitten in der Antwort abgestürzt. Starte die App, lass proxy_pass auf die Adresse zeigen, auf der sie wirklich lauscht, und lies dann im nginx-Fehlerlog den genauen Grund nach.
Wohin welcher nginx-Fehler zeigt
Wähle den Statuscode, den du siehst, oder tippe ein Wort aus deinem Fehlerlog ein, und der Finder grenzt die Liste auf die passenden Ursachen ein. Jede Karte nennt die Ursache, die Prüfung, die sie bestätigt, und einen Konfigurationsschnipsel, den du anpassen kannst. Solange du nicht filterst, werden alle Karten angezeigt.
Als Besucher verursachst du ihn mit nichts, was du tust. Der Proxy hat die Anwendung dahinter angefragt und keine gültige Antwort erhalten. Als Betreiber der Website liegt es an deiner App oder deinen Proxy-Einstellungen, also prüfe zuerst, ob der Upstream-Prozess läuft.
Ein 502 bedeutet, dass der Upstream fehlerhaft geantwortet oder die Verbindung abgelehnt hat. Ein 504 bedeutet, dass nginx gewartet hat und nichts rechtzeitig angekommen ist. Das erste deutet auf eine gestoppte oder abstürzende App hin, das zweite auf langsame Verarbeitung oder einen zu niedrig gesetzten Timeout.
Setze client_max_body_size im http-, server- oder location-Block, zum Beispiel client_max_body_size 20m;. Der Standard ist 1m. Ein Wert von 0 schaltet die Größenprüfung ab, was auf einer öffentlichen Website selten gewollt ist.
Endet die URL mit einem Schrägstrich, sucht nginx nach einer Index-Datei wie index.html. Gibt es keine und ist autoindex aus, was der Standard ist, darf nginx nichts ausliefern. Lege die Index-Datei an oder leite die Anfrage mit try_files weiter.
Der Speicherort wird durch die Direktive error_log in deiner Konfiguration festgelegt. Durchsuche deine nginx.conf und die eingebundenen Dateien nach error_log, denn Pakete und Container legen das Log an unterschiedlichen Orten ab.
Ein Ausgangspunkt für eine App auf Port 3000. Er reicht den ursprünglichen Host und das Schema durch, setzt explizite Timeouts und lässt Platz für größere Header.
Teste mit nginx -t und lade dann neu. Passe Port und Limits an deine App an.
Die App hinter nginx läuft nicht, daher wird die Verbindung abgelehnt.
Rufe die proxy_pass-Adresse vom nginx-Rechner aus mit curl ab. Eine abgelehnte Verbindung bestätigt es.
Starte die App unter einem Prozessmanager, der sie nach einem Absturz neu startet.
proxy_pass zeigt auf einen Port oder Socket, auf dem die App nicht lauscht.
Vergleiche die Adresse in proxy_pass mit der, die die App beim Start ausgibt.
Bringe beide exakt in Übereinstimmung, einschließlich des Host-Teils.
Die App sendet Antwort-Header, die größer sind als der Puffer, in den nginx sie einliest, zum Beispiel wegen vieler Cookies.
Suche nach einer Logzeile, die einen zu großen Header erwähnt.
Erhöhe proxy_buffer_size für diese location. Der Standard ist eine Speicherseite, also 4k oder 8k.
Die App brauchte zwischen zwei Lesevorgängen länger als proxy_read_timeout, standardmäßig 60 Sekunden.
Miss dieselbe Anfrage direkt gegen die App mit curl.
Beschleunige den Endpunkt oder verlagere die Arbeit in einen Hintergrundjob. Erhöhe den Timeout nur für diese location.
Nginx konnte innerhalb von proxy_connect_timeout, standardmäßig 60 Sekunden, nicht einmal eine Verbindung öffnen.
Prüfe, ob eine Firewall im Weg ist oder der Host vom Proxy aus nicht erreichbar ist.
Repariere den Netzwerkpfad. Laut nginx-Dokumentation kann dieser Timeout meist nicht über 75 Sekunden liegen, ein Erhöhen hilft also nicht.
Eine URL mit Schrägstrich am Ende hat keine Index-Datei und autoindex ist aus.
Liste den Ordner auf, auf den root zeigt, und suche nach index.html.
Lege die Index-Datei an oder leite die Anfrage mit try_files an deine App weiter.
Der nginx-Worker-Benutzer kann die Datei nicht lesen oder einen der übergeordneten Ordner nicht betreten.
Suche im Fehlerlog nach einer permission-denied-Zeile mit dem Pfad.
Gib dem Worker-Benutzer Leserechte auf die Dateien und Ausführungsrechte auf jeden übergeordneten Ordner.
Eine allow- oder deny-Regel hat auf den Besucher zugetroffen. Die Regeln werden der Reihe nach geprüft, und der erste Treffer gewinnt.
Lies jede allow- und deny-Zeile, die für die location gilt, von oben nach unten.
Ordne die Regeln so, dass das spezifische allow vor dem breiten deny all steht.
Es wurde root verwendet, wo alias gemeint war, daher hängt nginx das location-Präfix doppelt an den Pfad.
Leite den Dateipfad her: root hängt die ganze URI an, alias ersetzt das passende Präfix.
Verwende alias mit Schrägstrich am Ende auf beiden Seiten, wenn der Ordnername von der URL abweicht.
Eine Route einer Single-Page-App wie /dashboard hat keine Datei auf der Festplatte.
Die Startseite lädt, aber ein Neuladen auf einer inneren Route schlägt fehl.
Falle mit try_files auf index.html zurück, damit der Router der App den Pfad übernimmt.
Der Request-Body ist größer als client_max_body_size, standardmäßig 1m.
Uploads unter einem Megabyte funktionieren, größere schlagen fehl.
Erhöhe das Limit nur für die Upload-location.
Statuscode
Alle Codes
Wörter aus deinem Fehlerlog
zum Beispiel: refused, timed out, denied
Prüfen
Lösung
{n} passende Ursachen
Keine Ursache passt. Leere die Suche oder wähle einen anderen Code.
Kostenlos starten · Keine Kreditkarte nötig