De ce PHP-FPM pierde proxy-ul care funcționează în terminal
Urmărește configurația proxy până în workerii PHP-FPM și distinge mediul lor de contextele de flux PHP.
Același fișier PHP poate folosi un proxy într-un terminal și poate ieși direct când este servit de PHP-FPM. Începe prin a compara procesele care îl rulează. Terminalul pornește PHP cu mediul shell-ului; serverul web trimite o cerere către workeri pe care FPM i-a creat deja.
Privește mediul workerului
Configurația pool-ului FPM oferă clear_env și intrări explicite env[NAME]. Cu curățarea mediului activată, exportarea unei variabile în shell-ul de login nu o plasează într-un worker. Intrările din pool pot transmite variabile selectate:
env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080Aplică modificările de configurare prin procedura normală de reîncărcare FPM a implementării tale. Pune valorile în pool-ul care servește efectiv aplicația. Un alt pool, cont de serviciu sau container poate explica de ce o editare aparent corectă nu are efect.
Când depanezi o cerere live, inspectează doar dacă setările așteptate există. O pagină publică de diagnosticare care afișează valori complete de mediu poate expune credențialele proxy împreună cu secrete nelegate.
Apoi verifică transportul PHP
libcurl are o gestionare documentată a mediului proxy; un handle PHP cURL explicit are și el propriile opțiuni. Wrapperul de flux HTTP al PHP are o configurare separată de context. Furnizarea de variabile unui worker nu face ca fiecare API de rețea PHP să le consume.
Asta oferă o verificare utilă în două părți: confirmă ce a primit workerul, apoi confirmă cum citește clientul HTTP ales setările proxy. Dacă CLI și FPM primesc aceleași valori dar se comportă totuși diferit, compară în continuare opțiunile clientului și regulile de ocolire. Editarea repetată a profilului shell nu poate rezolva o diferență din interiorul clientului HTTP al workerului.