Protokol düzeyinde HTTP proxy ve SOCKS5: CONNECT, ATYP, aracı ne görür ve nasıl seçilir

Bir proxy servisinin müşteri panelini açtıysanız şu manzarayı görmüşsünüzdür: aynı adres, aynı kullanıcı adı, yanında iki port. Biri HTTP olarak etiketlenmiş, diğeri SOCKS5. Çoğu kişi rastgele ya da alışkanlıktan seçer. Oysa bu iki satırın arkasında bayt düzeyinde farklı yapıda, trafiğinizi farklı gören ve gerçek istemcilerde farklı davranan iki ayrı protokol var. Bu rehber, aradaki farkı son bayta kadar inceliyor ve pratik seçim tablolarıyla bitiyor.

Giriş: neden tek bir proxy iki modda sunuluyor ve bu pazarlama değil

Başlıktaki soruya dürüst bir yanıtla başlayalım. Proxeon size iki portlu bir adres verdiğinde, arkasında aynı makine, aynı çıkış IP adresi ve aynı hesap var. Fark, trafiğin nereye gittiğinde değil. Fark, istemcinizin yolun ilk bölümünde, uygulamanızdan aracıya kadar proxy sunucusuyla hangi dili konuştuğunda.

HTTP proxy HTTP dilini konuşur. HTTP isteklerini alır, okur, ne elde etmek istediğinizi anlar ve kaynağa kendisi gider. Önbelleğe alabilir, başlık ekleyebilir, durum kodlarıyla yanıt verebilir. HTTP olmayan her şey için tek bir evrensel hilesi vardır: onu düz bir boruya dönüştüren CONNECT metodu.

SOCKS5 HTTP'nin ne olduğunu hiç bilmez. Bu bir oturum katmanı protokolüdür: istemci "beni şu host ve porta bağla" der, proxy bir TCP bağlantısı açar ve o andan itibaren baytları iki yön arasında aktarmaya başlar. İçinde ne olduğu onu ilgilendirmez: TLS, IMAP, SSH, bir veritabanı protokolü ya da kendi ikili formatınız.

Neden tek bir mod bırakılmıyor? Çünkü uyumlulukları farklı. Kurumsal ve masaüstü yazılımların yarısı yalnızca sistem ayarları üzerinden HTTP proxy kullanabilir. Ağ kütüphanelerinin önemli bir kısmı ve neredeyse tüm web dışı trafik SOCKS5'te daha rahat eder. Aynı IP üzerinde her iki modu sunmak, istemciyi araca uydurmak yerine aracı istemciye göre seçebileceğiniz anlamına gelir.

Bu makalede öğrenecekleriniz:

• HTTP proxy'ye giden bir isteğin metin düzeyinde nasıl göründüğü ve normal bir site isteğinden farkı;
• şeffaf HTTP modunda proxy'nin tam olarak neyi gördüğü ve değiştirebileceği;
• CONNECT metodunun nasıl çalıştığı ve tünel kurulduktan sonra aracının neyi görmeye devam ettiği;
• SOCKS5'in bayt düzeyinde el sıkışması, kimlik doğrulama şemaları ve üç ATYP adres türü;
• SOCKS5 isteğinde alan adı ile IP arasındaki seçimin neden coğrafi konum ve DNS gizliliğini etkilediği;
• HTTP dışı protokoller, UDP, ek yük, önbellekleme ve loglama açısından karşılaştırma;
• "görev, protokol, neden" tablosu ve popüler istemci ile kütüphanelerdeki uyumluluk analizi.

UDP ASSOCIATE komutunun işleyişini ve curl ile Python'da socks5 ile socks5h şemaları arasındaki farkı burada ayrıntılı olarak ele almıyoruz: bu konulara Proxeon blogunda ayrı yazılar ayrıldı, ilgili yerlerde bağlantı verilecek.

Temeller: proxy ağ yığınında nerede durur

Protokol tartışmasının anlamlı olması için terimler üzerinde anlaşalım. Çok değiller.

Üç taraf ve iki bağlantı

Proxy'li her senaryoda üç taraf vardır: istemci (tarayıcınız, betiğiniz, posta programınız), proxy sunucusu (aracı) ve hedef sunucu (origin). Aralarında birbirinden bağımsız iki TCP bağlantısı bulunur. Birincisi: istemciden proxy'ye. İkincisi: proxy'den hedef sunucuya. Hedef sunucu yalnızca ikinci bağlantıyı görür ve dolayısıyla yalnızca proxy'nin IP adresini görür.

Bu makalede tartıştığımız her şey yalnızca ilk bağlantıyla ilgilidir. HTTP ile SOCKS5 arasındaki fark tam orada yaşar. İkinci bağlantı her iki durumda da aynı yapıdadır: proxy'den hedef hosta normal bir TCP.

Model katmanları ve bunun neden önemli olduğu

Yararlı bir benzetme: bir kargo şirketi düşünün. Şeffaf moddaki HTTP proxy, paketinizi açan, adresi ve içeriği okuyan, gerekirse yeniden paketleyen ve hatta deposunda bir kopyası varsa kendisi yanıt verebilen bir kurye gibidir. SOCKS5 ise adresi söylediğiniz ama paketi mühürlü teslim ettiğiniz bir kurye gibidir. İçinde ne olduğunu bilmez ve bilmek istemez.

Ağ modeli terimleriyle konuşursak, HTTP proxy uygulama katmanında çalışır: isteğin anlamını anlar. SOCKS5 oturum katmanında çalışır: "host", "port", "bağlantı" kavramlarıyla işlem yapar ve daha yukarı çıkmaz.

Ad çözümlemesi nerede yapılır

Tüm bu metinde kırmızı bir iplik gibi geçecek ayrı bir kavram: DNS çözümlemesi. example.com'a başvurduğunuzda, birisinin adı bir IP adresine dönüştürmesi gerekir. Bunu istemciniz yerel olarak yapabilir ya da proxy kendi tarafında yapabilir. Buna bağlı olarak, hangi DNS altyapısını kullandığınız, CDN'den hangi bölgesel yanıtı aldığınız ve ziyaret ettiğiniz alan adları hakkındaki bilginin yerel ağa sızıp sızmadığı değişir. Bu maddeyi unutmayın; hem HTTP hem de SOCKS5 bölümünde karşımıza çıkacak.

Kimlik doğrulama

Hem HTTP proxy hem de SOCKS5 kullanıcı adı ve parolayı doğrulayabilir, ama bunu farklı şekillerde yapar. HTTP, Proxy-Authorization başlığını ve 407 yanıt kodunu kullanır. SOCKS5 ise yöntem numarası 0x02 olan ayrı bir alt protokol kullanır. Protokolden bağımsız bir alternatif de vardır: istemcinin IP adresine göre yetkilendirme; proxy, önceden izin verilen bir adresten gelen herkesi kabul eder. Proxeon'da her iki seçenek de mevcut ve aralarındaki tercih, kimlik bilgilerini iletemeyen istemcileri bağlamanın ne kadar kolay olduğunu etkiler.

