Quick answer
AH01071 is Apache's way of saying PHP-FPM logged an error while serving a request.
AH01071 is Apache’s way of saying PHP-FPM logged an error while serving a request. The scary part is that the page often still loads, so the real error stays hidden in the logs until you know where to look.
What you need: SSH access to the server, plus read access to the Apache and PHP-FPM logs.
Find the actual PHP error
AH01071 always carries a second half after the pipe. Check the PHP-FPM error log, not just the Apache error log. On Debian/Ubuntu it lives at /var/log/php-fpm/ or inside the FPM pool config.
Match the request to the pool
If you run several pools (one per vhost), the error belongs to whichever pool served the request. Confirm the pool name from the Apache vhost’s SetHandler or the FPM socket path.
Fix the root cause
The message is almost always a PHP warning, a missing extension, or a permissions problem. Fix the underlying PHP issue and the AH01071 noise disappears with it.
tail -f /var/log/php*-fpm.log /var/log/apache2/error.log
# or for a systemd pool:
journalctl -u php8.3-fpm -fHow it works, in detail
AH01071 is emitted by mod_proxy_fcgi when the PHP-FPM backend writes to stderr while handling a request. Because the front end still returns a response, the warning is easy to miss until a feature breaks. The message after the pipe is the real error, and it usually belongs to the pool that served that vhost, which is why a shared FPM log is the wrong place to look. Matching the request time to the pool log is the fastest way to pin down which site is at fault.
Common pitfalls
- Searching only the Apache error log and missing the PHP-FPM log entirely.
- Fixing the symptom by raising error_reporting instead of resolving the underlying PHP warning.
Pro tip
Set a per-pool error log in each FPM pool config, then tail it with tail -f while reproducing the request.
Treat AH01071 as a pointer, not the problem itself. Once you read the PHP message it wraps, the fix is usually a one-liner.
0 Comments