Configurar un Proxy en wget: Todas las Formas, Orden de Prioridad y el Problema con SOCKS5

wget busca el proxy en cuatro sitios, y cuando difieren elige uno sin avisar. Esta guía describe los cuatro, el orden en que se sobrescriben y lo que wget no puede hacer. Todo lo siguiente se ejecutó con wget 1.25.0 el 30 de septiembre de 2026 contra un proxy de prueba, así que los mensajes de error son reales.

Versión rápida

# un comando
https_proxy=http://login:password@proxy.example.com:10000 wget https://example.com/file.zip

# toda la sesión del shell
export http_proxy=http://login:password@proxy.example.com:10000
export https_proxy=http://login:password@proxy.example.com:10000
wget https://example.com/file.zip

Define ambas variables. http_proxy se usa para destinos http:// y https_proxy para destinos https://, y casi todo es HTTPS ahora. La dirección del proxy en sí comienza con http:// en ambos casos: ese es el protocolo con el que wget habla al proxy, no el protocolo del sitio.

Los cuatro sitios donde wget busca

1. Variables de entorno

El ejemplo de arriba. Los nombres en minúsculas son los que documenta wget y funcionan en cron jobs, contenedores y scripts porque el proceso completo las hereda.

2. El archivo .wgetrc

Para una máquina o usuario que siempre usa el mismo proxy, ponlo en ~/.wgetrc:

use_proxy = on
http_proxy = http://login:password@proxy.example.com:10000
https_proxy = http://login:password@proxy.example.com:10000

Cualquier archivo funciona si apuntas la variable WGETRC hacia él, que es como mantienes archivos de proxy separados para trabajos separados.

3. La opción -e en la línea de comandos

-e establece un comando de .wgetrc para una ejecución:

wget -e use_proxy=yes -e https_proxy=http://login:password@proxy.example.com:10000 https://example.com/file.zip

4. --proxy-user y --proxy-password

Estos proporcionan las credenciales separadas de la dirección:

https_proxy=http://proxy.example.com:10000 wget --proxy-user=login --proxy-password='p@ss#word' https://example.com/file.zip

Son la opción correcta cuando la contraseña contiene símbolos, por un motivo que se explica más adelante.

Qué sobrescribe a qué

Configuramos las cuatro fuentes para que difieran y observamos cuál obedecía wget:

Entonces un .wgetrc en la máquina silenciosamente vence al https_proxy que exportaste para un trabajo, y un flag --proxy-user silenciosamente reemplaza el login en la dirección. Cuando wget usa un proxy que no esperabas, estas dos reglas suelen ser la razón.

La trampa de los caracteres especiales

Nuestra contraseña de prueba era p@ss#word. Puesta en la dirección tal cual, wget nunca alcanzó el proxy:

Resolving ss... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address 'ss'

Leyó el primer @ como el final del login e intentó conectarse a un host llamado ss. Dos soluciones, ambas probadas:

# codifica en porcentaje la contraseña dentro de la dirección
https_proxy=http://login:p%40ss%23word@proxy.example.com:10000 wget https://example.com/

# o pásala por separado, sin codificación necesaria
https_proxy=http://proxy.example.com:10000 wget --proxy-user=login --proxy-password='p@ss#word' https://example.com/

@ se convierte en %40, # se convierte en %23, : se convierte en %3A, / se convierte en %2F y % mismo se convierte en %25.

Evitar el proxy

Tres formas, todas probadas con un proxy en el entorno que habría rechazado la solicitud:

# este comando va directo
wget --no-proxy https://example.com/

# estos hosts siempre van directo
export no_proxy=example.com,internal.company.net
wget https://example.com/

# desactiva el proxy en .wgetrc o con -e
wget -e use_proxy=no https://example.com/

no_proxy es una lista separada por comas de nombres de host o sufijos de dominio. Es la que se usa para servicios internos que no deben salir por el proxy.

SOCKS5: lo que wget no puede hacer

wget solo habla con proxies HTTP. Dale una dirección SOCKS y se detiene inmediatamente:

Error parsing proxy URL socks5://127.0.0.1:1080: Unsupported scheme.

socks5h:// obtiene la misma respuesta. Las guías que muestran una línea socks en .wgetrc están describiendo una característica que no existe. Tienes tres salidas.

