curl non pode ler o teu ficheiro PAC: pasa o proxy no seu lugar

O enderezo do ficheiro PAC e o extremo do proxy parecen intercambiables nun ficheiro de configuración, e non o son. Un é un programa de política que hai que avaliar para cada URL; o outro é un host e un porto que acepta conexións. curl só entende o segundo. Pasar un enderezo PAC a --proxy é un erro de categoría que falla dun xeito confuso, normalmente despois dun tempo de espera CONNECT longo cara a un servidor web.

Que é realmente cada un

As preguntas frecuentes de curl dinllo claramente: curl non ofrece interpretación de JavaScript nin de PAC. Un envoltorio arredor de curl que entenda PAC pode facelo, pero curl en si non, e ningunha opción o converte nun navegador.

Por que o navegador funciona e curl non

Un navegador intégrase coa configuración de proxy do sistema, descarga o ficheiro PAC e executa as súas regras contra o URL que abres. Esa avaliación é o servizo que ofrece o ficheiro PAC, e ocorre dentro do navegador, non dentro do teu terminal.

Descargar o ficheiro PAC con curl só obtén o seu texto. Non fai que curl execute a política, e lelo a man para atopar un proxy é unha versión manual da mesma avaliación, coa mesma probabilidade de escoller a rama equivocada. Se o les, le a instrución return que corresponde ao teu host en lugar do primeiro nome de proxy do ficheiro. A maioría dos ficheiros PAC conteñen varios, e só unha rama te afecta.

Para un proxy HTTP aprobado e un servizo HTTPS aprobado, unha petición ilustrativa é:

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

O primeiro enderezo é o receptor do proxy, o segundo é o servizo que queres. Son extremos de exemplo, non unha proba que alguén fixese, así que substitúeos polo esquema, o porto e o fluxo de autenticación da túa organización.

Escolle o proxy para este destino

Pregunta ao administrador que proxy escolle a política para o URL que necesitas, non que proxy ten a organización. As regras PAC poden devolver resultados distintos para servizos internos, sitios públicos e condicións de conmutación por erro, e unha regra que hoxe coincide co teu URL pode coincidir con outra despois dunha edición.

Se o fluxo de traballo necesita máis dunha petición coñecida, usa unha configuración estática que o administrador admita ou unha integración aprobada que entenda PAC. Codificar un só enderezo copiado funciona ata o día en que a política cambia e ninguén lembra por que se escolleu ese enderezo.

Despois mira que herda curl. As variables de contorno de proxy e NO_PROXY poden substituír ou excluír o proxy que pasaches, e unha exclusión que coincida co teu destino envía a petición directamente sen avisar. Conserva a política prevista en lugar de borrar todas as exclusións ou forzar todo por un só enderezo. Executa a petición unha vez con -v e comproba a que enderezo se conectou realmente.

Mante as dúas identidades TLS separadas

Cun proxy HTTPS, hai dúas conexións TLS en xogo: a túa cara ao proxy e a do proxy cara ao destino. Cada unha ten a súa propia identidade que verificar, e desactivar a verificación de calquera delas non é unha solución PAC, é un segundo problema engadido ao primeiro.

Mantén a verificación activada e le o fallo que obtés. Un desafío de autenticación do proxy, un proxy inalcanzable e unha negativa do sitio web son tres resultados distintos, e só o primeiro trata de credenciais. A VPN aínda debe proporcionar unha ruta permitida cara a un proxy privado, incluída a resolución de nomes para o propio host do proxy, antes de que algo disto funcione.

Anota o extremo, o esquema, o porto, o método de autenticación, as exclusións e a ruta VPN ata o proxy. Ese rexistro é o que fai reproducible a seguinte petición, e é a diferenza entre coñecer o teu proxy e adiviñalo.