Cómo utilizar cURL con un proxy: HTTP, HTTPS, SOCKS, autenticación y soluciones

Sustituye el marcador de posición del proxy por el host y el puerto que te proporcione tu servicio de proxy. En primer lugar, solicita a un punto final de comprobación de IP de confianza la dirección pública visible sin proxy:

curl "https://api.ipify.org"

Ahora envía la misma solicitud a través del proxy:

curl --proxy "http://proxy.example:8080" "https://api.ipify.org"

-x es la forma abreviada de --proxy, por lo que este comando de cURL con proxy es equivalente a:

curl -x "http://proxy.example:8080" "https://api.ipify.org"

Un segundo resultado diferente suele confirmar que la solicitud salió a través de otra dirección. Si no ha cambiado, no des por hecho todavía que el proxy no funciona. Comprueba si el punto final, el tipo de proxy, la política de red o el proveedor utilizan una IP de salida fija. Resulta útil disponer de una lista de comprobación más amplia sobre cómo probar proxies antes de añadir el proxy a la automatización.

Si curl --version falla, ve a la sección de instalación de la plataforma y luego vuelve aquí.

Para la autenticación del proxy con cURL, introduce las credenciales en la URL o pásalas por separado:

curl -x "http://demo-user:demo-pass@proxy.example:8080" "https://api.ipify.org"

curl -x "http://proxy.example:8080" \
  --proxy-user "demo-user:demo-pass" \
  "https://api.ipify.org"

Utiliza marcadores de posición ficticios en la documentación y escribe entre comillas todos los argumentos que contengan credenciales. --proxy-user Esto mantiene las credenciales fuera de la URL del proxy, pero no hace que la línea de comandos sea secreta. En el caso de contraseñas que contengan @, :, %, espacios o metacaracteres de shell, comprueba las reglas de escape o de codificación porcentual de tu shell y de la versión de cURL antes de utilizarlas en producción.

Cada solicitud de cURL con proxy especifica dos puntos finales distintos:

curl --proxy "http://proxy.example:8080" "https://target.example/resource"

El valor que aparece después de --proxy es la URL del proxy. Indica a cURL dónde se encuentra el intermediario y cómo conectarse a él. El último argumento es la URL de destino, que identifica la API, la página o el archivo que realmente deseas.

Conceptualmente, cURL envía la solicitud a través del proxy, y este la reenvía hacia el destino. Cambiar el esquema del proxy modifica la forma en que cURL llega a ese intermediario. Cambiar el destino modifica el recurso que se solicita. Las credenciales del proxy deben figurar en la configuración del proxy, no en la URL de destino.

Mantener separadas estas funciones evita un error habitual: cambiar el esquema de destino cuando lo que se pretendía era cambiar el protocolo del proxy. Además, hace que la revisión de los registros sea más segura, ya que permite ocultar el valor del proxy que contiene las credenciales sin ocultar el objetivo que se está probando.

Una dirección autenticada tiene este formato:

protocol://username:password@host:port

protocol selecciona HTTP, HTTPS o una variante de SOCKS. host y port localiza el listener del proxy. El nombre de usuario y la contraseña opcionales autorizan el uso de ese proxy. Si se omite el esquema, cURL trata el proxy como HTTP, pero indicarlo explícitamente facilita la revisión de los scripts.

Los esquemas de destino y de proxy son independientes. Por ejemplo, este comando accede a un destino HTTPS a través de un proxy HTTP:

curl --proxy "http://proxy.example:8080" "https://target.example/api"

Una https:// URL de proxy significa que la propia conexión entre el cliente y el proxy utiliza TLS. No significa que el destino también deba utilizar HTTPS. Si se requiere autenticación, añade --proxy-user "USER:PASS" en lugar de mezclar las credenciales del proxy con las del destino. Pon entre comillas ambas URL, especialmente cuando haya cadenas de consulta o caracteres sensibles al shell.

