cURL’ün dünya genelinde tahmini olarak 20 milyar kuruluma ulaştığı söyleniyor — macOS, çoğu Linux dağıtımı ve Windows 10/11’e varsayılan olarak gömülü geliyor. Buna rağmen, on geliştiriciye bir cURL isteğini proxy üzerinden doğru şekilde nasıl yönlendireceklerini sorun; birbirinden biraz farklı on cevap alırsınız ve bunların yarısı, işin içine kimlik doğrulama ya da SOCKS girer girmez bozulur.
Burada kapatmak istediğim boşluk tam da bu. Çoğu rehber size tek bir komut gösterir, çalıştığını söyler ve geçer. Proxy’nin gerçekten bir şey yapıp yapmadığını nasıl doğrulayacağınızı anlatmazlar (spoiler: bazen yapmıyordur) ve kurulumunuz en ufak bir şekilde ideal senaryodan saptığında karşınıza çıkan hata kodlarını da açıklamazlar. Bu rehber; HTTP/HTTPS proxy’ler, SOCKS4/SOCKS5/socks5h, ortam değişkenleri (ve bunların kendine özgü tuzakları), kapsamlı bir sorun giderme tablosu ve cURL ile proxy artık işini yapamadığında ne yapılması gerektiğini kapsıyor.
cURL Nedir ve Neden Proxy ile Kullanılır?
cURL, bir URL’ye veri gönderip almak için kullanılan komut satırı aracıdır. Hepsi bu — grafik arayüz yok, süs yok; sadece HTTP, HTTPS, FTP ve birkaç başka protokolü konuşabilen bir program. En basit kullanım şu şekildedir:
curl https://example.com
Bu komut sayfayı çeker ve ham HTML’yi terminalinize döker. Kendi başına da işe yarar; ancak geliştiricilerin ve teknik iş kullanıcılarının cURL’e yönelmesinin asıl nedeni API testleri, veri çekme, coğrafi kısıtlamalı içerikleri kontrol etme ve istekleri CI/CD hatları içinde çalıştırmaktır.
Proxy, makineniz ile hedef sunucu arasında konumlanır ve isteğinizi sizin adınıza iletir. Hedef taraf sizin IP’nizi değil, proxy’nin IP’sini görür. Bunun meşru kullanım sebepleri vardır: sitenizin başka bir ülkeden nasıl göründüğünü test etmek, QA sırasında rate limit’leri aşmadan çalışmak ya da trafiği şirketinizin zorunlu kurumsal ağ geçidinden geçirmek gibi. cURL, HTTP, HTTPS, SOCKS4 ve SOCKS5 dahil tüm proxy protokollerini destekler. Bu rehberde sık göreceğiniz bayraklar ise -x / --proxy (proxy adresinin kendisi), -v (ayrıntılı çıktı, en iyi hata ayıklama dostunuz) ve -k (SSL doğrulamasını atlar; test dışında neredeyse hiçbir zaman kullanmamanız gerekir) olacaktır.
Devam etmeden önce kısa bir not: Bu rehber, cURL ile proxy kullanmanın ağ düzeyindeki mekaniklerini anlatıyor. Bu, bir hedef sitenin kullanım koşullarını veya kurumunuzun güvenlik politikasını görmezden gelme izni değildir. Proxy, ağ rotanızı değiştirir — neyin yasal ya da izinli olduğunu değiştirmez.
Başlamadan Önce
Zorluk Seviyesi: Başlangıç - Orta
Gerekli Süre: Temel örnekleri uygulamak için yaklaşık 15 dakika
Gereksinimler:
- cURL yüklü olmalı (
curl --versionile kontrol edin — macOS, Linux veya Windows 10/11 kullanıyorsanız büyük olasılıkla zaten yüklüdür) - Sağlayıcınızdan alınmış proxy bilgileri: host, port, protokol (HTTP/HTTPS/SOCKS) ve gerekiyorsa kullanıcı adı/parola
- Bir terminal (macOS’ta Terminal, Linux’ta herhangi bir shell, Windows’ta PowerShell veya CMD)
Herhangi bir nedenle cURL yüklü değilse kurulumu tek satırlıktır: macOS’ta Homebrew ile brew install curl, Debian/Ubuntu’da sudo apt install curl, RHEL/CentOS’ta sudo yum install curl. Windows’ta ise Windows 10 build 17063’ten beri işletim sistemiyle birlikte gelir.
Bu rehber boyunca örnek değerler kullanacağım — proxy adresi için proxy.example:8080, kimlik bilgileri için user:pwd. Bunları kendi gerçek proxy detaylarınızla değiştirin ve gerçek bilgileri asla shell geçmişine, ekran görüntüsüne ya da Slack mesajına yapıştırmayın. Slack kanallarında gördüğüm proxy parolası sızıntılarının sayısını söylesem hoş olmaz.
cURL ile HTTP veya HTTPS Proxy Nasıl Kullanılır?
Bu en yaygın kurulumdur ve proxy ile ilgili işlerin büyük çoğunluğunda bunu kullanırsınız.
-x / --proxy Bayrağını Kullanmak
Temel sözdizimi şöyledir:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x ve --proxy aynı işi yapar — aklınızda hangisi kalıyorsa onu seçin. HTTP, cURL’ün varsayılan proxy şeması olduğundan, teknik olarak http:// ön ekini atıp sadece proxy.example:8080 yazabilirsiniz. Yine de bunu açıkça yazmanızı öneririm; altı ay sonra açıklık için kendinize teşekkür edeceksiniz.
Tüm URL’yi çift tırnak içine alın. Parolanız içinde @, # veya & varsa, tırnaksız bir ifade cURL’e ulaşmadan önce shell tarafından bozulur.
HTTPS Proxy Üzerinden Bağlanmak
Bazı sağlayıcılar, yalnızca proxy’den hedefe giden bağlantıyı değil, proxy’nin kendisine olan bağlantıyı da TLS üzerinden kurar. Bu, HTTPS siteleri scrape etmekten farklı bir şeydir — proxy protokolü ile hedef protokol birbirinden bağımsız değişkenlerdir. Belirtmek için:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
Burada sertifika hatası alırsanız, -k ekleyip yolunuza devam etme dürtüsüne direnin. Bu bayrak SSL sertifika doğrulamasını tamamen devre dışı bırakır; beş dakikalık yerel bir test için sorun değildir ama üretim ya da gerçek kullanıcı verisiyle temas eden işler için kötü bir fikirdir. TLS’i araya girerek sonlandıran kurumsal bir proxy ile çalışıyorsanız (enterprise ortamlarda sık görülen MITM kurulumu), doğru çözüm proxy’nin CA sertifikasını içe aktarmaktır; doğrulamayı kapatmak değil.
--proxy-user ile Kimlik Doğrulama
Kimlik bilgilerini URL’ye gömmek yerine ayrı bir bayrakla da verebilirsiniz:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
Büyük -U ile hedef site kimlik doğrulaması (-u / --user, küçük harf) aynı şey değildir — bunları karıştırmak, proxy parolanızı yanlış hedefe göndermenin en kolay yollarından biridir. Basic yerine NTLM veya Digest kullanan kurumsal ortamlarda, --proxy-user ile birlikte --proxy-ntlm ya da --proxy-digest ekleyin.
SOCKS Proxy ile cURL Nasıl Kullanılır: SOCKS4, SOCKS5 ve socks5h
SOCKS proxy’ler HTTP proxy’lere göre daha düşük bir katmanda çalışır — hangi protokolü tünellediğinizle ilgilenmezler. Bu da onları HTTP dışı trafik, Tor devreleri ve gizlilik hassasiyeti olan işler için kullanışlı kılar. Rakip rehberlerin çoğu bu konuyu tek bir komutla geçer. Bu bir hatadır; çünkü SOCKS4, SOCKS5 ve socks5h:// arasındaki farklar gerçekten önemlidir.
| Özellik | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP desteği | Evet | Evet | Evet |
| UDP desteği | Hayır | Evet | Evet |
| Kimlik doğrulama | Hayır | Evet | Evet |
| Uzak DNS çözümleme | Hayır | Hayır (yerel DNS) | Evet (proxy çözer) |
| Tor ile uyumlu | Hayır | Riskli (DNS sızıntısı) | Evet |
DNS çözümleme satırı insanların en çok hata yaptığı yerdir. socks5:// kullanırken bağlantıyı proxy’ye vermeden önce alan adını makineniz çözer — yani yerel DNS çözücünüz (dolayısıyla ISS’niz) hangi domaine gitmeye çalıştığınızı görür; gerçek HTTP trafiği proxy üzerinden geçse bile durum budur. socks5h:// bunu düzelterek alan adı çözümlemeyi proxy’ye bırakır; böylece hedefle ilgili hiçbir şey yerelde sızmaz. Tor belgelerinin neden özellikle socks5h:// önerdiğinin sebebi budur — düz socks5:// kullanmak, Tor’un sağlaması gereken anonimlik avantajının önemli bir kısmını boşa çıkarır.
Her varyantın cURL karşılığı şöyledir:
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"
Özel bir nedeniniz yoksa varsayılan olarak socks5h:// kullanın. Ek bir maliyeti yoktur ve aksi halde fark etmeyebileceğiniz bir sızıntıyı kapatır.
Ortam Değişkenleriyle Proxy Ayarlamak (ve Tuzaklardan Kaçınmak)
Her komutta -x yazmak bir süre sonra yorucu olur. Ortam değişkenleri, proxy’yi shell oturumu başına bir kez ayarlamanıza ve sonraki tüm cURL çağrılarının bunu otomatik devralmasına izin verir — cURL kılavuzu desteklenen küme olarak http_proxy, HTTPS_PROXY, ALL_PROXY ve NO_PROXY değişkenlerini belirtir.
Temel Kullanım
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"
İnsanların sürekli takıldığı nokta şu: değişken adı proxy’nin değil, hedef URL’nin protokolüne atıfta bulunur. Yani http_proxy, http:// ile başlayan URL’lere yapılan istekleri yönetir; HTTPS_PROXY ise https:// URL’lerine yapılan istekleri yönetir — ikisini de aynı HTTP proxy sunucusuna yönlendirebilirsiniz ve bu tamamen normaldir.
NO_PROXY ile Atlamak
export NO_PROXY="localhost,127.0.0.1,.internal.example"
Virgülle ayrılır ve .internal.example başındaki nokta, tüm alt alan adları için joker görevi görür. NO_PROXY, diğer her şeyin önüne geçer — komut satırında -x açıkça belirtilmiş olsa bile, NO_PROXY ile eşleşen bir hedef o istek için proxy’yi atlar.
İnsanların Gerçekten Takıldığı Tuzaklar
exportetmeyi unutmak. Sadecehttp_proxy=http://...yazıpexportetmezseniz, değişken yalnızca mevcut shell’inizde yaşar ve alt süreç olan cURL’e tamamen görünmez. Tecrübeme göre bu, “proxy çalışmıyor” destek taleplerinin en yaygın sebebidir.- Büyük/küçük harf hassasiyeti. cURL özellikle önce küçük harfli
http_proxydeğişkenini kontrol eder ve iki sürüm birden varsa bunu öncelikli kabul eder. Bazı başka araçlar yalnızca büyük harfli sürümü okur. Bir değişkenin “neden yakalanmadığını” debug ederken, farklı harf kullanımına sahip bir kopya olup olmadığına bakın. - PowerShell takma adı tuzağı. PowerShell 5.1’de
curlyazmak gerçekten cURL çalıştırmaz — farklı bayraklara sahip tamamen başka bir araç olanInvoke-WebRequestçağrılır. Windows’ta-xbayrağı garip hatalar veriyorsa, gerçekten cURL çalıştırdığınızdan emin olmak için açıkçacurl.exeyazın. - Windows sözdizimi farkları. CMD’de
set http_proxy=...kullanılır; PowerShell’de ise$env:http_proxy = "...". Terminal oturumları arasında bunları karıştırmak, bir öğleden sonrayı kaybetmenin kolay bir yoludur. - Eski değişkenler.
unset http_proxyveunset https_proxy, her isteği sessizce yanlış yönlendirip başarısız eden ölü bir proxy yapılandırmasını temizler.
Hızlı aç/kapa için .bashrc içine birkaç takma ad eklemek gerçekten zaman kazandırır:
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’ün Her Zaman Proxy Kullanmasını Sağlamak (Config Dosyası)
Zamanın %95’inde kurumsal proxy arkasındaysanız, .curlrc dosyası (Unix benzeri sistemlerde ana klasörünüzde) veya _curlrc dosyası (Windows’ta app-data klasöründe) ortam değişkenlerine dokunmadan kalıcı bir varsayılan ayar tanımlar:
proxy="http://proxy.example:8080"
Tek seferlik bir istek için bunu atlamak istediğinizde, --noproxy "*" o tek çalıştırmada config ayarını geçersiz kılar. Öncelik genellikle komut satırı bayrağı > ortam değişkeni > config dosyası şeklindedir; dolayısıyla çakışma varsa komut satırındaki -x her zaman kazanır.
Önemli bir uyarı: .curlrc içine düz metin parolası koymayın; özellikle bir yerde senkronize edilebilecek, yedeklenebilecek ya da yanlışlıkla bir repoya commit edilebilecekse. CI hatlarında, bunun yerine platformunuzun secret manager’ını kullanın ve kimlik bilgilerini maskelenmiş ortam değişkenleri olarak enjekte edin.
Proxy’nizin Gerçekten Çalışıp Çalışmadığını Nasıl Doğrularsınız
Bu, neredeyse tüm diğer rehberlerin atladığı ama en çok hata ayıklama süresi kazandıran bölümdür. Proxy kurup trafiği yönlendirdiğini varsaymak, insanların saatlerce aslında proxy kullanmayan bir scraper’ı debug etmesine yol açar.
Yöntem 1: Çıkış IP’nizi Karşılaştırın
Aynı IP-echo isteğini iki kez çalıştırın — bir kez doğrudan, bir kez proxy üzerinden — ve karşılaştırın:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
İki komut da aynı IP adresini döndürüyorsa proxy hiçbir şey yapmıyordur. Bayrak sözdiziminizi, ortam değişkenlerinizi veya NO_PROXY’nun yanlışlıkla hedefinizle eşleşip eşleşmediğini kontrol edin.
Yöntem 2: Ayrıntılı Çıktıyı Okuyun
Herhangi bir proxy isteğine -v eklediğinizde cURL tüm el sıkışmayı yazdırır:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
* Connected to proxy.example (xx.xx.xx.xx) port 8080 satırına, ardından > CONNECT httpbin.org:443 HTTP/1.1 ve sonunda < HTTP/1.1 200 Connection established benzeri bir satıra bakın. Bu sıra — proxy’ye bağlan, ardından hedefe CONNECT tüneli aç — HTTP CONNECT yöntemi çalışıyor demektir ve HTTPS hedefi bir HTTP proxy üzerinden yönlendirildiğinde tam olarak böyle olmalıdır. Eğer CONNECT satırı hiç görünmüyorsa, proxy bayrağı uygulanmıyordur. Burada dikkat: -v’yi yalnızca aktif hata ayıklama sırasında kullanın ve paylaşmadan önce çıktıyı gizleyin — ayrıntılı mod proxy kimlik bilgilerini düz metin olarak yazabilir.
Yöntem 3: Yan Yana Karşılaştırma
Özellikle coğrafi testler için, iki çıktıyı da dosyalara kaydedip diff alın:
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
Yanıt gövdeleri (veya coğrafi kısıtlamalı içerik için başlıklar) farklıysa, proxy’nin ağ rotanızı gerçekten değiştirdiğine dair görsel doğrulama elde etmişsiniz demektir — daha derine inmeden önce şüpheyi ortadan kaldırmanın hızlı ve düşük zahmetli yolu budur.
Yaygın cURL Proxy Hatalarını Giderme
Çoğu rehber burada el sallar ve bir kez -k önerir. Bu konu gerçek bir referans tablosunu hak ediyor.
| Hata | Muhtemel Neden | Çözüm |
|---|---|---|
curl: (7) Failed to connect | Yanlış proxy host/port ya da proxy kapalı | Adresi doğrulayın; ham bağlantıyı telnet host port veya nc -zv host port ile test edin |
407 Proxy Authentication Required | Eksik ya da yanlış proxy kimlik bilgileri | --proxy-user user:pass ekleyin; sağlayıcının Basic yerine NTLM/Digest/Negotiate isteyip istemediğini kontrol edin |
curl: (56) Recv failure: Connection reset by peer | Proxy aktarım sırasında bağlantıyı kesti | Sağlayıcıyla proxy kararlılığını kontrol edin; TLS sonlandıran bir proxy ise sertifika işlemeyi doğrulayın, zorla kapatmayın |
curl: (28) Connection timed out | Güvenlik duvarı engeli, eski proxy ya da yanlış port | Artık kullanılmayan değişkenler için env | grep -i proxy çalıştırın; eski değişkenleri temizleyin; nedeni izole etmek için doğrudan bir istek test edin |
| Sertifika doğrulama hatası | Güvenilmeyen veya araya giren proxy sertifikası | Doğru CA zincirini alın ve --proxy-cacert kullanın; tek seferlik teşhis dışında doğrulamayı kapatmayın |
Bu hataların herhangi birinde evrensel ilk adım -v eklemektir. Bu size bağlantının tam olarak nerede koptuğunu — DNS çözümleme, TCP bağlantısı, TLS el sıkışması ya da proxy kimlik doğrulama aşaması — üç haneli bir hata kodundan tahmin yürütmek yerine açıkça söyler.
Özellikle kurumsal proxy’lerde, --proxy-ntlm ve --proxy-negotiate Windows etki alanı kimlik doğrulama şemalarını kapsar. cURL’ün yerleşik olarak gerçekten iyi yönetemediği bir şey ise PAC dosyalarıdır (bazı şirketlerin proxy’leri dinamik atamak için kullandığı Proxy Auto-Config betikleri). Şirketiniz bunu kullanıyorsa, gerçek proxy host ve portunu manuel olarak çıkarmanız gerekir — genellikle tarayıcınızın ağ ayarlarından — çünkü cURL’ün yerleşik bir PAC ayrıştırıcısı yoktur.
cURL + Proxy Yeterli Olmadığında
cURL’ü proxy ile kullanmak, statik HTML, REST API çağrıları ve basit veri çekme işleri konusunda elinden gelenin en iyisini yapar. Zorlandığı yer ise modern web’in favori savunmalarıdır: JavaScript ile render edilen tek sayfalı uygulamalar, Cloudflare veya Akamai gibi anti-bot sistemleri ve CAPTCHA duvarları. cURL’ü bunlardan biri arkasındaki bir React ya da Vue uygulamasına yönlendirdiğinizde, geri dönen şey çoğu zaman boş bir <div id="root"></div> olur — teknik olarak başarılı bir istek, pratikte ise işe yaramaz veri. Bu cURL hatası değildir. Sadece tarayıcı değildir ve hiçbir zaman öyleymiş gibi davranmamıştır.
Terminalden cURL kullanmaya zaten alışkınsanız ve bu duvara çarptıysanız, doğal sonraki adım tamamen farklı bir araç zincirine geçmek değil; render ve yapılandırmayı sizin yerinize halledecek bir katman eklemektir. Thunderbit geliştirici araçları bu boşluğu kapatmak için tasarlanmıştır.
| Senaryo | cURL + Proxy | Thunderbit API (POST /extract) |
|---|---|---|
| Statik HTML sayfa | Mükemmel çalışır | Çalışır, ayrıca yapılandırılmış veri döndürür |
| JS ile render edilen SPA | Boş/kısmi HTML alır | renderMode: "full" ile JS’i işler |
| Anti-bot / CAPTCHA | Engellenir | Yerleşik destek |
| Yapılandırılmış çıktı | Ham HTML — siz ayrıştırırsınız | Kendi şemanızla JSON |
| Toplu işlem (100+ URL) | Manuel döngü + kendi rate limit’iniz | POST /batch/extract |
Thunderbit’in Open API’si JS ağırlıklı sayfalardan doğrudan şemaya uygun JSON döndüren bir /extract uç noktası ve temiz Markdown dönüşümü için bir /distill uç noktası sunar — ikisi de şu ana kadar cURL komutları çalıştırdığınız aynı terminal oturumundan çağrılabilir. Ayrıca Claude veya Cursor gibi AI kodlama asistanları için bir MCP sunucusu ve tamamen script içinde kalmak isterseniz bir CLI (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json) de vardır. Bunların hiçbiri cURL’ün iyi olduğu işleri cURL’den almaz — sadece cURL’ün yapısal olarak devam edemediği noktada devreye girer. AI destekli çekimin kendi scraper mantığınızı yazmaya kıyasla nerede durduğunu daha geniş çerçevede görmek isterseniz, AI web scraping incelememiz ve en iyi AI web scraper’lar karşılaştırmamız bu konuyu daha ayrıntılı ele alıyor. İşe kod yazmadan, daha çok iş odaklı bir açıdan yaklaşıyorsanız kod yazmadan web scraping yazımız da iyi bir başlangıçtır.
Sonuç
cURL ile proxy’nin doğru şekilde konuşmasını sağlamak, gerçek hata noktalarını bildiğinizde zor değildir — ve bunların neredeyse hiçbirinin proxy’nin kendisi olmadığı ortaya çıkar. export etmeyi unutmak. -u ile -U’yu karıştırmak. socks5h:// yerine socks5:// kullanmak. curl.exe yerine PowerShell’in curl takma adını çalıştırmak. Bunların her biri, proxy sağlayıcısıyla ilgisi olmayan kafa karıştırıcı ve genel görünümlü hatalar üretir.
En çok zaman kazandıran alışkanlık: sorun gidermeden önce doğrulayın. IP-echo kontrolünü çalıştırın, -v çıktısına bir göz atın, downstream’de bir şey bozuk varsaymadan önce proxy’nin gerçekten istek yolunda olup olmadığını teyit edin. Hedefiniz size temiz HTML yerine JavaScript göndermeye başladığında, bu daha fazla bayrakla çözülecek bir cURL problemi değildir — Thunderbit API’si gibi render için tasarlanmış bir aracı devreye sokmanız gerektiğinin işaretidir. JSON çıktısı ile ham HTML arasındaki farkı bizzat görmek istiyorsanız ücretsiz bir plan da sunar.
SSS
cURL varsayılan olarak proxy kullanır mı?
Hayır. http_proxy / HTTPS_PROXY ortam değişkenlerini ayarlamadıysanız veya bir .curlrc dosyası yapılandırmadıysanız, cURL hedefe doğrudan bağlanır; arada proxy olmaz.
cURL’ün tek bir istekte proxy kullanmasını nasıl engellerim?
O belirli komuta --noproxy "*" ekleyin. Tüm shell oturumu için kapatmak istiyorsanız unset http_proxy && unset https_proxy çalıştırın.
cURL ile dönen proxy’leri kullanabilir miyim?
Evet — sağlayıcınız dönen bir gateway sunuyorsa (her istekte yeni IP atayan tek bir uç nokta), -x bayrağını diğer proxy’lerde olduğu gibi bu gateway adresine yönlendirmeniz yeterlidir. JS ile render edilen hedeflerde daha karmaşık rotasyon mantıkları için Thunderbit gibi bir API katmanı, rotasyon ve anti-bot tarafını içeride ele alır; böylece yeniden deneme mantığını elle yönetmeniz gerekmez.
socks5:// neden DNS isteklerimi sızdırıyor da socks5h:// sızdırmıyor?
'socks5://' kullanıldığında yerel makineniz, bağlantı isteğini proxy’ye göndermeden önce hedef alan adını çözer — yani ISS’nizin DNS çözücüsü ziyaret ettiğiniz alan adını görür. socks5h:// ise alan adı çözümlemeyi proxy’nin kendisine bırakır; böylece hedefle ilgili hiçbir şey yerelde görünmez.
cURL’ü proxy ile kullanmak yasal mı?
Çoğu yargı alanında bir proxy kullanmak tek başına yasaldır. Önemli olan onu nasıl kullandığınızdır — hedef sitenin kullanım koşullarına, uygulanabildiği yerlerde robots.txt dosyasına ve ilgili veri gizliliği yasalarına mutlaka uyun. Bu rehber yalnızca teknik mekanikleri kapsar; belirli bir kullanım senaryosu için hukuki onay vermez.
Daha Fazla Bilgi
