Cum folosești Wget cu un proxy (și eviți greșelile frecvente)

Configurarea unui proxy în Wget pare o treabă de cinci secunde — până când ajungi să pierzi o oră încercând să afli de ce cererile tale ocolesc complet proxy-ul, fără niciun mesaj de eroare. Am văzut asta atât la administratori de sistem cu experiență, cât și la dezvoltatori juniori.

Cauza reală nu este aproape niciodată proxy-ul în sine. Problema este că Wget poate citi setările de proxy din patru locuri diferite, că eșuează în tăcere când folosești litere mari sau mici greșite la variabile și că există particularități de rețea corporate pe care niciun manual nu le explică pe înțelesul tuturor. Acest ghid acoperă toate metodele de configurare a Wget cu proxy, regulile exacte de prioritate atunci când se suprapun mai multe metode, exemple reale de ieșire în terminal pentru fiecare eroare comună și o secțiune dedicată pentru Windows și pentru utilizatorii din rețele corporate — adică exact publicul pe care aproape toate celelalte tutoriale îl ignoră.

Dificultate: Începător spre intermediar
Timp necesar: ~15 minute pentru citit și configurat; ~2 minute după ce știi ce faci
Ai nevoie de: O instalare funcțională de Wget (instrucțiuni mai jos), adresa proxy-ului (host + port) și, opțional, credențiale pentru proxy

Încearcă Thunderbit pentru extragerea datelor structurate

Ce este Wget și de ce l-ai folosi cu un proxy?

Wget este un instrument din linia de comandă care descarcă fișiere și pagini web de pe internet fără să folosească un browser. Propria descriere GNU îl numește un „descărcător de rețea neinteractiv” — adică rulează în fundal, reia transferurile întrerupte și gestionează descărcările recursive fără ca cineva să dea click pe ceva.

În acest context, un proxy este un server intermediar. În loc ca mașina ta să se conecteze direct la site-ul țintă, Wget trimite cererea către proxy, iar proxy-ul o redirecționează mai departe. Principalele motive pentru care ai face asta sunt:

Conformitate cu firewall-ul corporate — compania ta cere ca tot traficul de ieșire să treacă printr-un proxy aprobat
Confidențialitate și gestionarea IP-ului — cererile par să vină din IP-ul proxy-ului, nu din al tău
Testare geo — poți accesa resurse blocate pe regiuni sau poți verifica comportamentul CDN-urilor dintr-o anumită zonă
Fluxuri de colectare a datelor — descarci HTML prin proxy-uri rotative pentru cercetare sau monitorizare
Medii CI/CD — runner-ele de build din rețele restrictive pot ajunge la internet doar prin proxy

Wget suportă nativ proxy-uri HTTP, HTTPS și FTP. Nu suportă SOCKS5. Dacă ai nevoie de SOCKS5, curl are suport nativ pentru schemele socks4://, socks5:// și socks5h:// — sau poți înfășura Wget cu un instrument precum proxychains4.

Cum instalezi Wget pe Linux, macOS și Windows

Înainte să configurezi proxy-ul, ai nevoie de Wget pe mașina ta. Secțiunea asta e scurtă — este o cerință, nu subiectul principal.

