So sieht die Meldung aus
FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 198.51.100.7, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.3-fpm.sock:"Häufige Ursachen
SCRIPT_FILENAMEist falsch zusammengesetzt, z. B. ohne$document_root.rootsteht nur imlocation /-Block und gilt nicht fürlocation ~ \.php$.- PHP-FPM läuft in einem Container oder chroot und sieht einen anderen Pfad als nginx.
- Der PHP-FPM-Benutzer darf die Datei oder ein Elternverzeichnis nicht lesen.
- Die angefragte PHP-Datei existiert wirklich nicht und es fehlt
try_files.
Prüfen
- Betroffene Anfragen im Log anzeigen
grep 'Primary script unknown' /var/log/nginx/error.log | tail -n 5 - root, fastcgi_pass und SCRIPT_FILENAME in der aktiven Konfiguration anzeigen
nginx -T 2>/dev/null | grep -nE '^\s*(root|fastcgi_pass|fastcgi_param\s+SCRIPT_FILENAME|try_files) ' - Benutzer und Socket des PHP-FPM-Pools anzeigen
grep -E '^(user|group|listen|chroot)' /etc/php/*/fpm/pool.d/www.conf - Prüfen, ob der PHP-FPM-Benutzer die Datei lesen kann
sudo -u www-data test -r /var/www/site/index.php && echo ok
Lösung
rootauf server-Ebene setzen, nicht nur in einer location.- Im PHP-Block
include fastcgi_params;undfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;verwenden. try_files $fastcgi_script_name =404;ergänzen, damit nicht vorhandene Skripte sauber mit 404 enden.- Bei Docker denselben Pfad in nginx- und PHP-Container mounten.
- Rechte für den Pool-Benutzer korrigieren und
nginx -t && systemctl reload nginxausführen.
Häufige Fragen
Warum kommt „File not found.“ statt einer nginx-404-Seite?
Die Meldung stammt von PHP-FPM, nicht von nginx. nginx hat die Anfrage weitergereicht, ohne vorher zu prüfen, ob die Datei existiert.
Ist das ein Sicherheitsproblem?
Der Fehler selbst nicht. Aber try_files … =404 vor fastcgi_pass verhindert auch, dass PHP-FPM manipulierte Pfade wie /upload/bild.jpg/x.php verarbeitet.