Esta matriz recoge en un solo lugar los patrones básicos de cURL con proxy:

Utilizar -x o --proxy de forma coherente en un script. Las opciones son equivalentes, pero la forma extendida suele ser más clara en la automatización compartida. Recuerda que los modificadores de cURL distinguen entre mayúsculas y minúsculas.

Un proxy SOCKS5 de cURL puede utilizar -x, y cURL también proporciona opciones dedicadas para SOCKS:

curl -x "socks4://proxy.example:1080" "https://target.example"
curl -x "socks5://proxy.example:1080" "https://target.example"
curl -x "socks5h://proxy.example:1080" "https://target.example"
curl --socks5 "proxy.example:1080" --proxy-user "USER:PASS" "https://target.example"

Para la resolución de nombres de host, socks5:// y --socks5 normalmente resuelven el nombre de destino de forma local, mientras que socks5h:// y --socks5-hostname solicitan al proxy que lo resuelva. SOCKS4a añade de forma similar la resolución de nombres de host por parte del proxy a SOCKS4. Esta distinción es importante cuando el DNS local no puede resolver el destino o cuando se desea que las consultas DNS sigan la ruta del proxy.

Consulta el manual oficial de la línea de comandos de cURL y compáralo con la versión que muestra curl --version antes de confiar en un comportamiento de SOCKS dependiente de la versión en un entorno de producción.

A la hora de decidir cómo configurar el proxy en cURL, elige el ámbito más restringido que se adapte a la tarea. Un indicador puntual es más fácil de auditar, mientras que las variables de entorno y los archivos de configuración reducen la repetición.

En macOS, Linux y otros shells de estilo POSIX, exporta las variables en minúsculas:

export http_proxy="http://USER:PASS@proxy.example:8080"
export https_proxy="http://USER:PASS@proxy.example:8080"

curl "https://target.example"

unset http_proxy
unset https_proxy

El nombre de la variable sigue el esquema de la URL de destino. Por lo tanto, https_proxy puede seguir conteniendo una http:// URL de proxy. Estas variables de entorno de proxy de cURL afectan al shell actual y a sus procesos hijos, no a todas las aplicaciones ni a todos los usuarios.

PowerShell y el Símbolo del sistema utilizan una sintaxis diferente para las variables de entorno. Mantén los nombres en minúsculas para garantizar la portabilidad y comprueba el uso de mayúsculas en la versión exacta del shell y de cURL que utilices. Las variables más generales, como ALL_PROXY y NO_PROXY requieren pruebas específicas para cada versión.

Un archivo de configuración de cURL aplica los valores predeterminados a cURL sin redirigir programas no relacionados. Las ubicaciones habituales para los usuarios son ~/.curlrc en Linux y macOS y _curlrc en %APPDATA% en Windows:

proxy = "http://USER:PASS@proxy.example:8080"

Trata el archivo como si fuera confidencial si contiene credenciales. En sistemas tipo Unix, utiliza chmod 600 ~/.curlrc; en Windows, limita su lista de control de acceso (ACL) a la cuenta prevista. Un --proxy puede sustituir al proxy configurado para un comando.

Las ubicaciones de búsqueda de la configuración y su orden de prioridad pueden variar según la compilación y el contexto de ejecución, por lo que conviene confirmarlas antes de confiar en un valor predeterminado oculto en la integración continua (CI).

<!-- Se necesita investigación adicional: verificar las mayúsculas y la coincidencia de ALL_PROXY/NO_PROXY, la búsqueda en el archivo de configuración y la prioridad completa de la configuración del proxy para las versiones de cURL y los sistemas operativos compatibles. -->

Para utilizar un proxy diferente para una solicitud, indícalo explícitamente:

curl --proxy "http://alternate-proxy.example:8080" "https://target.example"

Para forzar una conexión directa a pesar de las variables de entorno o de un archivo de configuración de cURL, utiliza la omisión de todos los hosts respaldada por el código fuente:

