Come usare Wget con un proxy (ed evitare gli errori più comuni)

La configurazione del proxy in Wget sembra una roba da cinque secondi — finché non ti ritrovi a passare un’ora a capire perché le richieste stanno saltando completamente il proxy, senza dare fuori nessun messaggio d’errore. L’ho visto succedere sia a sysadmin con le mani in pasta sia a sviluppatori junior.

La causa quasi mai è il proxy in sé. Di solito il problema è che Wget può leggere le impostazioni proxy da quattro punti diversi, che gli errori possono restare muti se sbagli maiuscole e minuscole, e che ci sono stranezze tipiche delle reti aziendali che nessuna pagina di manuale si prende davvero la briga di spiegare. Questa guida copre tutti i modi per configurare Wget con un proxy, le regole precise di precedenza quando più metodi si sovrappongono, l’output reale del terminale per ogni errore comune e una sezione dedicata a Windows e a chi sta dietro firewall aziendali — cioè proprio quel pubblico che quasi tutti gli altri tutorial fanno finta che non esista.

• Difficoltà: Da principiante a intermedio
• Tempo richiesto: ~15 minuti per leggere e configurare; ~2 minuti quando sai già dove mettere le mani
• Cosa ti serve: Un’installazione funzionante di Wget (istruzioni sotto), l’indirizzo del proxy (host + porta) e, facoltativamente, le credenziali del proxy

Prova Thunderbit per l’estrazione di dati strutturati

Che cos’è Wget e perché usarlo con un proxy?

Wget è uno strumento da riga di comando che scarica file e pagine web da internet senza bisogno di un browser. La descrizione ufficiale di GNU lo definisce un "non-interactive network downloader" — in pratica, lavora in background, riprende i trasferimenti interrotti e gestisce i download ricorsivi senza richiedere interventi manuali.

In questo contesto, un proxy è un server intermediario. Invece di collegarsi direttamente al sito di destinazione, Wget manda la richiesta al proxy, che poi la inoltra. I motivi principali per cui può servirti sono:

• Conformità ai firewall aziendali — la tua azienda richiede che tutto il traffico in uscita passi da un proxy approvato
• Privacy e gestione dell’IP — le richieste sembrano provenire dall’IP del proxy, non dal tuo
• Geo-testing — recuperare risorse bloccate per area geografica o testare il comportamento del CDN da una posizione specifica
• Pipeline di raccolta dati — scaricare HTML tramite proxy rotanti per attività di ricerca o monitoraggio
• Ambienti CI/CD — runner di build su reti molto restrittive che possono raggiungere internet solo tramite proxy

Wget supporta in modo nativo proxy HTTP, HTTPS e FTP. Non supporta SOCKS5. Se ti serve SOCKS5, curl ha supporto nativo per gli schemi socks4://, socks5:// e socks5h:// — oppure puoi avviare Wget tramite uno strumento come proxychains4.

Come installare Wget su Linux, macOS e Windows

Prima di configurare i proxy, devi avere Wget installato sulla tua macchina. Questa parte è veloce: è un prerequisito, non il piatto forte.

