Защо 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 клиента на работника.