curl --noproxy "*" "https://target.example"

Es más seguro utilizar cURL con omisión de proxy que eliminar temporalmente la configuración, ya que podrías olvidarte de restaurarla. cURL también admite reglas de omisión selectivas mediante opciones de comando y ajustes de entorno, pero la coincidencia de nombres de host, dominios y direcciones puede ser sutil. Pruébalas con la versión de cURL utilizada en producción, en lugar de dar por sentado que el NO_PROXY se aplique en todas partes.

Una pasarela de proxies rotativos mantiene una única dirección de conexión mientras selecciona una IP de salida de un grupo para cada solicitud o según una política definida por el proveedor:

curl -x "http://USER:PASS@gateway.example:8000" "https://target.example/page/1"
curl -x "http://USER:PASS@gateway.example:8000" "https://target.example/page/2"

Esto facilita la automatización de un flujo de trabajo de cURL con proxy rotativo mediante scripts, ya que la rotación se produce detrás de la pasarela. No garantiza el acceso, no evita la limitación de ancho de banda ni hace que un rastreador agresivo sea aceptable. Sigue siendo necesario aplicar una concurrencia razonable, reintentos, control del ritmo de las solicitudes, sesiones estables cuando sea necesario y respetar las normas del destino. Para un análisis más profundo del diseño, «proxies rotativos para el scraping web» es un tema útil a tratar a continuación.

Cuando un proxy cURL no funcione, empieza por la solicitud fallida más pequeña y utiliza diagnósticos detallados:

curl --verbose --proxy "http://proxy.example:8080" "https://target.example"

Limpia la salida detallada antes de compartirla, ya que puede revelar nombres de host, encabezados o datos de autenticación. A continuación, trabaja por síntomas en lugar de cambiar varias opciones a la vez.

Compara las comprobaciones de IP directas y a través del proxy, y luego prueba con un destino al que se sepa que se puede acceder. curl -I "URL" Cabeceras de las solicitudes; unas cabeceras de respuesta HTTP más completas en el flujo de trabajo de cURL pueden revelar redireccionamientos, solicitudes de autenticación y metadatos de limitación de velocidad. Una referencia de errores de estado del proxy resulta útil cuando un intermediario devuelve su propia respuesta.

No realices un diagnóstico basándote únicamente en un código de estado o de salida. Pueden surgir síntomas similares en diferentes saltos. Consulta el manual instalado o el manual oficial de cURL para conocer el significado exacto de los códigos de salida y los indicadores de diagnóstico en tu compilación.

Nunca publiques nombres de usuario, contraseñas o tokens de proxy en producción. Utiliza marcadores de posición en los ejemplos, escribe los argumentos entre comillas y recuerda que el historial de comandos, la inspección de procesos, los registros de CI, los volcados de entorno y las copias de seguridad de la configuración pueden revelar información confidencial. --proxy-user mejora la legibilidad, no la confidencialidad. Opta por un gestor de secretos, una variable de tiempo de ejecución protegida o un indicador interactivo cuando tu flujo de trabajo lo permita.

Si una solicitud de cURL con proxy falla en la validación del certificado, corrige la cadena de confianza o proporciona el material correcto de la CA de confianza. El -k opción «or» --insecure opción desactiva la verificación del certificado, así que resérvala para diagnósticos breves y controlados. No debe convertirse en la solución habitual en producción. Con un proxy HTTPS, identifica qué conexión TLS ha fallado antes de elegir la solución, ya que el proxy y el destino son contextos de validación de certificados independientes.

Ejecuta curl --version primero; cada comando de cURL con proxy necesita un ejecutable que funcione. Windows suele proporcionar curl.exe, pero la disponibilidad y la resolución en PowerShell varían según la compilación y el perfil. Utiliza Get-Command curl y curl.exe --version; si no está, utiliza las descargas oficiales de cURL para Windows.

En macOS, instálalo con brew install curl. En Ubuntu o Debian, utiliza sudo apt install curl.

