A curl nem tudja olvasni a PAC-fájlt: adja át helyette a proxyt

A PAC-fájl címe és a proxy végpontja felcserélhetőnek tűnik egy konfigurációs fájlban, de nem az. Az egyik szabályzatprogram, amelyet minden URL-hez ki kell értékelni; a másik egy gazdagép és port, amely kapcsolatokat fogad. A curl csak a másodikat érti. Egy PAC-cím átadása a --proxy kapcsolónak kategóriahiba, amely zavaró módon vall kudarcot, általában egy hosszú CONNECT-időtúllépés után egy webkiszolgáló felé.

Mi is valójában mindegyik

Ezt mondja ki világosan a curl GYIK: a curl nem nyújt JavaScript- vagy PAC-értelmezést. Egy PAC-t ismerő burkoló a curl körül tudja ezt, maga a curl azonban nem, és semmilyen kapcsoló nem teszi böngészővé.

Miért működik a böngésző, és miért nem a curl

A böngésző integrálódik a rendszer proxybeállításaival, letölti a PAC-fájlt, és lefuttatja annak szabályait az általunk megnyitott URL-re. Ez az értékelés a PAC-fájl által nyújtott szolgáltatás, és a böngészőn belül történik, nem a terminálunkban.

A PAC-fájl curl-lel való letöltése csak a szövegét hozza el. Nem készteti a curlt a szabályzat végrehajtására, és kézzel olvasni, hogy proxyt találjunk, ugyanazon értékelés kézi változata, ugyanolyan eséllyel a rossz ágat választva. Ha mégis olvassa, a gazdagépéhez illő return utasítást olvassa, ne a fájl első proxynevét. A legtöbb PAC-fájl többet tartalmaz, és csak egy ág vonatkozik Önre.

Egy jóváhagyott HTTP-proxy és egy jóváhagyott HTTPS-szolgáltatás esetén egy szemléltető kérés:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Az első cím a proxy figyelője, a második a kívánt szolgáltatás. Ezek példa végpontok, nem valaki által elvégzett teszt, ezért helyettesítse őket szervezete sémájával, portjával és hitelesítési folyamatával.

Válassza ki a proxyt ehhez a célhoz

Kérdezze meg a rendszergazdát, melyik proxyt választja a szabályzat a szükséges URL-hez, és ne azt, hogy melyik proxy van a szervezet birtokában. A PAC-szabályok eltérő eredményt adhatnak belső szolgáltatásokra, nyilvános oldalakra és feladatátvételi helyzetekre, és egy ma az URL-jéhez illő szabály egy szerkesztés után már másikhoz illeszkedhet.

Ha a munkafolyamat egynél több ismert kérést igényel, használjon rendszergazda által támogatott statikus beállítást vagy jóváhagyott, PAC-t ismerő integrációt. Egyetlen másolt cím beégetése addig működik, amíg a szabályzat meg nem változik, és már senki sem emlékszik, miért azt a címet választották.

Utána nézze meg, mit örököl a curl. A proxy környezeti változói és a NO_PROXY felülírhatják vagy kizárhatják az átadott proxyt, és a céljához illő kizárás csendben közvetlenül küldi a kérést. Őrizze meg a szándékolt szabályzatot, ahelyett hogy minden kizárást törölne, vagy mindent egyetlen címen keresztül kényszerítene. Futtassa a kérést egyszer -v kapcsolóval, és ellenőrizze, melyik címhez csatlakozott valójában.

Tartsa külön a két TLS-identitást

HTTPS-proxy esetén két TLS-kapcsolat van játékban: az Öné a proxy felé és a proxyé a cél felé. Mindegyiknek megvan a maga ellenőrizendő identitása, és bármelyikük ellenőrzését kikapcsolni nem PAC-javítás, hanem második probléma az elsőhöz adva.

Hagyja bekapcsolva az ellenőrzést, és olvassa el a kapott hibát. A proxyhitelesítési kihívás, az elérhetetlen proxy és a webhely elutasítása három különböző eredmény, és csak az első szól a hitelesítő adatokról. A VPN-nek továbbra is engedélyezett utat kell biztosítania egy privát proxyhoz, beleértve magának a proxy gazdagépnek a névfeloldását is, mielőtt bármi ebből sikerülhet.

Jegyezze fel a végpontot, a sémát, a portot, a hitelesítési módszert, a kizárásokat és a proxyhoz vezető VPN-utat. Ez a feljegyzés teszi reprodukálhatóvá a következő kérést, és ez a különbség a proxy ismerete és a róla való találgatás között.