Usa el puerto HTTP del proxy. La mayoría de los proxies de pago hablan ambos protocolos. Los nuestros responden HTTP y SOCKS5 en el mismo puerto residencial, y en puertos separados para direcciones estáticas, así que la solución es escribir http:// en lugar de socks5://.

Usa curl en su lugar. curl soporta SOCKS5 nativamente:

curl -x socks5h://login:password@proxy.example.com:1080 -O https://example.com/file.zip

Envuelve wget en proxychains4 cuando tiene que ser wget, por ejemplo dentro de un script que no puedes cambiar. Lo ejecutamos a través de un servidor SOCKS5 con un nombre de usuario y contraseña, y funcionó:

sudo apt install -y proxychains4

cat > socks.conf <<'EOF'
strict_chain
proxy_dns
[ProxyList]
socks5 proxy.example.com 1080 login password
EOF
proxychains4 -q -f socks.conf wget https://example.com/file.zip
proxy_dns hace que los nombres de host se resuelvan a través del proxy, que es lo que necesitas por las razones explicadas en qué es un proxy DNS.
La conexión al proxy no va cifrada
Una limitación más. Si pones la dirección del proxy como https://, wget no abre una conexión TLS hacia el proxy. En nuestras pruebas se conectó en texto plano y envió su petición exactamente igual que lo habría hecho con un proxy http://. Así que las credenciales del proxy viajan sin cifrar entre tu equipo y el proxy, independientemente del esquema que escribas. En redes que no controlas, es un motivo para preferir el filtrado por dirección IP cuando el proveedor lo ofrezca, o para usar un cliente que sí soporte conexiones cifradas al proxy, como hace curl.
Interpretar los errores de wget
wget dice
Qué ocurrió
Proxy tunneling failed: Proxy Authentication Required seguido de Unable to establish SSL connection.
El proxy devolvió 407: login incorrecto, contraseña incorrecta o ninguno enviado. La guía del 407 tiene el checklist
unable to resolve host address 'ss' o similar
Un símbolo en la contraseña rompió la dirección. Codifícala o usa --proxy-user
Error parsing proxy URL ...: Unsupported scheme.
Una dirección SOCKS. wget no puede usarla
Connecting to 127.0.0.1:18499... failed: Connection refused.
Puerto incorrecto o el proxy está caído
La descarga funciona pero desde el lugar equivocado
Otra fuente está reemplazando la tuya. Revisa .wgetrc y -e
Descarga masiva educada a través de un proxy
El parámetro que más importa cuando wget recupera muchas páginas no es el proxy, es el ritmo:
export https_proxy=http://login_c_US_s_7_ttl_1h:password@proxy.sotaproxy.com:10000

wget --mirror --no-parent --wait=2 --random-wait --limit-rate=500k \
     --user-agent="my-mirror/1.0 (+mailto:you@example.com)" \
     https://example.com/docs/
--wait y --random-wait espacian las peticiones, --limit-rate limita el ancho de banda, y wget respeta robots.txt en descargas recursivas por defecto. El sufijo de sesión en el login mantiene cada petición del espejo sobre una misma dirección de salida durante una hora, de manera que el sitio ve un único visitante en lugar de una multitud. La sintaxis de sufijos está en la referencia de cadenas de conexión.
FAQ
¿Cómo hago que wget use un proxy?
Define http_proxy y https_proxy en el entorno como http://login:password@host:port, o pon las mismas líneas en ~/.wgetrc con use_proxy = on.
¿Cómo hago que wget ignore el proxy?
wget --no-proxy para un comando puntual, no_proxy=host1,host2 en el entorno para hosts específicos, o -e use_proxy=no.
¿Soporta wget SOCKS5?
No. Rechaza la dirección con "Unsupported scheme". Usa el puerto HTTP del proxy, usa curl, o envuelve wget en proxychains4.
¿Por qué wget dice "unable to resolve host address" cuando configuro un proxy?
Un símbolo en la contraseña, normalmente @, cortó la dirección en el lugar equivocado. Codifica la contraseña en porcentaje o pásala con --proxy-user y --proxy-password.
¿Qué tiene prioridad, la variable de entorno o .wgetrc?
.wgetrc. Y -e en la línea de comandos gana a ambos.