Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Der NGINX 404-Fehler entsteht oft nicht durch das Fehlen eines Dateis, sondern durch dessen tatsächliche Abwesenheit, falsche document root, server_name, root/alias-Verwendung oder einen fehlenden try_files-Befehl für einen Front-Controller. Diese Anleitung behandelt die Szenarien WordPress, Laravel und SPA separat.
2026/07/17 03:48:20 [error] 2307#2307: *912 open() "/usr/share/nginx/html/Produkt/42" failed (2: No such file or directory)
GET /Produkt/42 HTTP/2.0 404NGINX mappiert die Anfrage-URI auf einen Datei-/Verzeichnis-Pfad im aktiven Server- und Location-Block. Falsche Übereinstimmung oder fehlende Fallbacks ergeben bei bestehender Anwendungsroute trotzdem einen 404.
Wenn die Startseite geöffnet wird und Unterseiten 404-Fehler geben, ist die try_files-Regel in location / der erste Verdächtige in WordPress/Laravel-ähnlichen Front-Controller-Anwendungen.
Die root-Direktive fügt dem angegebenen root-URI hinzu; alias ändert jedoch die Übereinstimmung der location-Sektion auf eine andere Weise. Wenn eine Regex-Location ohne Vorsicht verwendet wird, wird der Dateipfad falsch berechnet.
Wenn der server_name nicht übereinstimmt, kann die Anfrage auf die Standard-Server-Block zurückfallen. In diesem Fall werden, selbst wenn die richtigen Dateien auf dem Server vorhanden sind, von einem anderen Document Root aus 404-Seiten angezeigt.
Bei SPA-Anwendungen wie React/Vue ist ein Fallback auf index.html erforderlich, wenn ein echter statischer Datei nicht gefunden wird; API- und statische Asset-Orte sollten von diesem Fallback getrennt werden.
Verstecken Sie 404 nicht, indem Sie alle Anfragen an index.php oder index.html erzwingen; statische Datei-, API- und nicht-existente URL-Verhalten sollten getrennt bleiben.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: NGINX konnte die Quelle auf dem von NGINX berechneten Dateipfad nicht finden.
Mögliche Ursache: Falscher root/Alias oder fehlende Datei.
Bedeutung: Übereinstimmende Datei oder Fallback nicht gefunden
Mögliche Ursache: try_files, location, server_name oder Anwendungsroute-Konfigurationen.
Bedeutung: Der FastCGI-Skriptpfad entspricht nicht dem aktuellen PHP-Datei.
Mögliche Ursache: SCRIPT_FILENAME, root oder Alias ist nicht übereinstimmend.
Bedeutung: PHP-FPM-Skriptdatei nicht gefunden.
Mögliche Ursache: Unterschied zwischen NGINX und PHP-FPM Chroot/Path.
Bedeutung: Fallback verarbeitet die gleiche URI wiederholt.
Mögliche Ursache: Falsche try_files- oder error_page-Ziel.
Bedeutung: Gute Links erreichen den index.php Front-Controller nicht.
Mögliche Ursache: Eksik try_files $uri $uri/ /index.php?$args.
Bedeutung: Client-seitige Route wird direkt als Datei auf dem Server gesucht.
Mögliche Ursache: SPA index.html fallback eksik.
Bedeutung: Anfrage zeigt nicht auf public/index.php.
Mögliche Ursache: Die Dokumentenwurzel ist nicht Projektktktktkt/public oder try_files fehlt.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
nginx -T | grep -nE 'server_name|listen |root |alias |location |try_files|fastcgi_param SCRIPT_FILENAME'Zeigt alle Richtlinien an, die die Pfadzuordnung der Anfrage beeinflussen.
realpath /var/www/example
find /var/www/example -maxdepth 2 -type f | head -n 50Überprüft das Deploy-Verzeichnis und die erwarteten Eingabedateien.
curl -sI -H 'Host: example.com' http://127.0.0.1/Produkt/42
curl -skI https://example.com/Produkt/42Zeigen Sie die Differenz der Standardvhost mit server_name.
grep ' 404 ' /var/log/nginx/access.log | tail -n 50
tail -n 100 /var/log/nginx/error.logVergleicht 404-URLs und berechnete Dateipfade.
curl -skI https://example.com/
curl -skI https://example.com/olmayan-dosya.css
curl -skI https://example.com/uygulama-routeTestet Front-Controller und tatsächliches 404-Verhalten separat.
nginx -t && systemctl reload nginxNeue Routenkonfiguration wird sicher angewendet.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
Systemd, Paketpfad und journald-Prüfungle für NGINX 404 Not Found und try_files
nginx -T | grep -nE 'server_name|root |alias |try_files'
tail -n 100 /var/log/nginx/error.logSELinux, PHP-FPM-Pool, RHEL-basierte Dienstkontrolle für NGINX 404 Not Found und try_files
nginx -T | grep -nE 'server_name|root |alias |try_files'
ls -Zd /var/www/example 2>/dev/nullNGINX-Virtualhost-Dateien, die von Plesk generiert werden: nginx 404 not found und try_files-Prüfungle.
grep -R 'try_files\|root ' /var/www/vhosts/system/example.com/conf 2>/dev/null
plesk repair web example.com -nÜberprüfen Sie zunächst den korrekten virtuellen Host, dann den physischen Pfad und schließlich den Anwendungs-Fallback.
Überprüfen Sie, ob die Anfrage in die richtige server_name-Block gefallen ist.
curl -sI -H 'Host: example.com' http://127.0.0.1/Vergleichen Sie den Pfad in der open()-Zeile mit dem tatsächlichen Bereitstellungsverzeichnis.
tail -n 100 /var/log/nginx/error.logÜberprüfen Sie, wie die Location URI in einen Dateipfad umgewandelt wird.
nginx -T | grep -nE 'location |root |alias 'WordPress/Laravel-Route sollten auf die entsprechende Index-Datei zurückfallen.
nginx -T | grep -n 'try_files'Bestätigen Sie, dass der Fallback nicht 200 zeigt, wenn es um nicht existierende Assets geht.
for p in / /api/health /olmayan.css /uygulama-route; do curl -sk -o /dev/null -w "$p %{http_code}\n" https://example.com$p; doneNach der Syntax reinigen und überprüfen Sie auch die Cachingschicht/CDN.
nginx -t && systemctl reload nginxlocation / erfordert index.php Front-Controller-Fallback.
nginx -T | grep -n 'try_files'Die Dokumentenwurzel sollte das öffentliche Verzeichnis des Projektktktktkts sein, nicht die Projektktktktktwurzel.
nginx -T | grep -n 'root '; test -f /var/www/proje/public/index.php && echo OKClient-Route benötigt index.html-Fallback; API sollte ausgeschlossen werden.
curl -skI https://example.com/panel/MonatarlarAlias, Fallunterscheidung, Deploy-Pfad und Build-Ausgabe werden überprüft.
find /var/www/example -iname 'dosya.css'Übereinstimmung von server_name und Reihenfolge von default_server werden überprüft.
nginx -T | grep -nE 'listen .*default_server|server_name'Web-Konfiguration und document root Domain wird auf der Grundlage neu erstellt.
plesk repair web example.com -yIn Front-Controller-Anwendungen fehlt der try_files-Fallback innerhalb von location / oder ist falsch.
Überprüft die angegebenen Dateien und Verzeichnisse in der Reihenfolge; wenn nicht gefunden, wendet einen internen Redirect oder Fehlercode auf die URI im letzten Parameter an.
Root fügt dem root-Anforderungs-URI den gegebenen Pfad hinzu; alias ersetzt den passenden Location-Pfad durch einen anderen physischen Pfad.
In der Regel wird der Ansatz location / mit try_files $uri $uri/ /index.php?$args verwendet; sollte an die bestehende Struktur und Sicherheitsregeln angepasst werden.
Die Dokumentenwurzel sollte das öffentliche Verzeichnis des Laravel-Projektktktktkts sein und nicht existierende Routen sollten an public/index.php weitergeleitet werden.
Der Browser fordert den Client-Seiten-Route direkt an, wenn erforderlich, und NGINX sucht nach dem echten Datei. Für SPAs ist ein kontrollierter index.html-Fallback erforderlich.
Die Anfrage kann auf einen anderen oder Standard-Serverblock fallen und über die falsche Wurzel einen 404- oder einen anderen Site anzeigen.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.