HTTP proxy: mutlak URI'li istek, proxy neyi görür ve değiştirebilir

Bir siteye giden normal bir HTTP isteği şöyle görünür:

GET /catalog/items?page=2 HTTP/1.1
Host: shop.example

Dikkat edin: istek satırında yalnızca yol var. Host ayrı bir başlıkta iletilir. Bu formata origin-form denir. İstemci, bir siteyle değil bir proxy'yle konuştuğunu bildiğinde formatı absolute-form'a çevirir: istek satırına tam URI yerleştirilir.

GET http://shop.example/catalog/items?page=2 HTTP/1.1
Host: shop.example
Proxy-Authorization: Basic dXNlcjpwYXNz
User-Agent: my-parser/1.0
Accept: text/html

Host'u neden iki kez yazmak gerekiyor? Tarihsel olarak mutlak form, Host başlığından önce ortaya çıktı ve proxy'ye nereye gideceğini söylemenin tek yolu buydu. Modern HTTP/1.1 standardı, proxy'den mutlak formu kabul etmesini, proxy'ye başvuran istemciden ise tam olarak bunu kullanmasını ister. Host başlığı uyumluluk için ve proxy'nin isteği zaten origin-form'da ileteceği hedef sunucu için korunur.

HTTP proxy'nin gördükleri

Şeffaf modda (istemci ile hedef site arasında şifreleme yoksa) proxy istek ve yanıtta bulunan her şeyi görür:

• metot, sorgu parametreleri dahil tam URL;
• tüm istek başlıkları: User-Agent, Cookie, Authorization, Referer;
• isteğin gövdesi tamamen: formlar, JSON, yüklenen dosyalar;
• yanıt durumu, yanıt başlıkları ve yanıt gövdesi.

Bu bir yan etki değil. Mimarinin temel özelliğidir: bir isteği iletmek için proxy onu ayrıştırmak zorundadır. Ayrıştırdığına göre de onunla istediği her şeyi yapabilir.

HTTP proxy'nin değiştirebilecekleri

Standart, başlıkları uçtan uca (end-to-end) ve atlama bazlı (hop-by-hop) olarak ikiye ayırır. Atlama bazlı başlıklar belirli bir bağlantıya aittir ve proxy tarafından iletilmeden önce silinmek zorundadır. Bunlara Connection, Keep-Alive, Proxy-Authorization, Proxy-Authenticate, TE, Trailer, Transfer-Encoding, Upgrade dahildir. Bu yüzden proxy kullanıcı adınız ve parolanız hedef siteye uçmaz: Proxy-Authorization başlığı standart gereği proxy'de çıkarılır.

Zorunlu temizliğin yanı sıra proxy şunları yapabilir:

• kendi adını ve protokol sürümünü belirten Via başlığını ekleyebilir; standart bunu gerektirir ama pratikte anonim proxy'ler bunu atlar;
• istemcinin gerçek IP'sini içeren X-Forwarded-For ekleyebilir; kurumsal proxy'ler böyle yapar ve dış kaynaklarla çalışmak için satın aldığınız bir proxy bunu asla yapmamalıdır;
• yanıt önbelleğe alınabilir olarak işaretlenmişse hedef sunucuya başvurmadan yanıtı önbelleğinden verebilir;
• gövde kodlamasını değiştirebilir, sıkıştırma ekleyebilir veya kaldırabilir, HTML içindeki bağlantıları yeniden yazabilir;
• isteği kendi yanıtıyla, örneğin 403 veya 407 ile reddedebilir.

407 Proxy Authentication Required yanıtı ayrı bir paragrafı hak ediyor. Proxy yetkilendirme istiyorsa ve istemci bunu göndermemişse, proxy 407 adıyla ve desteklediği şemaları listeleyen Proxy-Authenticate başlığıyla yanıt verir. İyi istemciler bundan sonra isteği Proxy-Authorization ile tekrarlar. Kötü istemciler kullanıcıya anlaşılmaz bir hata gösterir. Kurulum sırasında sık yaşanan sorun tam da buradan çıkar: uygulama "proxy'yi görmüyor", oysa gerçekte 407'yi işlemeyi bilmiyor.

Uygulamada inceleyelim

Bütün bunları kendi gözünüzle görmenin en basit yolu: -v anahtarlı curl.

curl -v -x http://user:pass@gate.proxeon.net:8080 http://httpbin.org/get

Çıktıda GET http://httpbin.org/get HTTP/1.1 biçiminde bir satır ve Proxy-Authorization başlığı göreceksiniz. İşte mutlak form budur.

Aynı isteği Python'da soket üzerinden elle yapalım, hiçbir sihir kalmasın:

import socket, base64

creds = base64.b64encode(b"user:pass").decode()
req = (
"GET http://httpbin.org/get HTTP/1.1\r\n"
"Host: httpbin.org\r\n"
f"Proxy-Authorization: Basic {creds}\r\n"
"Connection: close\r\n\r\n"
)
s = socket.create_connection(("gate.proxeon.net", 8080))
s.sendall(req.encode())
print(s.recv(65535).decode(errors="replace"))

Burada proxy için hiçbir kütüphane yok. Sadece bir soket ve doğru oluşturulmuş bir metin. Şeffaf moddaki HTTP proxy o kadar basittir ki bir akşamda yazılabilir; gücü de zayıflığı da aynı yerde.

HTTP modunda ad nerede çözülür

Mutlak formda istemci host adını olduğu gibi proxy'ye iletir. Çözümlemeyi proxy yapar. İstemcinin hedef sunucunun IP adresini bilmesi gerekmez ve yerel bir DNS sorgusu çalıştırılmaz. Bu kullanışlıdır ama bizi ana sınırlamaya götürür: anlatılan şema yalnızca şifrelenmemiş HTTP için çalışır. HTTPS için mutlak form işe yaramaz, çünkü TLS bağlantısı istemci ile hedef sunucu arasında kurulmalıdır ve proxy sertifikayı bozmadan araya giremez. İşte bu yüzden CONNECT icat edildi.

CONNECT metodu: HTTP proxy'yi TCP tüneline dönüştürmek

CONNECT, proxy'den isteği iletmesini değil, belirtilen host ve portla bir TCP bağlantısı kurmasını ve ardından şeffaf bir boru olmasını isteyen bir HTTP metodudur. İstek şöyle görünür:

CONNECT shop.example:443 HTTP/1.1
Host: shop.example:443
Proxy-Authorization: Basic dXNlcjpwYXNz
Proxy-Connection: Keep-Alive

Hedefin formatına dikkat edin: şema ve yol yok, yalnızca host ve port. Bu, origin-form ve absolute-form'dan sonra üçüncü format olan authority-form'dur.

Proxy kabul ederse şöyle yanıtlar:

HTTP/1.1 200 Connection established

Koddan sonraki metin herhangi bir şey olabilir; istemciler yalnızca 2xx'e bakar. Bu andan itibaren HTTP biter. İstemci sokete ne yazarsa proxy onu bayt bayt hedef sunucuya iletir, tersi de geçerli. İstemci TLS el sıkışmasını tam bu sokette, doğrudan sunucuya bağlıymış gibi başlatır.

