curl no puede leer tu archivo PAC: pasa el proxy en su lugar

La dirección del archivo PAC y el extremo del proxy parecen intercambiables en un archivo de configuración, y no lo son. Uno es un programa de política que debe evaluarse para cada URL; el otro es un host y un puerto que acepta conexiones. curl solo entiende el segundo. Pasar una dirección PAC a --proxy es un error de categoría que falla de forma confusa, normalmente tras un tiempo de espera CONNECT largo hacia un servidor web.

Qué es realmente cada uno

Las preguntas frecuentes de curl lo dicen claramente: curl no ofrece interpretación de JavaScript ni de PAC. Un envoltorio alrededor de curl que entienda PAC puede hacerlo, pero curl en sí no, y ninguna opción lo convierte en un navegador.

Por qué el navegador funciona y curl no

Un navegador se integra con la configuración de proxy del sistema, descarga el archivo PAC y ejecuta sus reglas contra la URL que abres. Esa evaluación es el servicio que ofrece el archivo PAC, y ocurre dentro del navegador, no dentro de tu terminal.

Descargar el archivo PAC con curl solo obtiene su texto. No hace que curl ejecute la política, y leerlo a mano para encontrar un proxy es una versión manual de la misma evaluación, con la misma probabilidad de elegir la rama equivocada. Si lo lees, lee la instrucción return que corresponde a tu host en lugar del primer nombre de proxy del archivo. La mayoría de los archivos PAC contienen varios, y solo una rama te afecta.

Para un proxy HTTP aprobado y un servicio HTTPS aprobado, una petición ilustrativa es:

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

La primera dirección es el receptor del proxy, la segunda es el servicio que quieres. Son extremos de ejemplo, no una prueba que alguien haya hecho, así que sustitúyelos por el esquema, el puerto y el flujo de autenticación de tu organización.

Elige el proxy para este destino

Pregunta al administrador qué proxy elige la política para la URL que necesitas, no qué proxy tiene la organización. Las reglas PAC pueden dar resultados distintos para servicios internos, sitios públicos y condiciones de conmutación por error, y una regla que hoy coincide con tu URL puede coincidir con otra después de una edición.

Si el flujo de trabajo necesita más de una petición conocida, usa una configuración estática que el administrador admita o una integración aprobada que entienda PAC. Codificar una sola dirección copiada funciona hasta el día en que la política cambia y nadie recuerda por qué se eligió esa dirección.

Después mira qué hereda curl. Las variables de entorno de proxy y NO_PROXY pueden sustituir o excluir el proxy que pasaste, y una exclusión que coincida con tu destino envía la petición directamente sin avisar. Conserva la política prevista en lugar de borrar todas las exclusiones o forzarlo todo por una sola dirección. Ejecuta la petición una vez con -v y comprueba a qué dirección se conectó realmente.

Mantén las dos identidades TLS separadas

Con un proxy HTTPS, hay dos conexiones TLS en juego: la tuya hacia el proxy y la del proxy hacia el destino. Cada una tiene su propia identidad que verificar, y desactivar la verificación de cualquiera de ellas no es una solución PAC, es un segundo problema añadido al primero.

Mantén la verificación activada y lee el fallo que obtienes. Un desafío de autenticación del proxy, un proxy inalcanzable y una negativa del sitio web son tres resultados distintos, y solo el primero trata de credenciales. La VPN todavía debe proporcionar una ruta permitida hacia un proxy privado, incluida la resolución de nombres para el propio host del proxy, antes de que algo de esto funcione.

Anota el extremo, el esquema, el puerto, el método de autenticación, las exclusiones y la ruta VPN hasta el proxy. Ese registro es lo que hace reproducible la siguiente petición, y es la diferencia entre conocer tu proxy y adivinarlo.