curl kan inte läsa din PAC-fil: skicka proxyn i stället

Adressen till PAC-filen och proxyns slutpunkt ser ut att kunna bytas ut i en konfigurationsfil, och det kan de inte. Den ena är ett policyprogram som måste utvärderas för varje URL; den andra är en värd och en port som tar emot anslutningar. curl förstår bara den andra. Att skicka en PAC-adress till --proxy är ett kategorifel som misslyckas på ett förvirrande sätt, vanligtvis efter en lång CONNECT-timeout mot en webbserver.

Vad var och en egentligen är

Det säger vanliga frågor om curl tydligt: curl erbjuder ingen JavaScript- eller PAC-tolkning. Ett PAC-medvetet omslag runt curl kan göra det, men curl själv inte, och ingen flagga gör den till en webbläsare.

Varför webbläsaren fungerar och curl inte

En webbläsare integrerar med systemets proxykonfiguration, hämtar PAC-filen och kör dess regler mot den URL du öppnar. Den utvärderingen är tjänsten PAC-filen tillhandahåller, och den sker inne i webbläsaren, inte i din terminal.

Att hämta PAC-filen med curl ger bara dess text. Det får inte curl att köra policyn, och att läsa den manuellt för att hitta en proxy är en manuell version av samma utvärdering, med samma chans att välja fel gren. Om du läser den, läs return-satsen som matchar din värd i stället för det första proxynamnet i filen. De flesta PAC-filer innehåller flera, och bara en gren gäller dig.

För en godkänd HTTP-proxy och en godkänd HTTPS-tjänst är en illustrerande begäran:

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

Den första adressen är proxyns lyssnare, den andra är tjänsten du vill ha. Det här är exempelslutpunkter och inte ett test som någon har utfört, så ersätt dem med din organisations schema, port och autentiseringsflöde.

Välj proxyn för den här destinationen

Fråga administratören vilken proxy policyn väljer för den URL du behöver, inte vilken proxy organisationen äger. PAC-regler kan ge olika resultat för interna tjänster, offentliga webbplatser och redundanslägen, och en regel som passar din URL idag kan efter en ändring passa en annan.

Om arbetsflödet behöver mer än en känd begäran, använd en statisk inställning som administratören stöder eller en godkänd PAC-medveten integration. Att hårdkoda en enda kopierad adress fungerar till den dag policyn ändras och ingen längre minns varför den adressen valdes.

Titta sedan på vad curl ärver. Proxy-miljövariabler och NO_PROXY kan åsidosätta eller utesluta proxyn du skickade, och ett undantag som matchar ditt mål skickar begäran direkt utan att säga det. Behåll den avsedda policyn i stället för att radera varje undantag eller tvinga allt genom en enda adress. Kör begäran en gång med -v och kontrollera vilken adress den faktiskt anslöt till.

Håll de två TLS-identiteterna isär

Med en HTTPS-proxy är två TLS-anslutningar i spel: din till proxyn och proxyns till destinationen. Var och en har sin egen identitet att verifiera, och att stänga av verifieringen för någon av dem är inte en PAC-lösning, det är ett andra problem ovanpå det första.

Låt verifieringen vara på och läs felet du får. En proxyautentiseringsutmaning, en oåtkomlig proxy och ett avslag från webbplatsen är tre olika resultat, och bara det första handlar om inloggningsuppgifter. VPN måste fortfarande tillhandahålla en tillåten väg till en privat proxy, inklusive namnsuppslagning för själva proxyvärden, innan något av detta kan lyckas.

Skriv ned slutpunkten, schemat, porten, autentiseringsmetoden, undantagen och VPN-vägen till proxyn. Den anteckningen är det som gör nästa begäran reproducerbar, och det är skillnaden mellan att känna sin proxy och att gissa sig till den.