Aracı CONNECT'ten sonra ne görür

Asıl ilginç kısım burada başlıyor. Az önce her şeyi gören proxy aniden körleşir. Başarılı CONNECT'ten sonra proxy şunları bilir:

• CONNECT satırındaki host adı ve port; aldığı tek anlamsal bilgi budur;
• bağlantının kurulduğu ve kapatıldığı zaman;
• iki yönde aktarılan bayt miktarı;
• tünelin içinde TLS varsa TLS ClientHello içeriği: orada açık metin olarak SNI (sunucu adı), desteklenen şifre listesi, uzantılar iletilir; modern Encrypted Client Hello uzantısı SNI'yi de gizler ama desteği henüz yaygın değil;
• HTTP düzeyinden hiçbir şey: ne URL, ne başlık, ne çerez, ne gövde.

Başka bir deyişle, CONNECT'ten sonra HTTP proxy tam olarak SOCKS5 kadarını görür. Host, port, zamanlamalar, hacimler. İki protokol arasındaki görüş farkı yalnızca şifrelenmemiş HTTP trafiği için geçerlidir ve 2026'da gerçek görevlerde bunun çok azı kaldı.

CONNECT illa HTTPS'e götürmek zorunda değil

Yaygın bir düşünce hatası: CONNECT yalnızca HTTPS için gerekli. Aslında standart tünelin içeriğini sınırlamaz. CONNECT üzerinden 993 portundaki bir IMAP sunucusuna, 22 portundaki SSH'a, herhangi bir TCP servisine bağlanılabilir. Tek soru, proxy yapılandırmasının buna izin verip vermediğidir. Birçok genel ve kurumsal HTTP proxy, kötüye kullanımı önlemek için CONNECT'e yalnızca 443 ve bazen 80 portunda izin verir. Proxeon CONNECT'e rastgele portlarda izin verir, ancak yazılımınız SOCKS5 destekliyorsa HTTP dışı protokoller için SOCKS5 daha doğal bir seçim olarak kalır, aşağıda göreceğimiz gibi.

Örnek: CONNECT üzerinden elle TLS

openssl aracı HTTP proxy'sinden kendi başına geçebilir:

openssl s_client -proxy gate.proxeon.net:8080 -connect shop.example:443 -servername shop.example

Python'da standart kütüphaneyle, dış bağımlılık olmadan şöyle görünür:

import http.client, ssl

conn = http.client.HTTPSConnection("gate.proxeon.net", 8080,
 context=ssl.create_default_context())
conn.set_tunnel("shop.example", 443,
headers={"Proxy-Authorization": "Basic dXNlcjpwYXNz"})
conn.request("GET", "/")
resp = conn.getresponse()
print(resp.status, resp.getheader("server"))

set_tunnel metodu tam olarak anlatılanı yapar: CONNECT gönderir, 200 bekler, ardından soketi TLS ile sarar. Dikkat edin, TLS bağlamı sertifikayı proxy'nin değil, tam olarak shop.example'ın doğrular. Proxy bu şemada istemcide hata yaratmadan sertifikayı değiştiremez.

HTTP/2 ve HTTP/3'te CONNECT

HTTP/2'de CONNECT metodu korunmuştur ama tek bir çoklanmış bağlantı içinde çalışır: her tünel ayrı bir akıştır. Bu, proxy'ye tek bir TCP bağlantısı üzerinden düzinelerce tünel taşımayı ve el sıkışmalardan tasarruf etmeyi sağlar. Genişletilmiş CONNECT (:protocol sözde başlığıyla) HTTP/2 üzerinden WebSocket için kullanılır. QUIC tabanlı HTTP/3'te CONNECT-UDP spesifikasyonu ortaya çıktı; bu resmen HTTP proxy üzerinden UDP tünellemeye izin verir. Ancak istemci kütüphanelerinde bu henüz egzotik ve pratikte proxy üzerinden UDP gerekiyorsa SOCKS5'e bakacaksınız.

CONNECT'in yapamadıkları

• Önbelleğe alma: tünelin içeriği opak.
• Başlıkları değiştirme: görünmüyorlar.
• HTTP/1.1'de tek tünel üzerinden birden çok hedef hostu çoklama: bir CONNECT bir TCP bağlantısına eşittir.
• HTTP/1.1 ve HTTP/2'de UDP iletme.

SOCKS5: el sıkışma, kimlik doğrulama ve ATYP

SOCKS5, RFC 1928'de, kullanıcı adı ve parola kimlik doğrulama şeması ise RFC 1929'da tanımlanmıştır. Her iki spesifikasyon birkaç sayfaya sığar; bu da protokolün avantajlarından biridir: sıfırdan uygulamak zor değildir, dolayısıyla çok sayıda uygulaması vardır ve yorum farkı azdır.

SOCKS5 ikili bir protokoldür. Metin yok, yalnızca sabit yapılı baytlar. CONNECT komutu için tam alışverişi inceleyelim.

Adım 1: selamlama ve kimlik doğrulama yönteminin seçimi

İstemci sürümü ve desteklediği kimlik doğrulama yöntemlerini gönderir:

05 02 00 02
VER=5 NMETHODS=2 METHODS: 00 (kimlik doğrulama yok), 02 (kullanıcı adı/parola)

Sunucu bir yöntem seçer ve iki baytla yanıt verir:

05 02
VER=5 METHOD=02 (sunucu kullanıcı adı/parola istiyor)

Sunucu 05 FF yanıtı verirse, bu "önerilen yöntemlerden hiçbiri uygun değil" anlamına gelir ve istemci bağlantıyı kapatmak zorundadır. Parolayı vermeyi unuttuğunuzda ve Proxeon proxy'niz kullanıcı adıyla yetkilendirmeye ayarlıysa, bayt düzeyinde görünen tam olarak budur.

Adım 2: RFC 1929'a göre kimlik doğrulama

Yöntem 02 seçildiyse istemci şunu gönderir:

01 04 75 73 65 72 04 70 61 73 73
VER=1 ULEN=4 UNAME="user" PLEN=4 PASSWD="pass"

Dikkat: alt protokolün sürümü burada 05 değil, 01. Bu, kendi yazdığınız istemcilerde sık görülen bir hata kaynağıdır. Sunucu şöyle yanıtlar:

01 00
VER=1 STATUS=00 (başarı; başka herhangi bir değer reddetme anlamına gelir)

Kullanıcı adı ve parola açık metin olarak iletilir. Sizinle proxy arasındaki ağ güvenilir değilse bunu hatırlamakta fayda var. Pratikte proxy'ye bağlantı genellikle sağlayıcının kendi kanalı üzerinden gider ve sorun taşıma katmanında veya IP ile yetkilendirmeye geçilerek çözülür.

Adım 3: bağlantı isteği

Şimdi en önemli mesaj:

05 01 00 03 0C 73 68 6F 70 2E 65 78 61 6D 70 6C 65 01 BB
VER=5 CMD=01 (CONNECT) RSV=00 ATYP=03 (alan adı)
LEN=12 ADDR="shop.example" PORT=0x01BB (443)

