No input file specified (PHP-FPM / cgi.fix_pathinfo)

What’s actually happening

Every PHP page returns a blank-ish white page with just the text "No input file specified." Static files (CSS, images) still load fine, so the site isn't fully down. It usually starts right after a server migration, a document-root change, or a fresh nginx + PHP-FPM setup. The HTTP status is typically 404 from PHP itself, not from the web server.

Common causes

• SCRIPT_FILENAME passed to PHP-FPM points at a path that doesn't exist on disk — the classic nginx mistake of using $document_root$fastcgi_script_name when the root is set inside the location block, not the server block.
• The app was moved to a new directory but the web server's root / SCRIPT_FILENAME still references the old path.
• cgi.fix_pathinfo behavior plus a bad PATH_INFO split, so PHP tries to execute a path segment that isn't a file.
• PHP-FPM runs in a chroot or container where the path the web server sees (/var/www/html/index.php) doesn't match the path inside PHP's filesystem.
• File or directory permissions stop the PHP-FPM worker user (often www-data) from reading the script, so it resolves to nothing.

How to fix it

1. Confirm what path PHP is actually being told to runAdd fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; to the nginx fastcgi block and temporarily log it, or drop a phpinfo() file and check $_SERVER['SCRIPT_FILENAME']. If that path doesn't exist on disk, you've found it.
2. Fix the root / SCRIPT_FILENAME mismatchIn nginx, put `root` in the server block, not inside location ~ \.php$. The standard pairing is `root /var/www/html;` at server level and `fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;` in the PHP location. Reload with nginx -s reload.
3. Check the file exists and is readable by the FPM userRun `ls -l /var/www/html/index.php` and confirm the owner/group matches the `user` in /etc/php/*/fpm/pool.d/www.conf. A 750 directory owned by root will block www-data. `namei -l /var/www/html/index.php` walks the whole path and shows where the permission breaks.
4. Reconcile chroot / container pathsIf PHP-FPM uses `chroot` in the pool config, SCRIPT_FILENAME must be relative to the chroot, not the host. Either drop the chroot directive or set `fastcgi_param SCRIPT_FILENAME` to the in-jail path. In Docker, make sure the app volume is mounted at the same path in both the nginx and php-fpm containers.
5. Set cgi.fix_pathinfo deliberatelyIn php.ini set cgi.fix_pathinfo=0 (the secure default for FPM setups) and make sure your nginx try_files doesn't pass non-existent paths to FastCGI. Restart php-fpm after editing.