SOCKS5 ve HTTP proxy: protokoller, DNS ve uyumluluk

SOCKS5 ve HTTP proxy farkı: HTTP CONNECT ile SOCKS5 tünellerinin ayrımı, DNS'in nerede çözüldüğü, hangi istemcinin hangi kimlik doğrulamayı desteklediği ve satın aldığınız protokolü nasıl test edeceğiniz.

Bu rehber bir proxy tarifesinde HTTP ile SOCKS5 ucu arasında seçim yapan, veya bir istemcinin neden birini reddettiğini anlamaya çalışan herkes içindir. Ücretsiz proxy dağıtmıyoruz, IP satmıyoruz. Bundan sonrası protokollerin kendisini, DNS sorgularınızın nereye gittiğini ve gerçekten ne aldığınızı nasıl test edeceğinizi kapsar.

01HTTP CONNECT ve SOCKS5: her tünel nasıl çalışır#

Ayrıntıya girmeden önce gerisinden daha önemli bir nokta var: protokol köken değildir. Residential havuz HTTP, SOCKS5 veya ikisi olarak satılabilir. Datacenter IP'ler de iki biçimde gelir. SOCKS5 bir kalite notu değildir. Bayt taşıma yoludur. Hedef sitenin trafiğinize güvenip güvenmemesi, istemcinizin geçide ulaşmak için kullandığı el sıkışmasına değil, IP'nin ağına ve geçmişine bağlıdır.

Bir HTTP proxy istemcinizle HTTP konuşur. İki tür trafiği farklı ele alır.

Düz http:// URL'lerinde istemci tam isteği proxy'ye gönderir; proxy okur, iletir, yolda başlık ekleyebilir, çıkarabilir veya önbelleğe alabilir. Az sayıda genel site hâlâ düz HTTP sunar, pratikte bu yol seyrektir.

https:// URL'lerinde ve düz HTTP olmayan her şeyde istemci CONNECT yöntemini kullanır. RFC 9110, bölüm 9.3.6 altında CONNECT, proxy'den adlı hedefe bir tünel açmasını ister; bu başarılı olunca trafiği yorumlamayı bırakıp iki yönlü bayt iletmesini, bir taraf kapatana kadar sürdürür. İstek hedefi yalnızca ana bilgisayar ve porttur, örneğin CONNECT example.com:443. Proxy 2xx durumla yanıtlayınca TLS istemciniz ile site arasında uçtan uca çalışır. Proxy hangi ana bilgisayar ve porta sorduğunuzu görebilir ama çözülmüş sayfayı okuyamaz.

Bir SOCKS5 proxy bir katman daha aşağıda çalışır. RFC 1928 kısa bir ikili el sıkışması tanımlar: istemci kimlik doğrulama yöntemleri sunar, sunucu birini seçer, sonra istemci bir komut ve hedefle istek gönderir. Üç komut vardır: olağan TCP akışı için CONNECT, gelen bağlantılar için BIND, UDP iletme için UDP ASSOCIATE. SOCKS5 yükün HTTP, TLS, SMTP veya bir oyun protokolü olup olmadığını umursamaz. Yalnızca bayt taşır.

Yani «SOCKS5 ve HTTP CONNECT» aslında akıllı proxy ile aptal proxy arasında bir seçim değildir. HTTPS trafikte ikisi de opak bir TCP tüneline varır. Asıl farklar HTTPS dışında ne taşıyabildikleri, hedef adın nasıl iletildiği ve hangi istemcilerin onlarla konuşmayı bildiğidir.

RFC 9110 ayrıca proxy'lerin CONNECT'i bilinen portlarla veya yapılandırılmış bir hedef listesiyle kısıtlaması gerektiğini (SHOULD restrict) söyler, çünkü 25. porta açık CONNECT spam iletmek için kötüye kullanılabilir. Bu yüzden HTTP ucu geçerli kimlik bilgisiyle bile bir veritabanına, posta sunucusuna veya özel TCP porta tüneli reddedebilir. Bu portlar gerekiyorsa sağlayıcının belgelerinde izin verilen CONNECT portlarını kontrol edin veya bunlara izin veren bir SOCKS5 ucu kullanın.

02DNS: cihazınızda mı, proxy üzerinden mi çözülür#

DNS, bir sitenin veya ISP'nizin sizin hakkınızda ne öğrenebileceğini gerçekten değiştiren parçadır ve SOCKS5 yapılandırmasının en sık yanlış gittiği yerdir.

