SOCKS5 proxy nedir? RFC 1928’e göre el sıkışma ve komutlar

SOCKS5 proxy, istemcinin “şu adrese, şu porttan bağlan” isteğini ileten ve sonra iki uç arasında baytları olduğu gibi aktaran bir aracıdır. HTTP proxy’den farkı, taşıdığı trafiğin HTTP olmak zorunda olmamasıdır: TCP üzerinde çalışan hemen her protokol SOCKS5 üzerinden geçebilir. Protokol RFC 1928 (yeni sekmede açılır) ile, kullanıcı adı ve parola doğrulaması ise RFC 1929 (yeni sekmede açılır) ile tanımlanır.

SOCKS5 ağ katmanlarında nerede durur?

SOCKS, uygulama katmanı ile taşıma katmanı arasında konumlanır. İstemci önce proxy sunucusuna sıradan bir TCP bağlantısı açar (geleneksel port 1080), kısa bir müzakere yapar ve ardından aynı bağlantı hedefe uzanan bir boru gibi çalışır. Proxy, bağlantının hedef adresini ve portunu bilir; içeriği ise yorumlamaz. Hedef bir HTTPS sitesiyse TLS oturumu istemci ile hedef sunucu arasında kurulur ve proxy şifreli baytlardan başka bir şey görmez.

El sıkışma, bayt bayt

Bir SOCKS5 oturumu üç adımdan oluşur: yöntem seçimi, (gerekirse) kimlik doğrulama ve bağlantı isteği. Aşağıdaki örnekte istemci, kullanıcı adı ve parolayla api.ipify.org adresine 443 numaralı porttan bağlanmak istiyor. Değerler onaltılık (hex) yazılmıştır.

# 1) İstemci → proxy: yöntem önerisi
05 02 00 02
│  │  │  └─ 02 = kullanıcı adı/parola (RFC 1929)
│  │  └──── 00 = kimlik doğrulama yok
│  └─────── NMETHODS = 2 yöntem öneriliyor
└────────── VER = 5

# 2) Proxy → istemci: seçilen yöntem
05 02            # 02 seçildi; FF olsaydı "kabul edilebilir yöntem yok"

# 3) İstemci → proxy: RFC 1929 alt müzakeresi
01 09 4b 55 4c 4c 41 4e 49 43 49 06 50 41 52 4f 4c 41
│  │  └─ "KULLANICI" (9 bayt)    │  └─ "PAROLA" (6 bayt)
│  └──── ULEN = 9                └──── PLEN = 6
└─────── alt müzakere sürümü = 1

# 4) Proxy → istemci: doğrulama sonucu
01 00            # 00 = başarılı; başka her değer = başarısız, bağlantı kapanır

# 5) İstemci → proxy: CONNECT isteği, alan adıyla
05 01 00 03 0d 61 70 69 2e 69 70 69 66 79 2e 6f 72 67 01 bb
│  │  │  │  │  └─ "api.ipify.org" (13 bayt)           └─ port 443
│  │  │  │  └──── alan adı uzunluğu = 0x0d
│  │  │  └─────── ATYP = 03 (alan adı)
│  │  └────────── RSV = 00
│  └───────────── CMD = 01 (CONNECT)
└──────────────── VER = 5

# 6) Proxy → istemci: yanıt
05 00 00 01 <BND.ADDR 4 bayt> <BND.PORT 2 bayt>
#  REP = 00 → başarılı; bundan sonra bağlantı hedefe açık bir borudur

Yanıttaki REP alanı hatayı da taşır: 01 genel sunucu hatası, 02 kural kümesi bağlantıya izin vermiyor, 03 ağa ulaşılamıyor, 04 sunucuya ulaşılamıyor, 05 bağlantı reddedildi, 06 TTL süresi doldu, 07 komut desteklenmiyor, 08 adres türü desteklenmiyor. Port numaraları ağ bayt sırasıyla (büyük uçlu) yazılır; 443 bu yüzden 01 bb olur.

Kimlik doğrulama yöntemleri

Kullanıcı adı yerine istemcinin IP adresini yetkilendiren kurulumlar da vardır; bu durumda istemci 00 yöntemini önerir ve proxy, bağlantının geldiği adrese bakarak karar verir. İki yaklaşımın farkları için kimlik doğrulama rehberine bakabilirsiniz.

Üç komut: CONNECT, BIND, UDP ASSOCIATE

• CONNECT (01) — Hedefe giden bir TCP bağlantısı kurar. Web, e-posta, SSH ve benzeri trafiğin neredeyse tamamı bu komutla taşınır.
• BIND (02) — Proxy’nin, hedefin geri bağlanacağı bir port açmasını ister. Aktif kip FTP gibi sunucunun istemciye ikinci bir bağlantı açtığı eski protokoller için tasarlanmıştır; proxy iki ayrı yanıt gönderir: biri port açıldığında, diğeri bağlantı geldiğinde.
• UDP ASSOCIATE (03) — UDP datagramlarının proxy üzerinden aktarılması için bir ilişki kurar.

