Proxy con wget: comandos y ejemplos

Publicado:

12 min de lectura

Acar Diveroli
Autor: Acar Diveroli
Descarga a través de un proxy en una ventana de terminal

wget es una herramienta de línea de comandos, incluida de serie en la mayoría de los sistemas Linux y macOS, que se usa para descargar archivos y obtener páginas web. Se elige a menudo para descargar un archivo desde un script en un servidor, para hacer un espejo de un sitio o para una prueba de acceso sencilla. En este artículo explicamos, con comandos de ejemplo, las tres formas de ejecutar wget a través de un proxy, la autenticación, los detalles de HTTPS, lo que hay que tener en cuenta en las descargas masivas y los errores más frecuentes.

Todas las opciones descritas están documentadas en el manual de GNU Wget.

Antes de empezar: ¿tienes wget instalado?

Comprueba la versión en la terminal:

bash
wget --version

Si no se encuentra el comando, puedes usar sudo apt install wget en Debian y Ubuntu, o brew install wget con Homebrew en macOS. wget no viene integrado en Windows; para las mismas tareas puedes usar curl.exe, incluido de serie desde Windows 10. La escritura wget en PowerShell no es el wget real: es un alias del comando Invoke-WebRequest y no acepta las opciones de este artículo.

Usar una dirección de prueba que devuelva tu IP facilita las pruebas. Si el proxy funciona, esa dirección muestra la IP del proxy, no la tuya:

bash
wget -qO- https://httpbin.org/ip

Aquí -q silencia la salida y -O- imprime el contenido descargado en pantalla en lugar de escribirlo en un archivo. Ejecútalo una vez antes de definir el proxy y anota tu propia IP; en las siguientes pruebas verás la diferencia de inmediato.

El formato de la dirección del proxy

En los tres métodos, el proxy se escribe de la misma forma:

text
http://kullanici:parola@sunucu:port
  • El esquema http:// es el protocolo de la conexión que se establece con el proxy. Este esquema se usa también al acceder a sitios HTTPS; explicamos el porqué más abajo.
  • La parte kullanici:parola@ es opcional. Si autorizaste la IP de tu servidor desde el panel del proxy, puedes omitir esta parte por completo.
  • La información sunucu:port varía según tu plan; puedes encontrar los valores correctos en tu panel de cliente.

Método 1: con variables de entorno

wget lee las variables de entorno estándar de proxy del sistema: http_proxy, https_proxy, ftp_proxy y no_proxy. Este es el método más rápido, y muchas otras herramientas que corren en la misma terminal también usan estas variables.

bash
export http_proxy="http://kullanici:parola@pr.proxynet.io:8000"
export https_proxy="http://kullanici:parola@pr.proxynet.io:8000"

wget -qO- https://httpbin.org/ip

Hay tres puntos a tener en cuenta:

  • El valor de https_proxy también empieza con http://. Esta variable indica el proxy que se usará al ir a sitios HTTPS; la conexión que se establece con el propio proxy es HTTP, y el tráfico HTTPS se tuneliza dentro de esa conexión.
  • Las variables solo son válidas en esa sesión de terminal. Si quieres que sean permanentes, añádelas a ~/.bashrc o ~/.zshrc.
  • Prefiere las minúsculas. wget lee las variables en minúscula; en algunos sistemas también puede estar definida la versión en mayúscula HTTP_PROXY, y si las dos definiciones no coinciden, genera confusión. Lo más seguro es ajustar ambas al mismo valor.

Si quieres que ciertas direcciones no pasen por el proxy, usa no_proxy:

bash
export no_proxy="localhost,127.0.0.1,.sirketiniz.local"

Esta variable evita que los servicios de la red interna o los servidores de desarrollo locales pasen por el proxy. Un nombre de dominio que empieza con un punto cubre todos los subdominios de ese dominio.

Método 2: en la línea de comandos, de forma puntual

Para hacer pasar por el proxy un único comando, sin modificar las variables de entorno, puedes pasar la configuración de wget directamente al comando con la opción -e (--execute):

bash
wget -e use_proxy=yes \
     -e https_proxy=http://pr.proxynet.io:8000 \
     --proxy-user=kullanici \
     --proxy-password=parola \
     https://httpbin.org/ip -O -

Este método es especialmente útil en scripts: la configuración del proxy no afecta a otros comandos y puedes dar un proxy distinto en cada llamada. Por ejemplo, si en un bucle quieres hacer cada descarga desde un punto de salida diferente, tomarías el valor de -e https_proxy= de la variable del bucle.

Cada línea dada con -e es un ajuste que también se puede escribir en un archivo .wgetrc. Es decir, cada clave que verás en el siguiente método también es válida aquí.

Método 3: con un archivo .wgetrc, de forma permanente

