Cómo usar Wget con un proxy (y evitar los errores más comunes)

Configurar un proxy en Wget parece una tarea de cinco segundos… hasta que te pasas una hora intentando descubrir por qué tus solicitudes se están saltando el proxy por completo, sin mostrar ni un solo mensaje de error. He visto esto tanto en administradores de sistemas veteranos como en desarrolladores junior.

La causa de raíz casi nunca es el proxy en sí. El problema suele estar en los cuatro sitios distintos desde los que Wget puede leer la configuración del proxy, en los fallos silenciosos cuando usas mayúsculas y minúsculas incorrectas en una variable, y en esos detalles de redes corporativas que ningún manual se molesta en explicar. Esta guía cubre todos los métodos para configurar Wget con un proxy, las reglas exactas de prioridad cuando varios métodos entran en conflicto, salidas reales de terminal para los errores más comunes, y una sección dedicada a usuarios de Windows y de redes corporativas — justo el público que casi todos los demás tutoriales fingen que no existe.

Dificultad: De principiante a intermedio
Tiempo necesario: ~15 minutos para leer y configurar; ~2 minutos cuando ya le pillas el truco
Qué necesitas: Una instalación funcional de Wget (instrucciones abajo), una dirección de proxy (host + puerto) y, opcionalmente, credenciales del proxy

Prueba Thunderbit para extraer datos estructurados

Qué es Wget y por qué usarlo con un proxy

Wget es una herramienta de línea de comandos que descarga archivos y páginas web de Internet sin necesidad de navegador. La propia documentación de GNU lo define como un "descargador de red no interactivo"; o sea, puede ejecutarse en segundo plano, reanudar transferencias interrumpidas y gestionar descargas recursivas sin que nadie tenga que hacer clic en nada.

En este contexto, un proxy actúa como intermediario. En lugar de que tu equipo se conecte directamente al sitio de destino, Wget envía la solicitud al proxy y este la reenvía. Las razones más habituales para hacerlo son:

Cumplimiento de firewall corporativo — tu empresa exige que todo el tráfico saliente pase por un proxy autorizado
Privacidad y gestión de IP — las solicitudes aparecen desde la IP del proxy, no desde la tuya
Pruebas geográficas — acceder a recursos bloqueados por región o comprobar el comportamiento de una CDN desde una ubicación concreta
Canales de recopilación de datos — descargar HTML mediante proxies rotativos para investigación o monitorización
Entornos CI/CD — runners de compilación en redes restringidas que solo pueden salir a Internet a través de un proxy

Wget admite de forma nativa proxies HTTP, HTTPS y FTP. No soporta SOCKS5. Si necesitas SOCKS5, curl ofrece soporte nativo para los esquemas socks4://, socks5:// y socks5h://, o puedes envolver Wget con una herramienta como proxychains4.

Cómo instalar Wget en Linux, macOS y Windows

Antes de configurar el proxy, necesitas tener Wget instalado. Esta parte es rápida: es un requisito previo, no el plato fuerte.