UDP ASSOCIATE’te istemci önce TCP üzerinden isteği gönderir; proxy yanıtta datagramların gönderileceği adresi ve portu (BND.ADDR, BND.PORT) bildirir. İstemci her datagramın başına küçük bir başlık ekler: iki ayrılmış bayt (00 00), bir parçalama baytı (FRAG), adres türü, hedef adres ve hedef port. Proxy başlığı çıkarıp veriyi hedefe gönderir, dönen yanıtları aynı başlıkla geri sarar. İlişki, isteğin geldiği TCP bağlantısı kapanınca sona erer. Bir proxy’nin bu komutu desteklemesi zorunlu değildir; desteklemeyen sunucu 07 yanıtı verir.

Adres türleri ve DNS: socks5 ile socks5h

İstekteki ATYP alanı hedefin nasıl yazıldığını belirler: 01 IPv4 (4 bayt), 03 alan adı (1 bayt uzunluk + ad), 04 IPv6 (16 bayt). Bu seçim, alan adının kim tarafından çözüleceğini de belirler. İstemci adı kendisi çözüp proxy’ye IP gönderirse DNS sorgusu sizin ağınızdan, sizin çözümleyicinize gider. Adı olduğu gibi gönderirse çözümlemeyi proxy yapar.

cURL ve Python requests gibi araçlar bu farkı URL şemasıyla ifade eder: socks5:// adı yerelde çözer, socks5h:// ise çözümlemeyi proxy’ye bırakır (cURL’de --socks5 ve --socks5-hostname seçenekleri; ayrıntı için cURL kılavuzu (yeni sekmede açılır) ve requests belgeleri (yeni sekmede açılır)). Yerel çözümlemenin neden bir sızıntı sayıldığı DNS sızıntısı yazısında anlatılıyor.

curl --proxy "socks5h://KULLANICI:PAROLA@PROXY_ADRESI:PORT" \
  "https://api.ipify.org?format=json"
# Beklenen çıktı: {"ip":"<proxy çıkış adresi>"}

Parolada @, : veya / gibi karakterler varsa URL içinde yüzde kodlamasıyla (%40, %3A, %2F) yazılmalıdır. Aynı testi tarayıcıdan yapmak isterseniz SOCKS5 kontrol aracı el sıkışmanın hangi adımda başarısız olduğunu gösterir.

Bağlantı kurulamıyorsa: belirtiden nedene

SOCKS5 hataları çoğu zaman el sıkışmanın hangi adımında kalındığına bakılarak çözülür. cURL’ü -v seçeneğiyle çalıştırmak, bu adımları ve proxy’nin döndürdüğü kodu gösterir.

SOCKS4 ve SOCKS4a farklı protokollerdir

SOCKS4, SOCKS5’in eski bir sürümü değil, ayrı ve daha dar bir protokoldür. Yalnızca IPv4 hedeflerini ve TCP’yi taşır; UDP ve IPv6 desteği yoktur; parola doğrulaması bulunmaz, istekte yalnızca bir kullanıcı kimliği alanı vardır. SOCKS4a uzantısı hedefin alan adıyla gönderilmesine izin vererek DNS sorununu kısmen çözer. Bir istemcide “SOCKS” seçeneği gördüğünüzde hangi sürümü kastettiğini kontrol edin: SOCKS4 istemcisi bir SOCKS5 sunucusunun beklediği müzakereyi yapmaz ve bağlantı kurulamaz.

SOCKS5 ne zaman doğru seçimdir?

• HTTP olmayan TCP trafiği: SSH, veritabanı istemcileri, e-posta protokolleri veya proxy destekleyen masaüstü uygulamaları.
• UDP gerektiren uygulamalar: yalnızca hem istemci hem proxy UDP ASSOCIATE’i destekliyorsa.
• Alan adının proxy tarafında çözülmesi istendiğinde: socks5h ile yerel DNS sorgusu oluşmaz.
• Başlıklara dokunulmaması gerektiğinde: SOCKS5 uygulama verisini değiştirmez; HTTP proxy’lerde görülen Via gibi başlıklar eklenmez.

Yalnızca web istekleri gönderiyorsanız HTTP proxy de çoğu zaman yeterlidir; iki protokolün tablo halinde karşılaştırması HTTP ve SOCKS5 karşılaştırmasında yer alıyor.

Özet

SOCKS5; yöntem seçimi, isteğe bağlı RFC 1929 doğrulaması ve tek bir bağlantı isteğinden oluşan sade bir protokoldür. CONNECT ile TCP taşır, UDP ASSOCIATE ile UDP taşıyabilir, alan adını proxy’ye çözdürebilir ve içeriği şifrelemez. Bu sitede SOCKS5, ayrı bir ürün olarak değil, Türkiye ISP paketlerinde ve haftalık/aylık Türkiye mobil paketlerinde sipariş sırasında seçilen bir protokol olarak yer alır; ayrıntılar HTTP & SOCKS5 Proxy sayfasında.