Si usas wget con proxy de forma continua en la misma máquina, puedes escribir la configuración en un archivo ~/.wgetrc de tu directorio de usuario:

ini
use_proxy = on
http_proxy = http://pr.proxynet.io:8000
https_proxy = http://pr.proxynet.io:8000
proxy_user = kullanici
proxy_password = parola

Como el archivo contiene una contraseña, restringe los permisos para que solo tú puedas leerlo:

bash
chmod 600 ~/.wgetrc

Si hace falta un ajuste a nivel de todo el sistema, las mismas líneas se pueden escribir en /etc/wgetrc; el archivo del directorio de usuario tiene prioridad sobre los valores del archivo del sistema.

Si quieres desactivar temporalmente el proxy mientras este archivo está definido, añade la opción --no-proxy para un único comando:

bash
wget --no-proxy https://httpbin.org/ip -O -

¿Qué método elegir?

SituaciónMétodo recomendado
Prueba rápida en la terminalVariable de entorno
En un script, proxy distinto en cada llamadaLínea de comandos con -e
Uso continuo de proxy en un servidor.wgetrc
Mantener ciertas direcciones fuera del proxyno_proxy
Descarga programada con cron.wgetrc (cron no propaga las variables de entorno)
Dentro de un contenedor DockerVariable de entorno (con ENV)

Si los tres métodos están definidos a la vez, el orden de prioridad es: las opciones de la línea de comandos tienen prioridad sobre las variables de entorno, y las variables de entorno tienen prioridad sobre el archivo .wgetrc.

¿Cómo funciona el proxy en sitios HTTPS?

Al acceder a una dirección HTTPS a través de un proxy, wget envía primero una petición CONNECT hedef:443 al proxy. El proxy abre una conexión TCP con el destino y, a partir de ahí, solo transfiere bytes cifrados. Es decir, el proxy no puede ver el contenido del sitio; solo sabe a qué nombre de dominio te conectas.

El resultado práctico es este: puedes acceder con seguridad a sitios HTTPS aunque la dirección del proxy empiece con http://. La verificación del certificado se hace entre tu equipo y el sitio de destino; el proxy no interviene en esa verificación. Comparamos este comportamiento del proxy y su diferencia con SOCKS en nuestro artículo Diferencia entre SOCKS y HTTP.

Combinado con opciones habituales

La configuración del proxy por sí sola rara vez basta; en el trabajo real suelen hacer falta algunas opciones más. El siguiente ejemplo descarga un archivo a través del proxy con ajustes de reintento y tiempo de espera:

bash
wget --timeout=30 --tries=3 --waitretry=5 \
     --user-agent="Mozilla/5.0 (X11; Linux x86_64)" \
     -O rapor.pdf https://example.com/rapor.pdf
  • --timeout limita el tiempo de espera de cada operación de red.
  • --tries determina cuántas veces se reintenta una descarga fallida; --waitretry añade una espera entre intentos.
  • --user-agent cambia la identidad del navegador. La identidad predeterminada de wget se bloquea directamente en algunos sitios; usar un valor identificable es más transparente y da menos problemas.
  • -O asigna el nombre del archivo de salida; si añades -c, la descarga incompleta continúa desde donde se quedó.

Si hacen falta cookies al obtener una página, las opciones --load-cookies y --save-cookies mantienen la sesión en un archivo; así es como puedes conservar una sesión iniciada junto con el proxy.

¿wget admite proxy SOCKS?

GNU wget no tiene soporte de SOCKS integrado; todos los métodos anteriores son para proxy HTTP y HTTPS. Si necesitas usar SOCKS5, tienes dos opciones:

  • Usar cURL. cURL admite directamente los esquemas socks5:// y socks5h:// y hace casi todo lo que hace wget. Los detalles están en nuestro artículo Cómo usar un proxy con cURL.
  • Usar una herramienta de enrutamiento. En Linux, herramientas como proxychains pueden enrutar hacia un proxy SOCKS las conexiones de programas sin soporte de SOCKS. En Windows, Proxifier hace el mismo trabajo.

Para paquetes que funcionan directamente con wget, puedes consultar la página de Proxies HTTPS.

Errores comunes y sus soluciones

"407 Proxy Authentication Required"

Faltan las credenciales del proxy o son incorrectas. Comprueba el usuario y la contraseña. Si la contraseña tiene caracteres especiales como @, : o #, escríbelos en la dirección con codificación porcentual (%40 para @), o usa las opciones --proxy-user y --proxy-password, que no requieren codificación.

El comando no usa el proxy en absoluto

  • Asegúrate de haber definido la variable con export; escribir solo http_proxy=... no la propaga a los procesos hijos.
  • Si vas a una dirección HTTPS, tiene que estar definida la variable https_proxy, no http_proxy.
  • Comprueba si hay una línea use_proxy = off en .wgetrc.
  • Si ejecutas sudo wget, sudo puede no propagar tus variables de entorno por defecto; propágalas con sudo -E o escribe el ajuste en /etc/wgetrc.
  • La dirección de destino puede coincidir con un dominio de la lista no_proxy.

