Hoekom PHP-FPM die proxy verloor wat in jou terminaal werk
Volg proxy-konfigurasie tot in PHP-FPM-werkers en onderskei hul omgewing van PHP-stroomkontekste.
Dieselfde PHP-lêer kan 'n proxy in 'n terminaal gebruik en direk gaan wanneer dit deur PHP-FPM bedien word. Begin deur die prosesse wat dit laat loop, te vergelyk. Jou terminaal begin PHP met sy skelomgewing; die webbedienaar stuur 'n versoek na werkers wat FPM reeds geskep het.
Kyk na die werker se omgewing
Die FPM-poelkonfigurasie voorsien clear_env en eksplisiete env[NAME]-inskrywings. Met omgewingsopruiming geaktiveer, plaas die uitvoer van 'n veranderlike in jou aanmeldskel dit nie in 'n werker nie. Poelinskrywings kan geselekteerde veranderlikes deurgee:
env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080Pas konfigurasieveranderings toe deur jou ontplooiing se normale FPM-herlaaiprosedure. Sit die waardes in die poel wat die toepassing werklik bedien. 'n Ander poel, diensrekening of houer kan verduidelik waarom 'n oënskynlik korrekte wysiging geen effek het nie.
Kyk slegs of die verwagte instellings bestaan wanneer jy 'n lewende versoek ontfout. 'n Openbare diagnostiese bladsy wat volledige omgewingswaardes druk, kan proxy-aanmeldings saam met onverwante geheime blootstel.
Kontroleer dan die PHP-transport
libcurl het gedokumenteerde hantering van proxy-omgewings; 'n eksplisiete PHP cURL-handvatsel het ook sy eie opsies. PHP se HTTP-stroomomslag het 'n aparte kontekskonfigurasie. Om veranderlikes aan 'n werker te gee, maak nie dat elke PHP-netwerk-API dit gebruik nie.
Dit gee 'n nuttige tweedelige kontrole: bevestig wat die werker ontvang het, bevestig dan hoe die gekose HTTP-kliënt proxy-instellings lees. As CLI en FPM dieselfde waardes ontvang maar steeds anders optree, vergelyk volgende die kliënt se opsies en omsy-reëls. Herhaaldelik die skelprofiel wysig kan nie 'n verskil binne die werker se HTTP-kliënt oplos nie.