cURLia arvioidaan käytettävän noin 20 miljardissa asennuksessa ympäri maailmaa — se on valmiiksi mukana macOS:ssä, useimmissa Linux-jakeluissa sekä Windows 10/11:ssä. Ja silti, jos kysyt kymmeneltä kehittäjältä, miten cURL-pyyntö ohjataan oikein proxyn kautta, saat kymmenen hieman erilaista vastausta, joista puolet hajoaa heti, kun mukaan tulee tunnistautuminen tai SOCKS.
Juuri tämän aukon haluan tässä paikata. Useimmat ohjeet näyttävät yhden komennon, sanovat että se toimii, ja jatkavat eteenpäin. Ne eivät kerro, miten varmistat, että proxy oikeasti tekee mitään (vihje: joskus ei tee), eivätkä ne todellakaan käy läpi virhekoodeja, jotka ilmestyvät heti, kun asetuksesi poikkeaa vähänkin onnellisesta peruspolusta. Tämä opas kattaa kaiken olennaisen — HTTP/HTTPS-proxyt, SOCKS4/SOCKS5/socks5h, ympäristömuuttujat ja niiden käytännön sudenkuopat, kunnollisen vianmääritystaulukon sekä sen, mitä tehdä silloin, kun cURL ja proxy eivät enää riitä.
Mikä cURL on ja miksi sitä käytetään proxyn kanssa?
cURL on komentorivityökalu datan siirtämiseen URL-osoitteeseen ja sieltä pois. Siinä se — ei käyttöliittymää, ei turhia koristeita, vain ohjelma, joka puhuu HTTP:tä, HTTPS:ää, FTP:tä ja muutamia muita protokollia. Yksinkertaisin käyttötapa on:
curl https://example.com
Tämä hakee sivun ja tulostaa raakadatan HTML:n terminaaliin. Hyödyllinen sellaisenaan, mutta todellinen syy, miksi kehittäjät ja tekniset liiketoimintakäyttäjät tarttuvat cURLiin, on API-testien tekeminen, datan kerääminen, maantieteellisesti rajoitetun sisällön tarkistaminen sekä pyyntöjen ajaminen CI/CD-putkissa.
Proxy toimii välissä sinun koneesi ja kohdepalvelimen välillä ja välittää pyynnön puolestasi. Kohde näkee proxyn IP-osoitteen, ei sinun. Tällä on merkitystä useista täysin laillisista syistä: esimerkiksi sivuston ulkoasun testaaminen toisesta maasta käsin, rate limit -rajojen kiertäminen QA-ympäristössä tai liikenteen ohjaaminen yrityksen pakollisen yhdyskäytävän kautta. cURL tukee koko kirjon proxy-protokollia — HTTP, HTTPS, SOCKS4 ja SOCKS5 — ja tässä oppaassa toistuvasti näkemäsi liput ovat -x / --proxy (proxyn osoite), -v (verbose-tuloste, paras apusi vianmääritykseen) ja -k (ohittaa SSL-varmennuksen, jota ei käytännössä pitäisi käyttää muualla kuin testauksessa).
Yksi nopea huomio ennen kuin jatkamme: tämä opas käsittelee verkon toimintaa ja cURLin käyttöä proxyn kanssa. Se ei ole lupa ohittaa kohdesivuston käyttöehtoja tai organisaatiosi turvallisuuspolitiikkaa. Proxy muuttaa verkkoreittiä — se ei muuta sitä, mikä on sallittua tai laillista.
Ennen kuin aloitat
Vaikeustaso: Aloittelijasta keskitason käyttäjään
Arvioitu aika: noin 15 minuuttia ydinesimerkkien läpikäymiseen
Tarvitset:
- cURL asennettuna (tarkista komennolla
curl --version— jos käytät macOS:ää, Linuxia tai Windows 10/11:tä, se on hyvin todennäköisesti jo valmiina) - Proxy-palveluntarjoajalta saadut tiedot: host, portti, protokolla (HTTP/HTTPS/SOCKS) sekä tarvittaessa käyttäjätunnus ja salasana
- Terminaali (Terminal macOS:ssä, mikä tahansa shell Linuxissa, PowerShell tai CMD Windowsissa)
Jos cURL puuttuu jostain syystä, sen asentaminen on yhdellä rivillä hoidettu: Homebrewlla macOS:ssä brew install curl, Debian/Ubuntussa sudo apt install curl ja RHEL/CentOSissa sudo yum install curl. Windowsissa se on sisältynyt käyttöjärjestelmään Windows 10 build 17063:sta lähtien.
Käytän tässä oppaassa esimerkkitietoja — proxyn osoitteena proxy.example:8080 ja tunnuksina user:pwd. Vaihda ne omiin tietoihisi, äläkä koskaan liitä oikeita tunnuksia shellin historiaan, kuvakaappaukseen tai Slack-viestiin. Olen nähnyt Slack-kanavissa enemmän vuotaneita proxy-salasanoja kuin haluaisin myöntää.
Näin käytät cURLia HTTP- tai HTTPS-proxyn kanssa
Tämä on yleisin asetus, ja se palvelee valtaosaa proxytehtävistä.
-x / --proxy -lipun käyttö
Perussyntaksi näyttää tältä:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x ja --proxy tekevät täsmälleen saman asian — valitse se, joka on helpompi muistaa. Koska HTTP on cURLin oletusproxyprotokolla, voit teknisesti jättää http://-etuliitteen pois ja kirjoittaa vain proxy.example:8080. Itse kirjoittaisin sen kuitenkin näkyviin, koska puolen vuoden päästä kiität itseäsi selkeydestä.
Laita koko URL lainausmerkkeihin. Jos salasanassasi on merkkejä kuten @, # tai &, ilman lainausmerkkejä shell pilkkoo merkkijonon ennen kuin cURL ehtii nähdä sitä.
Yhteyden muodostaminen HTTPS-proxyn kautta
Jotkut palveluntarjoajat salaavat yhteyden itse proxylle TLS:llä, eivät vain proxyn ja kohteen välistä yhteyttä. Tämä on eri asia kuin HTTPS-sivun hakeminen — proxyprotokolla ja kohdeprotokolla ovat toisistaan riippumattomia. Näin se määritetään:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
Jos saat tässä sertifikaattivirheen, älä sorru lisäämään -k-lippua vain mennäksesi eteenpäin. Se poistaa SSL-varmennuksen kokonaan käytöstä, mikä voi olla ok viiden minuutin paikallisessa testissä, mutta on huono idea tuotannossa tai oikeita käyttäjätietoja käsittelevässä käytössä. Jos kyseessä on yritysproxy, joka tekee TLS:n väliintarkastuksen (MITM-asetelma, tyypillinen yritysympäristöissä), oikea korjaus on proxyn CA-sertifikaatin tuominen luotettuihin sertifikaatteihin, ei varmennuksen poistaminen käytöstä.
Tunnistautuminen --proxy-user-lipulla
Voit myös erottaa tunnistetiedot omaksi lipukseen sen sijaan, että ahtaisit ne URL:iin:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
Huomaa, että iso -U ei ole sama asia kuin kohdesivuston tunnistautuminen (-u / --user, pienellä) — niiden sekoittaminen on helppo tapa lähettää proxyn salasana väärään paikkaan. Jos yritysympäristössä käytetään Basicin sijaan NTLM- tai Digest-tunnistautumista, lisää --proxy-user-lipun rinnalle --proxy-ntlm tai --proxy-digest.
Näin käytät cURLia SOCKS-proxyn kanssa: SOCKS4 vs. SOCKS5 vs. socks5h
SOCKS-proxyt toimivat alemmalla tasolla kuin HTTP-proxyt — ne eivät välitä siitä, mitä protokollaa tunnelointiin käytetään. Siksi ne sopivat hyvin muun kuin HTTP-liikenteen välittämiseen, Tor-yhteyksiin ja kaikkeen yksityisyydelle herkempään käyttöön. Useimmat kilpailijaoppaat antavat tähän vain yhden komennon ja jatkavat matkaa. Se on virhe, koska erot SOCKS4:n, SOCKS5:n ja socks5h://:n välillä oikeasti merkitsevät.
| Ominaisuus | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP-tuki | Kyllä | Kyllä | Kyllä |
| UDP-tuki | Ei | Kyllä | Kyllä |
| Tunnistautuminen | Ei | Kyllä | Kyllä |
| Etä-DNS-haku | Ei | Ei (paikallinen DNS) | Kyllä (proxy ratkaisee) |
| Tor-yhteensopiva | Ei | Riskialtis (DNS-vuoto) | Kyllä |
DNS-resoluutio on se kohta, jossa ihmiset yleensä palavat. Kun käytät socks5://-muotoa, koneesi ratkaisee isäntänimen ennen kuin yhteys annetaan proxylle — eli paikallinen DNS-ratkaisija (ja käytännössä myös operaattorisi) näkee täsmälleen, mille verkkotunnukselle yrität mennä, vaikka varsinainen HTTP-liikenne kulkeekin proxyn kautta. socks5h:// korjaa tämän siten, että proxy hoitaa isäntänimen resolvauksen, jolloin kohteesta ei vuoda mitään paikallisesti. Juuri tästä syystä Torin ohjeistus vaatii socks5h://-muotoa — pelkkä socks5:// heikentää ison osan siitä anonymiteetistä, jota Torin on tarkoitus tarjota.
Näin kukin vaihtoehto näyttää cURLissa:
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"
Ellei sinulla ole erityistä syytä toimia toisin, käytä oletuksena socks5h://-muotoa. Se ei maksa mitään ylimääräistä ja estää vuodon, jota et muuten huomaisi lainkaan.
Proxyn asettaminen ympäristömuuttujilla (ja ansakuoppien välttäminen)
-x-lipun kirjoittaminen jokaiseen komentoon alkaa nopeasti ärsyttää. Ympäristömuuttujilla voit määrittää proxyn kerran shell-istuntoa kohden, ja kaikki sitä seuraavat cURL-kutsut perivät asetuksen automaattisesti — cURLin manuaali dokumentoi tuetuksi joukoksi http_proxy, HTTPS_PROXY, ALL_PROXY ja NO_PROXY.
Perusasiat
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"
Tässä tulee kohta, joka sekoittaa ihmiset jatkuvasti: muuttujan nimi viittaa kohde-URL:n protokollaan, ei proxyn protokollaan. Eli http_proxy ohjaa http://-osoitteisiin meneviä pyyntöjä, ja HTTPS_PROXY ohjaa https://-osoitteisiin meneviä pyyntöjä — molemmat voivat osoittaa täsmälleen samaan HTTP-proxy-palvelimeen, ja se on täysin normaalia.
Ohittaminen NO_PROXY-muuttujalla
export NO_PROXY="localhost,127.0.0.1,.internal.example"
Arvot erotetaan pilkuilla, ja .internal.example-alkuinen piste toimii jokerina kaikille aliverkkotunnuksille. NO_PROXY ohittaa kaiken muun — vaikka -x olisi annettu suoraan komentorivillä, NO_PROXY:n osuma ohittaa proxyn kyseisessä pyynnössä.
Sudenkuopat, joihin ihmiset oikeasti kompastuvat
exportunohtuu. Jos kirjoitat vainhttp_proxy=http://...ilmanexport-sanaa, muuttuja jää pelkästään nykyiseen shelliin eikä cURL näe sitä lapsiprosessina lainkaan. Tämä on kokemukseni mukaan yleisin syy tukeen tuleviin viesteihin tyyliin “proxy ei toimi”.- Kirjainkoko merkitsee. cURL tarkistaa erityisesti ensin pienellä kirjoitetun
http_proxy-muuttujan ja antaa sille etusijan, jos molemmat muodot ovat olemassa. Jotkut muut työkalut lukevat vain ison version. Jos selvität, miksi muuttujaa “ei poimita”, tarkista myös mahdollinen kaksoiskappale eri kirjainkoolla. - PowerShellin alias-ansa. PowerShell 5.1:ssä komento
curlei kutsu cURLia ollenkaan — se käynnistääInvoke-WebRequest-työkalun, joka on täysin eri ohjelma eri lipuilla. Jos-xaiheuttaa Windowsissa oudon virheen, kirjoitacurl.exesuoraan varmistaaksesi, että käytät oikeasti cURLia. - Windowsin syntaksierot. CMD käyttää komentoa
set http_proxy=...; PowerShell käyttää muotoa$env:http_proxy = "...". Näiden sekoittaminen eri terminaalisessioissa on helppo tapa menettää iltapäivä. - Vanhat muuttujat roikkuvat mukana.
unset http_proxyjaunset https_proxypoistavat vanhan proxyasetuksen, joka muuten ohjaa ja epäonnistuu hiljaa joka ikisessä pyynnössä.
Nopeaa vaihtamista varten pari aliasta .bashrc:ssä säästää oikeasti aikaa:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
Näin pakotat cURLin käyttämään aina proxya (asetustiedosto)
Jos olet yritysverkon proxyn takana 95 % ajasta, .curlrc-tiedosto (Unix-tyyppisissä järjestelmissä kotihakemistossa) tai _curlrc (Windowsissa app-data-kansiossa) asettaa pysyvän oletuksen ilman ympäristömuuttujien säätämistä:
proxy="http://proxy.example:8080"
Jos jossain yksittäisessä pyynnössä haluat ohittaa tämän, --noproxy "*" syrjäyttää asetuksen kyseiseltä ajokerralta. Etusijajärjestys menee yleensä näin: komentorivin lippu > ympäristömuuttuja > asetustiedosto, joten komentorivin -x voittaa aina, jos asetuksissa on ristiriita.
Yksi tärkeä varoitus: älä tallenna selväkielistä salasanaa .curlrc-tiedostoon, jos se voi päätyä synkronoitavaksi, varmuuskopioitavaksi tai vahingossa versionhallintaan. CI-putkissa kannattaa käyttää alustan salaisuuksien hallintaa ja syöttää tunnukset sen sijaan naamioituina ympäristömuuttujina.
Näin varmistat, että proxy oikeasti toimii
Tämä on kohta, jonka lähes kaikki muut oppaat ohittavat — ja juuri se säästää eniten vianmääritysaikaa. Proxy kannattaa ottaa käyttöön ja sitten olettaa, että liikenne kulkee sen kautta, vaikka todellisuudessa ihmiset käyttävät tunteja selvittäessään webscraperia, joka ei koskaan käyttänytkään proxya.
Menetelmä 1: vertaa ulospäin näkyvää IP:tä
Aja sama IP-vastauspyyntö kahdesti — kerran suoraan, kerran proxyn kautta — ja vertaa tuloksia:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Jos molemmat komennot palauttavat saman IP-osoitteen, proxy ei tee mitään. Tarkista lippujen syntaksi, ympäristömuuttujat tai se, osuuko NO_PROXY vahingossa kohteeseesi.
Menetelmä 2: lue verbose-tuloste
Lisää -v mihin tahansa proxy-pyyntöön, niin cURL tulostaa koko kättelyn:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
Etsi riviä kuten * Connected to proxy.example (xx.xx.xx.xx) port 8080, jonka jälkeen näkyy > CONNECT httpbin.org:443 HTTP/1.1 ja lopulta < HTTP/1.1 200 Connection established. Tämä ketju — yhteys proxylle ja sitten CONNECT-tunneli kohteeseen — on HTTP CONNECT -metodin toimintaa, ja juuri näin pitäisi tapahtua, kun HTTPS-kohde ohjataan HTTP-proxyn läpi. Jos CONNECT-riviä ei koskaan näy, proxy-lippu ei ole oikeasti käytössä. Yksi varoitus: käytä -v-lippua vain aktiivisen vianmäärityksen aikana, ja sensuroi tuloste ennen kuin jaat sitä missään — verbose-tila voi tulostaa proxy-tunnukset selväkielisinä.
Menetelmä 3: vertaile tiedostoja rinnakkain
Erityisesti maantieteellisen testauksen yhteydessä tallenna molemmat tulokset tiedostoihin ja vertaile niitä:
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
Jos vastauksen sisältö tai otsakkeet eroavat, sinulla on visuaalinen vahvistus siitä, että proxy todella muuttaa verkkoreittiä — nopea ja kevyt tapa lopettaa epäily ennen syvempää selvittämistä.
Yleisimmät cURL-proxyvirheet ja niiden vianmääritys
Useimmat oppaat viittaavat tähän ohimennen ja mainitsevat -k-lipun kerran. Tähän aiheeseen kuuluu oikea viittaustaulukko.
| Virhe | Todennäköinen syy | Korjaus |
|---|---|---|
curl: (7) Failed to connect | Väärä proxy-hosti/portti tai proxy on alhaalla | Tarkista osoite; testaa perusyhteys komennolla telnet host port tai nc -zv host port |
407 Proxy Authentication Required | Proxy-tunnukset puuttuvat tai ovat väärät | Lisää --proxy-user user:pass; tarkista, vaatiiko palveluntarjoaja Basicin sijaan NTLM/Digest/Negotiatea |
curl: (56) Recv failure: Connection reset by peer | Proxy katkaisi yhteyden siirron aikana | Tarkista proxyn vakaus palveluntarjoajalta; jos kyseessä on TLS-päätteinen proxy, varmista sertifikaattien käsittely äläkä pakota varmennuksen poistamista |
curl: (28) Connection timed out | Palomuuri estää, proxy on vanhentunut tai portti on väärä | Aja `env |
| Sertifikaatin varmennus epäonnistuu | Luottamaton tai liikennettä väliin tarkastava proxyn sertifikaatti | Hanki oikea CA-ketju ja käytä --proxy-cacert; vältä varmennuksen poistamista käytöstä muulloin kuin kertaluontoisessa diagnoosissa |
Kaikkien näiden kohdalla ensimmäinen yhteinen askel on -v-lipun lisääminen. Se näyttää täsmälleen, missä yhteys katkeaa — DNS-resoluutiossa, TCP-yhteydessä, TLS-kättelyssä vai proxy-tunnistautumisessa — sen sijaan että jäisit arvailemaan kolminumeroisen virhekoodin perusteella.
Yritysproxyjen kohdalla --proxy-ntlm ja --proxy-negotiate kattavat Windows-alueen tunnistautumistavat. Yksi asia, jota cURL ei oikeasti käsittele natiivisti: PAC-tiedostot (Proxy Auto-Config -skriptit, joita jotkut yritykset käyttävät proxyjen dynaamiseen valintaan). Jos organisaatiosi käyttää sellaista, sinun täytyy poimia varsinainen proxy-hosti ja portti käsin — yleensä selaimen verkkoasetuksista — koska cURLissa ei ole sisäänrakennettua PAC-parseria.
Milloin cURL + proxy ei enää riitä
cURL proxyn kanssa hoitaa staattiset HTML-sivut, REST API -kutsut ja yksinkertaisen datan haun käytännössä niin hyvin kuin mahdollista. Se alkaa kuitenkin hyytyä siellä, missä nykyverkko puolustautuu mieluiten: JavaScriptillä renderöidyissä single-page-sovelluksissa, Cloudflaren tai Akamain kaltaisissa bottisuojausjärjestelmissä sekä CAPTCHA-esteissä. Kun osoitat cURLin React- tai Vue-sovellukseen, jonka edessä on tällainen suoja, saat usein takaisin tyhjän <div id="root"></div>-elementin — teknisesti onnistunut pyyntö, käytännössä hyödytön lopputulos. Se ei ole cURLin vika. Se ei vain ole selain, eikä se koskaan ole väittänytkään olevansa.
Jos käytät jo cURLia terminaalista ja törmäät tähän rajaan, luonnollinen seuraava askel ei ole vaihtaa täysin toiseen työkaluketjuun — vaan lisätä kerros, joka hoitaa renderöinnin ja rakenteen puolestasi. Juuri tämän aukon Thunderbitin kehittäjätyökalut on rakennettu paikkaamaan.
| Tilanne | cURL + Proxy | Thunderbit API (POST /extract) |
|---|---|---|
| Staattinen HTML-sivu | Toimii erinomaisesti | Toimii, ja palauttaa myös jäsenneltyä dataa |
| JS-renderöity SPA | Saa tyhjän tai vajaaseen HTML:n | renderMode: "full" hoitaa JS:n |
| Anti-bot / CAPTCHA | Estyy | Sisäänrakennettu käsittely |
| Jäsennelty datalähtö | Raaka HTML — parsittava itse | JSON omalla skeemallasi |
| Eräajo (100+ URL:ia) | Manuaalinen looppi ja oma rate limiting | POST /batch/extract |
Thunderbitin Open API tarjoaa /extract-päätepisteen, joka palauttaa skeemaan sovitettua JSONia suoraan JS-raskaista sivuista, sekä /distill-päätepisteen siistiä Markdown-muunnosta varten — molempia voi kutsua samasta terminaali-istunnosta, jossa olet jo käyttänyt cURL-komentoja. Lisäksi tarjolla on MCP-palvelin AI-koodausavustajille kuten Claude tai Cursor sekä CLI-työkalu (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json), jos haluat pysyä kokonaan skripteissä. Mikään tästä ei korvaa cURLia niissä töissä, joissa cURL on vahva — se vain jatkaa siitä, mihin cURL rakenteellisesti ei enää yllä. Jos haluat laajemman kuvan siitä, missä AI-avusteinen tiedonhaku asettuu suhteessa oman scraper-logiikan kirjoittamiseen, meidän AI web scraping -katsauksemme ja best AI web scrapers -vertailumme käsittelevät aihetta tarkemmin, ja web scraping ilman koodausta on hyvä aloitus, jos lähestyt aihetta enemmän liiketoiminnan kuin tekniikan näkökulmasta.
Yhteenveto
cURLin ja proxyn saaminen toimimaan yhdessä ei ole vaikeaa, kunhan tiedät, missä varsinaiset vikakohdat ovat — ja käy ilmi, että lähes mikään niistä ei ole itse proxy. export unohtuu. -u ja -U menevät sekaisin. Käytät socks5://:ä, vaikka tarkoitit socks5h://:tä. Ajaat PowerShellin curl-aliasta etkä curl.exe:tä. Jokainen näistä tuottaa hämmentävän, geneerisen virheen, joka ei liity proxy-palveluntarjoajaan lainkaan.
Eniten aikaa säästävä tapa on tarkistaa ennen kuin alat vianmääritykseen. Aja IP-vastaustesti, vilkaise -v-tulostetta, varmista että proxy on oikeasti mukana pyynnön reitissä ennen kuin oletat, että jokin on rikki myöhemmin putkessa. Ja kun kohde alkaa syöttää sinulle JavaScriptiä siistin HTML:n sijaan, se ei ole cURL-ongelma, joka ratkeaa lisää lipputekniikkaa käyttämällä — se on merkki siitä, että tarvitset työkalun, joka on rakennettu renderöintiä varten, kuten Thunderbitin API, josta löytyy myös ilmainen taso, jos haluat nähdä itse eron raakahypertekstin ja JSON-vastauksen välillä.
Usein kysytyt kysymykset
Käyttääkö cURL proxya oletuksena?
Ei. Ellet ole asettanut http_proxy / HTTPS_PROXY -ympäristömuuttujia tai määrittänyt .curlrc-tiedostoa, cURL ottaa yhteyden suoraan kohteeseen ilman proxya.
Miten estän cURLia käyttämästä proxya yhdellä pyynnöllä?
Lisää kyseiseen komentoon --noproxy "*". Jos haluat poistaa asetuksen koko shell-istunnolta, aja unset http_proxy && unset https_proxy.
Voinko käyttää cURLia vaihtuvien proxyjen kanssa?
Kyllä — jos palveluntarjoajasi tarjoaa kiertävän gatewayn (yksi päätepiste, joka antaa uuden IP:n jokaiselle pyynnölle), osoita -x siihen aivan kuten mihin tahansa muuhun proxyn osoitteeseen. Monimutkaisemmassa kierrätyksessä JS-renderöityjen kohteiden kanssa Thunderbitin kaltainen API-kerros hoitaa kierron ja bottisuojauksen sisäisesti, joten retry-logiikkaa ei tarvitse rakentaa käsin.
Miksi socks5:// vuotaa DNS-pyyntöni mutta socks5h:// ei?
Kun käytät socks5://:tä, paikallinen koneesi ratkaisee kohteen isäntänimen ennen kuin yhteys lähetetään proxylle — eli operaattorisi DNS-palvelin näkee vierailemasi verkkotunnuksen. socks5h:// siirtää isäntänimen resolvauksen proxylle itselleen, jolloin kohteesta ei näy paikallisesti mitään.
Onko cURLin käyttö proxyn kanssa laillista?
Proxyä saa yleensä käyttää laillisesti useimmissa maissa. Olennaista on se, mitä sillä tehdään — noudata aina kohdesivuston käyttöehtoja, robots.txt-tiedostoa silloin kun se on relevantti, sekä sovellettavaa tietosuojalainsäädäntöä. Tämä opas käsittelee vain teknistä toimintaa, ei minkään tietyn käyttötapauksen oikeudellista hyväksyntää.
Lue lisää