"Unable to establish SSL connection"

Primero comprueba si la dirección de destino se abre sin el proxy. Si el problema es el certificado, la opción --no-check-certificate omite la verificación; pero esta opción debilita la seguridad de la conexión y solo debería usarse con fines de prueba. Recuerda que el proxy no interviene en la verificación del certificado: este error suele deberse a que el almacén de certificados raíz del sistema está desactualizado o a la configuración del sitio de destino.

La conexión se agota por tiempo de espera

Vuelve a comprobar la dirección y el puerto del proxy. Asegúrate de que el cortafuegos permite el tráfico hacia el puerto del proxy. En descargas largas, fijar explícitamente el tiempo de espera y el número de reintentos evita que los scripts se queden bloqueados:

bash
wget --timeout=30 --tries=3 https://httpbin.org/ip -O -

"ERROR 403: Forbidden"

El sitio de destino rechaza la petición. La causa puede no ser el proxy; el valor predeterminado de User-Agent de wget se bloquea directamente en algunos sitios. Da un valor identificable con --user-agent. Si el problema continúa, el sitio de destino puede estar comportándose según el tipo de IP del proxy; explicamos por qué se rechazan más a menudo las direcciones de centro de datos en nuestro artículo Diferencia entre proxies residenciales y de centro de datos.

Qué tener en cuenta en las descargas masivas

La opción -r de wget (descarga recursiva) puede obtener un sitio entero con un solo comando. Ese poder puede imponer una carga considerable sobre el servidor de destino. En las descargas masivas, las siguientes opciones benefician tanto a ti como al destino:

bash
wget -r -l 2 --wait=2 --random-wait --limit-rate=500k \
     --no-parent -A pdf https://example.com/belgeler/
  • -l 2 limita la profundidad a dos niveles; una profundidad ilimitada descarga el sitio entero.
  • --wait=2 pone dos segundos entre peticiones, --random-wait varía ese tiempo de forma aleatoria.
  • --limit-rate=500k limita la velocidad de descarga.
  • --no-parent impide subir a directorios superiores, -A pdf obtiene solo las extensiones indicadas.

wget respeta por defecto las reglas de robots.txt; no desactives ese comportamiento. Explicamos qué datos se pueden recopilar y en qué condiciones en nuestro artículo ¿Es legal el web scraping?.

En proyectos que necesitan muchas peticiones, distribuir las direcciones con Proxies rotativos en lugar de concentrar el tráfico en una sola IP reduce el riesgo de bloqueo y reparte la carga de forma más equilibrada sobre el sitio de destino. Para necesidades más amplias, puedes consultar nuestras soluciones de extracción de datos.

Preguntas frecuentes

¿wget o cURL?

Para descargar archivos, hacer espejos y descargas recursivas, wget es más práctico; para peticiones de API, métodos HTTP personalizados y proxy SOCKS, cURL es más capaz. Los dos leen el proxy HTTP de las mismas variables de entorno, así que una configuración definida una vez funciona en ambas herramientas.

¿La configuración del proxy afecta a otros programas?

El proxy definido con una variable de entorno afecta a todos los programas iniciados desde la misma shell que leen esas variables (por ejemplo, cURL, pip, git). Los métodos .wgetrc y -e solo afectan a wget.

¿Puedo usar el proxy sin guardar mi contraseña?

Sí. Si autorizas la IP de tu servidor desde el panel de tu proveedor de proxy, no hacen falta usuario y contraseña; la dirección se escribe simplemente como http://sunucu:port. Este es el método más limpio para servidores con IP fija.

¿Puedo obtener una IP distinta en cada petición con wget?

wget en sí no hace rotación. Hay dos caminos: usar un proxy rotativo (una sola dirección, una IP de salida distinta en cada conexión) o dar en un script un proxy diferente a cada llamada con -e https_proxy=.

¿Puedo descargar por FTP a través de un proxy?

Si la variable ftp_proxy está definida, wget obtiene las direcciones FTP a través del proxy HTTP; el proxy tiene que admitir este uso. Como hoy en día las fuentes FTP han disminuido, la mayoría de los paquetes de proxy se centran en HTTP y HTTPS.

En resumen

Hay tres formas de usar wget con un proxy: variables de entorno para pruebas rápidas, la opción -e para un uso puntual en scripts y un archivo .wgetrc para uso continuo. No olvides definir https_proxy para direcciones HTTPS, guardar las credenciales de forma segura, limitar la velocidad en las descargas masivas y pasar a cURL cuando necesites SOCKS.