Utiliza esta referencia de comandos de cURL para proxies, sustituyendo cada marcador de posición en mayúsculas.

• Inicia cada comando cURL con una configuración de proxy comparando los resultados de la IP pública directa y la del proxy. Esto permite diferenciar los problemas de enrutamiento de los fallos específicos del destino.
• Trata la URL del proxy y la URL de destino como valores independientes. El esquema de cada una de ellas controla una decisión de conexión diferente.
• Utiliza --proxy para solicitudes aisladas, variables de entorno de shell para flujos de trabajo temporales y un archivo de configuración de cURL protegido para valores predeterminados estables a nivel de usuario.
• Elige socks5h:// cuando se requiera la resolución del nombre de host por parte del proxy y verifica el comportamiento con respecto a la versión de cURL implementada en producción.
• Analiza la autenticación, la conectividad, el DNS, el TLS y las respuestas de destino como etapas independientes. No realices -k una corrección permanente del certificado.

No. Un proxy HTTP puede transmitir una solicitud a un destino HTTPS. El esquema de URL del proxy describe cómo se conecta cURL al proxy, mientras que el esquema de destino describe el recurso solicitado. Elige un proxy HTTPS cuando necesites específicamente TLS en la conexión entre el cliente y el proxy, no simplemente porque la URL de destino comience por https://.

Sí. -x es la forma abreviada de --proxy, y ambas proporcionan la dirección del proxy para esa solicitud. La opción larga es más fácil de leer en scripts y en la configuración de CI, mientras que la opción corta resulta más práctica en la terminal. Las opciones distinguen entre mayúsculas y minúsculas, por lo que -x no debe sustituirse por una variante en mayúsculas.

Utiliza curl --noproxy "*" "https://target.example". El asterisco entre comillas indica a cURL que omita el uso del proxy para todos los destinos de ese comando, incluso cuando se haya configurado un proxy mediante variables de entorno o un archivo de configuración. Las comillas también evitan que el shell expanda * en nombres de archivos locales.

cURL suele leer .curlrc el directorio de inicio del usuario en Linux y macOS y _curlrc en una ubicación de configuración de usuario de Windows, como %APPDATA%. Las rutas de búsqueda exactas pueden variar según la compilación y el contexto de ejecución. Consulta el manual de la versión que tengas instalada y protege cualquier archivo que almacene credenciales de proxy.

La forma más fiable de utilizar cURL con un proxy es mantener la configuración explícita y probar cada capa de forma independiente. Empieza por curl --version, realiza una comprobación directa de la IP pública, repítela con --proxy, y solo entonces añade credenciales o persistencia. Mantén la URL del proxy separada del destino, elige el protocolo en función de cómo necesites conectarte al proxy y utiliza SOCKS5h cuando la resolución del nombre de host de destino deba realizarse en el lado del proxy.

Para un trabajo repetible, adapta el alcance de la configuración a la tarea. Los parámetros de comando son más seguros para operaciones puntuales, las variables de entorno se adaptan a flujos de trabajo temporales en el shell, y un archivo de configuración bloqueado puede eliminar la repetición de los valores predeterminados exclusivos de cURL. Cuando falle una solicitud, aísla la autenticación, la accesibilidad, el DNS, el TLS y las respuestas de destino en lugar de probar parámetros al azar. En particular, trata -k como una excepción de diagnóstico controlada, no como un valor predeterminado en producción.

Si un proceso de scraping dedica más tiempo de ingeniería a la rotación de proxies, los CAPTCHAs y las solicitudes bloqueadas que al análisis del HTML devuelto, WebScrapingAPI ofrece una API de scraper que se encarga de esos aspectos de la capa de solicitud y devuelve HTML sin procesar, con la facturación vinculada a la extracción satisfactoria. Ese es el siguiente paso práctico cuando una configuración de proxy cURL gestionada manualmente deja de ser la opción más ligera.