“FastCGI sent in stderr” is a symptom, not a diagnosis. Nginx is reporting that the FastCGI application—usually PHP-FPM—wrote a diagnostic message to its error stream while Nginx was waiting for the response. Read the complete text inside the quotation marks. A PHP parse error needs a code fix; “primary script unknown” usually means a path mapping problem; “permission denied” points to filesystem access; connection and timeout messages point to the PHP-FPM listener or service.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Use the workflow below to identify the failing layer, correct only the setting that explains the message, validate Nginx, and retest while watching both Nginx and PHP-FPM logs.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What the message means
In a typical Nginx/PHP stack, Nginx sends a request to PHP-FPM through FastCGI. PHP-FPM returns the generated response and can also write diagnostics to its stderr stream. Nginx logs those diagnostics with the prefix FastCGI sent in stderr, often alongside while reading response header from upstream. The prefix identifies the reporting path; it does not identify the underlying fault.
Nginx’s fastcgi_catch_stderr directive can search the upstream error stream for a configured string and treat a match as an invalid response. That behavior does not make every stderr line an Nginx configuration error. The quoted suffix is the useful evidence. A warning, notice, parse error, and connection failure can all appear under the same prefix but require completely different changes.
#1 Best Overall
A representative entry might look like this:
FastCGI sent in stderr: "PHP message: PHP Parse error: syntax error, unexpected '<' in test.php on line 3" while reading response header from upstreamHere, the fix is in test.php at line 3, not in buffer settings. Other suffixes lead to different repairs.
Classify the quoted diagnostic before changing configuration
Copy the entire log line, including its timestamp, requested URI, upstream address, and the text inside the quotes. Then match the signature to the narrowest likely failure layer.
Recommended Free Tools
| Error signature in the quoted text | Likely layer | Targeted action | Typical scope |
|---|---|---|---|
PHP Parse error, PHP Fatal error, or an uncaught exception |
Application code or PHP runtime | Fix the named file, line, extension, or application setting; retry the same URL | One request, route, or release |
Primary script unknown, Unable to open primary script, No such file or directory |
Nginx-to-PHP path mapping | Compare root/alias, fastcgi_param SCRIPT_FILENAME, mounts, chroots, and symlinks |
One location, site, or deployment |
Permission denied |
Filesystem ownership or mode | Check traversal of every parent directory and read access to the script; check write access for cache, uploads, or sessions | One path, pool, or host |
| Connection refused or upstream unavailable | PHP-FPM service or endpoint | Confirm the service is running and that fastcgi_pass names its active socket or TCP listener |
Every URL using that pool |
| Timeout or a response that stops before headers | Application execution or transport timing | Inspect PHP-FPM and application logs first; change timeouts only when measured behavior supports it | Slow routes, one pool, or all sites |
The scope is a useful confirmation. If every PHP URL fails at the same moment, suspect the pool or listener before inspecting individual scripts. If one route fails while other PHP pages work, inspect that route’s filename, rewrite, application code, and write directories first. A change that affects every virtual host should not be the first response to a one-file error.
Repair workflow
1. Capture the complete Nginx error line
Open the Nginx error log and preserve the complete entry. Do not troubleshoot from a dashboard that truncates the quoted message. Record:
- the exact text after
FastCGI sent in stderr:; - the requested URI and HTTP method;
- the upstream socket or host and port;
- the timestamp, so it can be matched with PHP-FPM entries.
Request the same URL once while watching the log. Repeatedly refreshing a broken page can mix several unrelated failures together. Also note whether a static file or a simple PHP script works; that comparison separates routing and pool problems from application-specific failures.
2. Fix PHP parse, fatal, and exception messages in the application
If the suffix names a PHP file and line, open that file and correct the reported syntax or runtime problem. Common examples include an unexpected character, a missing delimiter, a missing extension, or an application configuration value that causes a fatal error. An uncaught exception must be handled or its underlying data/configuration problem corrected.
Check that the deployed file is the version you edited. Release-directory deployments, stale symlinks, and multiple application copies can make a correct local fix irrelevant to the file PHP-FPM actually opens. After deploying the correction, request the same URL again and compare the new timestamped entry.
Do not compensate for a parse or fatal error by increasing FastCGI buffers: buffering cannot make invalid PHP execute. If the error names an extension, verify that the extension is enabled in the PHP-FPM runtime rather than only in a command-line PHP installation.
3. Check the PHP-FPM logs
PHP-FPM pool configuration can redirect worker stdout and stderr to the main error log. Find the active pool configuration and use the pool-specific log when one is configured. PHP-FPM’s entry often includes the first error, stack context, or worker detail that Nginx can only summarize.
Match entries by timestamp and URI. If Nginx reports a generic upstream failure but PHP-FPM reports a fatal error, fix the PHP-FPM/application message first. If no corresponding PHP-FPM entry exists, verify that the request reaches the intended pool at all; a wrong socket, inactive pool, or network rule can prevent a worker from seeing it.
4. Verify the FastCGI endpoint
Inspect the PHP location block and compare fastcgi_pass with the endpoint PHP-FPM is actually listening on. Nginx accepts either a TCP host-and-port address or a Unix-domain socket.
- For a Unix socket, verify that the socket file exists at the configured path and that Nginx can access it. Socket ownership and mode must permit the Nginx worker to connect.
- For TCP, verify the address and port, and ensure the listener is reachable from the Nginx host or container.
- Check that the PHP-FPM service and the selected pool are running, rather than assuming a package installation started them.
A stale socket path, a changed PHP version, or a container whose network name differs from the configuration commonly produces connection-refused or upstream-unavailable text. Confirm the active pool’s listener instead of copying a path from an older package or tutorial.
5. Verify SCRIPT_FILENAME and the effective document root
PHP-FPM must receive the path to the real script as it appears from the PHP-FPM process’s filesystem. The conventional mapping is:
location ~ .php$ {
fastcgi_pass unix:/run/php/php-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}Use the actual socket name and document root for your installation. The essential directives here are fastcgi_pass, fastcgi_index, and fastcgi_param SCRIPT_FILENAME. For POST requests, pass the request metadata required by the FastCGI module, including REQUEST_METHOD, CONTENT_TYPE, and CONTENT_LENGTH; the included parameter file commonly supplies these.
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 problemsCompare three paths, character for character:
- Nginx’s
rootoraliasvalue; - the value produced by
$document_root$fastcgi_script_name(or your custom expression); - the path visible inside the PHP-FPM environment.
In containers, a file can exist at /var/www/html/index.php in the Nginx container while PHP-FPM sees a different mount or directory. Both processes must see the script at the path sent in SCRIPT_FILENAME. Chroots, symlinks, separate mounts, and release-directory deployments may require an explicit path rather than the conventional variable expression.
Be especially careful when changing from root to alias. An alias replaces the matched location path, so the filename produced by a generic $document_root$fastcgi_script_name expression may not be the file you expect. Review nested locations, rewrites, and regular-expression locations and verify the resulting filename for one failing URI.
6. Check permissions along the whole path
“Permission denied” is not limited to the PHP file. The PHP-FPM worker user needs execute (directory-traversal) permission on every parent directory and read permission on the script. Check the path from the filesystem root down to the file.
- Confirm the pool’s configured user and group.
- Confirm each parent directory allows that identity to traverse it.
- Confirm the script is readable by that identity.
- For applications that write cache, upload, or session data, grant write access only to the required directories and use the pool’s intended user/group.
Nginx and PHP-FPM do not have to run as the same identity, but their identities must be compatible with the ownership and mode of the files they need. Broadly making the entire document root writable can hide the symptom while creating a security risk; correct the specific owner, group, ACL, or mode instead.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A successful script read does not prove that the application can complete its request. Frameworks commonly write compiled templates, cache entries, uploaded files, or sessions after loading the PHP file. Check those directories separately, and keep code directories read-only where practical.
7. Validate before reloading
Run your platform’s Nginx configuration test (commonly nginx -t). Reload only after the test reports a valid configuration. Then request one known PHP URL while tailing both Nginx and PHP-FPM logs.
- Test the configuration.
- Reload Nginx without stopping the service.
- Request the failing URL once.
- Compare the new log line with the captured original.
- Confirm that the specific error class disappeared or changed to a newly actionable diagnostic.
If the configuration test fails, restore the last known-good file before investigating runtime behavior. A syntax error in Nginx can obscure the original FastCGI problem. Keep the test request controlled so you can correlate one request with one set of log entries.
8. Secure the FastCGI listener
Keep PHP-FPM on a protected Unix socket or a private network. PHP’s manual warns that PHP-FPM must not be reachable from an untrusted network: a client able to open a FastCGI connection can influence request configuration, including auto_prepend_file, and potentially execute code.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchDo not expose the FPM port directly to the public internet. Restrict firewall rules and container networking to the Nginx-to-FPM path, and protect a Unix socket with appropriate ownership and mode. A quick connectivity fix that binds FPM to a public interface can turn a short outage into a code-execution vulnerability.
Diagnosing “primary script unknown”
This message means PHP-FPM could not open the script path supplied by Nginx. It is usually a mapping or access problem, not a PHP syntax problem.
When the file truly is missing
Check the deployed release and filename, including case sensitivity. Confirm that the URI is mapped to the intended directory and that an old symlink has not been left pointing at a removed release. A request for Index.php can fail on a case-sensitive filesystem even when index.php exists.
When Nginx and PHP-FPM use different paths
Inspect container volume mounts, chroot settings, and separate host paths. A path valid in Nginx’s namespace is irrelevant if PHP-FPM cannot see it. Align the mounts or set SCRIPT_FILENAME to the backend’s real path. Test the same path from the PHP-FPM environment, not only from the host shell or Nginx container.
When a location rule rewrites the path
Review regex PHP locations, nested locations, alias directives, and rewrites. An alias does not compose with $document_root in the same way as root; verify the resulting filename rather than assuming the conventional expression is correct.
Diagnosing PHP-FPM permission errors
Start with the exact identity of the pool worker, then test access at each directory level. A script may be readable while its parent directory blocks traversal, or the script may execute successfully while a framework fails when it tries to write a cache or session file.
- Use the pool’s configured user/group as the reference identity.
- Check ownership and mode on the script and every parent directory.
- Check application write directories separately from code directories.
- After changing ownership, group membership, ACLs, or modes, retry the same URL and read the new PHP-FPM log entry.
Apply the smallest change that grants the required operation. A group or ACL change is often safer than making all files world-readable or world-writable, and write permission should be limited to directories that genuinely need it.
Why a blank page or HTTP 502 appears
Blank response
A blank page can result from a fatal PHP error whose details are written only to logs, an application that emits no body, or a response that terminates before headers. Use the timestamped PHP-FPM entry and temporarily appropriate application-level diagnostics in a non-production environment; do not expose detailed errors to visitors.
If the blank response affects one route, compare it with a minimal known-good PHP file through the same location block. If the minimal file works, the listener and basic path mapping are probably healthy and the application route deserves attention. Remove temporary diagnostics after testing.
HTTP 502 Bad Gateway
Nginx returns 502 when it cannot obtain a valid upstream response. The quoted FastCGI text distinguishes a PHP fatal error from a dead listener, bad script path, or permission denial. Fix that underlying message before touching transport tuning.
Buffer and timeout settings: when they help and when they do not
fastcgi_buffer_size, fastcgi_buffers, and fastcgi_read_timeout control response buffering and read timing. They do not correct a PHP syntax error, a wrong SCRIPT_FILENAME, or a filesystem denial.
Change them only when the log and measured behavior show a response-size or timing problem—for example, a consistently slow endpoint that exceeds the current read interval or headers that exceed the configured buffer. Record the original values, change the smallest relevant scope (location or pool), validate the configuration, and retest. Increasing every buffer or timeout can conceal a slow or failing application and consume more resources.
Free tools Windows power users keep installed
One-click scans. No signup required.
Common deployment pitfalls
Many incidents appear immediately after a PHP upgrade, image rebuild, or release switch. The Nginx configuration may still reference the previous socket filename, while the new PHP-FPM pool listens elsewhere. Containers may be rebuilt with matching-looking paths that are not actually shared. A symlink can switch Nginx to a new release while PHP-FPM remains chrooted to an older directory. Check the active service, mounts, and effective paths at the time of the request rather than relying on old configuration fragments.
Another frequent mistake is fixing only the web server’s view of a path. PHP-FPM is the process opening the script, so its namespace, user, group, and pool settings determine whether the file can be found and read. Validate from that perspective and record the working endpoint and path as part of the deployment configuration.
Best Value
Use the failure layer to choose the smallest fix
| Layer | Evidence to collect | Smallest appropriate change | Do not change first |
|---|---|---|---|
| Nginx routing | Location block, root/alias, fastcgi_pass, generated script path |
Correct the endpoint or path mapping | PHP source code or global timeout values |
| PHP-FPM pool | Pool user/group, listener, worker and stderr logs | Start the correct pool, fix its listener, or correct pool identity | Publicly exposing the FPM port |
| Filesystem | Directory traversal, file-read, and application-write checks | Adjust ownership, group, ACL, or mode for the required paths | Making the whole site writable |
| Application | Named file/line, exception, extension, and application configuration | Fix code or runtime configuration and redeploy | FastCGI buffer changes |
| Transport/timing | Connection errors, measured response time, and timeout entries | Repair service reachability or tune the measured bottleneck | Raising all limits without evidence |
A compact verification checklist
- Did you copy the full quoted suffix, URI, upstream, and timestamp?
- Does the suffix identify a parse/fatal error, path, permission, connection, or timeout issue?
- Is the configured
fastcgi_passthe active socket or private TCP listener? - Does
SCRIPT_FILENAMEresolve to a file visible to PHP-FPM? - Can the pool worker traverse every parent directory and read the script?
- Can required cache, upload, and session directories be written without making code directories writable?
- Did the Nginx configuration test pass before reload?
- Did one controlled request produce a changed or resolved diagnostic in both logs?
- Is PHP-FPM inaccessible from untrusted networks?
Frequently Asked Questions
What does “FastCGI sent in stderr” mean?
It means the FastCGI backend, commonly PHP-FPM, wrote diagnostic text to its error stream while Nginx was reading the upstream response. The quoted suffix—not the prefix—identifies the problem.
How do I fix “FastCGI sent in stderr” in Nginx?
Copy the complete quoted message, classify it as an application, path, permission, endpoint, or timing error, then fix that layer. Verify the PHP-FPM logs, test the Nginx configuration, reload, and make one controlled request.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Why does Nginx say “primary script unknown”?
PHP-FPM cannot open the script path supplied by Nginx. Check the file, root or alias, SCRIPT_FILENAME, container mounts, chroots, symlinks, and parent-directory traversal.
Why is PHP-FPM reporting permission denied?
The pool worker may lack read permission on the script or execute permission on one of its parent directories. It may also lack write permission for a cache, upload, or session directory. Check the configured pool user and group at every path level.
Why does the page return HTTP 502?
Nginx returns 502 when it cannot obtain a valid upstream response. Use the quoted FastCGI diagnostic to distinguish a PHP fatal error, unavailable socket, missing script, permission denial, or timeout before changing transport settings.
Can increasing FastCGI buffers fix this error?
Not when the suffix reports a syntax error, wrong script path, or permission denial. Buffer and timeout directives are appropriate only when measured response size or execution time demonstrates a genuine buffering or timing limit.
Is it safe to expose PHP-FPM on a public address?
No. Keep PHP-FPM on a protected Unix socket or private network. An untrusted client that can open a FastCGI connection may control request settings such as auto_prepend_file and potentially execute code.
The Bottom Line
Treat “FastCGI sent in stderr” as a wrapper around the real diagnostic. Classify the quoted message, then fix the matching layer: PHP code, the FastCGI endpoint, the script path, filesystem permissions, or measured transport timing. Validate and reload only after the configuration test passes, and keep PHP-FPM on a protected listener.
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.
