Dlaczego PHP-FPM traci proxy, które działa w terminalu

Prześledź konfigurację proxy w workerach PHP-FPM i odróżnij ich środowisko od kontekstów strumieni PHP.

Ten sam plik PHP może korzystać z proxy w terminalu i łączyć się bezpośrednio, gdy jest obsługiwany przez PHP-FPM. Zacznij od porównania procesów, które go uruchamiają. Terminal uruchamia PHP ze środowiskiem powłoki; serwer WWW wysyła żądanie do workerów, które FPM już utworzył.

Sprawdź środowisko workera

Konfiguracja puli FPM udostępnia clear_env oraz jawne wpisy env[NAME]. Przy włączonym czyszczeniu środowiska wyeksportowanie zmiennej w powłoce logowania nie umieszcza jej w workerze. Wpisy puli mogą przekazywać wybrane zmienne:

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

Zmiany konfiguracji stosuj przez zwykłą procedurę przeładowania FPM w swoim wdrożeniu. Umieść wartości w puli, która faktycznie obsługuje aplikację. Inna pula, konto usługi lub kontener mogą wyjaśniać, dlaczego pozornie poprawna zmiana nie daje efektu.

Podczas debugowania aktywnego żądania sprawdzaj tylko, czy oczekiwane ustawienia istnieją. Publiczna strona diagnostyczna drukująca pełne wartości środowiska może ujawnić poświadczenia proxy wraz z niepowiązanymi sekretami.

Następnie sprawdź transport PHP

libcurl ma udokumentowaną obsługę środowiska proxy; jawny uchwyt PHP cURL ma również własne opcje. Nakładka strumienia HTTP w PHP ma osobną konfigurację kontekstu. Przekazanie zmiennych do workera nie sprawia, że każde API sieciowe PHP je wykorzysta.

Daje to użyteczną dwuczęściową kontrolę: potwierdź, co otrzymał worker, a następnie potwierdź, jak wybrany klient HTTP czyta ustawienia proxy. Jeśli CLI i FPM otrzymują te same wartości, ale nadal zachowują się inaczej, porównaj kolejno opcje klienta i reguły pomijania. Wielokrotne edytowanie profilu powłoki nie rozstrzygnie różnicy wewnątrz klienta HTTP workera.

Powiązane artykuły