Почему PHP-FPM теряет прокси, который работает в вашем терминале

Один и тот же PHP-файл может использовать прокси в терминале и подключаться напрямую под управлением PHP-FPM. Начните со сравнения процессов, которые его выполняют. Ваш терминал запускает PHP с окружением оболочки; веб-сервер отправляет запрос воркерам, которые FPM уже создал.

Посмотрите на окружение воркера

Конфигурация пула FPM предоставляет clear_env и явные записи env[NAME]. При включённой очистке окружения экспорт переменной в вашей оболочке входа не помещает её в воркер. Записи пула могут передавать выбранные переменные:

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

Применяйте изменения конфигурации через обычную процедуру перезагрузки FPM в вашем развёртывании. Помещайте значения в пул, который действительно обслуживает приложение. Другой пул, сервисная учётная запись или контейнер могут объяснить, почему казалось бы правильная правка не даёт эффекта.

При отладке живого запроса проверяйте только наличие ожидаемых настроек. Публичная диагностическая страница, печатающая полные значения окружения, может раскрыть учётные данные прокси вместе с посторонними секретами.

Затем проверьте транспорт PHP

libcurl имеет документированную обработку переменных окружения прокси; у явного дескриптора PHP cURL тоже есть свои опции. Обёртка HTTP-потока PHP имеет отдельную конфигурацию контекста. Передача переменных воркеру не заставляет каждый сетевой API PHP их использовать.

Это даёт полезную проверку из двух частей: подтвердите, что получил воркер, затем подтвердите, как выбранный HTTP-клиент читает настройки прокси. Если CLI и FPM получают одинаковые значения, но всё равно ведут себя по-разному, сравните далее опции клиента и правила обхода. Повторное редактирование профиля оболочки не устранит различие внутри HTTP-клиента воркера.