Fix PHP-FPM Errors

The Problem

Your site intermittently shows 502 or 504 errors, or PHP pages just hang, and the cause is somewhere in PHP-FPM — a crashed worker, an exhausted pool, or a misconfiguration — rather than the web server itself.

About this problem

PHP-FPM sits between the web server and your actual PHP code, managing a pool of worker processes — when something goes wrong here (a worker crashing from a fatal error, the pool running out of available workers, or a socket/port misconfiguration), the symptom shows up as a generic gateway error from the web server, which can make it look like an Nginx or Apache problem when the real cause is one layer deeper.

This typically appears under load, after a PHP version upgrade, or following a configuration change that wasn't fully tested.

What's Included

• Checking PHP-FPM's own error log alongside the web server's log to find the real cause
• Identifying whether the issue is pool exhaustion, crashed workers, or a configuration mismatch
• Correcting the specific PHP-FPM configuration causing the problem
• Testing under realistic conditions to confirm the fix holds, not just a one-off page load

What's NOT Included

• Fixing bugs in your application's own PHP code that are directly crashing workers (flagged separately if found)
• Scaling server resources — a capacity decision for you
• Ongoing performance tuning beyond fixing the specific error (see PHP-FPM configuration service for a fuller tuning pass)

How It Works

1. Check PHP-FPM's error log (commonly under /var/log/php*-fpm.log) alongside the web server's log for the matching timestamp.
2. Determine whether the pool is exhausting pm.max_children, a worker is crashing from a fatal PHP error, or there's a socket/port mismatch with the web server config.
3. If pool exhaustion, review and adjust pool sizing against actual resource availability.
4. If workers are crashing, trace the fatal error to the specific application code or extension causing it.
5. Apply the fix and monitor under real traffic conditions to confirm the error doesn't recur.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Why does my site show 502 errors only sometimes?

Intermittent 502s often point to PHP-FPM running out of available workers under specific traffic spikes, or a particular request type that reliably crashes a worker, rather than a constant failure.

Where does PHP-FPM log its own errors?

Typically in a dedicated log file separate from the web server's error log, commonly under /var/log with a php*-fpm naming pattern, though the exact path is configurable.

Can a PHP-FPM crash bring down my whole site?

A single worker crashing usually just fails that one request, since the pool manager restarts workers automatically — but if crashes happen faster than they can be replaced, the whole pool can become genuinely unresponsive.

Is a PHP-FPM error the same as an Nginx error?

No, Nginx (or Apache) just reports that it couldn't get a proper response from PHP-FPM — the actual root cause lives in PHP-FPM's own logs and configuration, one layer behind the web server.

Why did PHP-FPM errors start after I upgraded PHP?

A version upgrade can expose configuration incompatibilities, deprecated settings, or extensions that need reinstalling for the new version, any of which can manifest as new PHP-FPM errors.

Does restarting PHP-FPM fix these errors permanently?

It can clear a temporary stuck state, but if the underlying cause (pool sizing, a specific crashing request, a config mismatch) isn't addressed, the same errors typically return.