HTTP proxy ile istemci ana bilgisayar adını istek hedefinde teslim eder (CONNECT example.com:443), o bağlantının çözümlemesini proxy yapar. Bu, gerçekten proxy'den geçen istekler için yerel çözümü kaldırır. Cihazınızın hiç DNS sorgusu yapmayacağını garantilemez: tarayıcılar DNS'i önden alabilir, atlama listeleri ve «doğrudan» kuralları kimi ana bilgisayarları proxy çevresinden gönderir, WebRTC kendi bağlantılarını açabilir, cihazdaki diğer uygulamalar sistem çözümleyicisini kullanmaya devam eder.

SOCKS5 ile kararı istemci verir. RFC 1928 hedef alanının ham IPv4 adresi, ham IPv6 adresi veya tam nitelikli alan adı tutmasına izin verir. İstemci adı yerelde çözer ve yalnızca IP gönderirse, ISP'nizin çözümleyicisi (veya işletim sisteminizin kullandığı çözümleyici) trafiğin kendisi proxy'den geçse bile ziyaret ettiğiniz her alanı görür. İstemci alan adını gönderirse, proxy onu kendi ucunda çözer.

curl bu seçimi görünür kılar. Kılavuzu --socks5'i «belirtilen SOCKS5 proxy'yi kullan — ama ana bilgisayar adını yerelde çöz» diye, --socks5-hostname veya socks5h:// şemasını «ana bilgisayar adını proxy çözsün» diye anlatır. Proxy'lenen isteklerde o tek harf h, yerel çözümleyicinizin hedef adı görüp görmeyeceğine karar verir. Başka istemciler aynı anahtarı «SOCKS v5 kullanırken Proxy DNS» veya «uzak DNS» gibi adların altına gizler. HTTP için geçerli aynı uyarı burada da durur: uzak DNS, SOCKS tünelinden geçen trafiği kapsar; önden almayı, atlanan ana bilgisayarları, WebRTC'yi veya diğer uygulamaları kapsamaz, varsaymak yerine sızıntı testiyle doğrulayın.

Uzak çözümleme gizlilikten öte sonuçları da değiştirir. Çözümleyici konumuna göre yanıt veren bir CDN, yerelde çözülen adı proxy çıkışının yakınına değil sizin yakınızdaki bir kenara gönderebilir. IP doğru görünse bile sayfa yanlış bölgeden yüklenir.

Şema örneği, ağ ölçümü değil: her kurulumda proxy'lenen istekler için hedef adın nerede çözüldüğü. Tarayıcı önden almasını, atlama kurallarını, WebRTC'yi veya hâlâ yerel sorgu yapabilen diğer uygulamaları kapsamaz.

03İstemci uyumluluğu ve kimlik doğrulama#

İstemcinizin zaten iyi konuştuğu protokolü seçin. Ek paketler veya sarmalayıcılarla destek eklemek, «proxy bozuk» raporlarının sık kaynağıdır.

Tarayıcılar. Firefox'un kendi proxy ayarlarında HTTP ve SOCKS alanları vardır. Chromium tabanlı tarayıcılar sistem ayarlarını veya --proxy-server bayrağını izler. İkisi de CONNECT'i sorunsuz ele alır. Kullanıcı adı ve parolalı SOCKS5 zayıf noktadır: yerleşik tarayıcı SOCKS ayarlarında kimlik bilgisi girecek yer olmayabilir; insanların proxy eklentisi veya anti-detect tarayıcı kullanmasının bir nedeni budur. Profil başına bir protokol kullanın. Aynı profilde HTTP sistem proxy'sini SOCKS5 eklentisiyle karıştırmak, kimi isteklerin bir yoldan kimi diğerinden gitmesinin kolay yoludur.

Kazıyıcılar ve HTTP kitaplıkları. curl gibi yaygın HTTP istemcileri http://user:pass@host:port proxy'sini kutudan kabul eder ve HTTPS için CONNECT'i kendisi kullanır. Kimi kitaplıklarda SOCKS5 ek paket veya derleme seçeneği ister. Yığınınız yalnızca web sayfası çekiyorsa HTTP ucu daha az sürprizli yoldur. O seçimin köken tarafını web kazıma rehberimiz anlatır.

HTTP olmayan uygulamalar. Mesajlaşma uygulamaları, oyun başlatıcıları, posta istemcileri, SSH ve veritabanı araçları HTTP istemcisi değildir. Proxy desteklediklerinde çoğu zaman HTTP değil SOCKS alanıdır. SOCKS5'in daha iyi uyduğu yer burasıdır; geçit gerçekten UDP ASSOCIATE uyguluyorsa ses gibi UDP trafiği için de. Bir tarifede SOCKS5 desteği tek başına UDP desteklendiği anlamına gelmez, UDP için satın almadan önce doğrulayın.

Kimlik doğrulama. HTTP proxy kimlik bilgilerini Proxy-Authorization başlığında gönderir, eksik veya yanlışsa 407 Proxy Authentication Required yanıtlar. SOCKS5 önce bir yöntem pazarlık eder. RFC 1928 yöntem olarak GSSAPI ve USERNAME/PASSWORD listeler; giriş ve parola veren bir tarife ikincisini kullanır, bu RFC 1929'da belirtilir.

