Por qué curl se conecta a localhost en lugar de la URL remota
Separe el proxy heredado, el archivo curlrc predeterminado y el destino real antes de culpar a la VPN. Tres ejecuciones controladas mantienen activa la verificación TLS.
Si curl intenta conectarse a localhost independientemente de la URL que le haya dado, la VPN es el lugar equivocado para empezar. Un proxy HTTP o SOCKS local puede ser la primera conexión prevista, incluso cuando el servicio que desea está en un lugar completamente distinto. Si ese proxy ya no se ejecuta, el intento a localhost falla antes de que curl llegue siquiera al destino. Además, una respuesta del proxy no demuestra que el destino haya respondido.
Siga estos pasos en orden y deténgase en el primero que cambie el primer intento de conexión.
Lea primero las reglas de proxy del propio curl
curl lee variables de proxy específicas del protocolo, como https_proxy y HTTPS_PROXY, además de ALL_PROXY cuando no se aplica ningún valor específico del protocolo. Inspeccione el entorno del intérprete, el servicio o la tarea que realmente lanza curl, no el de su terminal actual. Un trabajo de CI, una unidad de systemd y un intérprete interactivo pueden heredar tres conjuntos distintos. Suponerlo a partir del intérprete visible es justo lo que hace que esta investigación pierda una tarde entera.
Merece la pena memorizar una excepción. curl acepta http_proxy solo en minúsculas; la versión en mayúsculas HTTP_PROXY se ignora, y por eso el mismo entorno se comporta de forma distinta en otras herramientas.
Lea los valores en privado, porque una URL de proxy suele llevar credenciales.
Después revise el archivo de configuración predeterminado de curl por si contiene anulaciones de proxy o de conexión, y confirme qué ejecutable está ejecutando en realidad. Un alias del intérprete, una función o un script envoltorio pueden añadir opciones que nunca aparecen en su línea de comandos.
Compare tres invocaciones con TLS activado
Use un destino de diagnóstico aprobado y el mismo binario para las tres ejecuciones.
curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status
-q suprime el curlrc predeterminado y debe ser el primer parámetro de la línea para funcionar. No elimina las variables de entorno de proxy, lo que sorprende a quienes esperan exactamente eso. La tercera forma añade un valor vacío de --proxy, sustituyendo el proxy solicitado por el entorno solo para esa invocación. Compare el primer intento de conexión de cada salida, no el código de estado final.
La salida detallada puede exponer encabezados, tokens y credenciales de proxy, así que manténgala en local y lea fragmentos antes de compartirla.
Qué descarta cada resultado
Si omitir la configuración predeterminada cambia la conexión, la fuente es el archivo de configuración. Si desactivar explícitamente el proxy heredado la cambia, la fuente es la variable de entorno. Si ninguna de las dos la cambia y localhost sigue apareciendo, revise las anulaciones de conexión de la línea de comandos, la resolución de nombres de host y el ejecutable seleccionado. Cada una tiene una solución distinta, y ninguna de ellas es un cambio de enrutamiento.
La carga de bibliotecas personalizadas o el comportamiento de red inyectado es una capa posterior, y una variable de entorno por sí sola no es prueba de ello.
Mantenga la decisión del proxy aparte de la VPN
Una vez que curl elige un destino directo, el sistema operativo sigue enrutando esa conexión. Desactivar un proxy de aplicación no desactiva la ruta de la VPN ni su política de filtrado. Haga comparaciones de acceso directo solo donde ese diagnóstico esté autorizado. Una prueba que elude la política en silencio no es un resultado válido, es un incidente.
Si se requiere un proxy local, restaure su servicio y su dirección en lugar de borrar sus ajustes.
Si solo algunos destinos privados necesitan acceso directo, añada una exclusión estrecha y aprobada, y conserve el proxy para todo lo demás. Guarde el primer error del camino elegido, porque un rechazo de localhost, un rechazo de CONNECT del proxy, un fallo de certificado y un error de autorización identifican cuatro etapas distintas.