Linux (Debian/Ubuntu y RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Verificar
wget --version

Ubuntu 24.04 LTS incluye Wget 1.21.4, mientras que Debian Trixie trae 1.25.0. Los paquetes de CentOS Stream 10 muestran 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

La fórmula de Homebrew ofrece actualmente Wget 1.25.0 estable, con 396,818 instalaciones durante el último año.

Windows (Chocolatey e instalación manual)

choco install wget
wget --version

El paquete GNU Wget de Chocolatey supera los 10 millones de descargas totales, aunque actualmente está en la versión 1.21.4. El binario suele ubicarse en C:\ProgramData\chocolatey\bin\wget.exe.

Un aviso para usuarios de Windows: la ubicación donde Wget busca .wgetrc varía según la compilación. Más detalles en la sección de Windows más abajo.

4 formas de usar Wget con un proxy (y cuál elegir)

Cuatro métodos, cada uno con un alcance y un nivel de prioridad distinto:

Opciones de línea de comandos -e — para un uso puntual, un solo comando
Archivo de configuración de usuario (~/.wgetrc) — se aplica a cada comando Wget que ejecutes
Archivo de configuración del sistema (/etc/wgetrc) — afecta a todos los usuarios de la máquina
Variables de entorno (http_proxy, https_proxy) — aplican a toda la sesión de shell

Método 1: flags de línea de comandos (proxy puntual)

Ideal para pruebas rápidas. La configuración desaparece al terminar el comando.

wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip

Para destinos HTTPS:

wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/

Prueba rápida — consulta tu IP aparente a través del proxy:

wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me

Si la salida muestra la IP del proxy en lugar de la tuya, vas por buen camino.

Método 2: archivo de configuración de usuario (~/.wgetrc)

Añade estas líneas a ~/.wgetrc (créalo si no existe):

use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com

Fíjate en los espacios alrededor de =: esa es la sintaxis documentada de .wgetrc. A partir de ahora, todos los comandos Wget que ejecutes con ese usuario pasarán por el proxy.

Método 3: configuración global (/etc/wgetrc)

Usa las mismas directivas que ~/.wgetrc, pero colocadas en el archivo de configuración del sistema. GNU lo documenta como un archivo global de inicio; la ruta exacta depende del prefijo de instalación. Ubicaciones habituales:

/etc/wgetrc (la mayoría de gestores de paquetes Linux)
/usr/local/etc/wgetrc (algunas compilaciones de Homebrew)
La ruta mostrada por wget --version bajo "Wgetrc:"

Esto viene genial para servidores compartidos, contenedores Docker o cualquier entorno donde todos los usuarios deban salir por el mismo proxy.

Método 4: variables de entorno (http_proxy / https_proxy)

export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com

Estas afectan a toda tu sesión de shell, no solo a Wget. Herramientas como curl también las detectan.

Advertencia crítica: Wget solo lee nombres de variables de entorno en minúsculas. HTTP_PROXY (en mayúsculas) se ignora sin avisar. Sin error, sin advertencia, nada. Más abajo te muestro la salida exacta en la sección de errores comunes, pero conviene grabarlo en la memoria desde ya.

Prioridad de los métodos de proxy: qué prevalece cuando hay varios configurados

Si tienes un proxy configurado en las variables de entorno y en .wgetrc y en la línea de comandos, ¿cuál manda? Nadie lo explica con claridad, así que lo probé.

Esta es la prioridad probada y documentada:

Prioridad	Método	Alcance	Sobrescribe
1 (más alta)	Flags CLI `-e`	Un solo comando	Todo
2	`~/.wgetrc`	Usuario actual	Configuración del sistema + variables de entorno
3	`/etc/wgetrc`	Todo el sistema	Solo variables de entorno
4 (más baja)	Variables de entorno `http_proxy` / `https_proxy`	Sesión de shell	Nada

Lo comprobé en Wget 1.25.0 configurando proxies en conflicto en cada nivel. Con el entorno apuntando al puerto 3128, el archivo de configuración al 3129 y la CLI al 3130:

La configuración gana a las variables de entorno: Wget se conectó al puerto 3129, ignorando 3128.
La CLI gana a la configuración: Wget se conectó al puerto 3130, ignorando tanto 3129 como 3128.

La salida de emergencia es --no-proxy. Omite cualquier configuración de proxy, sin importar de dónde venga:

wget --no-proxy https://internal-server.company.com/report.pdf

Caso práctico: tu administrador del sistema dejó un proxy en /etc/wgetrc, pero tú necesitas acceder directamente a un servidor interno. Usa --no-proxy para ese comando concreto en lugar de editar la configuración del sistema.

Cómo usar Wget con un proxy autenticado

La mayoría de los proxies empresariales y residenciales requieren nombre de usuario y contraseña. Wget lo admite mediante dos enfoques, ambos usando autenticación HTTP Basic para las credenciales del proxy.

Credenciales embebidas en la URL del proxy

wget -e use_proxy=on \
  -e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
  http://example.com/file.zip

Esto también funciona en .wgetrc:

http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/

Usar los flags --proxy-user y --proxy-password

wget --proxy-user=USERNAME --proxy-password=PASSWORD \
  -e use_proxy=on \
  -e http_proxy=http://proxy.company.com:8080/ \
  http://example.com/file.zip

Estos flags sobrescriben cualquier user:pass@ incrustado en la URL del proxy.

Cómo mantener seguras las credenciales

Ambos métodos exponen credenciales. GNU advierte que las contraseñas en la línea de comandos pueden verse con ps u otras herramientas de lista de procesos. Medidas de mitigación:

Máquinas de un solo usuario: guarda las credenciales en ~/.wgetrc y protege el archivo: chmod 600 ~/.wgetrc
Pipelines CI/CD: usa secrets cifrados de GitHub Actions o el equivalente de tu plataforma. Pásalos como variables de entorno en minúsculas en la definición del paso; nunca los escribas a mano en YAML.
Construcciones Docker: no uses ARG ni ENV para secretos. La documentación de Docker lo advierte explícitamente: los argumentos de compilación pueden persistir en la imagen final. Usa montajes de secretos de BuildKit.
Control de versiones: nunca hagas commit de .wgetrc con credenciales. Añádelo a .gitignore.

Un matiz específico de Wget en GitHub Actions: por convención, los nombres de los secretos se guardan en mayúsculas, pero las variables de entorno que expones a Wget deben ir en minúsculas (http_proxy, no HTTP_PROXY).

Cómo usar Wget con un proxy en Windows y detrás de firewalls corporativos

La mayoría de los artículos sobre este tema se quedan en "instálalo con Chocolatey". Si estás en Windows o detrás de un proxy corporativo, ahí es donde tus problemas empiezan.

Dónde busca Windows el archivo .wgetrc

La documentación de GNU dice que Wget lee $HOME/.wgetrc salvo que la variable de entorno WGETRC apunte a otra ubicación. En Windows, $HOME puede mapear a %USERPROFILE% (por ejemplo, C:\Users\alice) o no, dependiendo de si usas la compilación de Chocolatey, una compilación de MSYS2, Git Bash o un binario independiente.

Mi recomendación: evita adivinar y usa el flag --config para un comportamiento determinista:

wget --config=C:\Users\alice\wgetrc https://example.com/file.zip

Para comprobar si tu compilación lee un archivo de configuración desde una ubicación concreta, crea un archivo de prueba que apunte a un proxy incorrecto a propósito:

; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/

Luego ejecuta:

wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/

Si Wget intenta conectarse a 127.0.0.1:3128, entonces sí leyó el archivo.

Cómo configurar variables de entorno del proxy en Windows

CMD (solo para la sesión actual):

set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/

PowerShell (solo para la sesión actual):

$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/

Permanente (se mantiene tras reiniciar):

setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/

Después de setx, tienes que abrir una nueva ventana de terminal. La sesión actual no verá el cambio.

Trampas comunes de proxy corporativo: archivos PAC, autenticación NTLM y cómo encontrar tu proxy

Tres cosas que suelen hacer tropezar a los usuarios corporativos:

Archivos PAC: muchas empresas usan archivos de Proxy Auto-Configuration (PAC), scripts basados en JavaScript que le dicen al navegador qué proxy usar para cada URL. Wget no tiene intérprete de JavaScript, así que no puede leer archivos PAC. La documentación de curl dice lo mismo. La solución: abre el archivo PAC (o pregunta a IT), localiza el resultado PROXY host:port para tu dominio objetivo y configura esa dirección estática en Wget.

Autenticación NTLM: la autenticación de proxy de Wget solo implementa Basic auth. Si tu proxy corporativo requiere NTLM y te aparece 407 Proxy Authentication Required, no pierdas tiempo probando distintas sintaxis de --proxy-user. Instala Cntlm, un relé local que maneja autenticación NTLM/NTLMv2 y expone una interfaz de Basic auth para Wget. Cntlm sigue mantenido (última actualización en octubre de 2025, unas ~395 descargas por semana).

Árbol de decisión para usuarios de proxy corporativo:

Prueba set http_proxy=http://TU_PROXY:PUERTO/ y ejecuta Wget.
Si recibes un error 407 y tu empresa usa NTLM → instala Cntlm, configúralo con tus credenciales de dominio y apunta Wget al puerto local de Cntlm (normalmente http://127.0.0.1:3128/).
Si la empresa usa un archivo PAC → extrae el PROXY host:port real del PAC o pide a IT la dirección estática del proxy.

Puertos corporativos comunes para proxy: 3128 (estilo Squid), 8080 (proxy HTTP general), 8888 (proxies de depuración como Fiddler/Charles). Son convenciones, no garantías.

Errores comunes al usar Wget con un proxy (con salida real de errores)

Y ahora, la parte buena prometida en el título. Toda la salida de abajo se reprodujo en Wget 1.25.0 (macOS, Homebrew) el 2026-06-01.

Error 1: Falta el prefijo http://

Algunas guías antiguas afirman que esto siempre falla. En Wget 1.25.0, configurar http_proxy=127.0.0.1:3128 en realidad funciona: Wget añade http:// en silencio:

Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.

Aun así, se conectó al proxy correcto. Pero te recomiendo incluir siempre el prefijo http:// y una barra final. Evita ambigüedades entre versiones de Wget y hace que la sintaxis con credenciales (http://user:pass@host:port/) sea inequívoca.

Error 2: use_proxy=yes vs. use_proxy=on

En mis pruebas con Wget 1.25.0, tanto yes como on funcionaron. Pero los valores inválidos fallan con un mensaje claro:

wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.

Usa on para lograr la máxima compatibilidad: coincide con el formato booleano documentado en el manual y con la propia sugerencia de error de Wget.

Error 3: HTTP_PROXY en mayúsculas se ignora sin avisar

Este es el más frustrante porque no aparece ningún error. Wget simplemente se conecta directamente, como si no hubieras configurado ningún proxy.

En mayúsculas (fallo: no se usa proxy):

HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06--  http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK

En minúsculas (funciona: intenta usar proxy):

http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

¿Ves la diferencia? La versión en mayúsculas resolvió example.com directamente. La versión en minúsculas intentó usar el proxy. Sin advertencias en ninguno de los dos casos. curl tiene una rareza parecida: acepta mayúsculas para la mayoría de variables de proxy, pero rechaza explícitamente HTTP_PROXY en mayúsculas por motivos de seguridad.

Solución: usa siempre http_proxy y https_proxy en minúsculas.

Error 4: un proxy obsoleto en .wgetrc provoca "Connection refused"

Si tú (o tu administrador, o una imagen Docker) dejaste una dirección de proxy antigua en un archivo de configuración, verás algo como esto:

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

El error señala la IP del proxy antiguo, no el sitio de destino. Orden de diagnóstico (siguiendo la jerarquía de prioridad):

Revisa tu comando en busca de flags -e o alias de shell
Revisa ~/.wgetrc (o el archivo indicado por WGETRC)
Revisa la configuración del sistema (la ruta que muestra wget --version)
Revisa el entorno: env | grep -i proxy

Para depurar, --no-config es tu mejor aliado: le dice a Wget que omita todos los archivos de configuración:

wget --no-config --spider http://example.com/

Si eso funciona, el problema está en un archivo de configuración.

Error 5: confusión con la sintaxis del proxy HTTPS

Esto hace tropezar a mucha gente. Cuando defines https_proxy, la URL del proxy suele ser http://, no https://. Esto se debe a que Wget envía una solicitud HTTP CONNECT a través del proxy para crear un túnel para la sesión HTTPS cifrada.

Correcto:

https_proxy=http://proxy.company.com:8080/
wget https://example.com/

Wget envía CONNECT example.com:443 HTTP/1.1 al proxy y luego canaliza HTTPS a través de él.

Incorrecto (para URLs de destino HTTP con un endpoint de proxy HTTPS):

http_proxy=https://127.0.0.1:18082/
wget http://example.com/

Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.

Wget 1.25.0 rechaza directamente https:// como URL de proxy para destinos HTTP. Usa https_proxy=http://HOST:PORT/ salvo que tu organización haya documentado específicamente un endpoint de proxy HTTPS y lo hayas probado con tu compilación de Wget.

Hoja rápida de comandos de proxy para Wget

Guarda esta tabla. Reúne en un solo lugar todos los flags y directivas de configuración relacionados con proxy en Wget.

Flag / Directiva	Contexto	Ejemplo	Notas
`-e use_proxy=on`	CLI	`-e use_proxy=on`	`on` es la opción más segura; algunas compilaciones también aceptan `yes`
`-e http_proxy=`	CLI	`-e http_proxy=http://proxy:8080/`	Incluye el prefijo `http://` y la barra final `/`
`-e https_proxy=`	CLI	`-e https_proxy=http://proxy:8080/`	La URL del proxy suele ser `http://` incluso para destinos HTTPS
`--proxy-user`	CLI	`--proxy-user=admin`	Sobrescribe `user:pass@` embebido
`--proxy-password`	CLI	`--proxy-password=secret`	Visible en `ps` — evita usarlo en sistemas compartidos
`--no-proxy`	CLI	`--no-proxy`	Omite TODAS las configuraciones de proxy de cualquier fuente
`--no-config`	CLI	`--no-config`	Omite todos los archivos de configuración — útil para depurar
`--config=FILE`	CLI	`--config=/tmp/wgetrc`	Ruta de config determinista — ideal para Windows y CI
`http_proxy`	`.wgetrc` / env	`http_proxy = http://proxy:8080/`	El archivo de configuración usa espacios alrededor de `=`; la variable de entorno va en minúsculas
`https_proxy`	`.wgetrc` / env	`https_proxy = http://proxy:8080/`	Mismo formato que `http_proxy`
`ftp_proxy`	`.wgetrc` / env	`ftp_proxy = http://proxy:8080/`	Para descargas FTP
`no_proxy`	`.wgetrc` / env	`no_proxy = localhost,127.0.0.1,.corp`	Lista de dominios separada por comas
`proxy_user`	`.wgetrc`	`proxy_user = admin`	Equivalente a `--proxy-user`
`proxy_password`	`.wgetrc`	`proxy_password = secret`	Protege el archivo con `chmod 600`

Cuándo Wget + proxy no es la mejor opción (y qué usar en su lugar)

Después de tanta configuración de proxy, aquí va una postura contraria: a veces no deberías complicarte.

Mucha gente que busca "wget proxy" en realidad no está intentando descargar un solo archivo. Lo que quiere es recopilar datos estructurados de sitios web — precios de productos, listas de contactos, anuncios inmobiliarios — y ha acabado usando Wget porque es la herramienta de línea de comandos que conoce. El problema es que Wget te da HTML en bruto. Todavía tienes que analizarlo, limpiarlo y estructurarlo. Y si además rotas proxies para evitar bloqueos, ahora estás manteniendo una lista de proxies, un script de descarga, un parser y un pipeline de exportación.

Tu objetivo	Mejor herramienta	Por qué
Descargar un archivo concreto a través de un proxy	`wget` con flags de proxy	Simple, un solo comando
Reflejar un sitio o directorio a través de un proxy	`wget --recursive` + configuración de proxy	La descarga recursiva es una de las fortalezas principales de Wget
Extraer datos estructurados (tablas, listados, contactos)	Thunderbit	Wget entrega HTML en bruto y luego hay que parsearlo. Thunderbit usa IA para leer la página y exportar datos estructurados a Excel, Google Sheets, Airtable o Notion sin código. Su scraping en la nube gestiona la rotación de IP y las medidas anti-bot, así que te ahorras toda la configuración de proxy.
Llamadas a una API REST a través de un proxy	`curl`	Mejor control de cabeceras, soporte nativo de JSON, soporte SOCKS5
Recopilación programada y continua de datos	Thunderbit Scheduled Scraper o `cron` + wget	Thunderbit se adapta cuando cambian los diseños de las páginas; los scripts de cron + wget se rompen en silencio

Wget es excelente descargando archivos. Pero el flujo de trabajo de "configurar proxy → rotar IPs → descargar HTML → escribir un parser → exportar a una hoja de cálculo" tiene demasiadas piezas en movimiento cuando lo que de verdad quieres es una tabla de datos. Si ese es tu caso, nuestra extensión de Chrome resuelve todo el proceso en dos clics. Para profundizar en este enfoque, consulta nuestras guías sobre web scraping con IA y web scraping sin programar.

Pero si tu objetivo es "descargar este archivo ZIP a través de un proxy corporativo", Wget sigue siendo la herramienta adecuada, y ahora ya sabes cómo configurarlo correctamente.

Conclusiones clave

La versión corta:

Cuatro métodos, una prioridad clara: los flags de CLI sobrescriben la configuración de usuario, que sobrescribe la configuración del sistema, que sobrescribe las variables de entorno. --no-proxy lo anula todo.
Usa siempre minúsculas para las variables de entorno (http_proxy, no HTTP_PROXY). Las mayúsculas se ignoran en silencio.
Incluye siempre http:// en la URL del proxy, incluso para https_proxy. El endpoint del proxy es HTTP; el tráfico HTTPS se tuneliza mediante CONNECT.
Usa on para valores booleanos en .wgetrc y en flags -e. Es la opción más segura entre versiones de Wget.
Usuarios de Windows: usa --config=C:\ruta\a\wgetrc para evitar ambigüedades con el archivo de configuración. Usa set (CMD) o $env: (PowerShell) para variables de proxy de sesión.
Usuarios de proxy corporativo: Wget no puede leer archivos PAC y no soporta autenticación NTLM de forma nativa. Usa Cntlm como relé local si lo necesitas.
Guarda la hoja rápida de arriba: te evitará tener que releer este artículo cada vez que no recuerdes el nombre de un flag.

Si tu objetivo real es la extracción de datos estructurados, Thunderbit o curl pueden encajarte mejor. La mejor sesión de depuración es la que nunca tienes que empezar.

Preguntas frecuentes

1. ¿Wget admite proxies SOCKS5?

No. GNU Wget 1.x solo admite proxies HTTP, HTTPS y FTP. El proyecto Wget2 ha tenido SOCKS5 como solicitud de funcionalidad, pero no es una opción estándar documentada. Para SOCKS5, usa curl con sus esquemas nativos socks5:// o socks5h://, o envuelve Wget con proxychains4 para forzar el enrutado SOCKS.

2. ¿Por qué se ignora mi proxy cuando uso HTTP_PROXY en mayúsculas?

Wget solo lee nombres de variables de entorno en minúsculas (http_proxy, https_proxy, ftp_proxy, no_proxy). Las variantes en mayúsculas como HTTP_PROXY se ignoran sin avisar, sin error y sin advertencia. Este es uno de los problemas más comunes y frustrantes porque no hay ninguna pista de que algo vaya mal. Usa siempre minúsculas.

3. ¿Cómo omito el proxy para dominios concretos?

Usa la directiva no_proxy, ya sea como variable de entorno o en .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

O en ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

Los dominios se separan con comas. Un punto inicial (.mycompany.com) coincide con todos los subdominios.

4. ¿Puedo usar Wget con proxies rotativos?

Wget por sí mismo no tiene rotación de proxy integrada. Tienes dos opciones: usar un proveedor de proxies que rote IPs en el servidor (así siempre conectas al mismo gateway, pero cambia la IP de salida), o escribir un script de shell que elija un proxy aleatorio de una lista y lo pase mediante -e http_proxy=... en cada ejecución. Para algo más complejo — rotación automática, lógica de reintentos, gestión anti-bot — suele ser mejor una herramienta de scraping dedicada.

5. ¿Cuál es la diferencia entre http_proxy y https_proxy en Wget?

http_proxy se usa cuando la URL de destino empieza por http://. https_proxy se usa cuando la URL de destino empieza por https://. En ambos casos, la URL del proxy suele ser una dirección http://. Para destinos HTTPS, Wget envía una solicitud HTTP CONNECT a través del proxy para establecer un túnel, y el cifrado HTTPS real ocurre de extremo a extremo entre Wget y el servidor de destino. El proxy ve el nombre de host (a partir de la solicitud CONNECT), pero no puede leer el tráfico cifrado.

Prueba Thunderbit para AI Web Scraping Get Started Free

Más información