Configurar proxy no Wget parece tarefa de cinco segundos — até você passar uma hora tentando entender por que suas requisições estão ignorando o proxy por completo, sem mostrar nenhum erro. Já vi isso acontecer tanto com administradores de sistema experientes quanto com desenvolvedores iniciantes.
A causa raiz quase nunca é o proxy em si. O problema costuma estar nos quatro lugares diferentes de onde o Wget pode ler as configurações de proxy, nas falhas silenciosas quando você usa a capitalização errada da variável, e nas particularidades de rede corporativa que nenhum manual faz questão de explicar. Este guia cobre todos os métodos para configurar o Wget com proxy, as regras exatas de prioridade quando vários métodos entram em conflito, exemplos reais de saída no terminal para os erros mais comuns, e uma seção dedicada para usuários do Windows e de firewalls corporativos — justamente o público que quase todos os outros tutoriais fingem que não existe.
- Dificuldade: Iniciante a intermediário
- Tempo necessário: ~15 minutos para ler e configurar; ~2 minutos depois que você já sabe o que está fazendo
- O que você vai precisar: Uma instalação funcional do Wget (instruções abaixo), o endereço do proxy (host + porta) e, opcionalmente, credenciais de proxy
Experimente o Thunderbit para Extração Estruturada de Dados
O que é o Wget e por que usá-lo com um proxy?
O Wget é uma ferramenta de linha de comando que baixa arquivos e páginas da web da internet sem precisar de navegador. A própria documentação do GNU o descreve como um "baixador de rede não interativo" — ou seja, ele roda em segundo plano, retoma transferências interrompidas e faz downloads recursivos sem exigir cliques humanos.
Neste contexto, um proxy é um servidor intermediário. Em vez de sua máquina se conectar diretamente ao site de destino, o Wget envia a solicitação ao proxy, e o proxy a encaminha. Os principais motivos para usar isso são:
- Conformidade com firewall corporativo — sua empresa exige que todo o tráfego de saída passe por um proxy aprovado
- Privacidade e gerenciamento de IP — as requisições aparecem com o IP do proxy, não com o seu
- Teste geográfico — acessar recursos restritos por região ou testar o comportamento de CDN a partir de uma localização específica
- Pipelines de coleta de dados — baixar HTML por meio de proxies rotativos para pesquisa ou monitoramento
- Ambientes de CI/CD — runners de build em redes restritas que só conseguem acessar a internet por proxy
O Wget suporta nativamente proxies HTTP, HTTPS e FTP. Ele não suporta SOCKS5. Se você precisar de SOCKS5, o curl oferece suporte nativo aos esquemas socks4://, socks5:// e socks5h:// — ou você pode envolver o Wget com uma ferramenta como proxychains4.
Como instalar o Wget no Linux, macOS e Windows
Antes de configurar proxies, você precisa ter o Wget instalado. Esta parte é rápida — é um pré-requisito, não o foco principal.
Linux (Debian/Ubuntu e RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# Verificar
wget --version
O Ubuntu 24.04 LTS vem com o Wget 1.21.4, enquanto o Debian Trixie traz a versão 1.25.0. Os pacotes do CentOS Stream 10 mostram 1.24.5.
macOS (Homebrew)
brew install wget
wget --version
A fórmula do Homebrew atualmente distribui o Wget estável 1.25.0, com 396.818 instalações no último ano.
Windows (Chocolatey e instalação manual)
choco install wget
wget --version
O pacote GNU Wget do Chocolatey informa mais de 10 milhões de downloads totais, embora esteja atualmente na versão 1.21.4. O executável normalmente fica em C:\ProgramData\chocolatey\bin\wget.exe.
Um aviso para usuários do Windows: o local onde o Wget procura o arquivo .wgetrc varia conforme a compilação. Mais detalhes na seção de Windows abaixo.
4 maneiras de usar o Wget com um proxy (e qual escolher)
Quatro métodos, cada um com um escopo e uma prioridade diferentes:
- Flags de linha de comando
-e— uso pontual, em um único comando - Arquivo de configuração do usuário (
~/.wgetrc) — aplica-se a todo comando Wget que você executar - Arquivo de configuração do sistema (
/etc/wgetrc) — aplica-se a todos os usuários da máquina - Variáveis de ambiente (
http_proxy,https_proxy) — aplicam-se à sessão inteira do shell
Método 1: flags de linha de comando (proxy pontual)
Ideal para testes rápidos. As configurações desaparecem assim que o comando termina.
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/
Teste rápido — descubra qual IP o proxy está exibindo:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
Se a saída mostrar o IP do proxy em vez do seu, está tudo funcionando.
Método 2: arquivo de configuração do usuário (~/.wgetrc)
Adicione estas linhas em ~/.wgetrc (crie o arquivo se ele não existir):
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
Repare nos espaços ao redor do = — essa é a sintaxe documentada do .wgetrc. A partir daí, todo comando Wget executado por esse usuário passará pelo proxy.
Método 3: configuração global (/etc/wgetrc)
Os mesmos diretivos de ~/.wgetrc, mas colocados no arquivo de configuração do sistema. O GNU documenta isso como um arquivo global de inicialização — o caminho exato depende do prefixo da instalação. Locais comuns:
/etc/wgetrc(na maioria dos gerenciadores de pacotes Linux)/usr/local/etc/wgetrc(em algumas instalações via Homebrew)- O caminho exibido na saída de
wget --version, sob "Wgetrc:"
Isso é útil para servidores compartilhados, contêineres Docker ou qualquer ambiente em que todos os usuários devam sair pela mesma rota de proxy.
Método 4: variáveis de ambiente (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
Elas afetam toda a sessão do shell — não apenas o Wget. Ferramentas como o curl também vão usar essas variáveis.
Aviso crítico: o Wget lê apenas nomes de variáveis de ambiente em minúsculas. HTTP_PROXY (maiúsculo) é ignorado silenciosamente. Sem erro, sem aviso, nada. Vou mostrar a saída exata do terminal na seção de armadilhas, mas vale gravar isso na memória agora.
Prioridade dos métodos de proxy: o que substitui o quê quando há vários métodos configurados
Se você tiver proxy configurado nas variáveis de ambiente e no .wgetrc e na linha de comando, qual deles vale? Quase ninguém explica isso com clareza, então eu testei.
Esta é a prioridade testada e documentada:
| Prioridade | Método | Escopo | Substitui |
|---|---|---|---|
| 1 (mais alta) | Flags CLI -e | Um único comando | Tudo |
| 2 | ~/.wgetrc | Usuário atual | Configuração do sistema + variáveis de ambiente |
| 3 | /etc/wgetrc | Sistema inteiro | Apenas variáveis de ambiente |
| 4 (mais baixa) | Variáveis de ambiente http_proxy / https_proxy | Sessão do shell | Nada |
Eu verifiquei isso no Wget 1.25.0 configurando proxies conflitantes em cada nível. Com o ambiente apontando para a porta 3128, o arquivo de configuração para 3129 e a linha de comando para 3130:
- Configuração vence ambiente: o Wget conectou na porta 3129, ignorando 3128.
- CLI vence configuração: o Wget conectou na porta 3130, ignorando 3129 e 3128.
A saída de emergência é --no-proxy. Ele ignora todas as configurações de proxy, independentemente de onde tenham sido definidas:
wget --no-proxy https://internal-server.company.com/report.pdf
Cenário prático: o administrador do sistema definiu um proxy em /etc/wgetrc, mas você precisa acessar um servidor interno diretamente. Use --no-proxy só nesse comando, em vez de editar a configuração do sistema.
Como usar o Wget com um proxy autenticado
A maioria dos proxies residenciais e corporativos exige nome de usuário e senha. O Wget suporta isso por duas abordagens, ambas usando autenticação HTTP Basic para as credenciais do proxy.
Credenciais embutidas na URL do proxy
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
Isso também funciona no .wgetrc:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
Usando as flags --proxy-user e --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
Essas flags substituem qualquer user:pass@ embutido na URL do proxy.
Mantendo as credenciais seguras
Ambos os métodos expõem credenciais. O GNU alerta que senhas na linha de comando ficam visíveis via ps ou ferramentas de lista de processos. Mitigações:
- Máquinas de usuário único: armazene as credenciais em
~/.wgetrce proteja o arquivo:chmod 600 ~/.wgetrc - Pipelines de CI/CD: use segredos criptografados do GitHub Actions ou o equivalente da sua plataforma. Passe-os como variáveis de ambiente em minúsculas na definição da etapa — nunca coloque o valor diretamente no YAML.
- Builds Docker: não use
ARGnemENVpara segredos. A documentação do Docker avisa explicitamente que argumentos de build podem persistir na imagem final. Use mounts de secrets do BuildKit. - Controle de versão: nunca faça commit de um
.wgetrccom credenciais. Adicione-o ao.gitignore.
Um detalhe específico do Wget no GitHub Actions: por convenção, nomes de secrets são armazenados em maiúsculas, mas as variáveis de ambiente expostas ao Wget precisam estar em minúsculas (http_proxy, e não HTTP_PROXY).
Como usar o Wget com um proxy no Windows e atrás de firewalls corporativos
A maioria dos artigos sobre este tema para em "instale com Chocolatey". Se você usa Windows ou está atrás de um proxy corporativo, é aí que os problemas começam.
Onde o Windows procura o arquivo .wgetrc
A documentação do GNU diz que o Wget lê $HOME/.wgetrc a menos que a variável de ambiente WGETRC aponte para outro lugar. No Windows, $HOME pode mapear para %USERPROFILE% (por exemplo, C:\Users\alice), ou talvez não — depende se você está usando a build do Chocolatey, uma build do MSYS2, o Git Bash ou um binário independente.
Minha recomendação: pare de adivinhar e use a flag --config para ter comportamento determinístico:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
Para testar se a sua build lê um arquivo de configuração de um local específico, crie um arquivo de teste apontando para um proxy conhecido como inválido:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
Depois execute:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Se o Wget tentar se conectar a 127.0.0.1:3128, então ele leu o arquivo.
Definindo variáveis de ambiente de proxy no Windows
CMD (apenas na sessão atual):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (apenas na sessão atual):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
Permanente (sobrevive a reinicializações):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
Depois do setx, você precisa abrir uma nova janela de terminal. A sessão atual não verá a alteração.
Armadilhas de proxy corporativo: arquivos PAC, autenticação NTLM e como descobrir o endereço do proxy
Três coisas que derrubam usuários corporativos o tempo todo:
Arquivos PAC: muitas empresas usam arquivos Proxy Auto-Configuration (PAC) — scripts em JavaScript que dizem ao navegador qual proxy usar para cada URL. O Wget não tem interpretador JavaScript, então ele não consegue ler arquivos PAC. A documentação do curl faz o mesmo alerta. A alternativa: abrir o arquivo PAC (ou pedir ao TI), localizar o resultado PROXY host:port para o domínio desejado e configurar esse endereço fixo no Wget.
Autenticação NTLM: a autenticação de proxy do Wget implementa apenas Basic auth. Se o proxy corporativo exigir NTLM e você estiver recebendo 407 Proxy Authentication Required, não perca tempo testando sintaxes diferentes de --proxy-user. Instale o Cntlm — um relay local que lida com autenticação NTLM/NTLMv2 e apresenta uma interface Basic auth para o Wget. O Cntlm ainda é mantido (última atualização em outubro de 2025, ~395 downloads/semana).
Fluxo de decisão para usuários de proxy corporativo:
- Tente
set http_proxy=http://SEU_PROXY:PORTA/e execute o Wget. - Se aparecer erro
407e sua empresa usar NTLM → instale o Cntlm, configure com suas credenciais de domínio e aponte o Wget para a porta local do Cntlm (normalmentehttp://127.0.0.1:3128/). - Se a empresa usar um arquivo PAC → extraia o
PROXY host:portreal do PAC ou peça ao TI o endereço estático do proxy.
Portas comuns de proxy corporativo: 3128 (estilo Squid), 8080 (proxy HTTP genérico), 8888 (proxies de depuração como Fiddler/Charles). São convenções, não garantias.
Armadilhas comuns ao usar Wget com proxy (com saída real de erro)
Agora, a parte que prometi no título. Toda a saída abaixo foi reproduzida no Wget 1.25.0 (macOS, Homebrew) em 2026-06-01.
Armadilha 1: falta do prefixo http://
Alguns guias antigos dizem que isso sempre quebra. No Wget 1.25.0, definir http_proxy=127.0.0.1:3128 na verdade funciona — o Wget adiciona http:// silenciosamente:
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.
Mesmo assim, ele se conectou ao proxy correto. Ainda assim, recomendo sempre incluir o prefixo http:// e a barra final. Isso evita ambiguidades entre versões do Wget e deixa a sintaxe com credenciais (http://user:pass@host:port/) sem dúvidas.
Armadilha 2: use_proxy=yes versus use_proxy=on
Nos meus testes com o Wget 1.25.0, tanto yes quanto on funcionaram. Mas valores inválidos falham com um erro claro:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
Use on para maior compatibilidade — ele segue o formato booleano documentado no manual e também a própria dica de erro do Wget.
Armadilha 3: HTTP_PROXY em maiúsculas é ignorado silenciosamente
Esta é a mais irritante, porque não aparece nenhum erro. O Wget simplesmente se conecta direto, como se você nunca tivesse definido proxy.
Maiúsculo (quebrado — sem 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: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
Minúsculo (funcionando — tentativa de uso do 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.
Viu a diferença? A versão em maiúsculas resolveu example.com diretamente. A versão em minúsculas tentou usar o proxy. Sem aviso em nenhum dos casos. O curl tem uma peculiaridade parecida — ele aceita maiúsculas para a maioria das variáveis de proxy, mas rejeita explicitamente HTTP_PROXY em maiúsculas por motivos de segurança.
Correção: use sempre http_proxy e https_proxy em minúsculas.
Armadilha 4: proxy antigo no .wgetrc causando "Connection Refused"
Se você (ou o administrador do sistema, ou uma imagem Docker) deixou um endereço antigo de proxy em um arquivo de configuração, você verá algo assim:
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.
O erro aponta para o IP antigo do proxy, não para o site de destino. Ordem de diagnóstico (seguindo a hierarquia de prioridade):
- Verifique seu comando em busca de flags
-eou aliases de shell - Verifique
~/.wgetrc(ou o arquivo indicado porWGETRC) - Verifique a configuração do sistema (o caminho mostrado por
wget --version) - Verifique o ambiente:
env | grep -i proxy
Para depuração, --no-config é seu melhor amigo — ele manda o Wget ignorar todos os arquivos de configuração:
wget --no-config --spider http://example.com/
Se isso funcionar, o problema está em algum arquivo de configuração.
Armadilha 5: confusão na sintaxe de proxy HTTPS
Isso pega muita gente. Quando você define https_proxy, a URL do proxy em si normalmente é http://, e não https://. Isso acontece porque o Wget envia uma requisição HTTP CONNECT pelo proxy para criar um túnel para a sessão HTTPS criptografada.
Correto:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
O Wget envia CONNECT example.com:443 HTTP/1.1 ao proxy e então tunela o HTTPS por ali.
Incorreto (para URLs HTTP com 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.
O Wget 1.25.0 rejeita diretamente https:// como URL de proxy para destinos HTTP. Use https_proxy=http://HOST:PORT/ a menos que sua organização tenha documentado explicitamente um endpoint de proxy HTTPS e você já tenha testado isso com sua build do Wget.
Tabela rápida de comandos de proxy do Wget
Salve esta tabela. Ela reúne todos os flags e diretivas de configuração relacionados a proxy do Wget em um só lugar.
| Flag / Diretiva | Contexto | Exemplo | Observações |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on é a opção mais segura; algumas builds também aceitam yes |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | Inclua o prefixo http:// e a barra final / |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | A URL do proxy normalmente é http://, mesmo para destinos HTTPS |
--proxy-user | CLI | --proxy-user=admin | Substitui user:pass@ embutido |
--proxy-password | CLI | --proxy-password=secret | Fica visível em ps — evite em sistemas compartilhados |
--no-proxy | CLI | --no-proxy | Ignora TODAS as configurações de proxy de qualquer origem |
--no-config | CLI | --no-config | Ignora todos os arquivos de configuração — útil para depuração |
--config=FILE | CLI | --config=/tmp/wgetrc | Caminho de configuração determinístico — ótimo para Windows e CI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | No arquivo de configuração usa espaços ao redor do =; na variável de ambiente, tudo em minúsculas |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | Mesmo formato de http_proxy |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | Para recuperações via FTP |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | Lista de domínios separada por vírgulas |
proxy_user | .wgetrc | proxy_user = admin | Equivalente a --proxy-user |
proxy_password | .wgetrc | proxy_password = secret | Proteja o arquivo com chmod 600 |
Quando Wget + proxy não é a melhor solução (e o que usar no lugar)
Depois de toda essa configuração de proxy, aqui vai uma visão contrária: às vezes você nem deveria se preocupar com isso.
Muita gente que pesquisa "wget proxy" não está realmente tentando baixar um único arquivo. Está tentando coletar dados estruturados de sites — preços de produtos, listas de contatos, imóveis — e acaba recorrendo ao Wget porque é a ferramenta de linha de comando que já conhece. O problema é que o Wget entrega HTML bruto. Ainda é preciso fazer parsing, limpar e estruturar esses dados. E, se você estiver rotacionando proxies para evitar bloqueios, agora passa a manter uma lista de proxies, um script de download, um parser e um pipeline de exportação.
| Seu objetivo | Melhor ferramenta | Por quê |
|---|---|---|
| Baixar um único arquivo por meio de proxy | wget com flags de proxy | Simples, um único comando |
| Espelhar um site ou diretório via proxy | wget --recursive + configuração de proxy | O download recursivo é um dos pontos fortes do Wget |
| Extrair dados estruturados (tabelas, listagens, contatos) | Thunderbit | O Wget entrega HTML bruto — ainda é preciso interpretar. O Thunderbit usa IA para ler a página e exportar dados estruturados para Excel, Google Sheets, Airtable ou Notion, sem código. O scraping em nuvem lida com rotação de IP e medidas anti-bot, então você elimina a configuração de proxy. |
| Fazer chamadas REST API por meio de proxy | curl | Melhor controle de cabeçalhos, suporte nativo a JSON, suporte a SOCKS5 |
| Coleta recorrente e agendada de dados | Thunderbit Scheduled Scraper ou cron + wget | O Thunderbit se adapta quando o layout da página muda; scripts com cron + wget quebram em silêncio |
O Wget é ótimo para baixar arquivos. Mas o fluxo de "configurar proxy → rotacionar IPs → baixar HTML → escrever um parser → exportar para planilha" envolve muita coisa quando o que você realmente quer é uma tabela de dados. Se isso parece o seu caso, nossa extensão para Chrome cuida de todo o processo em dois cliques. Para saber mais sobre essa abordagem, veja nossos guias sobre web scraping com IA e web scraping sem programar.
Mas se o seu objetivo é "baixar este arquivo ZIP por meio de um proxy corporativo" — então o Wget continua sendo a ferramenta certa, e agora você sabe como configurá-lo do jeito correto.
Principais conclusões
A versão curta:
- Quatro métodos, prioridade clara: flags de CLI substituem a configuração do usuário, que substitui a configuração do sistema, que por sua vez substitui as variáveis de ambiente.
--no-proxyignora tudo. - Use sempre minúsculas nas variáveis de ambiente (
http_proxy, e nãoHTTP_PROXY). Maiúsculas são ignoradas silenciosamente. - Inclua sempre
http://na URL do proxy, mesmo parahttps_proxy. O endpoint do proxy é HTTP; ele faz túnel de HTTPS via CONNECT. - Use
onpara valores booleanos em.wgetrce flags-e. É a opção mais segura entre versões do Wget. - Usuários do Windows: use
--config=C:\caminho\para\wgetrcpara evitar ambiguidade no arquivo de configuração. Useset(CMD) ou$env:(PowerShell) para variáveis de proxy da sessão. - Usuários de proxy corporativo: o Wget não lê arquivos PAC nem oferece suporte nativo a autenticação NTLM. Use o Cntlm como relay local, se necessário.
- Salve a tabela rápida acima — ela vai evitar que você precise reler este artigo sempre que esquecer o nome de uma flag.
Se seu objetivo real é extração estruturada de dados, Thunderbit ou curl podem ser alternativas melhores. O melhor diagnóstico é aquele que você nunca precisa começar.
Perguntas frequentes
1. O Wget suporta proxies SOCKS5?
Não. O GNU Wget 1.x oferece suporte apenas a proxies HTTP, HTTPS e FTP. O projeto Wget2 já recebeu solicitação de suporte a SOCKS5, mas isso não é uma opção padrão documentada. Para SOCKS5, use curl com os esquemas nativos socks5:// ou socks5h://, ou envolva o Wget com proxychains4 para forçar o roteamento via SOCKS.
2. Por que minha configuração de proxy é ignorada quando uso HTTP_PROXY em maiúsculas?
O Wget só lê nomes de variáveis de ambiente em minúsculas (http_proxy, https_proxy, ftp_proxy, no_proxy). Variantes em maiúsculas como HTTP_PROXY são ignoradas silenciosamente — sem erro, sem aviso. Esse é um dos problemas mais comuns e frustrantes, justamente porque não há nenhum indício de que algo está errado. Use sempre minúsculas.
3. Como contornar o proxy para domínios específicos?
Use a diretiva no_proxy, seja como variável de ambiente ou no .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
Ou em ~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
Os domínios são separados por vírgula. Um ponto inicial (.mycompany.com) corresponde a todos os subdomínios.
4. Posso usar o Wget com proxies rotativos?
O Wget, por si só, não tem rotação de proxy embutida. Você tem duas opções: usar um provedor de proxy que faça a rotação de IP no servidor (assim você sempre acessa o mesmo gateway, mas o IP de saída muda) ou escrever um script de shell que escolha um proxy aleatório de uma lista e o passe via -e http_proxy=... a cada execução. Para algo mais complexo — rotação automática, lógica de retry, tratamento anti-bot — uma ferramenta dedicada de scraping normalmente é mais adequada.
5. Qual é a diferença entre http_proxy e https_proxy no Wget?
http_proxy é usado quando a URL de destino é http://. https_proxy é usado quando a URL de destino é https://. Em ambos os casos, a URL do proxy normalmente é um endereço http://. Para destinos HTTPS, o Wget envia uma requisição HTTP CONNECT pelo proxy para criar um túnel, e a criptografia HTTPS real acontece ponta a ponta entre o Wget e o servidor de destino. O proxy vê o hostname (a partir da requisição CONNECT), mas não consegue ler o tráfego criptografado.
Experimente o Thunderbit para Web Scraping com IA Get Started Free
Saiba mais