CMD alanı üç değer alır: 01 CONNECT (giden TCP bağlantısı), 02 BIND (gelen bağlantı bekleme, neredeyse hiç kullanılmaz), 03 UDP ASSOCIATE (bir UDP aktarıcısı oluşturma). UDP ASSOCIATE'in işleyişini ve tuzaklarını ayrı bir yazıda ele aldık; SOCKS5'te UDP yazısına bakabilirsiniz. Burada yalnızca şunu not edelim: iki protokolden UDP'si standart olarak bulunan tek protokol budur.

ATYP: alan adı ile IP karşıtlığı

ATYP alanı, istemcinin hedef adresi hangi biçimde ilettiğini belirler:

• 0x01 IPv4: sonraki 4 bayt adres;
• 0x03 alan adı: bir bayt uzunluk, ardından sonlandırıcı sıfır olmadan ad;
• 0x04 IPv6: sonraki 16 bayt adres.

Görünüşte teknik bir ayrıntı. Aslında bu, istemcinin verdiği en önemli kararlardan biri ve nedeni şu.

İstemci ATYP=0x01 veya 0x04 kullanıyorsa, isteği göndermeden önce kendisi DNS çözümlemesi yapmış demektir. Makineniz kendi DNS sunucusuna başvurmuş, adresi almış ve proxy'ye hazır IP'yi iletmiştir. Sonuçları:

• DNS sorgusu yerel ağınızdan geçmiş ve sağlayıcınız veya yöneticiniz tarafından görülmüştür;
• DNS'in sizin bölgeniz için verdiği IP'yi almışsınızdır; CDN arkasındaki siteler için bu, başka bir ülkede duran proxy'nin "yabancı" bir edge sunucusuna başvuracağı, bunun bağlantıyı yavaşlatacağı ve anormal görünebileceği anlamına gelir;
• makinenizde IPv6 yoksa hiçbir zaman AAAA kaydı alamaz ve proxy'nin IPv6 rotası olsa bile kullanamazsınız;
• ağınızdaki DNS standart dışı davranıyorsa proxy yanlış adres alır ve nedeni uzun süre arayabilirsiniz.

İstemci ATYP=0x03 kullanıyorsa çözümlemeyi proxy yapar. Kendi DNS altyapısını kullanır, konumuna uygun adresi alır ve yerel ağınız hangi alan adlarına başvurduğunuzu görmez. Coğrafi konum gerektiren görevler için bu kritiktir: belirli bir ülkedeki proxy'nin anlamı, hedef sunucu ev ağınızın DNS'ine göre seçiliyorsa kısmen kaybolur.

İstemciyi alan adı göndermeye nasıl zorlarız? İstemciye bağlı. curl ve Python kütüphanelerinde bu, socks5 ile socks5h arasındaki seçimle ilgilidir ve bu ayrı bir incelemenin konusudur. Burada nedeni anlamak önemlidir: h harfi "hostname" anlamına gelir ve ATYP=0x03'ü etkinleştirir. O olmadan kütüphane adı yerel olarak çözümler.

Adım 4: sunucu yanıtı

05 00 00 01 C0 A8 01 0A 1F 90
VER=5 REP=00 (başarı) RSV=00 ATYP=01 BND.ADDR=192.168.1.10 BND.PORT=8080

REP alanı sonuç kodunu içerir. Hata ayıklarken ezbere bilmek faydalıdır:

• 00 başarı;
• 01 genel sunucu hatası;
• 02 kurallara göre bağlantı yasak;
• 03 ağa ulaşılamıyor;
• 04 hosta ulaşılamıyor;
• 05 hedef sunucu bağlantıyı reddetti;
• 06 TTL doldu;
• 07 komut desteklenmiyor;
• 08 adres türü desteklenmiyor.

08 kodu, ATYP=0x03 veya IPv6'yı desteklemeyen eski ya da basitleştirilmiş uygulamalarda karşınıza çıkar. Proxeon üç adres türünü de destekler.

SOCKS5 içeriği neden ayrıştırmaz

REP=00 yanıtından sonra SOCKS5 protokolü bitmiştir. İstemcinin bundan sonra yazdığı her şeyi proxy, hedef bağlantıya hiç analiz etmeden aktarır. Bu bir uygulama sınırlaması değil, tasarımın özelliğidir. SOCKS5'in ne "istek" kavramı ne de "başlık" kavramı vardır. HTTP'nin, IMAP'in veya TLS'in ne olduğunu bilmez. Ona adres ve port verilmiştir, o iki boruyu bağlamıştır.

Bundan birkaç pratik sonuç çıkar:

• SOCKS5 önbelleğe alamaz: bir yanıtın nerede bitip diğerinin nerede başladığını anlamaz;
• SOCKS5 başlık ekleyemez veya içeriği değiştiremez; en fazla bağlantıyı kapatabilir;
• SOCKS5 URL'ye göre filtreleyemez, yalnızca host ve porta göre;
• SOCKS5, dün icat ettiğiniz dahil herhangi bir TCP protokolüyle aynı derecede iyi çalışır.

Python'da tam SOCKS5 el sıkışması

import socket, struct

def socks5_connect(proxy, user, pwd, host, port):
s = socket.create_connection(proxy)
s.sendall(b"\x05\x02\x00\x02")
ver, method = s.recv(2)
if method == 0x02:
u, p = user.encode(), pwd.encode()
s.sendall(b"\x01" + bytes([len(u)]) + u + bytes([len(p)]) + p)
if s.recv(2)[1] != 0:
raise RuntimeError("auth failed")
elif method != 0x00:
raise RuntimeError("no acceptable auth method")
h = host.encode()
s.sendall(b"\x05\x01\x00\x03" + bytes([len(h)]) + h + struct.pack("!H", port))
reply = s.recv(4)
if reply[1] != 0:
raise RuntimeError(f"connect failed, REP={reply[1]}")
atyp = reply[3]
s.recv({1: 4, 4: 16}.get(atyp, 0) if atyp != 3 else s.recv(1)[0])
s.recv(2)
return s

sock = socks5_connect(("gate.proxeon.net", 1080), "user", "pass", "shop.example", 443)
# sonrasında sock ssl.wrap_socket ile sarılabilir veya herhangi bir protokole verilebilir

Otuz satır ve alan adını (ATYP=0x03) ileten, çözümlemeyi proxy sunucusuna bırakan çalışan bir SOCKS5 istemciniz var. İşte bu basitlik, SOCKS5'i programlanabilir erişim için fiili standart yapıyor.

Kriterlere göre karşılaştırma: her biri nerede kazanır

Her iki protokolün işleyişini bayt düzeyinde incelediğimize göre, karşılaştırma artık zevk tartışması olmaktan çıkıp ölçülebilir farklar listesine dönüşüyor.

HTTP dışı protokoller

SOCKS5 standart olarak herhangi bir TCP protokolüyle çalışır: CONNECT komutu, host, port, tamam. HTTP proxy de CONNECT üzerinden çalışabilir ama çekincelerle: istemci HTTP dışı trafik için CONNECT göndermeyi bilmelidir (posta istemcileri bilir, çoğu CLI aracı bilmez) ve proxy istenen porta izin vermelidir. Kazanan: SOCKS5.

