Чому 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-клієнта воркера.