cURL draait wereldwijd naar schatting op 20 miljard installaties — het zit standaard ingebouwd in macOS, de meeste Linux-distributies en Windows 10/11. En toch: vraag tien developers hoe je een cURL-verzoek op de juiste manier via een proxy laat lopen, en je krijgt tien nét andere antwoorden, waarvan de helft stukloopt zodra authenticatie of SOCKS in beeld komt.
Precies die kloof wil ik hier dichten. De meeste handleidingen laten één commando zien, zeggen dat het werkt en gaan dan weer verder. Ze laten niet zien hoe je controleert of de proxy ook echt iets doet (spoiler: soms helemaal niet), en ze nemen je al helemaal niet mee door de foutcodes die verschijnen zodra je configuratie ook maar een beetje afwijkt van het ideale pad. Deze gids behandelt het volledige spectrum — HTTP/HTTPS-proxy's, SOCKS4/SOCKS5/socks5h, omgevingsvariabelen (en hun heel specifieke valkuilen), een degelijke troubleshooting-tabel en wat je kunt doen als cURL en een proxy het simpelweg niet meer samen redden.
Wat is cURL en waarom zou je het met een proxy gebruiken?
cURL is een command-line tool om data van en naar een URL te verplaatsen. Meer niet — geen GUI, geen franje, gewoon een programma dat HTTP, HTTPS, FTP en nog een handvol andere protocollen spreekt. De eenvoudigste aanroep ziet er zo uit:
curl https://example.com
Dat haalt de pagina op en zet de ruwe HTML in je terminal. Op zichzelf al handig, maar de echte reden dat developers en technische zakelijke gebruikers cURL pakken, is voor API-tests, datacapturing, het controleren van geo-beperkte content en het uitvoeren van requests binnen CI/CD-pipelines.
Een proxy staat tussen jouw machine en de doelserver en stuurt je verzoek namens jou door. De doelserver ziet het IP-adres van de proxy, niet dat van jou. Dat is om een aantal legitieme redenen belangrijk: testen hoe je site eruitziet vanuit een ander land, rate limits omzeilen tijdens QA, of verkeer via de verplichte corporate gateway van je bedrijf laten lopen. cURL ondersteunt het hele scala aan proxyprotocollen — HTTP, HTTPS, SOCKS4 en SOCKS5 — en de vlaggen die je in deze gids steeds terugziet zijn -x / --proxy (het proxyadres zelf), -v (uitvoer in verbose-modus, je beste vriend bij debuggen) en -k (SSL-verificatie overslaan, iets wat je buiten tests eigenlijk nooit zou moeten gebruiken).
Nog één korte opmerking voordat we verder gaan: deze gids gaat over de netwerkmechaniek van het gebruik van een proxy met cURL. Het is geen toestemming om de gebruiksvoorwaarden van een website of het beveiligingsbeleid van je organisatie te negeren. Een proxy verandert je netwerkroute — niet wat legaal of toegestaan is.
Voordat je begint
Moeilijkheidsgraad: Beginner tot gemiddeld
Benodigde tijd: ongeveer 15 minuten voor de kernvoorbeelden
Wat je nodig hebt:
- cURL geïnstalleerd (controleer met
curl --version— als je op macOS, Linux of Windows 10/11 zit, staat het er waarschijnlijk al op) - Proxy-gegevens van je provider: host, poort, protocol (HTTP/HTTPS/SOCKS) en indien nodig gebruikersnaam/wachtwoord
- Een terminal (Terminal op macOS, een shell op Linux, PowerShell of CMD op Windows)
Als cURL om wat voor reden dan ook niet is geïnstalleerd, dan is het een kwestie van één regel: brew install curl op macOS via Homebrew, sudo apt install curl op Debian/Ubuntu, of sudo yum install curl op RHEL/CentOS. Op Windows wordt het meegeleverd sinds Windows 10 build 17063.
In deze gids gebruik ik voorbeeldwaarden — proxy.example:8080 voor het proxyadres en user:pwd voor de credentials. Vervang die door je eigen proxygegevens, en plak nooit echte inloggegevens in je shell history, een screenshot of een Slack-bericht. Ik heb meer gelekte proxywachtwoorden in Slack-kanalen gezien dan me lief is.
Hoe gebruik je cURL met een HTTP- of HTTPS-proxy?
Dit is de meest voorkomende configuratie, en die gebruik je voor verreweg de meeste proxytaken.
Gebruik de -x / --proxy-flag
De basisvorm ziet er zo uit:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x en --proxy doen precies hetzelfde — kies vooral wat je zelf het makkelijkst onthoudt. Omdat HTTP cURL's standaard proxyschema is, kun je technisch gezien de http://-prefix weglaten en gewoon proxy.example:8080 schrijven. Ik zou het toch expliciet uitschrijven, want over zes maanden ben je blij met die helderheid.
Zet de volledige URL tussen dubbele aanhalingstekens. Als je wachtwoord een @, # of & bevat, dan haalt een on-gequote string je shell-invoer al uit elkaar voordat cURL het ooit ziet.
Verbinden via een HTTPS-proxy
Sommige providers versleutelen de verbinding naar de proxy zelf met TLS, niet alleen de verbinding van de proxy naar je doel. Dat is iets anders dan een HTTPS-site scrapen — het proxyprotocol en het doelprotocol zijn onafhankelijke variabelen. Zo geef je het op:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
Krijg je hier een certificaatfout, weersta dan de neiging om er snel -k aan toe te voegen en door te gaan. Die vlag schakelt SSL-certificaatverificatie volledig uit, wat prima is voor een lokale test van vijf minuten maar een heel slecht idee voor alles wat productie of echte gebruikersdata raakt. Werk je met een corporate proxy die TLS onderschept (een MITM-opstelling, veelvoorkomend in enterprise-omgevingen), dan is de juiste oplossing het importeren van het CA-certificaat van de proxy, niet het uitschakelen van verificatie.
Authenticeren met --proxy-user
Je kunt credentials ook loszetten in een eigen vlag in plaats van ze in de URL te proppen:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
Let op: hoofdletter -U is niet hetzelfde als authenticatie voor de doelsite (-u / --user, dus kleine letters) — die door elkaar halen is een makkelijke manier om je proxywachtwoord naar de verkeerde bestemming te sturen. In zakelijke omgevingen die NTLM- of Digest-authenticatie gebruiken in plaats van Basic, voeg je --proxy-ntlm of --proxy-digest toe naast --proxy-user.
Hoe gebruik je cURL met een SOCKS-proxy: SOCKS4 vs. SOCKS5 vs. socks5h
SOCKS-proxy's werken op een lager niveau dan HTTP-proxy's — het protocol van het verkeer maakt ze niet uit, wat ze handig maakt voor niet-HTTP-verkeer, Tor-circuits en alles wat privacygevoelig is. De meeste concurrenten geven hier één commando en zijn klaar. Dat is een fout, want de verschillen tussen SOCKS4, SOCKS5 en socks5h:// doen er echt toe.
| Functie | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP-ondersteuning | Ja | Ja | Ja |
| UDP-ondersteuning | Nee | Ja | Ja |
| Authenticatie | Nee | Ja | Ja |
| DNS-resolutie op afstand | Nee | Nee (lokale DNS) | Ja (proxy lost op) |
| Tor-compatibel | Nee | Risicovol (DNS-lek) | Ja |
De DNS-regel is waar mensen in de praktijk de meeste schade oplopen. Met socks5:// lost je machine de hostnaam op voordat de verbinding naar de proxy gaat — wat betekent dat je lokale DNS-resolver (en dus ook je internetprovider) precies ziet welk domein je probeert te bereiken, ook al loopt het daadwerkelijke HTTP-verkeer via de proxy. socks5h:// lost dat op door de proxy zelf de hostnaam te laten resolven, zodat lokaal niets van de bestemming lekt. Daarom hamert Tor-documentatie ook op socks5h:// — met puur socks5:// maak je een belangrijk deel van de anonimiteit van Tor ongedaan.
Zo gebruik je elke variant in cURL:
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
Tenzij je een specifieke reden hebt om dat niet te doen, kies je standaard voor socks5h://. Het kost niets extra en voorkomt een lek dat je anders waarschijnlijk nooit zou opmerken.
Proxy instellen met omgevingsvariabelen (en de valkuilen vermijden)
Bij elk commando steeds -x typen wordt al snel vermoeiend. Met omgevingsvariabelen stel je de proxy één keer per shellsessie in, waarna elke volgende cURL-aanroep die automatisch overneemt — de handleiding van cURL documenteert http_proxy, HTTPS_PROXY, ALL_PROXY en NO_PROXY als de ondersteunde set.
De basis
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
Hier gaat het vaak mis: de variabelenaam verwijst naar het protocol van de doel-URL, niet naar het protocol van de proxy. Dus http_proxy geldt voor requests naar http://-URL's, en HTTPS_PROXY voor requests naar https://-URL's — je kunt ze allebei naar exact dezelfde HTTP-proxy wijzen, en dat is volkomen normaal.
Omzeilen met NO_PROXY
export NO_PROXY="localhost,127.0.0.1,.internal.example"
Komma-gescheiden, en de punt aan het begin van .internal.example werkt als wildcard voor alle subdomeinen. NO_PROXY heeft voorrang op alles — zelfs als -x expliciet op de command line staat, zal een match in NO_PROXY die request langs de proxy laten gaan.
De valkuilen waar mensen echt op vastlopen
exportvergeten. Als je alleenhttp_proxy=http://...typt zonderexport, dan leeft de variabele alleen in je huidige shell en is die voor cURL als child process volledig onzichtbaar. Dat is in mijn ervaring verreweg de meest voorkomende oorzaak van supporttickets met de strekking: “de proxy werkt niet”.- Hoofdlettergevoeligheid. cURL controleert specifiek eerst op lowercase
http_proxyen geeft die voorrang als beide varianten bestaan. Sommige andere tools lezen alleen uppercase. Als je debugt waarom een variabele “niet wordt opgepikt”, check dan of er een dubbele versie met afwijkende hoofdletters staat. - De PowerShell-aliasval. In PowerShell 5.1 roept
curlhelemaal geen cURL aan — het startInvoke-WebRequest, een totaal andere tool met andere flags. Krijg je op Windows rare fouten op-x, typ dan explicietcurl.exeom zeker te weten dat je echt cURL draait. - Verschillen in Windows-syntax. CMD gebruikt
set http_proxy=...; PowerShell gebruikt$env:http_proxy = "...". Als je die door elkaar haalt tussen terminals, ben je zo een middag kwijt. - Verouderde variabelen.
unset http_proxyenunset https_proxywissen een dode proxyconfiguratie die ongemerkt elk request blijft omleiden — en laten falen.
Voor snel aan- en uitzetten besparen een paar aliases in je .bashrc echt tijd:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
cURL altijd via een proxy laten lopen (configbestand)
Als je 95% van de tijd achter een corporate proxy zit, zet een .curlrc-bestand (op Unix-achtige systemen in je thuismap) of _curlrc (op Windows, in de app-data-map) een permanente standaard zonder omgevingsvariabelen aan te raken:
proxy="http://proxy.example:8080"
Voor een losse request waarbij je de proxy wilt overslaan, overschrijft --noproxy "*" de configuratie voor precies die ene aanroep. De prioriteit is in grote lijnen: command-line flag > omgevingsvariabele > configbestand, dus -x op de command line wint altijd als er een conflict is.
Een belangrijke waarschuwing: zet geen plaintext wachtwoord in .curlrc als dat bestand ergens kan worden gesynchroniseerd, geback-upt of per ongeluk in een repo belandt. Gebruik voor CI-pipelines liever de secret manager van je platform en injecteer credentials als afgeschermde omgevingsvariabelen.
Hoe controleer je of je proxy echt werkt?
Dit is het onderdeel dat bijna elke andere gids overslaat, en precies het stuk dat je de meeste debugtijd bespaart. Een proxy instellen en er simpelweg van uitgaan dat het verkeer erdoorheen loopt, is hoe mensen uren verliezen aan een scraper die in de praktijk helemaal geen proxy gebruikte.
Methode 1: Vergelijk je uitgaande IP-adres
Doe dezelfde IP-echo-request twee keer — één keer direct, één keer via de proxy — en vergelijk de uitkomst:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Als beide commando's hetzelfde IP-adres teruggeven, doet je proxy niets. Controleer je flags, je omgevingsvariabelen of de vraag of NO_PROXY misschien per ongeluk je doel matcht.
Methode 2: Lees de verbose output
Voeg -v toe aan elk proxyverzoek en cURL toont de volledige handshake:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Zoek naar een regel als * Connected to proxy.example (xx.xx.xx.xx) port 8080, gevolgd door > CONNECT httpbin.org:443 HTTP/1.1 en uiteindelijk < HTTP/1.1 200 Connection established. Die sequentie — verbinding met de proxy, daarna een CONNECT-tunnel naar het doel — is de HTTP CONNECT-methode in actie, en precies wat er hoort te gebeuren wanneer een HTTPS-doel via een HTTP-proxy wordt gerouteerd. Verschijnt die CONNECT-regel nooit, dan wordt de proxyflag niet toegepast. Let wel op: gebruik -v alleen tijdens actief debuggen en redacteer de output voordat je die ergens deelt — in verbose-modus kunnen proxy-credentials in platte tekst worden getoond.
Methode 3: Side-by-side diff
Voor geo-tests is dit extra handig: sla beide outputs op in bestanden en vergelijk ze met diff:
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
Als de response bodies (of headers, bij geo-beperkte content) verschillen, heb je visuele bevestiging dat de proxy je netwerkpad echt verandert — een snelle, laagdrempelige manier om twijfel weg te nemen voordat je verder duikt.
Veelvoorkomende cURL-proxyfouten oplossen
De meeste handleidingen wuiven dit weg en noemen één keer -k. Dit onderwerp verdient een echte referentietabel.
| Fout | Waarschijnlijke oorzaak | Oplossing |
|---|---|---|
curl: (7) Failed to connect | Verkeerde proxyhost/-poort, of de proxy is offline | Controleer het adres; test de ruwe connectiviteit met telnet host port of nc -zv host port |
407 Proxy Authentication Required | Ontbrekende of onjuiste proxycredentials | Voeg --proxy-user user:pass toe; controleer of de provider NTLM/Digest/Negotiate vereist in plaats van Basic |
curl: (56) Recv failure: Connection reset by peer | De proxy verbrak de verbinding halverwege de overdracht | Controleer de stabiliteit van de proxy bij de provider; als het een TLS-beëindigende proxy is, verifieer dan de certificaatverwerking in plaats van die hard uit te schakelen |
curl: (28) Connection timed out | Firewall blokkeert, verouderde proxy of verkeerde poort | Draai env | grep -i proxy om te kijken of er oude variabelen zijn blijven hangen; unset verouderde variabelen; test een directe request om de oorzaak te isoleren |
| Certificaatverificatiefout | Niet-vertrouwd of onderscheppend proxycertificaat | Gebruik de juiste CA-keten en --proxy-cacert; vermijd verificatie uitschakelen buiten een eenmalige diagnose |
De universele eerste stap bij al deze problemen is -v toevoegen. Daarmee zie je precies waar de verbinding stukloopt — DNS-resolutie, TCP-connectie, TLS-handshake of de proxy-authenticatie-uitwisseling — in plaats van te moeten gokken op basis van een foutcode van drie cijfers.
Voor corporate proxies dekken --proxy-ntlm en --proxy-negotiate Windows-domeinauthenticatieschema’s af. Eén ding dat cURL echt niet native aankan: PAC-bestanden (Proxy Auto-Config-scripts die sommige bedrijven gebruiken om dynamisch proxies toe te wijzen). Gebruikt jouw organisatie zo’n bestand, dan moet je de daadwerkelijke proxyhost en -poort handmatig achterhalen — meestal via de netwerkinstellingen van je browser — omdat cURL geen ingebouwde PAC-parser heeft.
Wanneer cURL + een proxy niet genoeg is
cURL met een proxy kan statische HTML, REST API-calls en eenvoudige data-opvragingen eigenlijk prima aan. Waar het vastloopt, zijn de favoriete verdedigingslagen van het moderne web: JavaScript-gerenderde single-page apps, anti-botsystemen zoals Cloudflare of Akamai en CAPTCHA-muren. Richt je cURL op een React- of Vue-app achter zo’n laag, dan krijg je vaak alleen een lege <div id="root"></div> terug — technisch gezien een geslaagde request, praktisch gezien waardeloze data. Dat is geen cURL-bug. Het is gewoon geen browser, en het heeft ook nooit gedaan alsof.
Als je al comfortabel bent met cURL in de terminal en je loopt tegen die muur aan, dan is de logische volgende stap niet overstappen op een compleet andere toolchain — maar een laag toevoegen die rendering en structuur voor je afhandelt. Precies die kloof sluiten Thunderbit's developer tools.
| Scenario | cURL + Proxy | Thunderbit API (POST /extract) |
|---|---|---|
| Statische HTML-pagina | Werkt perfect | Werkt, en geeft ook gestructureerde data terug |
| JS-gerenderde SPA | Krijgt lege/deels geladen HTML | renderMode: "full" verwerkt de JavaScript |
| Anti-bot / CAPTCHA | Geblokkeerd | Ingebouwde afhandeling |
| Gestructureerde data-output | Ruwe HTML — zelf parsen | JSON via je eigen schema |
| Batch (100+ URL's) | Handmatige loop + eigen rate limiting | POST /batch/extract |
Thunderbit's Open API biedt een /extract-endpoint dat schema-gebonden JSON rechtstreeks uit JavaScript-zware pagina's teruggeeft, en een /distill-endpoint voor nette Markdown-conversie — beide zijn aan te roepen vanuit exact dezelfde terminalsessie waarin je al je cURL-commando's draait. Er is ook een MCP-server voor AI-codingassistenten zoals Claude of Cursor, en een CLI (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json) als je liever volledig in scripts blijft werken. Niets hiervan vervangt cURL voor de taken waar cURL goed in is — het neemt het gewoon over zodra cURL structureel niet verder kan. Wil je een breder beeld van waar AI-gestuurde extractie past ten opzichte van je eigen scraperlogica, dan gaan onze uitleg over AI web scraping en onze vergelijking van de beste AI-webscrapers daar dieper op in, en ons artikel over webscraping zonder coderen is een goede opstap als je hier instapt vanuit een business- in plaats van een engineeringhoek.
Afronding
cURL en een proxy goed met elkaar laten praten is niet moeilijk zodra je weet waar de echte foutpunten zitten — en het blijkt dat bijna geen van die punten de proxy zelf is. export vergeten. -u verwarren met -U. socks5:// gebruiken terwijl je socks5h:// bedoelde. PowerShell’s curl-alias draaien in plaats van curl.exe. Al deze fouten leveren verwarrende, generieke meldingen op die niets met je proxyprovider te maken hebben.
De gewoonte die de meeste tijd bespaart: eerst verifiëren, dan pas troubleshooten. Doe de IP-echo-check, kijk even naar de -v-output en bevestig dat de proxy überhaupt in het requestpad zit voordat je aanneemt dat er verderop iets mis is. En zodra je doel JavaScript teruggooit in plaats van nette HTML, is dat geen cURL-probleem dat je met nog meer flags oplost — het is een signaal dat je een tool nodig hebt die voor rendering gebouwd is, zoals Thunderbit's API, dat een gratis tier biedt als je zelf wilt zien hoe JSON-uitvoer verschilt van ruwe HTML.
FAQ's
Gebruikt cURL standaard een proxy?
Nee. Tenzij je http_proxy / HTTPS_PROXY-omgevingsvariabelen hebt ingesteld of een .curlrc-bestand hebt geconfigureerd, maakt cURL rechtstreeks verbinding met het doel zonder proxy.
Hoe voorkom ik dat cURL voor één request een proxy gebruikt?
Voeg --noproxy "*" toe aan dat specifieke commando. Om het voor de hele shellsessie uit te zetten, draai je unset http_proxy && unset https_proxy.
Kan ik cURL gebruiken met roterende proxies?
Ja — als je provider een roterende gateway aanbiedt (één endpoint dat per request een nieuw IP toewijst), wijs je -x gewoon naar dat gateway-adres zoals je bij elke andere proxy zou doen. Voor complexere rotatielogica tegen JS-gerenderde targets regelt een API-laag zoals Thunderbit intern de rotatie en anti-botkant, zodat jij retry-logica niet met de hand hoeft te beheren.
Waarom lekt socks5:// mijn DNS-requests, maar socks5h:// niet?
Bij socks5:// lost je lokale machine de bestemmingshostnaam op voordat het verbindingsverzoek naar de proxy gaat — daardoor ziet de DNS-resolver van je ISP het domein dat je bezoekt. socks5h:// verplaatst die hostnaamresolutie naar de proxy zelf, zodat lokaal niets over de bestemming zichtbaar is.
Is het legaal om cURL met een proxy te gebruiken?
Het gebruik van een proxy is in de meeste rechtsgebieden op zichzelf legaal. Waar het om draait, is wat je ermee doet — respecteer altijd de gebruiksvoorwaarden van de doelsite, robots.txt waar van toepassing, en alle relevante wetgeving rond gegevensprivacy. Deze gids behandelt alleen de technische kant, niet een juridische vrijbrief voor een specifieke use case.
Meer weten