UDP

SOCKS5'te UDP ASSOCIATE var. HTTP proxy'de 1.1 ve 2 sürümlerinde hiçbir şey yok, HTTP/3'ün CONNECT-UDP özelliği ise pratikte istemciler tarafından neredeyse hiç desteklenmiyor. Görev doğrudan DNS sorguları, QUIC, ses protokolleri, oyun trafiği içeriyorsa başka seçenek yok. Kazanan: SOCKS5, şu çekinceyle: her SOCKS5 sunucusu UDP'yi açmaz, tarife belgelerinden kontrol edin.

Bağlantı kurulumundaki ek yük

İstemci ile proxy arasında, TCP el sıkışmasının üzerine, gidiş-dönüş (RTT) cinsinden sayalım:

• HTTP proxy, şeffaf mod, yetkilendirme yok: 0 ek RTT, istek hemen gider;
• İlk istekte yetkilendirmeli HTTP CONNECT: 1 RTT (CONNECT, 200 yanıtı);
• Yetkilendirmesiz SOCKS5: 2 RTT (selamlama, istek);
• Kullanıcı adı ve parolalı SOCKS5: 3 RTT (selamlama, kimlik doğrulama, istek).

Bayt cinsinden fark terstir: yetkilendirmeli tam SOCKS5 el sıkışması yaklaşık 40 bayta sığar, Host, Proxy-Authorization ve User-Agent başlıklı CONNECT ise kolayca 150 ve üzerine çıkar. Ama gerçek görevlerde belirleyici olan bayt değil, RTT'dir. Proxy'ye gecikme 50 ms ise yetkilendirmeli SOCKS5, her yeni bağlantıya CONNECT'in 50 ms'sine karşı 150 ms ekler. İstemci bağlantıları yeniden kullanıyorsa (keep-alive, havuzlar) bu tek seferlik bir bedeldir. Her istek yeni bir soket açıyorsa fark birikir. RTT'de kazanan: HTTP. SOCKS5 için farkı kapatmanın yolu: bir RTT'yi ortadan kaldıran IP ile yetkilendirme.

Önbellekleme

Yalnızca şeffaf moddaki HTTP proxy. Ne CONNECT ne SOCKS5. Üstelik önbelleğe yalnızca şifrelenmemiş trafik alınabilir, bugün bunun azlığı nedeniyle bu kriter belirleyici olmaktan çıkıp niş bir alana dönüştü. İç derleme sistemleri, paket aynaları, güvenilir bir çevre içinde TLS'siz tekrarlanan API istekleri için önemlidir. Kazanan: HTTP, ama dar bir uygulanabilirlik alanıyla.

Loglama

Bu madde sık yanlış anlaşılır. Her modda proxy loga ne yazabilir?

• Şeffaf HTTP: tam URL, metot, başlıklar, istenirse gövde; yanıt durumu; hacimler.
• HTTP CONNECT: CONNECT satırındaki host ve port; zaman; hacimler; istenirse ClientHello'dan SNI.
• ATYP=0x03'lü SOCKS5: alan adı ve port; zaman; hacimler; istenirse SNI.
• ATYP=0x01/0x04'lü SOCKS5: yalnızca IP ve port; proxy alan adını bilmez; zaman; hacimler; SNI.

Şifrelenmiş trafik için CONNECT ve SOCKS5 aracıya aynı görünürlüğü verir. Fark yalnızca SOCKS5 istemcisinin alan adı yerine IP ilettiği yerde ortaya çıkar ve o zaman proxy daha da azını bilir. Ama bu durumda hedef sunucu da "yanlış" bölgeden gelen bir istek alır, ATYP bölümüne bakın. İnce ayrıntılarla berabere.

Hataların teşhisi

HTTP proxy insan tarafından okunabilir kodlarla yanıt verir: 407 yetkilendirmeyi, 403 yasağı, 502 hedefe ulaşılamadığını, 504 zaman aşımını gösterir. Bazı uygulamalar gövdeye açıklama ekler. SOCKS5 tek bir REP baytıyla yanıtlar ve her kütüphane bunu anlaşılır bir mesaja çevirmez. Yabancı bir ortamda hata ayıklarken HTTP proxy teşhis edilmesi daha kolaydır. Kazanan: HTTP.

Çoklama

HTTP/2 proxy, tek bir bağlantı üzerinden birçok CONNECT tüneli taşımaya imkân tanır. SOCKS5 her hedef için ayrı bir TCP bağlantısı gerektirir. Yüzlerce paralel bağlantı açan istemciler için bu, ağ yığını ve proxy üzerindeki yükü belirgin biçimde azaltır. Ancak istemcilerde proxy'ye HTTP/2 desteği şimdilik dağınık. Potansiyel kazanan: HTTP, fiili durumda ise berabere.

Trafiğe müdahale edebilme

Şeffaf moddaki HTTP proxy her şeyi değiştirebilir. CONNECT modunda ve SOCKS5'te yalnızca bağlantıyı kesebilir. Trafiğin değişmezliği konusunda garanti isteyen istemci için en iyisi SOCKS5 veya içinde TLS olan CONNECT'tir. Öngörülebilirlikte kazanan: SOCKS5.

Kimlik doğrulama

Her ikisi de kullanıcı adı ve parolayı destekler. HTTP ek olarak kurumsal ortamlar için önemli olan Digest, NTLM, Negotiate şemalarını destekler. SOCKS5 resmen GSSAPI yöntemine sahiptir ama ticari proxy'lerde neredeyse hiç karşılaşılmaz. Proxeon gibi bir servisle çalışmak için bu fark etmez: orada Basic ya da IP beyaz listesi kullanılır.

Göreve göre ne seçmeli: tablo

Sonuçları çalışır bir araca dönüştürelim. Tablo, Proxeon'da olduğu gibi her iki modun aynı IP üzerinde sunulduğu ve tek sorunun hangi portu belirteceğiniz olduğu varsayımından hareket eder.

Dört adımda seçim algoritması

1. İçindeki protokolü belirleyin. HTTP veya HTTPS değilse SOCKS5 alın, düşünmeyin bile.
2. İstemcinin neyi desteklediğini kontrol edin. Belgelerini socks5, proxy, CONNECT anahtar sözcükleriyle açın. SOCKS5 yoksa veya yetkilendirmesizse seçim sizin yerinize yapılmıştır.
3. Alan adının nerede çözümlenmesi gerektiğine karar verin. Bölge önemliyse (CDN, coğrafi içerik, izleme), alan adı ileten SOCKS5 veya HTTP CONNECT alın: her iki durumda çözümlemeyi proxy yapar.
4. Bağlantı profilini değerlendirin. Havuz olmadan çok sayıda kısa bağlantı: el sıkışma RTT'sine bakın, HTTP CONNECT seçin veya IP ile yetkilendirmeyi açın.

Popüler istemci ve kütüphanelerde uyumluluk

