“No input file specified” means PHP-FPM cannot open the script path Nginx sent in SCRIPT_FILENAME. Fix the path first: confirm the active document root, define SCRIPT_FILENAME exactly once, reject missing scripts with try_files $uri =404;, and verify that the PHP-FPM worker can read the file on the machine where it runs. Then test the Nginx configuration, reload it, and use both Nginx and PHP-FPM logs to confirm the resolved path.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What “No input file specified” actually means
Nginx does not execute a PHP file itself. It accepts the HTTP request, maps the URI to a filesystem path, and passes FastCGI parameters to a PHP-FPM pool. PHP-FPM then tries to open the file named by SCRIPT_FILENAME. If that path is wrong, the file is absent, or the PHP-FPM process cannot traverse the directories and read the file, PHP-FPM returns No input file specified.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
The message is therefore a path and access failure, not a PHP syntax error. It commonly appears where a browser user expected a normal 404 because Nginx forwarded a request for a nonexistent script instead of rejecting it first. A wrong document root, a URI-to-filesystem mismatch, duplicate SCRIPT_FILENAME parameters, a bad socket or pool, and differences between the Nginx host and the PHP-FPM host are the main causes.
Do not try to solve this by adding arbitrary path fragments to the URI or by changing fastcgi_index. As Nginx developer Maxim Dounin has noted, fastcgi_index is meaningless for this failure: the decisive value is the script path in SCRIPT_FILENAME.
Repair the configuration in this order
1. Confirm the active document root
Find the server block that actually handles the failing hostname and request. The root must point to the directory that contains the public entry files, not merely to the project directory or to a directory used by another virtual host. A typical layout might place the entry script at /var/www/example/public/index.php; in that case the active server block needs root /var/www/example/public;.
Check the complete, expanded Nginx configuration rather than relying on the file you last edited. Run the configuration dump command used by your installation, commonly nginx -T, and identify the matching server_name, listen address, and root. Also check for a more specific location block that overrides the behavior of the general PHP location.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Compare the requested URI with the file that should exist. For a request for /admin.php and a root of /var/www/example/public, the expected script is /var/www/example/public/admin.php. If the file is actually under another directory, correct the root or the deployment rather than trying to make PHP-FPM guess.
2. Define SCRIPT_FILENAME only once
PHP-FPM must receive one authoritative script path. A frequent mistake is to include a file that already defines SCRIPT_FILENAME and then add a second definition manually. Maxim Dounin described the result precisely: including fastcgi.conf can already send a SCRIPT_FILENAME parameter, so adding another one sends two values to PHP and only one can be correct.
Choose one of these approaches:
- Include a distribution-supplied file that defines
SCRIPT_FILENAME, and do not add another definition. - Include a parameter file that does not define it, then add one explicit line such as
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;.
Inspect the included file instead of assuming what it contains. Package layouts differ, and a locally modified include may not match the default for your operating system. Duplicate definitions can survive a syntax check because the configuration is syntactically valid while the FastCGI request is semantically wrong.
3. Reject nonexistent scripts before FastCGI
Put try_files $uri =404; inside the PHP location, before fastcgi_pass. Nginx checks whether the requested file exists under the active root. If it does not, Nginx returns an ordinary 404 and never sends the request to PHP-FPM. This prevents PHP-FPM from producing the misleading input-file message for a path that should have been rejected at the web-server layer.
The directive is especially important for direct requests to old, deleted, or mistyped .php files. It is separate from front-controller routing: an application that intentionally sends extensionless URLs to index.php can use a dedicated fallback in its general location, while direct PHP execution should still verify the script path.
4. Verify the FastCGI endpoint and PHP-FPM permissions
Confirm that fastcgi_pass points to the PHP-FPM pool you intend to use. The endpoint may be a Unix socket such as unix:/run/php/php-fpm.sock or a TCP address. A wrong endpoint normally produces a connection error rather than this exact message, but checking it prevents you from debugging the wrong pool.
Remember where the file is opened. PHP-FPM, not Nginx, opens SCRIPT_FILENAME. On a single host, the pool user must be able to traverse every parent directory and read the script. On a separated or load-balanced deployment, the file must exist and be readable on the host running PHP-FPM. A file present on the Nginx machine does not help if the FastCGI request is sent to another host that lacks the release, mount, or shared filesystem.
Check directory execute (traverse) permission as well as file read permission. A readable file inside a directory that the pool user cannot enter is still inaccessible. Use the account configured for the pool when performing an access test, and check mandatory access-control policies where your operating system uses them.
5. Treat PATH_INFO as a separate routing decision
Requests such as /script.php/extra contain a script portion and a PATH_INFO portion. The script filename should resolve to /script.php; /extra is request information passed separately. If Nginx constructs a fabricated path such as /script.php/extra and sends that as SCRIPT_FILENAME, PHP-FPM may report that no input file exists.
Only enable this form when the application needs it. Split the script portion from PATH_INFO deliberately, test the resulting variables, and confirm that the pool receives the real script path. PHP’s cgi.fix_pathinfo behavior can change how a path containing extra segments is interpreted, so do not assume that a configuration safe for ordinary .php requests is also correct for PATH_INFO URLs.
6. Test, reload, and inspect the resolved path
Run the platform’s Nginx configuration test, commonly nginx -t. Do not reload until it reports a successful syntax check and a valid configuration file. Reload Nginx using the service mechanism provided by your distribution.
Reproduce one failing request while watching the Nginx error log and the PHP-FPM log. Look for the exact path Nginx calculated, the pool that handled the request, permission-denied messages, and evidence that a nonexistent URI reached FastCGI. Logs are more useful when you test one known URL at a time and compare it with a script whose absolute path you have verified.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Minimal known-good configuration shape
This is the basic arrangement to adapt to your distribution, PHP version, socket name, and application directory:
server {
root /var/www/example/public;
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}The example uses fastcgi_params and adds one explicit SCRIPT_FILENAME. If your installation’s fastcgi_params already defines that parameter, remove the manual line or switch to an include strategy that leaves exactly one definition. Conversely, if you use fastcgi.conf and it contains the parameter, do not append a second copy.
$document_root comes from the active server and location context, while $fastcgi_script_name is the script portion of the request. Together they should form the absolute path that exists on the PHP-FPM host. If your application uses a different mapping, use an explicit absolute root that reflects the actual deployment, but keep the same one-definition rule.
Choosing an include and path strategy
| Configuration choice | How SCRIPT_FILENAME is derived |
Missing-script behavior | PATH_INFO handling | Main risk |
|---|---|---|---|---|
fastcgi_params plus one explicit parameter |
Usually $document_root$fastcgi_script_name, unless your local file already defines it |
Safe when try_files $uri =404; appears before fastcgi_pass |
Requires an intentional split and testing | Adding a second definition when the include already contains one |
fastcgi.conf with no manual duplicate |
Defined by the included file | Safe when the PHP location includes the same pre-FastCGI existence check | Depends on the variables and location rules in the included configuration | Assuming every distribution’s include has identical contents |
| Hard-coded absolute script path | A fixed path chosen for a specific script or location | Can be safe, but still use a file-existence check where appropriate | Must be designed separately | Breaks when releases, roots, or hosts change |
| URI-derived path without an existence check | Built from request variables and passed directly to PHP-FPM | Missing files reach FastCGI and can trigger the message | Often mishandles extra path segments | URI-to-filesystem mismatches and unsafe assumptions |
The table’s first two rows are normally the maintainable choices. The important distinction is not the filename of the include; it is knowing which file owns SCRIPT_FILENAME, ensuring the path is correct, and refusing nonexistent scripts before the FastCGI handoff.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why a normal 404 can turn into this PHP-FPM message
Nginx can route a request to a PHP location based on its URI pattern even when no corresponding file exists. Without try_files $uri =404;, Nginx builds a FastCGI request and PHP-FPM attempts to open the resulting path. PHP-FPM has no reliable way to know that the web server intended a 404, so it reports that it cannot open the supplied input file.
Adding the existence check restores the proper division of responsibility: Nginx decides whether the requested script exists, and PHP-FPM executes only a file that passed that check. This also makes log entries and client responses easier to interpret.
Diagnosing duplicate or conflicting parameters
When the root appears correct but the error persists, inspect every inherited and included directive in the active server block. A second fastcgi_param SCRIPT_FILENAME may come from a global include, a server-level include, or the PHP location itself. The configuration can pass nginx -t while still sending conflicting values.
Remove all but one definition, reload, and test a script whose absolute path is known. Do not attempt to fix the issue by reversing the order of duplicate lines: relying on which duplicate a particular FastCGI implementation uses is fragile. The durable fix is one owner for the parameter.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
PATH_INFO: safe handling for URLs with extra segments
Support for /script.php/extra is application-specific. If the application does not require it, a location that matches only the PHP filename and rejects unexpected suffixes is simpler. If it does require it, define how the script name ends, how the remainder becomes PATH_INFO, and what value reaches SCRIPT_FILENAME.
- Verify that the script part maps to a real file.
- Pass only the script part as
SCRIPT_FILENAME. - Pass the trailing segment as
PATH_INFOaccording to the application’s expectations. - Test both an existing script with a valid suffix and a nonexistent script with a suffix.
- Check the effect of PHP’s
cgi.fix_pathinfosetting rather than assuming one universal behavior.
A PATH_INFO test is incomplete if it checks only the browser response. Confirm the resulting parameters in application or pool logs where available, and ensure that a malformed suffix cannot cause an unrelated file to be selected.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Load-balanced and split-host deployments
In a load-balanced design, Nginx may run on one machine while PHP-FPM runs on another, or several PHP-FPM hosts may serve the same virtual host. The script must be present at the same effective path on every PHP-FPM host that can receive the request. A release copied to the web tier but not to one backend produces intermittent failures: some requests work and others return the input-file message.
Check deployment consistency across the pool:
- The document-root path exists on every PHP-FPM host.
- The same release contains the requested script on every host.
- The PHP-FPM pool user can traverse directories and read the file everywhere.
- Shared mounts are mounted at the expected path before the pool accepts traffic.
- Nginx’s FastCGI destination points to the intended pool, not an old or differently mounted backend.
If failures correlate with a particular backend, compare that host’s filesystem, permissions, pool configuration, and PHP-FPM log with a working host. Fix the inconsistent node or remove it from rotation while deployment is corrected.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Symptom-to-cause checklist
| Observed symptom | Most likely cause | What to check next |
|---|---|---|
| Every PHP URL returns the message after a site move | Wrong active root or a stale virtual host |
Expanded Nginx configuration, matching server_name, and the absolute location of a known script |
| Only nonexistent PHP URLs show the message | No pre-FastCGI existence check | Add try_files $uri =404; before fastcgi_pass |
| The root looks correct, but one host fails | Missing file or inaccessible path on that PHP-FPM host | Backend filesystem, pool user permissions, mounts, and PHP-FPM logs |
| Changing the parameter line’s position changes the result | Duplicate SCRIPT_FILENAME definitions |
Inspect all includes and leave exactly one definition |
Ordinary /index.php works but /index.php/extra fails |
PATH_INFO mapping or cgi.fix_pathinfo behavior |
Split the script and suffix deliberately and test the received parameters |
| Nginx reports an upstream connection failure instead | Wrong socket, TCP address, or stopped PHP-FPM pool | Endpoint, service status, socket ownership, and pool selection |
Validation procedure after editing
- Identify one existing PHP file and record its exact absolute path on the PHP-FPM host.
- Confirm that the active server block’s
rootplus the request script name resolves to that path. - Search the effective configuration for every
SCRIPT_FILENAMEdirective and remove duplicates in the request’s inheritance chain. - Place
try_files $uri =404;beforefastcgi_passin the PHP location. - Check the socket or TCP endpoint and verify that the selected PHP-FPM pool can access the file.
- Run
nginx -t; correct every reported error before reloading. - Reload Nginx, request the known existing script, and then request a deliberately nonexistent PHP path.
- Expect the existing script to reach PHP-FPM and the nonexistent path to receive a normal 404 without a FastCGI handoff.
- For PATH_INFO URLs, test a valid suffix and an invalid script while checking logs for the separate script and path-info values.
- In a pool of backends, repeat the checks on every PHP-FPM host or temporarily route traffic to each host during verification.
Common fixes that do not solve the underlying problem
Changing fastcgi_index
fastcgi_index does not repair an incorrect script path supplied in SCRIPT_FILENAME. It is not the control that decides whether PHP-FPM can open the file in this situation.
Appending the URI to a guessed directory
Manually concatenating fragments until one URL works can hide a wrong document root or a location override. Derive the path from the active root and the script variable, then verify the resulting absolute path on the PHP-FPM host.
Adding more FastCGI parameters
Extra parameters do not compensate for a duplicate or incorrect SCRIPT_FILENAME. First establish which include owns the parameter and remove conflicting definitions.
Testing only through the browser
A browser shows the final status, not necessarily the path PHP-FPM received. Pair each test with Nginx and PHP-FPM logs, and test both an existing script and a missing one so that routing and execution are distinguished.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsFinal decision rule
Trace one request from URI to filesystem path: the active Nginx root must produce the real script path, exactly one SCRIPT_FILENAME value must carry that path to the intended PHP-FPM pool, and the PHP-FPM process must be able to read it on its own host. Put try_files $uri =404; ahead of FastCGI, handle PATH_INFO only by design, and reject or repair any backend whose filesystem does not match the web tier. That sequence turns the vague message into either a normal 404 or a concrete path, configuration, or permission error you can fix.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