SOCKS4 ve SOCKS4a parola desteği olmayan farklı protokollerdir; yalnızca SOCKS4 konuşan bir istemci yalnızca SOCKS5 konuşan bir uçla el sıkışmasını bitiremez. IP izin listesi parola ihtiyacını kaldırır ama protokolü değiştirmez. Sağlayıcının açıkça SOCKS4/SOCKS4a diye belgelendirdiği, genelde IP izin listesiyle eşlenen bir uç ya da SOCKS5 veya HTTP destekleyen bir istemci gerekir.

İstemciniz ile proxy arasındaki düz, şifrelenmemiş bağlantıda giriş korunmaz: HTTP Basic kimlik bilgileri yalnızca Base64 kodludur, SOCKS5 kullanıcı adı/parola açık metin gider. O ağ yolundaki herkes okuyabilir. HTTPS proxy ucu, yani istemciden proxy'ye bağlantının kendisinin TLS ile sarıldığı uç, o atlamayı kimlik bilgileri dahil korur. Her iki durumda da proxy kimlik bilgilerini önemli başka yerde yeniden kullanmayın.

Hız. İnsanlar sık sık «SOCKS5 ve HTTP proxy hızı» sorar. Fark küçüktür. İkisi de bağlantı açılınca bir el sıkışması ekler, sonra ikisi de bayt iletir. Pratikte hızı protokol değil, geçide uzaklık, sağlayıcının yükü ve çıkış IP'si kararlaştırır. Düz HTTP proxy'ler önbelleklediklerinde daha hızlı gelebilir ama bu HTTPS'e nadiren uygulanır.

SOCKS5 ve HTTPS. «HTTPS proxy» iki farklı şey demektir. Çoğu zaman CONNECT ile HTTPS siteleri tünelleyen HTTP proxy demektir; yukarıda anlatılan her şey. Bazen sizinle proxy arasındaki bağın kendisinin TLS ile sarıldığı anlamına gelir; bu yerel ağdan proxy kimlik bilgilerinizi ve hedef ana bilgisayar adlarını gizler. Düz HTTP-proxy ve SOCKS5 bağlantıları o ilk atlamayı şifrelemez, gizlemek önemliyse sağlayıcınız ve istemciniz destekliyorsa TLS sarmalı proxy ucu kullanın veya o segment için VPN kullanın.

04Hangisini seçmeli#

Son satır alıcıların en sık yaptığı hatadır. Datacenter IP'yi HTTP'den SOCKS5'e almak onu ev bağlantısı gibi göstermez. Site ağınızı puanlıyorsa çıkış türünü değiştirin. Residential proxy, mobil proxy ve datacenter proxy karşılaştırın veya önce residential ve datacenter proxy yazısını okuyun.

05Satın aldığınız protokol nasıl kontrol edilir#

Port numarasına güvenmeyin. 8080, 3128, 1080 ve 60000 gibi yüksek portlar iki protokol için de kullanılır, kimi geçit aynı portta ikisine de yanıt verir.

1. Önce kendi IP'nizi bilin. Karşılaştıracak bir taban için proxy olmadan IP adresim açın.

2. Ucun yanıt verdiğini kontrol edin. Sağlayıcının ucunu proxy kontrolüne HOST:PORT veya HOST:PORT:USER:PASS olarak yapıştırın. Kontrol bizim sunucumuzda çalışır, desteklenen protokolleri dener ve başarılı olan ilkini bildirir. Protokol öneki önce hangi protokolü deneyeceğini değiştirir, yedek denemeyi kapatmaz. Bu yüzden tek başarılı sonuç ucun hem HTTP hem SOCKS5 kabul ettiğini kanıtlamaz. Ayrı karşılaştırmak için aşağıdaki iki curl komutunu veya her protokolü zorlayan bir istemci kullanın. Kontrol başarısız olursa hatayı inceleyin; protokolün desteklenmediği sonucuna varmadan önce kimlik bilgilerini, IP izin listesini ve tarife kısıtlarını doğrulayın.

3. Aynı şeyi komut satırından kontrol edin. Sonuçlar karşılaştırılabilir olsun diye iki çalıştırmada da tek nötr test URL'si kullanın:

   # HTTP proxy: curl sends CONNECT for an https:// URL
   curl -v -x http://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   
   # SOCKS5 with proxy-side DNS (no local lookup)
   curl -v -x socks5h://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   

   İlk komutun ayrıntılı çıktısında CONNECT example.com:443 satırı ardından 200 yanıt HTTP tünelini doğrular. 407, proxy'nin HTTP konuştuğu ama kimlik bilgilerini reddettiği demektir; kimlik doğrulama sorunudur, protokol sorunu değil. HTTP denemesi bozuk yanıtla hemen düşerken socks5h:// bağlanıyorsa o port büyük olasılıkla SOCKS konuşur; sağlayıcının belgelerine karşı doğrulayın.