Teori, gerçek istemcilerin başladığı yerde biter. Aşağıda 2026 itibarıyla en yaygın araçların davranışı ele alınıyor. Sürümleri kontrol edin: davranış sürümden sürüme değişir.

curl

Her şeyi destekler. -x parametresindeki veya ortam değişkenlerindeki şemalar: http://, https:// (proxy'nin kendisine TLS), socks4://, socks4a://, socks5://, socks5h://. socks5 ile socks5h arasındaki fark ayrı bir yazıda ele alındı; burada şunu unutmayın: proxy tarafında çözümleme için socks5h gerekir.

curl -x socks5h://user:pass@gate.proxeon.net:1080 https://shop.example/
curl -x http://user:pass@gate.proxeon.net:8080 https://shop.example/

http_proxy, https_proxy, all_proxy ortam değişkenleri otomatik okunur; all_proxy SOCKS şemalarını da kabul eder.

wget

Yalnızca HTTP proxy. SOCKS hiçbir biçimde desteklenmez. SOCKS5 üzerinden wget gerekiyorsa bir sistem düzeyinde proxy'leyiciye ihtiyaç vardır.

Python: requests

HTTP proxy kutudan çıkar. SOCKS5 için ek PySocks paketi gerekir (requests[socks] olarak kurulur).

import requests

proxies = {
"http": "socks5h://user:pass@gate.proxeon.net:1080",
"https": "socks5h://user:pass@gate.proxeon.net:1080",
}
r = requests.get("https://shop.example/api/items", proxies=proxies, timeout=15)
print(r.status_code, r.headers.get("cf-ray"))

HTTP proxy üzerinden HTTPS için requests otomatik olarak CONNECT kullanır. HTTP proxy üzerinden HTTP için mutlak form kullanılır.

Python: httpx

HTTP proxy kutudan çıkar, SOCKS5 ise socksio paketiyle (httpx[socks]). httpx'te socks5:// şeması alan adını proxy sunucusuna iletir. Async desteklediği için paralel görevlerde kullanışlıdır.

import httpx, asyncio

async def main():
async with httpx.AsyncClient(proxy="socks5://user:pass@gate.proxeon.net:1080") as c:
r = await c.get("https://shop.example/")
print(r.status_code)

asyncio.run(main())

Python: aiohttp

HTTP proxy yerleşik. SOCKS5 için, çözümleme yerini rdns parametresiyle denetleyen ProxyConnector sınıfıyla aiohttp-socks paketi kullanılır.

Node.js: fetch ve undici

Node.js'in yerleşik fetch'i undici kullanır, burada HTTP proxy için ProxyAgent vardır. SOCKS5 için ekosistemden ayrı bir ajan, örneğin http/https modülleri için socks-proxy-agent kullanılır.

import { ProxyAgent, fetch } from "undici";

const agent = new ProxyAgent({
 uri: "http://gate.proxeon.net:8080",
 token: "Basic " + Buffer.from("user:pass").toString("base64"),
});
const res = await fetch("https://shop.example/", { dispatcher: agent });
console.log(res.status);

Go

Standart net/http, Transport.Proxy ve ortam değişkenleri üzerinden HTTP proxy'yi destekler. Go 1.13'ten itibaren HTTP_PROXY içindeki socks5:// şeması standart kütüphanede de kabul edilir. İnce denetim için golang.org/x/net/proxy paketi kullanılır.

package main

import (
"fmt"
"net/http"
"net/url"
)

func main() {
u, _ := url.Parse("socks5://user:pass@gate.proxeon.net:1080")
tr := &http.Transport{Proxy: http.ProxyURL(u)}
client := &http.Client{Transport: tr}
resp, err := client.Get("https://shop.example/")
if err != nil {
panic(err)
}
fmt.Println(resp.Status)
}

Go'da socks5 şeması alan adını proxy'ye iletir: yerel çözümleme yapılmaz.

Java

HTTP proxy, http.proxyHost, https.proxyHost sistem özellikleri veya Type.HTTP türüyle Proxy nesnesi üzerinden kullanılır. SOCKS, socksProxyHost ve Proxy.Type.SOCKS üzerinden. Yetkilendirme Authenticator sınıfıyla yapılır. JDK 8u111'den itibaren CONNECT tünelleri için Basic şeması varsayılan olarak jdk.http.auth.tunneling.disabledSchemes özelliğiyle devre dışı bırakılmıştır; bu özellik temizlenmezse açıklamasız 407 alırsınız. Bu, desteğe başvuruların en sık nedenlerinden biridir.

.NET

SocketsHttpHandler'lı HttpClient, WebProxy üzerinden HTTP proxy'yi destekler. SOCKS4, SOCKS4a ve SOCKS5 desteği .NET 6'da geldi ve socks5://host:port biçimindeki WebProxy adresiyle etkinleştirilir.

Tarayıcılar

Chromium tabanlı tarayıcılar sistem proxy ayarlarını ya da --proxy-server bayrağını kullanır. Yetkilendirmeli HTTP proxy çalışır: tarayıcı bir giriş iletişim kutusu gösterir. Sistem ayarları üzerinden SOCKS5 yetkilendirmesiz çalışır, kullanıcı adı ve parola aktarılamaz. Parolalı SOCKS5 için proxy API'sini kullanan bir eklenti ya da IP ile yetkilendirme gerekir. Firefox kendi proxy ayarlarına sahiptir, SOCKS5'i ve ATYP=0x03'ü etkinleştiren "Proxy DNS when using SOCKS v5" seçeneğini destekler. Firefox'ta SOCKS5 için yetkilendirme de standart olarak öngörülmez.

Posta istemcileri

Thunderbird, Firefox'a benzeyen proxy ayarlarını kullanır ve IMAP ile SMTP için SOCKS5'i destekler. Diğer birçok masaüstü posta istemcisinin hesap ayarlarında kendi SOCKS5 proxy bölümü vardır. Posta, HTTP proxy üzerinden yalnızca istemci 993 ve 465 portlarına CONNECT göndermeyi biliyorsa çalışır; bu ise ender görülür.

Sistem proxy'leyicileri

Kendi proxy ayarları olmayan uygulamalar için, sistem düzeyinde ağ çağrılarını yakalayıp SOCKS5 ya da HTTP proxy'ye yönlendiren programlar vardır. Neredeyse hepsi taşıma olarak SOCKS5'i tercih eder, çünkü içindeki protokolden bağımsızdır. Göreviniz böyle bir araç içeriyorsa SOCKS5 portunu hazır tutun.

Uyumluluk kontrol listesi

• İstemci SOCKS5'i biliyor mu? SOCKS5'te kullanıcı adı ve parolayı iletebiliyor mu?
• İstemci alan adını kendi mi çözümlüyor yoksa proxy'ye mi bırakıyor? Uzak DNS ayarı var mı?
• İstemci 407'yi doğru işliyor ve isteği yetkilendirmeyle tekrarlıyor mu?
• İstemci HTTPS için CONNECT mi kullanıyor yoksa https şemalı mutlak URI mi göndermeye çalışıyor (bazı eski kütüphaneler böyle yapar ve çalışmaz)?
• İstemci proxy'ye bağlantıları yeniden kullanıyor mu yoksa her istekte yenisini mi açıyor?

