This is a well-known class of problem, not a dramatic incident. I still walk into it after “a quick upgrade”.
// problem · 15 april 2026 · 1 min
Different PHP versions between CLI and the web server
The command line told the truth about a different binary than PHP-FPM.
Time wasted: 45 minutes
Problem
php -v and a phpinfo() page from the web server disagreed. A package existed in one and not the other.
Environment
Linux
PHP CLI
PHP-FPM
Symptoms
Composer/CLI used 8.3. The site ran 8.2 (or the reverse). An extension loaded on CLI 500’d in FPM. Or a syntax feature worked in artisan and exploded in the browser.
Expected
One PHP, one set of extensions, one version.
Investigation
php -v, php --ini, phpinfo(), FPM pool config, update-alternatives.
Things I tried
Reinstalled the extension once. Restarted Nginx only. Forgot that FPM is a different process with a different ini.
Root cause
Multiple PHP packages installed. CLI pointed at one binary. PHP-FPM’s pool pointed at another. This is normal on Debian/Ubuntu after a few upgrades. It is still a trap.
Solution
Align the FPM service and CLI to the same version. Restart php-fpm, not just Nginx. Confirm with phpinfo() and php -v.
Why it worked
They were never the same program. You configured one of them.
Lesson
After any PHP upgrade, compare CLI and FPM before you debug the application.
Found something wrong?
These notes can be incomplete, or wrong in a different environment. Suggest a correction on GitHub or email me at me@t4mer.net.
// related
// problem
Nginx/PHP-FPM 502 that looked like Laravel
The application log was empty because PHP never ran.
// til
TIL: what PHP-FPM actually does
PHP-FPM is a pool of PHP processes. Nginx does not speak PHP. It speaks FastCGI to that pool.
// problem
HTTP 421 Misdirected Request caused by an incorrect Host header
A 421 that looked like Nginx until the outbound Host header showed up.