Pse PHP-FPM e humb proxy-n që funksionon në terminalin tuaj

I njëjti skedar PHP mund të përdorë një proxy në terminal dhe të lidhet drejtpërdrejt kur shërbehet nga PHP-FPM. Filloni duke krahasuar proceset që e ekzekutojnë. Terminali juaj e nis PHP me mjedisin e shell-it; serveri web dërgon një kërkesë te workerat që FPM ka krijuar tashmë.

Shikoni mjedisin e worker-it

Konfigurimi i pool-it FPM ofron clear_env dhe hyrje eksplicite env[NAME]. Me pastrimin e mjedisit të aktivizuar, eksportimi i një ndryshoreje në shell-in e hyrjes nuk e vendos atë në një worker. Hyrjet e pool-it mund të kalojnë ndryshore të zgjedhura:

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

Aplikoni ndryshimet e konfigurimit përmes procedurës normale të ringarkimit të FPM në vendosjen tuaj. Vendosni vlerat në pool-in që shërben në të vërtetë aplikacionin. Një pool, llogari shërbimi ose kontejner tjetër mund të shpjegojë pse një redaktim në dukje i saktë nuk ka efekt.

Kur korrigjoni një kërkesë të drejtpërdrejtë, kontrolloni vetëm nëse ekzistojnë cilësimet e pritura. Një faqe publike diagnostikimi që printon vlera të plota të mjedisit mund të ekspozojë kredencialet e proxy-t bashkë me sekrete të palidhura.

Më pas kontrolloni transportin e PHP

libcurl ka trajtim të dokumentuar të mjedisit të proxy-t; një dorezë e qartë PHP cURL ka gjithashtu opsionet e veta. Mbështjellësi i stream-it HTTP të PHP ka një konfigurim të veçantë konteksti. Furnizimi i ndryshoreve një worker-i nuk bën që çdo API rrjeti i PHP t'i konsumojë ato.

Kjo jep një kontroll të dobishëm në dy pjesë: konfirmoni çfarë mori worker-i, pastaj konfirmoni si klienti HTTP i zgjedhur i lexon cilësimet e proxy-t. Nëse CLI dhe FPM marrin të njëjtat vlera por sillen ende ndryshe, krahasoni më pas opsionet e klientit dhe rregullat e anashkalimit. Redaktimi i përsëritur i profilit të shell-it nuk mund të zgjidhë një ndryshim brenda klientit HTTP të worker-it.