Linux (Debian/Ubuntu și RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Verificare
wget --version

Ubuntu 24.04 LTS include Wget 1.21.4, iar Debian Trixie are 1.25.0. Pachetele CentOS Stream 10 afișează 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

Formula Homebrew oferă în prezent Wget 1.25.0 stabil, cu 396.818 instalări în ultimul an.

Windows (Chocolatey și instalare manuală)

choco install wget
wget --version

Pacchetul GNU Wget de pe Chocolatey raportează peste 10 milioane de descărcări totale, deși în prezent este la versiunea 1.21.4. Binarul ajunge de obicei în C:\ProgramData\chocolatey\bin\wget.exe.

Un aspect important pentru utilizatorii Windows: locația unde Wget caută .wgetrc diferă în funcție de build. Detalii în secțiunea despre Windows de mai jos.

4 modalități de a folosi Wget cu un proxy (și pe care să o alegi)

Patru metode, fiecare cu un alt nivel de acoperire și prioritate:

Flag-uri din linia de comandă cu -e — pentru o singură comandă, ocazional
Fișier de configurare al utilizatorului (~/.wgetrc) — se aplică tuturor comenzilor Wget rulate de tine
Fișier de configurare de sistem (/etc/wgetrc) — se aplică tuturor utilizatorilor de pe mașină
Variabile de mediu (http_proxy, https_proxy) — se aplică întregii sesiuni de shell

Metoda 1: Flag-uri din linia de comandă (proxy de unică folosință)

Ideală pentru teste rapide. Setările dispar după ce comanda se termină.

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

Pentru ținte HTTPS:

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

Test rapid — verifică ce IP apare prin proxy:

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

Dacă rezultatul afișează IP-ul proxy-ului în locul celui propriu, totul funcționează.

Metoda 2: Fișierul de configurare al utilizatorului (~/.wgetrc)

Adaugă aceste linii în ~/.wgetrc (creează fișierul dacă nu există):

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

Observă spațiile din jurul lui = — aceasta este sintaxa documentată pentru .wgetrc. Orice comandă Wget rulezi acum ca utilizatorul respectiv va trece prin proxy.

Metoda 3: Configurare la nivel de sistem (/etc/wgetrc)

Aceleași directive ca în ~/.wgetrc, dar plasate în fișierul de sistem. GNU documentează acest fișier ca startup file global — calea exactă depinde de prefixul de instalare. Locații comune:

/etc/wgetrc (majoritatea managerilor de pachete Linux)
/usr/local/etc/wgetrc (anumite build-uri Homebrew)
Calea afișată în ieșirea wget --version sub „Wgetrc:”

Este util pe servere partajate, în containere Docker sau în orice mediu în care toți utilizatorii trebuie să treacă prin același proxy.

Metoda 4: Variabile de mediu (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

Acestea afectează întreaga sesiune de shell — nu doar Wget. Și instrumente precum curl le vor folosi.

Avertisment critic: Wget citește doar variabilele de mediu scrise cu litere mici. HTTP_PROXY (cu majuscule) este ignorată în tăcere. Nici eroare, nici avertisment, nimic. În secțiunea cu greșeli frecvente voi arăta exact ieșirea din terminal, dar merită să reții asta de acum.

Prioritatea metodelor de proxy: ce are câștig de cauză când sunt setate mai multe

Dacă ai proxy configurat și în variabilele de mediu, și în .wgetrc, și din linia de comandă, care dintre ele câștigă? Nimeni nu explică limpede acest lucru, așa că l-am testat.

Iată prioritatea testată și documentată:

Prioritate	Metodă	Acoperire	Suprascrie
1 (cea mai mare)	Flag-uri CLI `-e`	O singură comandă	Totul
2	`~/.wgetrc`	Utilizatorul curent	Configurația de sistem + variabilele de mediu
3	`/etc/wgetrc`	La nivel de sistem	Doar variabilele de mediu
4 (cea mai mică)	Variabilele de mediu `http_proxy` / `https_proxy`	Sesiunea de shell	Nimic

Am verificat acest lucru pe Wget 1.25.0 setând proxy-uri diferite la fiecare nivel. Cu mediul setat la portul 3128, fișierul de configurare la 3129 și linia de comandă la 3130:

Configurația bate mediul: Wget s-a conectat la portul 3129, ignorând 3128.
CLI bate configurația: Wget s-a conectat la portul 3130, ignorând atât 3129, cât și 3128.

Varianta de ocolire este --no-proxy. Aceasta ignoră toate setările de proxy, indiferent de unde au fost definite:

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

Situație practică: administratorul de sistem a setat un proxy în /etc/wgetrc, dar tu trebuie să accesezi direct un server intern. Folosește --no-proxy doar pentru acea comandă, în loc să modifici configurația de sistem.

Cum folosești Wget cu un proxy autentificat

Majoritatea proxy-urilor comerciale și rezidențiale cer nume de utilizator și parolă. Wget suportă asta prin două abordări, ambele folosind autentificarea HTTP Basic pentru credențialele proxy-ului.

Credențiale incluse direct în URL-ul proxy-ului

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

Funcționează și în .wgetrc:

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

Folosind flag-urile --proxy-user și --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

Aceste flag-uri au prioritate față de orice user:pass@ inclus direct în URL-ul proxy-ului.

Cum păstrezi credențialele în siguranță

Ambele metode pot expune credențialele. GNU avertizează că parolele din linia de comandă pot fi văzute prin ps sau alte instrumente de listare a proceselor. Măsuri de reducere a riscului:

Mașini cu un singur utilizator: Stochează credențialele în ~/.wgetrc și restricționează fișierul: chmod 600 ~/.wgetrc
Pipeline-uri CI/CD: Folosește GitHub Actions encrypted secrets sau echivalentul platformei tale. Trimite-le ca variabile de mediu scrise cu litere mici în definiția pasului — niciodată hardcodate în YAML.
Build-uri Docker: Nu folosi ARG sau ENV pentru secrete. Documentația Docker avertizează explicit că argumentele de build pot rămâne în imaginea finală. Folosește în schimb montări de secrete BuildKit.
Controlul versiunilor: Nu comite niciodată .wgetrc cu credențiale. Adaugă-l în .gitignore.

Un detaliu specific Wget pentru GitHub Actions: numele secretelor sunt stocate convențional cu majuscule, dar variabilele de mediu pe care le expui către Wget trebuie să fie cu litere mici (http_proxy, nu HTTP_PROXY).

Cum folosești Wget cu un proxy pe Windows și în spatele unui firewall corporate

Cele mai multe articole despre acest subiect se opresc la „instalează cu Chocolatey.” Dacă ești pe Windows sau în spatele unui proxy corporate, de fapt acolo încep problemele.

Unde caută Windows fișierul .wgetrc

Documentația GNU spune că Wget citește $HOME/.wgetrc dacă variabila WGETRC nu indică altceva. Pe Windows, $HOME poate fi mapat la %USERPROFILE% (de exemplu, C:\Users\alice), sau nu — depinde dacă folosești build-ul Chocolatey, un build MSYS2, Git Bash sau un binar independent.

Recomandarea mea: evită presupunerile și folosește flag-ul --config pentru un comportament predictibil:

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

Ca să testezi dacă build-ul tău citește un fișier de configurare dintr-o anumită locație, creează un fișier de test care indică spre un proxy sigur greșit:

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

Apoi rulează:

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

Dacă Wget încearcă să se conecteze la 127.0.0.1:3128, înseamnă că a citit fișierul.

Cum setezi variabilele de mediu pentru proxy pe Windows

CMD (doar pentru sesiunea curentă):

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

PowerShell (doar pentru sesiunea curentă):

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

Permanent (persistă după restart):

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

După setx, trebuie să deschizi o fereastră nouă de terminal. Sesiunea curentă nu va vedea schimbarea.

Probleme frecvente în rețele corporate: fișiere PAC, autentificare NTLM și aflarea adresei proxy-ului

Trei lucruri care îi încurcă constant pe utilizatorii corporate:

Fișiere PAC: Multe organizații folosesc fișiere Proxy Auto-Configuration (PAC) — scripturi bazate pe JavaScript care spun browserelor ce proxy să folosească pentru fiecare URL. Wget nu are interpret JavaScript, deci nu poate citi fișiere PAC. Și documentația curl spune același lucru. Soluția: deschide fișierul PAC (sau întreabă IT-ul), găsește rezultatul PROXY host:port pentru domeniul tău și configurează acea adresă statică în Wget.

Autentificare NTLM: Autentificarea proxy-ului în Wget implementează doar Basic auth. Dacă proxy-ul corporate cere NTLM și primești 407 Proxy Authentication Required, nu pierde timpul încercând diferite variante de --proxy-user. Instalează Cntlm — un proxy local intermediar care gestionează autentificarea NTLM/NTLMv2 și oferă către Wget o interfață Basic auth. Cntlm este încă întreținut (ultima actualizare în octombrie 2025, ~395 descărcări/săptămână).

Arbore de decizie pentru utilizatorii corporate:

Încearcă set http_proxy=http://YOUR_PROXY:PORT/ și rulează Wget.
Dacă primești eroarea 407 și compania folosește NTLM → instalează Cntlm, configurează-l cu credențialele de domeniu și direcționează Wget către portul local al Cntlm (de obicei http://127.0.0.1:3128/).
Dacă firma folosește un fișier PAC → extrage adresa reală PROXY host:port din fișier sau cere IT-ului adresa statică a proxy-ului.

Porturi corporate frecvente pentru proxy: 3128 (stil Squid), 8080 (proxy HTTP general), 8888 (proxy-uri de debug precum Fiddler/Charles). Sunt convenții, nu garanții.

Greșeli frecvente la folosirea Wget cu un proxy (cu ieșiri reale de eroare)

Acum vine partea care justifică titlul. Toate ieșirile de mai jos au fost reproduse pe Wget 1.25.0 (macOS, Homebrew) la 2026-06-01.

Greșeala 1: lipsește prefixul http://

Unele ghiduri mai vechi spun că asta strică întotdeauna. În Wget 1.25.0, setarea http_proxy=127.0.0.1:3128 chiar funcționează — Wget adaugă în tăcere http://:

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.

Totuși s-a conectat la proxy-ul corect. Dar eu recomand să incluzi mereu prefixul http:// și o bară oblică finală. Elimină ambiguitatea între versiunile Wget și face sintaxa pentru credențiale (http://user:pass@host:port/) neechivocă.

Greșeala 2: use_proxy=yes vs. use_proxy=on

Atât yes, cât și on au funcționat în testele mele pe Wget 1.25.0. Dar valorile invalide eșuează cu un mesaj clar:

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

Folosește on pentru compatibilitate cât mai largă — se aliniază cu formatul boolean documentat în manual și cu indiciul de eroare al Wget.

Greșeala 3: HTTP_PROXY cu majuscule este ignorat în tăcere

Aceasta este cea mai enervantă problemă, pentru că nu apare niciun mesaj de eroare. Wget pur și simplu se conectează direct, ca și cum nu ai fi setat niciun proxy.

Varianta cu majuscule (nu funcționează — nu se folosește 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

Varianta cu litere mici (funcționează — încearcă proxy-ul):

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.

Vezi diferența? Varianta cu majuscule a rezolvat direct example.com. Varianta cu litere mici a încercat proxy-ul. Niciun avertisment în niciun caz. Curl are o particularitate similară — acceptă majuscule pentru majoritatea variabilelor de proxy, dar respinge explicit HTTP_PROXY cu majuscule din motive de securitate.

Rezolvare: folosește întotdeauna http_proxy și https_proxy cu litere mici.

Greșeala 4: un proxy vechi în .wgetrc provoacă „Connection Refused”

Dacă tu (sau adminul, sau o imagine Docker) ai lăsat o adresă veche de proxy într-un fișier de configurare, vei vedea ceva de genul:

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.

Eroarea indică IP-ul proxy-ului vechi, nu site-ul țintă. Ordinea de diagnostic, urmând ierarhia de prioritate:

Verifică în comandă flag-urile -e sau aliasurile de shell
Verifică ~/.wgetrc (sau fișierul indicat de WGETRC)
Verifică fișierul de sistem (calea afișată de wget --version)
Verifică mediul: env | grep -i proxy

Pentru depanare, --no-config este prietenul tău — îi spune lui Wget să sară peste toate fișierele de configurare:

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

Dacă asta funcționează, problema este într-un fișier de configurare.

Greșeala 5: confuzie legată de sintaxa proxy-ului HTTPS

Asta îi încurcă pe mulți. Când setezi https_proxy, URL-ul proxy-ului este de obicei http://, nu https://. Asta pentru că Wget trimite o cerere HTTP CONNECT prin proxy pentru a crea un tunel pentru sesiunea HTTPS criptată.

Corect:

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

Wget trimite CONNECT example.com:443 HTTP/1.1 către proxy, apoi transmite HTTPS prin tunel.

Greșit (pentru URL-uri țintă HTTP cu un 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 respinge direct https:// ca URL de proxy pentru ținte HTTP. Folosește https_proxy=http://HOST:PORT/ cu excepția cazului în care organizația ta a documentat explicit un endpoint HTTPS pentru proxy și l-ai testat cu build-ul tău de Wget.

Fișă rapidă de comenzi Wget pentru proxy (referință rapidă, ușor de salvat)

Salvează tabelul acesta. Concentrează într-un singur loc toate flag-urile și directivele Wget legate de proxy.

Flag / Directivă	Context	Exemplu	Observații
`-e use_proxy=on`	CLI	`-e use_proxy=on`	`on` este cea mai sigură opțiune; unele build-uri acceptă și `yes`
`-e http_proxy=`	CLI	`-e http_proxy=http://proxy:8080/`	Include prefixul `http://` și bara oblică finală `/`
`-e https_proxy=`	CLI	`-e https_proxy=http://proxy:8080/`	URL-ul proxy-ului este de obicei `http://` chiar și pentru ținte HTTPS
`--proxy-user`	CLI	`--proxy-user=admin`	Suprascrie `user:pass@` inclus direct
`--proxy-password`	CLI	`--proxy-password=secret`	Vizibil în `ps` — evită pe sisteme partajate
`--no-proxy`	CLI	`--no-proxy`	Ocolește TOATE setările de proxy din orice sursă
`--no-config`	CLI	`--no-config`	Sare peste toate fișierele de configurare — util la depanare
`--config=FILE`	CLI	`--config=/tmp/wgetrc`	Cale de configurare deterministă — excelent pentru Windows și CI
`http_proxy`	`.wgetrc` / env	`http_proxy = http://proxy:8080/`	În fișierul de configurare se pun spații în jurul lui `=`; variabila de mediu se scrie cu litere mici
`https_proxy`	`.wgetrc` / env	`https_proxy = http://proxy:8080/`	Același format ca `http_proxy`
`ftp_proxy`	`.wgetrc` / env	`ftp_proxy = http://proxy:8080/`	Pentru descărcări FTP
`no_proxy`	`.wgetrc` / env	`no_proxy = localhost,127.0.0.1,.corp`	Listă de domenii separată prin virgulă
`proxy_user`	`.wgetrc`	`proxy_user = admin`	Echivalent cu `--proxy-user`
`proxy_password`	`.wgetrc`	`proxy_password = secret`	Protejează fișierul cu `chmod 600`

Când Wget + proxy nu este instrumentul potrivit (și ce să folosești în schimb)

După toată configurația asta de proxy, iată o idee contrariană: uneori nici nu merită să te complici.

Mulți dintre cei care caută „wget proxy” nu încearcă, de fapt, să descarce un singur fișier. Ei vor să colecteze date structurate de pe site-uri — prețuri de produse, liste de contacte, anunțuri imobiliare — și au ajuns la Wget fiindcă este instrumentul din linia de comandă pe care îl cunosc. Problema este că Wget îți oferă HTML brut. Încă trebuie să îl parsezi, să îl cureți și să îl structurezi. Iar dacă rotești proxy-uri ca să eviți blocările, ajungi să întreții o listă de proxy-uri, un script de descărcare, un parser și un flux de export.

Scopul tău	Cel mai bun instrument	De ce
Să descarci un singur fișier prin proxy	`wget` cu flag-uri pentru proxy	Simplu, o singură comandă
Să clonezi un site sau un director prin proxy	`wget --recursive` + configurare proxy	Descărcarea recursivă este unul dintre punctele forte ale Wget
Să extragi date structurate (tabele, listări, contacte)	Thunderbit	Wget îți dă HTML brut — tot mai trebuie să îl parsezi. AI-ul Thunderbit citește pagina și scoate date structurate în Excel, Google Sheets, Airtable sau Notion, fără cod. Scraping-ul în cloud gestionează rotația IP-urilor și măsurile anti-bot, așa că sari complet peste setarea proxy-ului.
Să faci apeluri REST API prin proxy	`curl`	Control mai bun al headerelor, suport nativ JSON, suport SOCKS5
Colectare continuă, programată, de date	Thunderbit Scheduled Scraper sau `cron` + wget	Thunderbit se adaptează când se schimbă structura paginii; scripturile cron + wget se pot strica în tăcere

Wget este foarte bun la descărcări de fișiere. Dar fluxul „configurezi proxy-ul → rotești IP-urile → descarci HTML → scrii un parser → exporți în spreadsheet” are foarte multe componente mobile atunci când, de fapt, tu vrei doar un tabel cu date. Dacă ți se pare familiar, extensia noastră Chrome rezolvă întregul flux în două clickuri. Pentru mai multe despre această abordare, vezi ghidurile noastre despre AI web scraping și web scraping fără cod.

Dar dacă obiectivul tău este „descarcă acest fișier ZIP printr-un proxy corporate” — Wget rămâne instrumentul potrivit, iar acum știi cum să-l configurezi corect.

Idei esențiale

Varianta scurtă:

Patru metode, prioritate clară: Flag-urile CLI suprascriu configurația utilizatorului, care suprascrie configurația de sistem, care suprascrie variabilele de mediu. --no-proxy suprascrie tot.
Folosește întotdeauna litere mici pentru variabilele de mediu (http_proxy, nu HTTP_PROXY). Varianta cu majuscule este ignorată în tăcere.
Include întotdeauna http:// în URL-ul proxy-ului, chiar și pentru https_proxy. Endpoint-ul proxy este HTTP; HTTPS este tunelat prin CONNECT.
Folosește on pentru valorile booleene în .wgetrc și în flag-urile -e. Este cea mai sigură alegere între versiunile Wget.
Utilizatori Windows: folosește --config=C:\cale\către\wgetrc ca să eviți ambiguitățile fișierului de configurare. Folosește set (CMD) sau $env: (PowerShell) pentru variabilele de proxy ale sesiunii.
Utilizatori corporate: Wget nu poate citi fișiere PAC și nu suportă nativ autentificarea NTLM. Folosește Cntlm ca relay local dacă este necesar.
Salvează fișa rapidă de mai sus — te va scuti să recitești articolul de fiecare dată când ai nevoie de numele unui flag.

Dacă obiectivul tău real este extragerea de date structurate, Thunderbit sau curl pot fi o alegere mai bună. Cea mai bună sesiune de depanare este cea pe care nu trebuie să o începi niciodată.

Întrebări frecvente

1. Wget suportă proxy-uri SOCKS5?

Nu. GNU Wget 1.x suportă doar proxy-uri HTTP, HTTPS și FTP. Proiectul Wget2 a avut SOCKS5 ca cerere de funcționalitate, dar nu este o opțiune standard documentată. Pentru SOCKS5, folosește curl cu schemele sale native socks5:// sau socks5h://, ori înfășoară Wget cu proxychains4 pentru a forța rutarea prin SOCKS.

2. De ce este ignorată setarea mea de proxy când folosesc HTTP_PROXY cu majuscule?

Wget citește doar variabilele de mediu scrise cu litere mici (http_proxy, https_proxy, ftp_proxy, no_proxy). Variantele cu majuscule, precum HTTP_PROXY, sunt ignorate în tăcere — fără eroare, fără avertisment. Este una dintre cele mai comune și mai frustrante probleme, tocmai pentru că nu există niciun indiciu că ceva nu merge. Folosește întotdeauna litere mici.

3. Cum ocolesc proxy-ul pentru anumite domenii?

Folosește directiva no_proxy, fie ca variabilă de mediu, fie în .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

Sau în ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

Domeniile se separă cu virgulă. Un punct la început (.mycompany.com) include toate subdomeniile.

4. Pot folosi Wget cu proxy-uri rotative?

Wget nu are rotație de proxy încorporată. Ai două opțiuni: folosești un furnizor de proxy care rotește IP-urile pe serverul lor (astfel încât tu tot accesezi aceeași adresă de gateway, dar IP-ul de ieșire se schimbă), sau scrii un script shell care alege aleator un proxy dintr-o listă și îl transmite la fiecare rulare prin -e http_proxy=.... Pentru ceva mai complex — rotație automată, logică de retry, gestionarea anti-bot — de obicei e mai potrivit un instrument dedicat de scraping.

5. Care este diferența dintre http_proxy și https_proxy în Wget?

http_proxy se folosește când URL-ul țintă este http://. https_proxy se folosește când URL-ul țintă este https://. În ambele cazuri, URL-ul proxy-ului este de obicei tot o adresă http://. Pentru țintele HTTPS, Wget trimite prin proxy o cerere HTTP CONNECT pentru a crea un tunel, iar criptarea HTTPS propriu-zisă are loc cap-coadă între Wget și serverul țintă. Proxy-ul vede hostname-ul (din cererea CONNECT), dar nu poate citi traficul criptat.

Încearcă Thunderbit pentru AI Web Scraping Get Started Free

Află mai multe