4. Yalnızca geçti/kaldı değil, çıkış IP'lerini karşılaştırın. Her protokolün ödediğiniz ülkede ve ağ türünde çıktığını kontrol edin. Rotating havuzda iki test protokolden bağımsız farklı IP, hatta farklı ağ gösterebilir; tek başına uyuşmazlık ayrı havuz kanıtı değildir. Sticky oturum bire bir karşılaştırmayı daha olası kılar ama testler arasında veya yeniden bağlandıktan sonra aynı IP'nin tutulacağını garantilemez.

5. Aynı oturumda DNS'i izleyin. Uzak DNS kullanın (socks5h:// veya istemcide «Proxy DNS») ve sızıntı testi çalıştırın. Bir proxy'nin çalışıp çalışmadığı yazısı DNS ve WebRTC kontrollerini adım adım anlatır.

6. IPv6'yı ayrı test edin. SOCKS5 IPv6 hedef taşıyabilir ama yalnızca geçidin IPv6 çıkışı varsa. Çift yığın ilanı çift yığın test ister.

Sonuçları nasıl okuyacağınıza dair varsayımsal işlenmiş bir örnek. Bir tarife tek geçit ana bilgisayarını iki portla listelesin, siz de yukarıdaki iki curl komutunu aynı test URL'sine karşı çalıştırın. Bu kalıplar örnektir, gerçek bir sağlayıcıdan sonuç değildir:

Bir protokole karar vermeden kısa kontrol listesi:

• İstemcinizin bu protokol için yerelde ayarı var, tarife kullanıcı adı ve parola kullanıyorsa o alanlar da dahil.
• Proxy'lenen isteklerin DNS'i proxy'de çözülüyor (SOCKS5 için socks5h:// veya «Proxy DNS») ve gerçek tarayıcı veya uygulamayla sızıntı testi çalıştırıldı.
• İhtiyacınız olan portlara izin var: HTTP ucunda CONNECT hedefleri, gerekiyorsa SOCKS5 ucunda UDP.
• Çıkış ülkesi ve ağ türü tarifeyle uyuyor, protokolden ayrı değerlendirilmiş.
• Kimlik bilgilerinin o ağdan geçmesi kaygıysa cihazınızdan proxy'ye bağ TLS proxy ucu veya VPN ile korunuyor.

Protokol bir uyumluluk seçimidir, köken bir erişim seçimidir, oturum kipi (sticky veya rotating) bir akış seçimidir. Bu sırayla karar verin, daha temiz IP sanarak SOCKS5 için fazla ödemezsiniz.

06Hem HTTP hem SOCKS5 sunan sağlayıcılar#

Satın almadan önce her sağlayıcının belgelerinde tarifenin hangi protokolleri kapsadığını, her biri için port veya ana bilgisayar adlarını, UDP desteğini ve istemciniz gerektiriyorsa IP izin listesinin olup olmadığını kontrol edin.

SOAX — residential ve mobil proxy3.8218

SOAX rotating residential ve mobil proxy'yi ortak kredi havuzunda satar; datacenter ve ISP aynı tarifelerde. Builder ayda $200 + KDV'dan başlar (200 kredi); Builder'da Tier 1 trafik $3/GB.

85 ülke

$3,00

1 GB başı

Bright Data — residential ve datacenter proxy4.41442

Bright Data, veri toplama için büyük bir proxy ağıdır: yaklaşık 195 ülkede residential, mobil, ISP ve datacenter IP'ler. Residential trafik abonelik olmadan kullandıkça ödenebilir; datacenter ve ISP adresleri 10 IP'lik paketlerden başlar. Residential ve mobil erişim kimlik doğrulaması ister.

10 ülke

$5,00

1 GB başı

Oxylabs — residential ve datacenter proxy4.0771

Oxylabs residential, mobil, ISP ve datacenter proxy'leri $30'dan tek aylık abonelik altında satar. Alıcı ödemeleri: kartlar, havale, AliPay, PayPal.

10 ülke

$0,45

1 GB başı

Decodo (Smartproxy) — residential ve datacenter proxy4.22118

Decodo (eski adı Smartproxy) residential ve datacenter proxy satar. Residential: aylık tarife olmadan $4/GB veya 3 GB için $3.75/GB'dan aylık paketler. Ödeme: kart, PayPal, Alipay, Google/Apple Pay, kripto (sınırlı).

83 ülke

$0,38

1 GB başı