Why PHP-FPM Loses the Proxy That Works in Your Terminal

The same PHP file can use a proxy in a terminal and go direct when served by PHP-FPM. Start by comparing the processes that run it. Your terminal starts PHP with its shell environment; the web server sends a request to workers that FPM has already created.

Look at the worker's environment

The FPM pool configuration provides clear_env and explicit env[NAME] entries. With environment clearing enabled, exporting a variable in your login shell does not place it in a worker. Pool entries can pass selected variables:

env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080

Apply configuration changes through your deployment's normal FPM reload procedure. Put the values in the pool that actually serves the application. A different pool, service account, or container can explain why an apparently correct edit has no effect.

Inspect only whether the expected settings exist when debugging a live request. A public diagnostics page that prints complete environment values can expose proxy credentials along with unrelated secrets.

Then check the PHP transport

libcurl has documented proxy environment handling; an explicit PHP cURL handle has its own options as well. PHP's HTTP stream wrapper has a separate context configuration. Supplying variables to a worker does not make every PHP network API consume them.

That gives a useful two-part check: confirm what the worker received, then confirm how the chosen HTTP client reads proxy settings. If CLI and FPM receive the same values but still behave differently, compare client options and bypass rules next. Repeatedly editing the shell profile cannot settle a difference inside the worker's HTTP client.