Miért veszíti el a PHP-FPM a terminálban működő proxyt

Ugyanaz a PHP fájl használhat proxyt egy terminálban, és közvetlenül kapcsolódhat, amikor a PHP-FPM szolgálja ki. Kezdje az őt futtató folyamatok összehasonlításával. A terminál a saját héj környezetével indítja a PHP-t; a webszerver kérést küld azoknak a munkafolyamatoknak, amelyeket az FPM már létrehozott.

Nézze meg a munkafolyamat környezetét

Az FPM pool konfiguráció clear_env és explicit env[NAME] bejegyzéseket biztosít. Ha a környezet tisztítása engedélyezett, a bejelentkezési héjban exportált változó nem kerül be a munkafolyamatba. A pool bejegyzések kiválasztott változókat adhatnak át:

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

Alkalmazza a konfigurációs változtatásokat a telepítés szokásos FPM újratöltési eljárásával. Tegye az értékeket abba a poolba, amely valóban kiszolgálja az alkalmazást. Egy másik pool, szolgáltatásfiók vagy konténer magyarázhatja, miért nincs hatása egy látszólag helyes szerkesztésnek.

Élő kérés hibakeresésekor csak azt ellenőrizze, hogy a várt beállítások léteznek-e. Egy nyilvános diagnosztikai oldal, amely teljes környezeti értékeket nyomtat ki, proxy hitelesítő adatokat és más titkokat is felfedhet.

Ezután ellenőrizze a PHP átvitelt

A libcurl dokumentált proxy környezetkezeléssel rendelkezik; egy explicit PHP cURL leírónak is megvannak a saját beállításai. A PHP HTTP stream wrappere külön kontextuskonfigurációval rendelkezik. A változók átadása egy munkafolyamatnak nem teszi azt, hogy minden PHP hálózati API felhasználja őket.

Ez hasznos kétrészes ellenőrzést ad: igazolja, mit kapott a munkafolyamat, majd igazolja, hogyan olvassa a választott HTTP kliens a proxy beállításokat. Ha a CLI és az FPM ugyanazokat az értékeket kapja, de mégis másként viselkedik, hasonlítsa össze a kliens beállításait és a megkerülési szabályokat. A héj profiljának ismételt szerkesztése nem tudja megoldani a munkafolyamat HTTP kliensén belüli eltérést.