Nginx Bad Gateway (502) Fehler bei Django 500 Fehlern (anstatt die Django 500 Seite anzuzeigen) mit DEBUG = False Einstellung

Question

Ich habe ein Problem mit meinem aktuellen Setup ... Und das Problem ist, dass wenn ich DEBUG = False in der Django-Datei settings.py einstelle, nginx bei 500 Fehlern aufhört, Django-Tracebacks anzuzeigen, aber auch nicht unsere 500-Seite. Es wird nur der Nginx-Fehler 502 Bad Gateway angezeigt.

Ich erhalte den E-Mail-Fehler mit Traceback, obwohl ich es so konfiguriert habe, dass mir Tracebacks per E-Mail zugeschickt werden, wenn sie auftreten. Aber ich möchte den Benutzern eine schöne 500-Seite anzeigen und keinen Nginx 502-Gateway-Fehler ...

Ehrlich gesagt weiß ich nicht einmal, wo ich mit der Suche nach der Ursache des Problems beginnen soll. Ich bin bereit, alle erforderlichen Konfigurationsdateien zu posten, wenn ein Nginx-Experte vorbeikommt und mir sagt, was er sehen möchte.

alan

Edit1: Ich habe nachgeschaut, welche Protokolldatei bei einem dieser 500 Fehler angezeigt wird, und dort steht Folgendes:

[pid: 16203|app: 0|req: 1/1] my.ip.address () {46 vars in 915 bytes} [Thu Sep 12 10:01:17 2013] GET /settings/personal/ => generated 0 bytes in 1249 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)

Bedeutet dies, dass es irgendwie ein Fehler von Django ist, weil es so aussieht, als hätte Django 0 Bytes zurückgegeben?

Answer 1

Bedeutet dies, dass es irgendwie ein Fehler von Django ist, weil es so aussieht, als hätte Django 0 Bytes zurückgegeben?

Ja, hier liegt kein Nginx-Problem vor. Das Problem besteht darin, dass Django nichts zurückgibt, sondern eine 500-Fehlerseite.

Answer 2

Verwenden Sie die error_page-Direktive von nginx dokumentiertHier

Damit fängt Nginx den 5XX-Fehler vom Backend ab und zeigt dem Endbenutzer jede gewünschte Seite an.

Answer 3

Ich hatte vor kurzem das gleiche Problem. Um das zu beheben, habe ich Folgendes zu den uwsgi-Startparametern hinzugefügt: –catch-exceptions und –error-route-status=”500 file:filename=/usr/local/nginx/html/index.html,status=500 Interner Serverfehler”

Eines davon war, Ausnahmen von Django abzufangen, selbst wenn DEBUG=false ist. Und das andere war, eine Anfrage an eine bestimmte Datei umzuleiten, damit der Client keine Seite voller Django-Ausnahmen sieht, sondern stattdessen eine „Es tut uns leid, bla bla“-Meldung. Bedenken Sie, dass ich die Version von uwsgi 1.9.15 verwende.