Wget-proxyconfiguratie lijkt iets van vijf seconden — tot je een uur kwijt bent aan uitzoeken waarom je verzoeken de proxy volledig omzeilen, zonder ook maar één foutmelding. Ik heb dit zien gebeuren bij zowel ervaren sysadmins als junior developers.
De oorzaak ligt bijna nooit bij de proxy zelf. Het zit ’m in de vier verschillende plekken waar Wget proxy-instellingen kan inlezen, de stille fouten als je de verkeerde hoofdletters gebruikt voor variabelen, en de eigenaardigheden van bedrijfsnetwerken die in geen enkele man-pagina netjes worden uitgelegd. Deze gids behandelt elke manier om Wget met een proxy te configureren, de precieze prioriteitsregels als meerdere methoden botsen, echte terminaluitvoer voor alle veelvoorkomende fouten, en een aparte sectie voor Windows-gebruikers en mensen achter bedrijfsfirewalls — precies de groep die in vrijwel elke andere handleiding wordt overgeslagen.
- Moeilijkheid: Beginner tot gemiddeld
- Benodigde tijd: ~15 minuten om te lezen en in te stellen; ~2 minuten zodra je weet wat je doet
- Wat je nodig hebt: Een werkende Wget-installatie (instructies hieronder), een proxy-adres (host + poort) en eventueel proxy-inloggegevens
Probeer Thunderbit voor gestructureerde data-extractie
Wat is Wget en waarom zou je het met een proxy gebruiken?
Wget is een command-line tool waarmee je bestanden en webpagina’s van internet downloadt zonder browser. GNU’s eigen beschrijving noemt het een “non-interactive network downloader” — het draait dus op de achtergrond, hervat onderbroken overdrachten en kan recursief downloaden zonder dat iemand ergens op hoeft te klikken.
Een proxy is in deze context een tussenserver. In plaats van dat je machine rechtstreeks verbinding maakt met een doelwebsite, stuurt Wget het verzoek naar de proxy, en die stuurt het door. De belangrijkste redenen om dat te doen zijn:
- Naleving van bedrijfsfirewalls — je organisatie eist dat al het uitgaande verkeer via een goedgekeurde proxy loopt
- Privacy en IP-beheer — verzoeken lijken afkomstig van het IP-adres van de proxy, niet van jou
- Geo-testen — geografisch geblokkeerde resources ophalen of CDN-gedrag testen vanuit een specifieke regio
- Dataverzamelingspijplijnen — HTML downloaden via roterende proxies voor onderzoek of monitoring
- CI/CD-omgevingen — build runners op afgeschermde netwerken die alleen via een proxy internettoegang hebben
Wget ondersteunt standaard HTTP-, HTTPS- en FTP-proxies. SOCKS5 wordt niet ondersteund. Als je SOCKS5 nodig hebt, heeft curl native ondersteuning voor socks4://, socks5:// en socks5h:// — of je kunt Wget omhullen met een tool zoals proxychains4.
Wget installeren op Linux, macOS en Windows
Voordat je proxies instelt, moet Wget op je machine staan. Dit stuk is kort — het is een vereiste, niet de hoofdact.
Linux (Debian/Ubuntu en RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# Controleren
wget --version
Ubuntu 24.04 LTS wordt geleverd met Wget 1.21.4, terwijl Debian Trixie 1.25.0 heeft. CentOS Stream 10-pakketten laten 1.24.5 zien.
macOS (Homebrew)
brew install wget
wget --version
Homebrew’s formule levert momenteel de stabiele Wget 1.25.0, met 396.818 installaties in het afgelopen jaar.
Windows (Chocolatey en handmatige installatie)
choco install wget
wget --version
Chocolatey’s GNU Wget-pakket meldt meer dan 10 miljoen totale downloads, al zit het momenteel op versie 1.21.4. De binary komt meestal terecht in C:\ProgramData\chocolatey\bin\wget.exe.
Een belangrijke tip voor Windows-gebruikers: waar Wget naar .wgetrc zoekt, verschilt per build. Meer daarover in de Windows-sectie hieronder.
4 manieren om Wget met een proxy te gebruiken (en welke je moet kiezen)
Vier methoden, elk met een andere scope en prioriteit:
- Command-line
-eflags — eenmalig, voor één opdracht - Gebruikersconfiguratiebestand (
~/.wgetrc) — geldt voor elk Wget-commando dat jij uitvoert - Systeemconfiguratiebestand (
/etc/wgetrc) — geldt voor alle gebruikers op de machine - Omgevingsvariabelen (
http_proxy,https_proxy) — geldt voor de hele shellsessie
Methode 1: Command-line flags (eenmalige proxy)
Ideaal voor snelle tests. De instellingen verdwijnen zodra het commando klaar is.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
Voor HTTPS-doelen:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
Snelle rooktest — haal je zichtbare IP op via de proxy:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
Als de uitvoer het IP-adres van de proxy toont in plaats van dat van jou, zit je goed.
Methode 2: Gebruikersconfiguratiebestand (~/.wgetrc)
Voeg deze regels toe aan ~/.wgetrc (maak het bestand aan als het nog niet bestaat):
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
Let op de spaties rondom = — dat is de gedocumenteerde .wgetrc-syntax. Elk Wget-commando dat je als deze gebruiker uitvoert, loopt voortaan via de proxy.
Methode 3: Systeemwijd configbestand (/etc/wgetrc)
Dezelfde directives als in ~/.wgetrc, maar dan in het systeemconfiguratiebestand. GNU beschrijft dit als een globaal opstartbestand — het exacte pad hangt af van je installprefix. Veelvoorkomende locaties:
/etc/wgetrc(meeste Linux-package managers)/usr/local/etc/wgetrc(sommige Homebrew-builds)- Het pad dat je ziet in de uitvoer van
wget --versiononder “Wgetrc:”
Dit is handig voor gedeelde servers, Docker-containers of elke omgeving waarin alle gebruikers via dezelfde proxy moeten lopen.
Methode 4: Omgevingsvariabelen (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
Deze hebben effect op je hele shellsessie — niet alleen op Wget. Tools zoals curl pikken ze ook op.
Belangrijke waarschuwing: Wget leest alleen kleine letters in omgevingsvariabelen. HTTP_PROXY (hoofdletters) wordt stilzwijgend genegeerd. Geen fout, geen waarschuwing, niets. In de valkuilen-sectie laat ik de exacte terminaluitvoer zien, maar dit is alvast iets om goed te onthouden.
Prioriteit van proxy-methodes: wat wint wanneer meerdere methodes zijn ingesteld?
Als je een proxy hebt ingesteld in je omgevingsvariabelen en in .wgetrc en op de command line, welke wint dan? Niemand legt dit duidelijk uit, dus ik heb het getest.
Hier is de geteste en gedocumenteerde volgorde van prioriteit:
| Prioriteit | Methode | Scope | Overschrijft |
|---|---|---|---|
| 1 (hoogste) | -e CLI-flags | Eén commando | Alles |
| 2 | ~/.wgetrc | Huidige gebruiker | Systeemconfig + omgevingsvariabelen |
| 3 | /etc/wgetrc | Systeemwijd | Alleen omgevingsvariabelen |
| 4 (laagste) | http_proxy / https_proxy omgevingsvariabelen | Shellsessie | Niets |
Ik heb dit geverifieerd op Wget 1.25.0 door op elk niveau conflicterende proxies in te stellen. Met de omgeving op poort 3128, het configuratiebestand op 3129 en de CLI op 3130:
- Config wint van omgeving: Wget verbond met poort 3129 en negeerde 3128.
- CLI wint van config: Wget verbond met poort 3130 en negeerde zowel 3129 als 3128.
De uitweg is --no-proxy. Daarmee omzeil je alle proxy-instellingen, ongeacht waar ze zijn geconfigureerd:
wget --no-proxy https://internal-server.company.com/report.pdf
Praktisch voorbeeld: je sysadmin heeft een proxy ingesteld in /etc/wgetrc, maar jij moet een interne server rechtstreeks bereiken. Gebruik dan --no-proxy voor dat ene commando in plaats van het systeemconfiguratiebestand aan te passen.
Wget gebruiken met een geauthenticeerde proxy
De meeste zakelijke en residentiële proxies vereisen een gebruikersnaam en wachtwoord. Wget ondersteunt dit via twee benaderingen, beide met HTTP Basic-authenticatie voor proxygegevens.
Inloggegevens direct in de proxy-URL
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
Dit werkt ook in .wgetrc:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
Met de flags --proxy-user en --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
Deze flags overschrijven alles wat via user:pass@ in de proxy-URL is ingebouwd.
Inloggegevens veilig houden
Beide methoden lekken inloggegevens. GNU waarschuwt dat wachtwoorden op de command line zichtbaar zijn via ps of andere proceslijsttools. Maatregelen:
- Machines voor één gebruiker: Bewaar inloggegevens in
~/.wgetrcen vergrendel het bestand:chmod 600 ~/.wgetrc - CI/CD-pipelines: Gebruik GitHub Actions encrypted secrets of een equivalent op jouw platform. Geef ze door als omgevingsvariabelen in kleine letters in de step-definitie — nooit hardcoden in YAML.
- Docker-builds: Gebruik geen
ARGofENVvoor geheimen. Docker waarschuwt expliciet dat build arguments in het uiteindelijke image kunnen achterblijven. Gebruik in plaats daarvan BuildKit secret mounts. - Versiebeheer: Commit nooit een
.wgetrcmet credentials. Voeg het bestand toe aan.gitignore.
Een Wget-specifieke nuance voor GitHub Actions: geheimnamen worden volgens conventie in hoofdletters opgeslagen, maar de omgevingsvariabelen die je aan Wget doorgeeft moeten in kleine letters zijn (http_proxy, niet HTTP_PROXY).
Wget gebruiken met een proxy op Windows en achter bedrijfsfirewalls
De meeste artikelen over dit onderwerp blijven steken bij “installeer met Chocolatey”. Als je op Windows zit of achter een bedrijfsproxy werkt, beginnen je problemen daar juist pas.
Waar Windows naar .wgetrc zoekt
De GNU-documentatie zegt dat Wget $HOME/.wgetrc leest, tenzij de omgevingsvariabele WGETRC naar iets anders wijst. Op Windows kan $HOME worden gemapt naar %USERPROFILE% (bijv. C:\Users\alice), maar dat hoeft niet — afhankelijk van of je de Chocolatey-build, een MSYS2-build, Git Bash of een losse binary gebruikt.
Mijn advies: laat het giswerk achterwege en gebruik de --config-flag voor voorspelbaar gedrag:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
Om te testen of jouw build een configuratiebestand op een specifieke locatie leest, maak je een testbestand dat naar een bekend verkeerde proxy wijst:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
Voer daarna uit:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Als Wget probeert verbinding te maken met 127.0.0.1:3128, dan heeft het bestand gelezen.
Proxy-omgevingsvariabelen instellen op Windows
CMD (alleen voor deze sessie):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (alleen voor deze sessie):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
Permanent (blijft na herstart bestaan):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
Na setx moet je een nieuw terminalvenster openen. De huidige sessie ziet de wijziging niet.
Veelvoorkomende bedrijfsproxy-valkuilen: PAC-bestanden, NTLM-authenticatie en je proxy-adres vinden
Drie dingen die bedrijfsgebruikers steeds weer laten struikelen:
PAC-bestanden: Veel organisaties gebruiken Proxy Auto-Configuration (PAC)-bestanden — JavaScript-gebaseerde scripts die browsers vertellen welke proxy ze voor welke URL moeten gebruiken. Wget heeft geen JavaScript-interpreter, dus het kan PAC-bestanden niet lezen. De documentatie van curl zegt hetzelfde. De oplossing: open het PAC-bestand (of vraag IT), zoek de PROXY host:port-uitkomst voor jouw doeldomein en stel dat statische adres in Wget in.
NTLM-authenticatie: Wget’s proxy-authenticatie ondersteunt alleen Basic auth. Als je bedrijfsproxy NTLM vereist en je krijgt 407 Proxy Authentication Required, verspil dan geen tijd aan verschillende --proxy-user-varianten. Installeer Cntlm — een lokale relay die NTLM/NTLMv2-afhandeling doet en voor Wget een Basic-auth interface presenteert. Cntlm wordt nog steeds onderhouden (laatste update oktober 2025, ~395 downloads/week).
Beslisboom voor bedrijfsproxygebruikers:
- Probeer
set http_proxy=http://YOUR_PROXY:PORT/en voer Wget uit. - Krijg je een
407-fout en gebruikt je bedrijf NTLM → installeer Cntlm, configureer het met je domeinreferenties en verwijs Wget naar de lokale poort van Cntlm (meestalhttp://127.0.0.1:3128/). - Gebruikt het bedrijf een PAC-bestand → haal de echte
PROXY host:portuit het PAC-bestand of vraag IT om het statische proxy-adres.
Veelgebruikte bedrijfsproxy-poorten: 3128 (Squid-stijl), 8080 (algemene HTTP-proxy), 8888 (debuggingproxies zoals Fiddler/Charles). Dit zijn conventies, geen garanties.
Veelvoorkomende valkuilen bij Wget met een proxy (met echte foutuitvoer)
Nu het beloofde deel uit de titel. Alle onderstaande output is gereproduceerd op Wget 1.25.0 (macOS, Homebrew) op 2026-06-01.
Valkuil 1: ontbrekend http://-voorvoegsel
Sommige oudere handleidingen beweren dat dit altijd misgaat. In Wget 1.25.0 werkt http_proxy=127.0.0.1:3128 juist wel — Wget zet er stilzwijgend http:// voor:
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.
Het verbond nog steeds met de juiste proxy. Maar ik raad je aan om toch altijd http:// en een afsluitende slash te gebruiken. Dat voorkomt ambiguïteit tussen Wget-versies en maakt credentials-syntax (http://user:pass@host:port/) ondubbelzinnig.
Valkuil 2: use_proxy=yes versus use_proxy=on
Zowel yes als on werkten in mijn tests met Wget 1.25.0. Maar ongeldige waarden leveren een duidelijke fout op:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
Gebruik on voor de breedste compatibiliteit — het sluit aan bij de gedocumenteerde booleansyntaxis in de handleiding en bij Wget’s eigen foutmelding.
Valkuil 3: hoofdletters HTTP_PROXY worden stilzwijgend genegeerd
Dit is de frustrerendste valkuil, want er is helemaal geen foutmelding. Wget maakt gewoon rechtstreeks verbinding, alsof je nooit een proxy hebt ingesteld.
Hoofdletters (kapot — geen proxy gebruikt):
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
Kleine letters (werkt — proxy wordt geprobeerd):
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.
Zie je het verschil? De variant met hoofdletters loste example.com rechtstreeks op. De variant met kleine letters probeerde de proxy. In beide gevallen geen waarschuwing. Curl heeft een vergelijkbare eigenaardigheid — het accepteert hoofdletters voor de meeste proxyvariabelen, maar wijst uppercase HTTP_PROXY expliciet af om veiligheidsredenen.
Oplossing: Gebruik altijd kleine letters: http_proxy en https_proxy.
Valkuil 4: een verouderde proxy in .wgetrc veroorzaakt “Connection refused”
Als jij (of je sysadmin, of een Docker-image) een oud proxy-adres in een configuratiebestand hebt laten staan, zie je iets als dit:
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.
De fout wijst naar het oude proxy-IP, niet naar de doelsite. Diagnosevolgorde (volgens de prioriteitshiërarchie):
- Controleer je commando op
-eflags of shell-aliases - Controleer
~/.wgetrc(of het bestand dat doorWGETRCwordt aangewezen) - Controleer de systeemconfiguratie (het pad dat
wget --versiontoont) - Controleer de omgeving:
env | grep -i proxy
Voor debugging is --no-config je vriend — daarmee slaat Wget alle configuratiebestanden over:
wget --no-config --spider http://example.com/
Werkt dat wel, dan zit het probleem in een configuratiebestand.
Valkuil 5: verwarring over HTTPS-proxysyntax
Dit laat veel mensen struikelen. Wanneer je https_proxy instelt, is de proxy-URL zelf meestal http://, niet https://. Dat komt omdat Wget een HTTP CONNECT-verzoek via de proxy stuurt om een tunnel te maken voor de versleutelde HTTPS-sessie.
Correct:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget stuurt dan CONNECT example.com:443 HTTP/1.1 naar de proxy en tunneled HTTPS erdoorheen.
Onjuist (voor HTTP-doel-URL’s met een HTTPS-proxy-endpoint):
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 wijst https:// als proxy-URL voor HTTP-doelen direct af. Gebruik https_proxy=http://HOST:PORT/ tenzij je organisatie specifiek een HTTPS-proxy-endpoint heeft gedocumenteerd en je dit hebt getest met jouw Wget-build.
Wget proxy-command cheat sheet (handige snelreferentie)
Bookmark deze tabel. Hij bundelt alle proxy-gerelateerde Wget-flags en configuratiedirectives op één plek.
| Flag / directive | Context | Voorbeeld | Opmerkingen |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on is het veiligst; sommige builds accepteren ook yes |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | Voeg het http://-voorvoegsel en de afsluitende / toe |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | De proxy-URL is meestal http://, zelfs voor HTTPS-doelen |
--proxy-user | CLI | --proxy-user=admin | Overschrijft inline user:pass@ |
--proxy-password | CLI | --proxy-password=secret | Zichtbaar in ps — vermijd op gedeelde systemen |
--no-proxy | CLI | --no-proxy | Omzeilt ALLE proxy-instellingen uit alle bronnen |
--no-config | CLI | --no-config | Slaat alle configuratiebestanden over — handig voor debugging |
--config=FILE | CLI | --config=/tmp/wgetrc | Voorspelbaar configuratiepad — ideaal voor Windows en CI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | Configbestand gebruikt spaties rond =; env var gebruikt kleine letters |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | Zelfde formaat als http_proxy |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | Voor FTP-downloads |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | Komma-gescheiden domeinlijst |
proxy_user | .wgetrc | proxy_user = admin | Equivalent aan --proxy-user |
proxy_password | .wgetrc | proxy_password = secret | Beveilig het bestand met chmod 600 |
Wanneer Wget + proxy niet de juiste keuze is (en wat je dan beter kunt gebruiken)
Na al die proxyconfiguratie volgt hier een tegendraadse observatie: soms moet je er gewoon niet aan beginnen.
Veel mensen die zoeken op “wget proxy” willen eigenlijk niet één bestand downloaden. Ze willen gestructureerde data van websites halen — productprijzen, contactlijsten, vastgoedaanbod — en grijpen automatisch naar Wget omdat dat het command-line tool is dat ze kennen. Het probleem is dat Wget je ruwe HTML geeft. Die moet je nog steeds parsen, opschonen en structureren. En als je roterende proxies gebruikt om blokkades te omzeilen, beheer je ineens een proxylijst, een downloadscript, een parser en een exportpipeline.
| Jouw doel | Beste tool | Waarom |
|---|---|---|
| Eén bestand downloaden via een proxy | wget met proxy-flags | Simpel, één commando |
| Een site of map spiegelen via een proxy | wget --recursive + proxyconfiguratie | Recursief ophalen is een kernkracht van Wget |
| Gestructureerde data scrapen (tabellen, lijsten, contacten) | Thunderbit | Wget levert ruwe HTML — je moet het nog parsen. Thunderbit leest de pagina met AI en zet de data zonder code om naar Excel, Google Sheets, Airtable of Notion. De cloud scraping regelt IP-rotatie en anti-botmaatregelen, dus je slaat proxyconfiguratie helemaal over. |
| REST API-calls via een proxy | curl | Betere headercontrole, native JSON-ondersteuning, SOCKS5-ondersteuning |
| Doorlopende, geplande dataverzameling | Thunderbit Scheduled Scraper of cron + wget | Thunderbit past zich aan wanneer paginalay-outs veranderen; cron + wget-scripts falen vaak stilzwijgend |
Wget is sterk in bestandsdownloads. Maar de workflow “proxy instellen → IP’s roteren → HTML downloaden → parser schrijven → exporteren naar spreadsheet” bestaat uit veel bewegende delen als je eigenlijk gewoon een tabel met data wilt. Als dat op jouw situatie lijkt, regelt onze Chrome-extensie de hele pijplijn in twee klikken. Voor meer hierover, zie onze gidsen over AI-webscraping en webscraping zonder coderen.
Maar als je doel is “download dit ZIP-bestand via een bedrijfsproxy” — dan is Wget nog steeds de juiste tool, en nu weet je hoe je het goed instelt.
Belangrijkste inzichten
De korte versie:
- Vier methoden, duidelijke prioriteit: CLI-flags overschrijven gebruikersconfiguratie, die systeemconfiguratie overschrijft, die weer omgevingsvariabelen overschrijft.
--no-proxyoverschrijft alles. - Gebruik altijd kleine letters voor omgevingsvariabelen (
http_proxy, nietHTTP_PROXY). Hoofdletters worden stilzwijgend genegeerd. - Neem altijd
http://op in je proxy-URL, ook voorhttps_proxy. Het proxy-endpoint is HTTP; HTTPS wordt via CONNECT getunneld. - Gebruik
onvoor booleans in.wgetrcen-eflags. Dat is de veiligste keuze tussen Wget-versies. - Windows-gebruikers: Gebruik
--config=C:\pad\naar\wgetrcom onduidelijkheid over configuratiebestanden te vermijden. Gebruikset(CMD) of$env:(PowerShell) voor proxyvariabelen in een sessie. - Bedrijfsproxy-gebruikers: Wget kan PAC-bestanden niet lezen en ondersteunt NTLM-authenticatie niet native. Gebruik Cntlm als lokale relay als dat nodig is.
- Bookmark de cheat sheet hierboven — dat bespaart je het herlezen van dit artikel elke keer dat je een flagnaam nodig hebt.
Als je echte doel gestructureerde data-extractie is, zijn Thunderbit of curl mogelijk een betere keuze. De beste debug-sessie is degene die je nooit hoeft te starten.
FAQs
1. Ondersteunt Wget SOCKS5-proxies?
Nee. GNU Wget 1.x ondersteunt alleen HTTP-, HTTPS- en FTP-proxies. Het Wget2-project heeft SOCKS5 als feature request gehad, maar het is geen standaard gedocumenteerde optie. Gebruik voor SOCKS5 curl met de native socks5://- of socks5h://-schemes, of omhul Wget met proxychains4 om SOCKS-routing af te dwingen.
2. Waarom wordt mijn proxy-instelling genegeerd wanneer ik uppercase HTTP_PROXY gebruik?
Wget leest alleen omgevingsvariabelen in kleine letters (http_proxy, https_proxy, ftp_proxy, no_proxy). Varianten in hoofdletters zoals HTTP_PROXY worden stilzwijgend genegeerd — geen fout, geen waarschuwing. Dit is een van de meest voorkomende en frustrerende problemen, omdat er niets lijkt mis te zijn. Gebruik altijd kleine letters.
3. Hoe omzeil ik de proxy voor specifieke domeinen?
Gebruik de directive no_proxy, als omgevingsvariabele of in .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
Of in ~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
Domeinen worden met komma’s gescheiden. Een punt aan het begin (.mycompany.com) matcht alle subdomeinen.
4. Kan ik Wget gebruiken met roterende proxies?
Wget zelf heeft geen ingebouwde proxyrotatie. Je hebt twee opties: gebruik een proxyprovider die IP’s server-side roteert (zodat je altijd hetzelfde gateway-adres gebruikt, maar het exit-IP verandert), of schrijf een shellscript dat willekeurig een proxy uit een lijst kiest en die bij elke run meegeeft via -e http_proxy=.... Voor iets complexers — automatische rotatie, retry-logica, anti-botafhandeling — is een gespecialiseerde scrapingtool meestal een betere keuze.
5. Wat is het verschil tussen http_proxy en https_proxy in Wget?
http_proxy wordt gebruikt wanneer de doel-URL http:// is. https_proxy wordt gebruikt wanneer de doel-URL https:// is. In beide gevallen is de proxy-URL zelf meestal een http://-adres. Voor HTTPS-doelen stuurt Wget een HTTP CONNECT-verzoek via de proxy om een tunnel op te zetten, en de eigenlijke HTTPS-versleuteling gebeurt end-to-end tussen Wget en de doelserver. De proxy ziet de hostnaam (uit het CONNECT-verzoek), maar kan het versleutelde verkeer niet lezen.
Probeer Thunderbit voor AI-webscraping Get Started Free
Meer weten
