Ich weiß, dass das schon tausend Mal gefragt wurde, aber alle Antworten, die ich gefunden habe, funktionieren einfach nicht (für mich oder normalerweise das ursprüngliche OP dieser Fragen) ... Also werde ich versuchen es zu erklären das Problem so gut wie ich nur kann und hoffentlich können wir es für mich und für andere, die vorher gefragt haben, funktionieren.
Meine Nginx-Konfiguration (mit vielen anderen irrelevanten Sachen entfernt) ist wie folgt:
%Vor% Alles, was ich versuche, ist, Nginx dazu zu bringen, alle 404s abzufangen und sie über location ~ \.php$ an PHP-FPM zurückzusenden, damit dem Benutzer eine benutzerdefinierte Fehlerseite angezeigt wird, aber ich bekomme immer die Standard-Nginx-Fehlerseite.
Die folgenden URLs sollten alle die Ausgabe von mydomain.co.uk/error404.php anzeigen:
Aber sie zeigen tatsächlich die Standard-Nginx 404-Seite. Wenn die location ~ \.php$ einen anderen Fehlercode an 404 (z. B. 5xx) zurückgibt, dann wollen wir uns nicht einmischen, sondern nur den Inhalt und die Header zurückgeben, die FastCGI an erster Stelle zurückgegeben hat.
Ich hoffe, dass das Sinn macht und dass jemand helfen kann. Vielen Dank im Voraus.
BEARBEITEN: Ich habe versucht, recursive_error_pages on; zur Zeile nach # Custom error pages hinzuzufügen, aber das führt dazu, dass alle Nginx 404 Not Found Fehler zu Nginx 500 Internal Server Error Fehlern werden.
BEARBEITEN Andere Dateien hinzufügen: /etc/nginx/fastcgi.conf
%Vor%fastcgi_params
%Vor%Ich nehme an, dass ich diese beiden wahrscheinlich sowieso nicht brauche! ; -)
Ich habe endlich das meiste rausgeholt. Danke an alle für Ihre Tipps und die Zeit in die Antwort zu schreiben.
Das Problem ist, dass unser error404.php unsere Fehlerseite mit einem 404 Not Found-Header zurückgegeben hat (mit header('HTTP/1.0 404 Not Found'); ) und Nginx diesen Fehler dann abfing, da recursive_error_pages aus ist (Standard) und es angezeigt wurde eigene 404 Seite. Das Abschalten von fastcgi_intercept_errors ist die Lösung. Wenn wir das header('HTTP/1.0 404 Not Found'); aus der Fehlerdatei entfernen, erhalten wir den Fehler, aber mit 200 , was offensichtlich nicht das ist, was wir wollen.
Dies löst jedoch nicht das Problem des Zugriffs auf eine fehlende Seite, die mit .php endet (entspricht also dem Standortblock, da wir jetzt die Standard-PHP-FPM-Antwort auf die eines 404-Headers mit der body File not found. . Ich könnte Nates Antwort verwenden, um dies zu umgehen, aber ich möchte nicht alle angeben Ich suche nach einer anderen Lösung und poste sie hier, wenn ich eine bekomme.
BEARBEITEN: Eine vollständigere Lösung:
Sie müssen Fehler in Ihrem Hauptphp-Standortblock abfangen ( fastcgi_intercept_errors ist on ) und dann einen anderen Block für Ihre Fehlerseiten haben, wo Sie sie nicht abfangen. Siehe dieses Konfigurationsbeispiel:
Dies bedeutet, dass auf allen PHP-Seiten, die einen HTTP-Statuscode von 404 zurückgeben, der eigene Inhalt (sofern vorhanden) ignoriert wird und stattdessen der Inhalt der /http_errors/404.php -Datei verwendet wird.
Ich glaube, was Sie verlangen, ist mit nginx allein nicht möglich - es sei denn, Sie konfigurieren jede bekannte .php-Datei manuell. Wenn Sie die bekannten .php-Dateien auflisten können, können Sie anhand dieser Informationen einen erwarteten 404 erkennen. Statt alle .php-Dateien mit einem regulären Ausdruck zu erfassen, geben Sie bekannte PHP-Dateien an:
Ersetzen Sie location ~ \.php$ {} durch etwas wie:
location ~ ^ / (Index | foo | bar | admin / index) .php $ {}
Dies wird jedoch kein 404 erfassen, das von Ihrem externen php-fpm generiert wurde, wenn eine Anfrage nach einer angeblich bekannten PHP-Datei wie index.php 404 zurückgibt, obwohl Sie es nginx gesagt haben sollte existieren.
Eine vollständige Lösung würde wahrscheinlich einen zusätzlichen Server vor dem Nginx-Server erfordern, der eine 404-Antwort von php-fpm / nginx erkennt, die dann eine weitere Round-Trip-Anfrage an Ihr Backend sendet die Datei error404.php . Sie würden immer noch auf das Problem Ihrer error404.php -Datei stoßen und auch selbst eine 404 zurückgeben. Ich schaute in Varnish , um zu sehen, ob ein entdecktes 404 eine zweite Anfrage an den Ursprungsserver für eine Fehlerseite erzeugen konnte, aber unglücklicherweise die vcl_backend_error kann nur geliefert werden 404 oder wiederholen Sie die Anfrage. Varnish - oder etwas Ähnliches - könnte einen Weg haben, um das zu erreichen, was Sie wollen, aber es wird nicht einfach sein.
Alles was ich sagen kann ist, dass dies ein Grund ist, warum die meisten Leute nginx und php-fpm nicht auf verschiedenen Rechnern einrichten - es verursacht Kopfschmerzen wie diese. Wenn möglich, sollten Sie wirklich in Betracht ziehen, nginx und php-fpm auf demselben Rechner zu belassen und diese Server zu verteilen. Welchen Nutzen Sie davon haben, dass Sie sie trennen, ist die zusätzlichen Probleme wahrscheinlich nicht wert.
Der location ~ \.php$ -Block benötigt eine try_files, um nach Dateiexistenzen zu suchen. Wenn es nicht existiert, gebe 404 zurück, und deine error404.php wird es übernehmen.
Ihr "root / var / www / xxxxxx;" sollte außerhalb des Bausteins "location ~ .php $" und vor "error_page 404 = /error404.php;"
seinWenn Sie immer noch nicht die gewünschte 404-Seite von error404.php bekommen, schlage ich vor, dass Sie mit einer Standardkopie von nginx.conf debuggen und dann Ihre Fehlerseite von dort anpassen, weil das, was wir vorgeschlagen haben, funktioniert. Ich habe die gleichen Konfigurationen für meinen eigenen Server verwendet.
Wenn es immer noch nicht funktioniert, sollte es ein Upstream-Problem sein.
Sie möchten auch Ihr
überprüfenenthält /etc/nginx/fastcgi.conf; Beinhalten fastcgi_params;
um zu sehen, ob es irgendwelche Rogue-Variablen gibt. Es könnte einige doppelte Variablen geben.
Allgemeine Faustregel beim Debugging. Reduziere deine Variablen. Beginnen Sie mit einer einfachen Konfiguration und arbeiten Sie sich hoch, um sie anzupassen.
Der richtige Weg
error_page 404 /path/to/404.php;
Ich weiß, dass es funktioniert, weil ich vor kurzem eine Anwendung erstellt habe, und dies war das Setup für die Fehlerbehandlung. Bitte beachten Sie, dass ich URL-Rewriting verwenden, um index.php von Anfragen für jedes Verzeichnis zu entfernen. Auf diese Weise können Sie Ihr Fehlerscript einrichten, um Informationen in Ihre Datenbank zu schreiben, was unter anderem für das Debuggen von ajax-Fehlern hilfreich sein kann:
Tags und Links php nginx http-status-code-404