Linux (Debian/Ubuntu e RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Verifica
wget --version

Ubuntu 24.04 LTS include Wget 1.21.4, mentre Debian Trixie arriva a 1.25.0. I pacchetti di CentOS Stream 10 mostrano la versione 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

La formula di Homebrew distribuisce attualmente Wget 1.25.0 stabile, con 396.818 installazioni nell’ultimo anno.

Windows (Chocolatey e installazione manuale)

choco install wget
wget --version

Il pacchetto GNU Wget di Chocolatey dichiara oltre 10 milioni di download totali, anche se al momento è alla versione 1.21.4. Il binario si trova di solito sotto C:\ProgramData\chocolatey\bin\wget.exe.

Una nota per chi usa Windows: il punto in cui Wget cerca il file .wgetrc cambia in base alla build. I dettagli sono nella sezione Windows più avanti.

4 modi per usare Wget con un proxy (e quale scegliere)

Quattro metodi, ognuno con un ambito e una priorità diversa:

1. Flag da riga di comando -e — uso singolo, comando isolato
2. File di configurazione utente (~/.wgetrc) — vale per ogni comando Wget eseguito da quell’utente
3. File di configurazione di sistema (/etc/wgetrc) — vale per tutti gli utenti della macchina
4. Variabili d’ambiente (http_proxy, https_proxy) — valgono per l’intera sessione della shell

Metodo 1: Flag da riga di comando (proxy temporaneo)

Perfetto per test rapidi. Le impostazioni spariscono quando il comando finisce.

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

Per destinazioni HTTPS:

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

Test rapido — controlla l’IP visibile passando dal proxy:

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

Se l’output mostra l’IP del proxy invece del tuo, tutto funziona.

Metodo 2: File di configurazione utente (~/.wgetrc)

Aggiungi queste righe a ~/.wgetrc (crea il file se non esiste):

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

Nota gli spazi attorno a = — è la sintassi documentata di .wgetrc. Da questo momento, ogni comando Wget eseguito da questo utente passerà dal proxy.

Metodo 3: Configurazione a livello di sistema (/etc/wgetrc)

Stesse direttive di ~/.wgetrc, ma inserite nel file di configurazione di sistema. La documentazione GNU lo descrive come file di avvio globale — il percorso esatto dipende dal prefisso di installazione. I percorsi più comuni sono:

• /etc/wgetrc (la maggior parte dei gestori pacchetti Linux)
• /usr/local/etc/wgetrc (alcune build di Homebrew)
• Il percorso mostrato nell’output di wget --version sotto "Wgetrc:"

È utile per server condivisi, container Docker o qualsiasi ambiente in cui tutti gli utenti debbano passare dallo stesso proxy.

Metodo 4: Variabili d’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

Queste impostazioni influenzano l’intera sessione della shell, non solo Wget. Anche strumenti come curl le leggono automaticamente.

Avviso fondamentale: Wget legge solo i nomi delle variabili d’ambiente in minuscolo. HTTP_PROXY (maiuscolo) viene ignorato senza alcuna segnalazione. Nessun errore, nessun warning, niente. Ti mostro l’output esatto del terminale nella sezione degli errori più subdoli, ma è bene fissarlo subito in testa.

Precedenza dei metodi proxy: cosa prevale quando sono impostati più metodi?

Se hai un proxy configurato nelle variabili d’ambiente e in .wgetrc e nella riga di comando, quale vince? Nessuno lo spiega con chiarezza, quindi l’ho testato.

Ecco la precedenza, testata e documentata:

Priorità	Metodo	Ambito	Sovrascrive
1 (più alta)	Flag CLI -e	Un singolo comando	Tutto
2	~/.wgetrc	Utente corrente	Config di sistema + variabili d’ambiente
3	/etc/wgetrc	Tutto il sistema	Solo variabili d’ambiente
4 (più bassa)	Variabili d’ambiente http_proxy / https_proxy	Sessione della shell	Nulla

L’ho verificato su Wget 1.25.0 impostando proxy diversi a ogni livello. Con l’ambiente puntato alla porta 3128, il file di configurazione alla 3129 e la CLI alla 3130:

• La configurazione supera l’ambiente: Wget si è collegato alla porta 3129, ignorando la 3128.
• La CLI supera la configurazione: Wget si è collegato alla porta 3130, ignorando sia la 3129 sia la 3128.

La via d’uscita è --no-proxy. Bypassa ogni impostazione proxy, indipendentemente da dove sia stata configurata:

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

Scenario pratico: il sysadmin ha impostato un proxy in /etc/wgetrc, ma tu devi raggiungere direttamente un server interno. In quel caso usa --no-proxy per quel singolo comando invece di modificare la configurazione di sistema.

Come usare Wget con un proxy autenticato

La maggior parte dei proxy residenziali e aziendali richiede nome utente e password. Wget lo supporta con due approcci, entrambi basati su HTTP Basic authentication per le credenziali del proxy.

Credenziali inline nell’URL del proxy

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

Funziona anche in .wgetrc:

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

Uso dei flag --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

Questi flag hanno priorità su qualsiasi credenziale user:pass@ incorporata nell’URL del proxy.

Come tenere al sicuro le credenziali

Entrambi i metodi espongono le credenziali. La documentazione GNU avverte che le password passate da riga di comando sono visibili tramite ps o strumenti simili che elencano i processi. Contromisure consigliate:

• Macchine mono-utente: salva le credenziali in ~/.wgetrc e proteggi il file: chmod 600 ~/.wgetrc
• Pipeline CI/CD: usa i segreti cifrati di GitHub Actions o l’equivalente della tua piattaforma. Passali come variabili d’ambiente in minuscolo nella definizione dello step — mai hardcoded nello YAML.
• Build Docker: non usare ARG o ENV per i segreti. La documentazione Docker avverte esplicitamente che gli argomenti di build possono restare nell’immagine finale. Usa invece i secret mount di BuildKit.
• Controllo versioni: non committare mai .wgetrc con credenziali. Aggiungilo a .gitignore.

Un dettaglio specifico di Wget per GitHub Actions: per convenzione i nomi dei segreti vengono memorizzati in maiuscolo, ma le variabili d’ambiente che esponi a Wget devono essere in minuscolo (http_proxy, non HTTP_PROXY).

Come usare Wget con un proxy su Windows e dietro firewall aziendali

Molti articoli su questo tema si fermano a "installa con Chocolatey". Se usi Windows o sei dietro un proxy aziendale, è proprio lì che i problemi iniziano.

Dove Windows cerca il file .wgetrc

La documentazione GNU dice che Wget legge $HOME/.wgetrc, a meno che la variabile d’ambiente WGETRC non punti altrove. Su Windows, $HOME può corrispondere a %USERPROFILE% (ad esempio C:\Users\alice), oppure no — a seconda che tu stia usando la build di Chocolatey, una build MSYS2, Git Bash o un binario standalone.

Il mio consiglio: evita di andare a tentoni e usa il flag --config per un comportamento deterministico:

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

Per verificare se la tua build legge un file di configurazione da una posizione specifica, crea un file di test che punti a un proxy sicuramente sbagliato:

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

Poi esegui:

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

Se Wget prova a connettersi a 127.0.0.1:3128, significa che ha letto il file.

Impostare le variabili proxy su Windows

CMD (solo sessione corrente):

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

PowerShell (solo sessione corrente):

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

Persistente (sopravvive ai riavvii):

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

Dopo setx, devi aprire una nuova finestra del terminale. La sessione corrente non vedrà la modifica.

Problemi tipici dei proxy aziendali: file PAC, autenticazione NTLM e come trovare l’indirizzo del proxy

Tre elementi che mettono spesso in difficoltà gli utenti aziendali:

File PAC: molte aziende usano i file Proxy Auto-Configuration (PAC) — script basati su JavaScript che dicono ai browser quale proxy usare per ogni URL. Wget non ha un interprete JavaScript, quindi non può leggere i file PAC. La documentazione di curl dice la stessa cosa. La soluzione: apri il file PAC (o chiedi all’IT), trova il risultato PROXY host:port per il dominio di destinazione e configura quell’indirizzo statico in Wget.

Autenticazione NTLM: l’autenticazione proxy di Wget implementa solo Basic auth. Se il proxy aziendale richiede NTLM e ricevi 407 Proxy Authentication Required, non perdere tempo a provare varianti di --proxy-user. Installa Cntlm — un relay locale che gestisce l’autenticazione NTLM/NTLMv2 e presenta a Wget un’interfaccia Basic auth. Cntlm è ancora mantenuto (ultimo aggiornamento ottobre 2025, circa 395 download/settimana).

Albero decisionale per chi usa proxy aziendali:

1. Prova set http_proxy=http://YOUR_PROXY:PORT/ ed esegui Wget.
2. Se ricevi un errore 407 e la tua azienda usa NTLM → installa Cntlm, configurarlo con le credenziali di dominio e punta Wget alla porta locale di Cntlm (di solito http://127.0.0.1:3128/).
3. Se l’azienda usa un file PAC → estrai dal PAC il vero PROXY host:port oppure chiedi all’IT l’indirizzo statico del proxy.

Porte proxy aziendali comuni: 3128 (stile Squid), 8080 (proxy HTTP generico), 8888 (proxy di debug come Fiddler/Charles). Sono convenzioni, non garanzie.

Errori più comuni quando si usa Wget con un proxy (con output reale degli errori)

Ed eccoci al punto forte promesso nel titolo. Tutti gli output qui sotto sono stati riprodotti su Wget 1.25.0 (macOS, Homebrew) il 2026-06-01.

Errore 1: manca il prefisso http://

Alcune guide vecchie sostengono che questo rompa tutto. In Wget 1.25.0, impostare http_proxy=127.0.0.1:3128 in realtà funziona: Wget aggiunge in silenzio http:// davanti:

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.

Si è comunque collegato al proxy corretto. Però ti consiglio di includere sempre il prefisso http:// e anche la barra finale. Evita ambiguità tra versioni diverse di Wget e rende più chiara la sintassi delle credenziali (http://user:pass@host:port/).

Errore 2: use_proxy=yes vs. use_proxy=on

Nei miei test con Wget 1.25.0, sia yes sia on hanno funzionato. Ma i valori non validi generano un errore chiaro:

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

Usa on per la compatibilità più ampia: corrisponde al formato booleano documentato nel manuale e al suggerimento d’errore di Wget stesso.

Errore 3: HTTP_PROXY maiuscolo ignorato senza avviso

Questo è l’errore più fastidioso, perché non c’è proprio nessun messaggio. Wget si collega direttamente, come se il proxy non fosse mai stato impostato.

Maiuscolo (non funzionante — nessun proxy usato):

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

Minuscolo (funzionante — tentativo di uso del 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.

Vedi la differenza? La versione in maiuscolo ha risolto example.com direttamente. Quella in minuscolo ha provato il proxy. Nessun avviso in entrambi i casi. curl ha una particolarità simile: accetta i nomi in maiuscolo per molte variabili proxy, ma rifiuta esplicitamente HTTP_PROXY per motivi di sicurezza.

Soluzione: usa sempre http_proxy e https_proxy in minuscolo.

Errore 4: proxy obsoleto in .wgetrc che causa "Connection refused"

Se tu (o il sysadmin, o un’immagine Docker) avete lasciato un vecchio indirizzo proxy in un file di configurazione, vedrai qualcosa del genere:

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.

L’errore punta al vecchio IP del proxy, non al sito di destinazione. L’ordine di diagnosi, seguendo la gerarchia di precedenza, è:

1. Controlla il comando per eventuali flag -e o alias della shell
2. Controlla ~/.wgetrc (o il file indicato da WGETRC)
3. Controlla la configurazione di sistema (il percorso mostrato da wget --version)
4. Controlla l’ambiente: env | grep -i proxy

Per il debug, --no-config è il tuo alleato: dice a Wget di saltare tutti i file di configurazione:

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

Se questo funziona, il problema è in un file di configurazione.

Errore 5: confusione sulla sintassi del proxy HTTPS

Questo manda in crisi un sacco di persone. Quando imposti https_proxy, l’URL del proxy è di solito http://, non https://. Questo perché Wget invia una richiesta HTTP CONNECT al proxy per creare un tunnel per la sessione HTTPS cifrata.

Corretto:

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

Wget invia CONNECT example.com:443 HTTP/1.1 al proxy e poi incanala HTTPS attraverso il tunnel.

Sbagliato (per URL di destinazione HTTP con endpoint 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 rifiuta del tutto https:// come URL proxy per destinazioni HTTP. Usa https_proxy=http://HOST:PORT/ a meno che la tua organizzazione non abbia documentato in modo esplicito un endpoint proxy HTTPS e tu non l’abbia già testato con la tua build di Wget.

Scheda rapida dei comandi proxy per Wget (riferimento veloce da salvare)

Salva questa tabella tra i preferiti. Raccoglie in un unico posto tutti i flag e le direttive di configurazione proxy di Wget.

Flag / Direttiva	Contesto	Esempio	Note
-e use_proxy=on	CLI	-e use_proxy=on	on è la scelta più sicura; alcune build accettano anche yes
-e http_proxy=	CLI	-e http_proxy=http://proxy:8080/	Includi il prefisso http:// e la barra finale /
-e https_proxy=	CLI	-e https_proxy=http://proxy:8080/	L’URL del proxy è di solito http:// anche per destinazioni HTTPS
--proxy-user	CLI	--proxy-user=admin	Sovrascrive user:pass@ inline
--proxy-password	CLI	--proxy-password=secret	Visibile in ps — evita di usarlo su sistemi condivisi
--no-proxy	CLI	--no-proxy	Bypassa TUTTE le impostazioni proxy da qualsiasi fonte
--no-config	CLI	--no-config	Salta tutti i file di configurazione — utile per il debug
--config=FILE	CLI	--config=/tmp/wgetrc	Percorso di configurazione deterministico — ottimo per Windows e CI
http_proxy	.wgetrc / env	http_proxy = http://proxy:8080/	Nel file di config ci sono spazi attorno a =; nella variabile d’ambiente serve il minuscolo
https_proxy	.wgetrc / env	https_proxy = http://proxy:8080/	Stesso formato di http_proxy
ftp_proxy	.wgetrc / env	ftp_proxy = http://proxy:8080/	Per i recuperi FTP
no_proxy	.wgetrc / env	no_proxy = localhost,127.0.0.1,.corp	Elenco di domini separati da virgola
proxy_user	.wgetrc	proxy_user = admin	Equivalente a --proxy-user
proxy_password	.wgetrc	proxy_password = secret	Proteggi il file con chmod 600

Quando Wget + proxy non è lo strumento giusto (e cosa usare al suo posto)

Dopo tutta questa configurazione del proxy, ecco una considerazione controcorrente: a volte non vale proprio la pena complicarsi la vita.

Molte persone che cercano "wget proxy" in realtà non stanno cercando di scaricare un singolo file. Vogliono raccogliere dati strutturati da siti web — prezzi di prodotti, liste di contatti, annunci immobiliari — e finiscono per scegliere Wget perché è lo strumento da riga di comando che conoscono. Il problema è che Wget ti restituisce HTML grezzo. Devi comunque analizzarlo, ripulirlo e strutturarlo. E se usi proxy rotanti per evitare blocchi, ti ritrovi a gestire una lista di proxy, uno script di download, un parser e una pipeline di esportazione.

Obiettivo	Strumento migliore	Perché
Scaricare un singolo file tramite proxy	wget con flag proxy	Semplice, un solo comando
Rispecchiare un sito o una directory tramite proxy	wget --recursive + configurazione proxy	Il recupero ricorsivo è uno dei punti forti di Wget
Estrarre dati strutturati (tabelle, elenchi, contatti)	Thunderbit	Wget ti dà HTML grezzo — poi devi ancora fare il parsing. L’AI di Thunderbit legge la pagina e restituisce dati strutturati in Excel, Google Sheets, Airtable o Notion senza codice. Lo scraping cloud gestisce rotazione IP e protezioni anti-bot, così eviti del tutto la configurazione del proxy.
Chiamate a REST API tramite proxy	curl	Miglior controllo sugli header, supporto JSON nativo, supporto SOCKS5
Raccolta dati programmata e continuativa	Thunderbit Scheduled Scraper o cron + wget	Thunderbit si adatta quando cambia il layout della pagina; gli script cron + wget possono rompersi senza avvisi

Wget è ottimo per scaricare file. Ma il flusso "configura proxy → ruota IP → scarica HTML → scrivi un parser → esporta in foglio di calcolo" porta via molti passaggi quando in realtà ti serve solo una tabella di dati. Se ti riconosci in questa situazione, la nostra estensione Chrome gestisce l’intera pipeline in due clic. Per approfondire questo approccio, guarda le nostre guide su AI web scraping e web scraping senza programmazione.

Ma se il tuo obiettivo è "scaricare questo file ZIP tramite un proxy aziendale", allora Wget resta lo strumento giusto — e adesso sai come configurarlo nel modo corretto.

Punti chiave da ricordare

La versione breve:

• Quattro metodi, precedenza chiara: i flag CLI hanno priorità sulla configurazione utente, che ha priorità su quella di sistema, che ha priorità sulle variabili d’ambiente. --no-proxy supera tutto.
• Usa sempre il minuscolo per le variabili d’ambiente (http_proxy, non HTTP_PROXY). Il maiuscolo viene ignorato senza avvisi.
• Includi sempre http:// nell’URL del proxy, anche per https_proxy. L’endpoint del proxy è HTTP; per HTTPS usa CONNECT.
• Usa on per i valori booleani in .wgetrc e nei flag -e. È la scelta più compatibile tra le versioni di Wget.
• Utenti Windows: usa --config=C:\path\to\wgetrc per evitare ambiguità sul file di configurazione. Usa set (CMD) o $env: (PowerShell) per le variabili proxy di sessione.
• Utenti con proxy aziendali: Wget non legge i file PAC e non supporta nativamente l’autenticazione NTLM. Se serve, usa Cntlm come relay locale.
• Salva la scheda rapida qui sopra: ti eviterà di rileggere l’articolo ogni volta che ti serve il nome di un flag.

Se il tuo vero obiettivo è l’estrazione di dati strutturati, Thunderbit o curl potrebbero essere una scelta migliore. Il miglior debug è quello che non devi nemmeno iniziare.

FAQ

1. Wget supporta i proxy SOCKS5?

No. GNU Wget 1.x supporta solo proxy HTTP, HTTPS e FTP. Il progetto Wget2 ha ricevuto una richiesta di funzionalità per SOCKS5, ma non è un’opzione standard documentata. Per SOCKS5, usa curl con gli schemi nativi socks5:// o socks5h://, oppure fai girare Wget attraverso proxychains4 per forzare il routing SOCKS.

2. Perché le impostazioni proxy vengono ignorate quando uso HTTP_PROXY in maiuscolo?

Wget legge solo i nomi delle variabili d’ambiente in minuscolo (http_proxy, https_proxy, ftp_proxy, no_proxy). Le varianti in maiuscolo come HTTP_PROXY vengono ignorate senza alcun messaggio — nessun errore, nessun warning. È uno dei problemi più comuni e più frustranti proprio perché non c’è nessun indizio che qualcosa non vada. Usa sempre il minuscolo.

3. Come posso bypassare il proxy per domini specifici?

Usa la direttiva no_proxy, come variabile d’ambiente o in .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

Oppure in ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

I domini sono separati da virgole. Un punto iniziale (.mycompany.com) corrisponde a tutti i sottodomini.

4. Posso usare Wget con proxy rotanti?

Wget non ha una funzione integrata di rotazione proxy. Hai due possibilità: usare un provider di proxy che ruota gli IP lato server (così continui a colpire lo stesso gateway, ma cambia l’IP di uscita), oppure scrivere uno script shell che pesca un proxy casuale da una lista e lo passa a ogni invocazione tramite -e http_proxy=.... Per qualcosa di più complesso — rotazione automatica, retry logic, gestione anti-bot — di solito è meglio uno strumento dedicato allo scraping.

5. Qual è la differenza tra http_proxy e https_proxy in Wget?

http_proxy viene usato quando l’URL di destinazione è http://. https_proxy viene usato quando l’URL di destinazione è https://. In entrambi i casi, l’URL del proxy è di solito un indirizzo http://. Per le destinazioni HTTPS, Wget invia al proxy una richiesta HTTP CONNECT per creare il tunnel, e la cifratura HTTPS vera e propria avviene end-to-end tra Wget e il server di destinazione. Il proxy vede l’hostname (dalla richiesta CONNECT) ma non può leggere il traffico cifrato.

Prova Thunderbit per l’AI Web Scraping Get Started Free

Scopri di più

• I migliori strumenti automatizzati per il web scraping
• Come estrarre dati da un sito web con Python
• I migliori servizi di web scraping
• Web scraping senza farsi bloccare
• Come configurare un server proxy