Mühendislik pratiğinden vakalar

Aşağıdaki sayılar anlatılan senaryolar için tipiktir ve etkinin mertebesini anlamak için verilmiştir, garanti edilmiş bir sonuç olarak değil.

Vaka 1: farklı bölgelerden vitrin izleme

Bir ekip, kendi bölgesel vitrinlerinin erişilebilirliğini ve fiyatlarını birkaç ülkedeki proxy üzerinden izliyordu. Python ve requests kullanıyorlardı, socks5:// şemasıyla. Zaman zaman metrikler bölge için "yanlış" fiyat gösteriyordu, oysa vitrin doğru çalışıyordu. Neden: kütüphane alan adını yerel olarak, ofisin bulunduğu ülkede çözümlüyor ve proxy'ye CDN edge sunucusunun hazır IP'sini iletiyordu. Başka bir ülkedeki proxy bu adrese dürüstçe bağlanıyor, CDN ise içeriği istemcinin IP'sine göre değil kendi düğümüne göre belirlediği bölgeye göre sunuyordu. Şemanın socks5h olarak değiştirilmesi çözümlemeyi proxy'ye taşıdı. Anormal ölçümlerin oranı neredeyse sıfıra düştü ve proxy'nin kendine en yakın CDN düğümüne gitmeye başlaması sayesinde medyan yanıt süresi yaklaşık üçte bir azaldı.

Vaka 2: kısa bağlantılı veri toplayıcı filosu

Açık fiyatları toplayan bir servis, günde birkaç yüz bine kadar isteği kullanıcı adı ve parolalı SOCKS5 üzerinden, her istekte yeni bağlantı açarak yapıyordu. Profil çıkarma, proxy'ye yaklaşık 40 ms gecikmeyle, bağlantı başına üç RTT el sıkışmanın istek başına 120 ms ek yük, yani toplam sürenin yaklaşık dörtte biri anlamına geldiğini gösterdi. İki değişiklik: HTTP istemcisinde bağlantı havuzu açıldı ve bir RTT'yi kaldıran IP ile yetkilendirmeye geçildi. Listenin tamamının işlenme süresi proxy sayısı değişmeden yaklaşık yüzde 30 azaldı. Protokol SOCKS5 olarak bırakıldı, çünkü HTTP CONNECT'e geçiş havuzdan daha az kazanç sağlardı.

Vaka 3: posta kutuları ve IMAP

Bir destek ekibi, her kutunun posta sunucusuna belirli bir bölgenin IP'si üzerinden bağlanması gereken birkaç bölge temsilciliği için masaüstü posta istemcisi kuruyordu. HTTP proxy üzerinden ilk deneme başarısız oldu: istemci IMAP için CONNECT göndermeyi bilmiyordu. Proxeon'daki SOCKS5 portuna geçiş sorunu dakikalar içinde çözdü, çünkü istemcinin her hesap için doğal bir SOCKS5 ayarı vardı. Ek yazılım gerekmedi.

Vaka 4: Java uygulaması ve gizemli 407

Bir kurumsal entegratör, Java servisini Basic yetkilendirmeli bir HTTP proxy üzerinden dış API'ye bağlıyordu. Kimlik bilgileri doğru olmasına ve aynı parametrelerle curl çalışmasına rağmen proxy sürekli 407 döndürüyordu. Neden: JDK'nın belirli bir güncellemesinden itibaren CONNECT tünelleri için Basic kimlik doğrulaması varsayılan olarak devre dışıydı. jdk.http.auth.tunneling.disabledSchemes'i temizleyen tek bir JVM bayrağı sorunu çözdü. Burada tam da HTTP proxy'nin okunabilir kodlarla yanıt vermesi işe yaradı: 407 kodu hemen arama yönünü gösterdi, oysa SOCKS5 benzer bir durumda 05 FF döndürürdü ve protokolü bilmeden bunu anlamak daha zor olurdu.

Sık karşılaşılan yanılgılar

• "SOCKS5, HTTP proxy'den daha güvenli." Şifrelenmiş trafik için her iki protokol de aracıya aynı görünürlüğü verir: host, port, zamanlamalar, hacimler, SNI. İçeriğin güvenliğini proxy protokolü değil TLS sağlar. Fark yalnızca şifrelenmemiş HTTP'de vardır, orada şeffaf HTTP proxy her şeyi görür.
• "HTTP proxy HTTPS ile çalışmaz." CONNECT üzerinden çalışır. Bu standart ve yaygın bir mekanizmadır; tüm tarayıcılar kurumsal proxy'ler üzerinden HTTPS sitelerine tam olarak böyle gider.
• "SOCKS5 ikili olduğu için daha hızlı." Bağlantı kurulumunda yetkilendirmeli SOCKS5, HTTP CONNECT'ten daha fazla RTT harcar. Veri aktarımında ikisi de hiçbir şey eklemez: el sıkışmadan sonra her ikisi de saf bir TCP borusudur. Hızı protokol değil, proxy'nin kanalı belirler.
• "CONNECT yalnızca 443 portu için gerekli." Standart portu sınırlamaz. Sınırlamaları belirli bir proxy'nin yapılandırması getirir.
• "SOCKS5 her zaman alan adını proxy'de çözümler." Yalnızca istemci ATYP=0x03 iletiyorsa. Birçok kütüphane varsayılan olarak yerel çözümler ve IP iletir.
• "HTTP proxy her zaman X-Forwarded-For ekler ve IP'mi açığa çıkarır." Bu, belirli kurumsal ayarların davranışıdır, protokolün özelliği değil. Ticari proxy'ler böyle başlıklar eklemez ve CONNECT modunda eklemek fiziksel olarak imkânsızdır.
• "Proxy, proxy parolamı açık metin görüyorsa site parolamı da görür." Proxy parolası proxy'ye iletilir ve standart gereği ileriye aktarılmaz. TLS tüneli içindeki site parolasını proxy görmez.
• "SOCKS5 içeriği ayrıştırmadığına göre kısıtlanamaz." Proxy hedef host, port, hacim, hız ve bağlantı sayısına göre kısıtlama yapabilir. Sadece URL'ye göre yapamaz.
• "Bir sağlayıcıda HTTP ve SOCKS5 portları ayrı sunuculardır." Genellikle tek sunucu ve tek çıkış IP'sidir, girişteki protokol farklıdır. Proxeon'da durum tam olarak böyledir.
• "Tarayıcıda parolalı SOCKS5, HTTP gibi ayarlanır." Hayır, Chromium ve Firefox'un sistem ayarları SOCKS5'e kimlik bilgilerini iletmez. IP ile yetkilendirme ya da eklenti gerekir.

SSS

Hedef site HTTP proxy mi yoksa SOCKS5 mi üzerinden geldiğimi anlayabilir mi?

Hayır. Hedef sunucu yalnızca ikinci bağlantıyı, proxy'den kendisine olanı görür ve o da her iki durumda proxy'nin IP adresinden gelen sıradan bir TCP'dir. Tek istisna: Via ya da X-Forwarded-For başlıklarını ekleyen şeffaf HTTP proxy. CONNECT modunda ve SOCKS5'te bu imkânsızdır.

HTTPS için HTTP proxy kullanırsam proxy içeriği gözetleyebilir veya değiştirebilir mi?

Yalnızca sertifika değiştirerek TLS araya girmesi yaparsa ve o zaman sertifika doğrulamasını manuel olarak devre dışı bırakmadıysanız ya da bu proxy'nin güvenilir kök sertifikasını elle kurmadıysanız istemciniz sertifika hatası verir. Normal çalışmada CONNECT'ten sonra proxy şifreli akışı görür ve içeriğini ne okuyabilir ne değiştirebilir.

Chrome'da parolalı SOCKS5 çalışmıyor ama parolalı HTTP proxy çalışıyor, neden?

Chromium'un ağ yığını 407 mekanizması üzerinden HTTP proxy için yetkilendirme diyaloğunu destekler ama SOCKS5 için RFC 1929'daki 0x02 yöntemini uygulamaz. Bu, protokolün değil tarayıcı geliştiricilerinin kararıdır. Çözüm: Proxeon panelinde IP adresiyle yetkilendirme ya da proxy'yi API üzerinden yöneten bir eklenti.

SOCKS5'te REP=05 dönerse ne yapmalı?

05 kodu hedef sunucunun TCP bağlantısını reddettiği anlamına gelir: port kapalı, servis çalışmıyor ya da hedefin güvenlik duvarı proxy'nin IP'sini engelliyor. Doğru portu ilettiğinizden emin olun ve başka bir proxy adresi deneyin. Bu durumda proxy doğru çalışıyor, sorun yolun ikinci yarısında.

SOCKS5'te REP=02 ile HTTP proxy'de 403 arasındaki fark nedir?

Anlamsal olarak ikisi de aynıdır: proxy kendi kurallarına göre bağlantı kurmayı reddetti. Bu genelde hedef portun veya hostun proxy politikası tarafından yasaklandığı anlamına gelir. HTTP proxy'de 403 yanıtının gövdesinde bazen açıklama vardır, SOCKS5'te yalnızca bir bayt.

Aynı kullanıcı adı ve parolayı hem HTTP hem SOCKS5 portu için kullanabilir miyim?

Proxeon'da evet: hesap ortaktır, yalnızca port ve protokol farklıdır. Protokolü değiştirdiğinizde kimlik bilgilerini değiştirmeniz gerekmez.

İstemcimin alan adını yerel mi yoksa proxy'de mi çözümlediğini nasıl anlarım?

En güvenilir yol: arayüzünüzde trafik yakalama çalıştırın ve proxy'ye bağlanmadan önce hedef alan adına bir DNS sorgusunun gidip gitmediğine bakın. Daha basit yol: hosts dosyanızda hedef alan adı için geçici olarak bilerek yanlış bir adres tanımlayın. Proxy üzerinden istek çalışmaya devam ediyorsa çözümlemeyi proxy yapıyordur. Bozuluyorsa istemci yapıyordur.

Kütüphane destekliyorsa proxy'ye HTTP/2 kullanmalı mıyım?

Farklı hedeflere çok sayıda paralel bağlantınız varsa ve istemci CONNECT akışlarını gerçekten çokluyorsa kazanç belirgin olur: daha az TCP bağlantısı, daha az el sıkışma. Ama bu olanağın istemciler ve proxy sunucularındaki desteği şimdilik dengesiz. İstemcinizin belgelerini kontrol edin ve tarifenizin girişte HTTP/2'yi destekleyip desteklemediğini sorun.

Host başlığı varken HTTP proxy'de neden mutlak URI var?

HTTP/1.1 standardı, istemcinin proxy'ye başvururken mutlak formu kullanmasını ister ki proxy isteğin yerel olarak mı işleneceğini yoksa iletilmesi mi gerektiğini açıkça anlasın. Host başlığı korunur çünkü proxy isteği hedef sunucuya zaten origin-form'da iletecek ve orada Host zorunludur. Bu tekrar, uyumluluğun bedelidir.

Kazıma için daha önemli olan: HTTP mi SOCKS5 mi?

HTTPS hedeflerinde görünürlük farkı yok, fark kütüphanenin davranışında. Kütüphane SOCKS5 ile düzgün çalışıyorsa ve alan adını iletiyorsa SOCKS5 alın: başlıklara müdahale etme riski yoktur ve doğru bölgesel çözümleme sağlar. Kütüphane SOCKS5'te kaprisliyse ya da havuz olmadan çok sayıda kısa bağlantınız varsa HTTP CONNECT hiç de fena değildir. En önemli tavsiye: her istek için proxy'ye yeni bağlantı açmayın, bu her protokol seçiminden daha pahalıdır.

Sonuç

Müşteri panelindeki iki port, "basit ve gelişmiş" pazarlama ikilisi değil. Bunlar aynı makineyle konuşmanın iki farklı dili. HTTP proxy istek ve yanıt dilini konuşur, anlamı anlar, önbelleğe alabilir ve hataları okunabilir kodlarla açıklar; anlamadığı her şey için onu TCP tüneline çeviren CONNECT'i vardır. SOCKS5 "host ve port" dilini konuşur, içeriği ayrıştırmaz, herhangi bir TCP protokolünü ve UDP'yi destekler ve alan adının nerede çözümlendiğini açıkça denetlemenize izin verir.

Şifrelenmiş trafik için iki protokol de aracıya aynı görünürlüğü verir. Aralarındaki seçimi güvenlik değil, üç pratik şey belirler: istemcinizin neyi desteklediği, içindeki protokol ve adları nerede çözümlemek istediğiniz.

Şimdi ne yapmalısınız

1. Görevinizin içindeki protokolü belirleyin. HTTP değilse hemen SOCKS5.
2. İstemcinizin belgelerinde yetkilendirmeli SOCKS5 desteğini ve uzak çözümleme seçeneğini kontrol edin.
3. Coğrafi kaynaklarla çalışıyorsanız alan adının proxy'ye gittiğinden emin olun: socks5h, remote DNS, ATYP=0x03 veya HTTP CONNECT.
4. Proxy'ye bağlantı havuzunu ya da keep-alive'i açın. Bu, herhangi bir protokol değişiminden daha fazla kazandırır.
5. İstemci SOCKS5'te kullanıcı adını iletemiyorsa Proxeon panelinde IP ile yetkilendirmeyi ayarlayın.
6. Hata ayıklarken curl -v ile başlayın: proxy'yle tüm diyaloğu gösterir ve istemci sorununu ağ sorunundan hemen ayırır.

Ve son olarak. Her iki protokol de onları kullanan mühendislerin çoğundan yaşlı ve ikisi de temel değişiklikler olmadan hâlâ çalışıyor. Bu, tasarım sadeliğinin kazandığı ender bir durumdur. Bağlantının ilk kırk baytında tam olarak ne olup bittiğini anladığınızda, portu rastgele seçmeyi bırakır ve aracı seçmeye başlarsınız.