HTTP proxy ve SOCKS5: protokol düzeyinde farklar ve göreve göre seçim
Makale içeriği
- Giriş: neden aynı proxy iki modda sunuluyor
- Temeller: iki aracılık katmanı
- Http proxy: mutlak uri'li istek
- Connect metodu: http proxy'nin tcp tüneli olarak kullanımı
- Socks5: el sıkışma, kimlik doğrulama ve atyp
- Kriterlere göre karşılaştırma: pratikte önemli olanlar
- Göreve göre ne seçilmeli: pratik bir çerçeve
- Popüler istemcilerde ve kütüphanelerde uyumluluk
- Tipik yanılgılar
- Çalışma için araçlar ve kaynaklar
- Vaka örnekleri ve uygulama sonuçları
- Sss: sık sorulan sorular
- Sonuç: doğru kararı nasıl verirsiniz
Aynı proxy sunucusu sıklıkla müşteriye iki modda sunulur: HTTP proxy ve SOCKS5 olarak. Çoğu kişi bunu bir pazarlama hilesi sanır. Değil. Bu iki harfin arkasında, ağ yığınının farklı katmanlarında çalışan, temelde birbirinden farklı iki aracılık protokolü yatar. Aralarındaki farkı anlamak, saatlerce hata ayıklamadan kurtarır, gecikmeyi azaltır ve belirli bir mühendislik görevi için doğru aracı seçmenize yardımcı olur.
Bu kılavuzda, her iki protokolün mekaniğini el sıkışmanın ilk baytından son başlığa kadar inceleyeceğiz. Her modda aracının tam olarak ne gördüğüne, SOCKS5'in trafik içeriğini neden bilinçli olarak ayrıştırmadığına ve CONNECT metodunun sıradan bir HTTP proxy'sini nasıl şeffaf bir TCP tüneline dönüştürdüğüne bakacağız. Sonunda görev-protokol eşleme tablosu ve ayrıntılı bir SSS sizi bekliyor. Üslup mühendisçe: minimum süslü laf, maksimum kod ve net ifade.
Giriş: neden aynı proxy iki modda sunuluyor
Bir postane düşünün. İlk modda, görevli zarfın üzerindeki adresi okur, mektubu başka bir zarfa koyabilir, damga basabilir ve bazen böyle bir mektubun dün de geldiğini söyleyip arşivden bir kopyasını verebilir. Bu HTTP proxy'dir: isteğin yazıldığı dili anlar ve içeriğiyle anlamlı veri olarak çalışır.
İkinci modda, aynı görevli mühürlü bir konteyner ve bir talimat alır: şu adrese ve şu porta teslim et, içinde ne olduğu onu ilgilendirmez. Göndericiden alıcıya bir boru döşer ve baytları iki yönde pompalar. Bu SOCKS5'tir: tünelin içeriğine kayıtsız kalan bir oturum katmanı protokolü.
Neden bir sağlayıcı, örneğin Proxeon, her iki modu aynı altyapı üzerinden sunar? Çünkü müşterilerin görevleri farklıdır. Birine HTTP düzeyinde önbellek ve filtreleme gerekir, diğerine rastgele bir TCP protokolünün şeffaf iletimi. Tek bir sunucu farklı portları dinleyip her iki senaryoya hizmet edebilir. Bu bir mühendislik çözümüdür, kelime oyunu değil.
Baştan akılda tutulması gereken kilit nokta: HTTP proxy uygulama katmanında (L7), SOCKS5 ise oturum katmanına daha yakın (koşullu olarak L5) çalışır. Diğer tüm farklar buradan doğar: proxy'nin ne gördüğü, neyi değiştirebildiği, hangi protokolleri desteklediği ve ne kadar ek yük getirdiği.
Temeller: iki aracılık katmanı
Derinleşmeden önce temel kavramları netleştirelim. Proxy, istemci ile hedef sunucu arasındaki aracıdır. İstemci isteği doğrudan değil, proxy'ye gönderir; proxy de onu ileri iletir. Proxy türleri arasındaki fark, hangi katmanda iletilen şeyi anladıklarıdır.
Uygulama katmanı ile oturum katmanı karşıtlığı
HTTP proxy, HTTP mesajını bütün olarak ayrıştırır. Metodu (GET, POST), yolu, tüm başlıkları ve şifrelenmemiş durumda gövdeyi de görür. Bu onu hem akıllı hem de sınırlı yapar: yalnızca anladığı protokolle çalışabilir.
SOCKS5 ise uygulama protokolünü hiç ayrıştırmaz. İstemciden X ana bilgisayarıyla Y portunda TCP bağlantısı kur şeklinde bir komut alır ve ardından baytları öylece iletir. İşte bu tarafsızlık, SOCKS5'i herhangi bir TCP protokolü için evrensel bir taşıyıcı yapar: HTTP, HTTPS, SMTP, IMAP ve kendi yazılımınızın birçok tescilli protokolü.
"Proxy içeriği görür" ne anlama gelir
HTTP proxy'nin içeriği gördüğünü söylediğimizde, söz konusu olan şifrelenmemiş HTTP'dir. Trafik CONNECT metodu üzerinden HTTPS olarak akıyorsa (aşağıda ayrıntılı olarak ele alacağız), HTTP proxy bile yalnızca şifrelenmiş akışı ve ana bilgisayar adını görür. Bu önemli bir ayrıntı: modern web neredeyse tamamen TLS üzerindedir, bu nedenle pratikte HTTP proxy'nin görüş derinliği tünel kurulum aşamasıyla sınırlıdır.
Portlar ve adresleme şemaları
İstemci tarafında fark, proxy'yi nasıl tanımladığınızda ortaya çıkar. HTTP proxy için şema http://user:pass@host:port şeklindedir. SOCKS5 için ise socks5://user:pass@host:port. Modların portları genellikle farklıdır, çünkü farklı işleyiciler bunları dinler. Aynı fiziksel Proxeon sunucusu, HTTP proxy'yi bir portta, SOCKS5'i başka bir portta sunabilir.
HTTP proxy: mutlak URI'li istek
Klasik HTTP proxy ve en belirgin özelliği olan istek satırındaki mutlak URI ile başlayalım. Bir proxy'ye yapılan isteği sunucuya yapılan doğrudan istekten görsel olarak ayıran şey budur.
Mutlak istek biçimi
Bir tarayıcı bir siteye doğrudan eriştiğinde göreli bir yol gönderir. İstek satırı şöyle görünür:
GET /index.html HTTP/1.1
Host: example.comAma aynı tarayıcı bir HTTP proxy'sine ayarlandığında, proxy sunucusuna URI'nin mutlak biçimini gönderir. Proxy, isteği tam olarak nereye ileteceğini bilmelidir, bu nedenle tüm adres ilk satıra yerleşir:
GET http://example.com/index.html HTTP/1.1
Host: example.com
Proxy-Connection: keep-aliveBu temel bir farktır. Proxy, http://example.com/index.html adresini okur, ana bilgisayarı çıkarır, hedef sunucuyla bağlantı kurar ve isteği normal, göreli biçimde iletir. RFC 7230 standardı, istemcilere proxy'ye başvururken absolute-form, doğrudan başvururken origin-form kullanmalarını açıkça emreder.
Proxy'nin gördüğü ve değiştirebildiği şeyler
Şifrelenmemiş HTTP modunda proxy çok şey görür. Sıralayalım:
- Tam URL, yol ve sorgu parametreleri dahil.
- Tüm istek başlıkları: User-Agent, Accept, Cookie, Referer.
- POST veya PUT'ta istek gövdesi.
- Sunucu yanıtı bütün olarak: durum, başlıklar, gövde.
Dahası, proxy trafiği meşru ve faydalı biçimde değiştirebilir. Kurumsal veya servis HTTP proxy'sinin tipik işlemleri:
- Servis başlıkları ekleme, örneğin
X-Forwarded-ForveyaVia. - İleri gitmemesi gereken hop-by-hop başlıkları kaldırma (
Connection,Proxy-Authorization). - Tekrarlanan istekler için yanıtları önbelleğe alma.
- Açık yapılandırma durumunda içeriği sıkıştırma veya dönüştürme.
Proxy'ye özgü başlıklar
Yalnızca istemci-proxy diyalogunda anlam taşıyan ve hedef sunucuya sızmaması gereken başlıklar vardır. Başlıcası, proxy'nin kendisine erişim için kimlik bilgilerini taşıyan Proxy-Authorization'dır. Bunu hedef sunucuya yönelik Authorization ile karıştırmayın. Ayrıca bir durum kodu çifti vardır: 407 Proxy Authentication Required, proxy'nin kimlik doğrulama gerektirdiği anlamına gelir; hedef sunucudan gelen 401'den farklıdır.
Pratik örnek: curl ile açık HTTP proxy
Proxeon HTTP proxy'sine curl ile nasıl başvurulacağını görelim. -x bayrağı proxy'yi belirler, -v ise diyaloğu gösterir:
curl -v -x http://user:pass@proxy.proxeon.net:8080 http://example.com/Çıktıda istek satırını mutlak biçimde ve Base64 ile kodlanmış kimlik bilgilerini taşıyan Proxy-Authorization başlığını göreceksiniz. Bu, curl'ün doğrudan hedef sunucuyla değil, tam olarak proxy ile konuştuğunu açıkça gösterir.
Sınırlama: yalnızca HTTP anlambilimi
Klasik HTTP proxy, ilk biçiminde yalnızca HTTP isteklerini iletebilir. Rastgele bir SMTP TCP akışıyla veya uygulamanızın ikili protokolüyle ne yapacağını bilemez. Şifrelenmemiş HTTP için bu mükemmel çalışır. Ancak HTTPS veya başka bir protokol ortaya çıktığında bir tünelleme mekanizmasına ihtiyaç duyulur. İşte burada CONNECT metodu sahneye çıkar.
CONNECT metodu: HTTP proxy'nin TCP tüneli olarak kullanımı
CONNECT metodu, HTTP proxy'nin HTTPS ve genel olarak herhangi bir TCP akışına hizmet etmesini sağlayan şeydir. Uygulama katmanındaki akıllı aracıyı şeffaf bir boruya dönüştürür. Mekaniği adım adım inceleyelim.
CONNECT neden gerekli oldu
HTTPS, tüm mesajı başlıklar ve yol dahil şifreler. Proxy mutlak URI'yi okumaya çalışsaydı, şifrelenmiş baytlara çarpardı. TLS el sıkışması doğrudan istemci ile hedef sunucu arasında gerçekleşmelidir, aksi halde uçtan uca şifreleme kaybolur. Yani proxy'nin okuması değil, iki noktayı birleştirip kenara çekilmesi gerekir.
CONNECT isteği nasıl görünür
İstemci proxy'ye, URL yerine ana bilgisayar-port çiftini authority-form'da belirten özel bir istek gönderir:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dХNlcjpwYXNzProxy, example.com:443 ile bir TCP bağlantısı kurar ve her şey yolunda giderse şöyle yanıt verir:
HTTP/1.1 200 Connection EstablishedBu satırdan sonra çok önemli bir şey olur: proxy artık bir HTTP ayrıştırıcı olmaktan çıkar. Çift yönlü bir bayt aktarıcısına dönüşür. İstemcinin bundan sonra gönderdiği her şey sunucuya kopyalanır ve tersi de geçerlidir. Tarayıcı tam da bu tünelin üzerinden TLS el sıkışmasını hedef sunucuyla doğrudan başlatır.
Aracının tünel kurulduktan sonra gördüğü şeyler
Bu, gizlilik ve güvenlik açısından kilit bir sorudur. 200 Connection Established'dan sonra HTTP proxy şunları görür:
- Ana bilgisayar adı ve port, CONNECT komutunun kendisinden - tünel kurulmadan önce.
- Şifrelenmiş bayt akışı - ve başka hiçbir şey.
- SNI (Server Name Indication), TLS ClientHello içinde, SNI şifrelemesi kullanılmıyorsa - teknik olarak bu da ana bilgisayar adını açığa çıkarır.
- Bağlantı meta verileri: iletilen veri hacmi, süre, zamanlamalar.
Proxy'nin tünelden sonra görmediği şeyler: URL yolu, sorgu parametreleri, başlıklar, çerezler, istek ve yanıt gövdeleri. Tüm bunlar TLS ile korunur. Dolayısıyla HTTPS trafiği için CONNECT modunda bir HTTP proxy, neredeyse SOCKS5 gibi davranır: o sadece taşıyıcıdır. Fark, istemcinin tünelle nasıl anlaştığında kalır.
Pratik: CONNECT iş başında
Bir HTTP proxy üzerinden HTTPS isteği yaptığınızda curl otomatik olarak CONNECT kullanır. Diyaloğu gözlemleyin:
curl -v -x http://user:pass@proxy.proxeon.net:8080 https://example.com/Verbose çıktısında önce CONNECT example.com:443 HTTP/1.1 satırını, ardından 200 Connection Established yanıtını, sonrasında ise TLS el sıkışma satırlarını ve şifrelenmiş tünelin içinden geçen asıl GET isteğini göreceksiniz. Proxy ise yalnızca ilk kısmı görmüştür.
CONNECT 443 portuyla sınırlı değil
CONNECT çoğunlukla 443 portuna yönlendirse de, spesifikasyon onu HTTPS'e bağlamaz. Teknik olarak CONNECT üzerinden, proxy izin verdiği sürece herhangi bir TCP protokolünü herhangi bir porta tünellemek mümkündür. Pratikte yöneticiler güvenlik nedeniyle genellikle izin verilen portların listesini kısıtlar, 443 ve bazen 22 veya başkalarını bırakır. Bu nedenle, örneğin CONNECT üzerinden SMTP tünellemeye çalışmak proxy politikasına takılabilir.
SOCKS5: el sıkışma, kimlik doğrulama ve ATYP
Şimdi RFC 1928'de tanımlanan SOCKS5'e geçelim. Bu, temelden farklı bir felsefeye sahip bir protokoldür. Ne ilettiğinizi bilmez ve bilmek istemez. Görevi bağlantı kurmak ve boru olmaktır.
El sıkışmanın genel mantığı
SOCKS5 diyaloğu HTTP'deki gibi metinsel değil, ikilidir. Birkaç kısa mesaj alışverişinden oluşur. Şematik olarak:
- İstemci desteklediği kimlik doğrulama yöntemlerinin listesini gönderir.
- Sunucu bir yöntem seçer ve seçimi bildirir.
- Gerekirse kimlik doğrulama yapılır.
- İstemci bir bağlantı isteği gönderir: komut, adres tipi, adres, port.
- Sunucu sonuçla yanıt verir.
- Şeffaf veri iletimi başlar.
Karşılama ve yöntem seçimi
İstemcinin ilk mesajı çok derli topludur. Sürüm numarasını (0x05), sunulan yöntem sayısını ve yöntemlerin kendisini içerir. En yaygın kullanılan ikisi: 0x00 - kimlik doğrulama olmadan ve 0x02 - kullanıcı adı/parola ile kimlik doğrulama (RFC 1929). Sunucu iki baytla yanıt verir: sürüm ve seçilen yöntem. Sunucu 0xFF döndürdüyse, önerilen yöntemlerden hiçbiri uygun değildir ve bağlantı kapatılır.
Kullanıcı adı ve parola ile kimlik doğrulama
0x02 yöntemi seçildiyse, istemci alt protokol sürümünü, kullanıcı adının uzunluğunu ve değerini, ardından parolanın uzunluğunu ve değerini içeren ayrı bir mesaj gönderir. Sunucu bir durumla yanıt verir. Önemli bir mühendislik nüansı: klasik SOCKS5'te bu veriler yerleşik şifreleme olmadan iletilir, bu nedenle bu tür proxy'lere yalnızca güvenli kanallar üzerinden veya kontrol edilen bir ortamda güvenilmelidir. Proxeon gibi servis proxy'leri için kimlik doğrulama IP bağlamasıyla desteklenebilir, bu da kimlik bilgilerinin sızma riskini azaltır.
Komutlar: CONNECT, BIND ve UDP ASSOCIATE
SOCKS5 üç komutu destekler. En sık kullanılanı CONNECT (0x01), giden TCP bağlantısı kurma. Eski FTP gibi protokollerde gelen bağlantılar için BIND (0x02) vardır. Bir de UDP veri paketlerini proxy'lemek için UDP ASSOCIATE (0x03) vardır. Burada UDP ASSOCIATE mekaniğini ve socks5 ile socks5h şemaları arasındaki farkları bilinçli olarak ele almıyoruz - bunlar özel materyallere ayrılmış ayrı büyük konulardır. Burada HTTP proxy ile karşılaştırma için en temel olana odaklanacağız: ATYP alanı.
ATYP: alan adı ile IP karşıtlığı ve bu neden çözümleme için kritik
SOCKS5 bağlantı isteğinde, kendisinden sonraki adresin nasıl yorumlanacağını belirleyen ATYP (address type) alanı vardır. Üç değer mümkündür:
0x01- IPv4 adresi, dört bayt.0x03- alan adı, ilk bayt uzunluk, ardından dizenin kendisi.0x04- IPv6 adresi, on altı bayt.
İşte en önemli pratik farklardan biri burada yatar. İstemci bir alan adı gönderdiğinde (ATYP 0x03), DNS çözümlemesini istemci değil, proxy sunucusu yapar. İstemci zaten çözümlenmiş bir IP adresi gönderdiğinde ise çözümleme istemci tarafında gerçekleşmiştir. Bu fark, hangi DNS'in kullanıldığını, hedef sunucunun sonuçta hangi IP'yi alacağını ve coğrafyaya bağlı yönlendirmenin ne kadar doğru çalışacağını etkiler.
Bir mühendis için bu şu anlama gelir: adın proxy ağında çözümlenmesi sizin için önemliyse, IP değil alan adı iletmeniz gerekir. Birçok kütüphane varsayılan olarak önce adı yerel olarak çözümler ve ancak sonra proxy'ye gider - bu davranışı değiştirir. Yerel ve uzak çözümleme arasındaki farkların ve socks5 ile socks5h şemalarının ayrıntılı analizi ayrı bir makaleye bırakılmıştır, bu nedenle burada yalnızca ATYP alanının varlığını kilit bir kontrol kolu olarak tespit ediyoruz.
Pratik: curl ile SOCKS5
curl'de SOCKS5 proxy'sine başvuru, HTTP varyantına simetriktir; yalnızca şema değişir:
curl -v --socks5 user:pass@proxy.proxeon.net:1080 https://example.com/Burada curl metin biçiminde herhangi bir CONNECT satırı göndermez - bunun yerine ikili bir SOCKS5 el sıkışması yapar ve ardından TLS trafiğini kurulan tünel üzerinden akıtır. Uygulama için fark neredeyse görünmezdir, ancak protokol düzeyinde tamamen farklı bir konuşma gerçekleşir.
SOCKS5 içeriği neden ayrıştırmaz - ve bu onun gücüdür
SOCKS5'in felsefesi minimalizmdir. İçindeki şeyin HTTP mi, SMTP mi yoksa kendi protokolünüz mü olduğunu anlamaya çalışmaz. Bu onu şöyle yapar:
- Evrensel: herhangi bir TCP protokolü özel destek olmadan geçer.
- Hafif: el sıkışma kısadır, uygulama katmanı ayrıştırması yoktur.
- Şeffaf: proxy verilere karışmaz, hiçbir şeyi değiştirmez ve önbelleğe almaz.
Aynı madalyonun diğer yüzü: SOCKS5 önbelleğe alamaz, URL'ye göre filtreleyemez veya başlık ekleyemez - çünkü onları hiç görmez. Evrenselliğin bedeli, uygulama katmanı zekâsından feragat etmektir.
Kriterlere göre karşılaştırma: pratikte önemli olanlar
Farkları, mühendislik görevlerinde seçimi gerçekten etkileyen parametrelere göre yapılandırılmış bir karşılaştırmada toplayalım.
HTTP dışı protokollerin desteği
SOCKS5 herhangi bir TCP protokolüyle çalışır: IMAP ve SMTP posta protokolleri, veritabanları, oyun protokolleri, kendi ikili alışverişleriniz. Klasik HTTP proxy doğal olarak yalnızca HTTP anlar. CONNECT üzerinden diğer TCP protokollerini tünelleyebilir, ancak yalnızca proxy ilgili porta izin veriyorsa. Pratikte bu genellikle 443 ile sınırlıdır. Sonuç: rastgele protokoller için SOCKS5 tercih edilir.
UDP
HTTP proxy prensipte UDP ile çalışmaz - modeli TCP istekleri etrafında kurulmuştur. SOCKS5'te UDP ASSOCIATE komutu vardır ve veri paketlerini proxy'leyebilir. Mekaniğini burada ayrıntılı olarak ele almıyoruz, ancak gerçeğin kendisi önemlidir: görev UDP gerektiriyorsa, HTTP proxy hemen devre dışı kalır.
Ek yük
SOCKS5 el sıkışması birkaç kısa ikili mesajdır. Yeni bir bağlantı için bu çok ucuzdur. CONNECT modunda HTTP proxy, TLS başlangıcından önce bir CONNECT isteği ve 200 yanıtı çifti için ek bir round-trip harcar. Çok sayıda kısa bağlantı senaryosunda gecikme farkı birikebilir. Öte yandan, sürekli keep-alive ve bağlantı yeniden kullanımıyla fark neredeyse ortadan kalkar. HTTP trafiği için HTTP proxy, önbellek ve bağlantı havuzu sayesinde kazanabilir.
Önbellekleme
Burada HTTP proxy rakipsizdir. HTTP anlambilimini anladığı için yanıtları önbelleğe alabilir, Cache-Control ve ETag başlıklarına saygı gösterebilir, 304 Not Modified döndürebilir. Statik kaynaklara yönelik tekrarlanan istekler için bu, trafiği ve gecikmeyi hissedilir ölçüde azaltır. SOCKS5 fiziksel olarak önbelleğe alamaz - içeride ne olduğunu görmez. Göreviniz yinelenen kaynaklara yapılan toplu HTTP isteklerini hızlandırmaksa, önbellekli HTTP proxy gerçek bir fayda sağlar.
Loglama ve gözlemlenebilirlik
HTTP proxy ayrıntılı bir access-log tutabilir: metot, URL, yanıt kodu, boyut, User-Agent. Bu, denetim, hata ayıklama ve analitik için - şifrelenmemiş HTTP ile çalışırken - değerlidir. CONNECT üzerinden HTTPS için ayrıntı düzeyi ana bilgisayar-port-hacim seviyesine düşer. SOCKS5 yalnızca bağlantı meta verilerini loglar: hedef adres, süre, trafik hacmi. HTTP düzeyinde uygulama gözlemlenebilirliğine ihtiyacınız varsa, HTTP proxy'yi seçin; taşıma ölçütleri yeterliyse SOCKS5 de kâfidir.
Trafik değişikliği
HTTP proxy meşru olarak başlık ekleyip kaldırabilir, bu servis amaçları için faydalıdır. SOCKS5 verilere hiç dokunmaz. Müdahalenin prensipte kabul edilemez olduğu senaryolar için SOCKS5'in şeffaflığı bir avantajdır.
Özet fark tablosu
- Model katmanı: HTTP proxy - uygulama L7; SOCKS5 - oturum L5.
- Diyalog biçimi: HTTP - metinsel; SOCKS5 - ikili.
- HTTP dışı protokoller: HTTP - yalnızca CONNECT üzerinden ve kısıtlamalarla; SOCKS5 - doğal olarak.
- UDP: HTTP - hayır; SOCKS5 - evet.
- Önbellekleme: HTTP - evet; SOCKS5 - hayır.
- Uygulama katmanı loglama: HTTP - şifrelenmemiş için evet; SOCKS5 - yalnızca meta veri.
- Başlık değişikliği: HTTP - evet; SOCKS5 - hayır.
- Bağlantı başına ek yük: HTTP CONNECT - ek bir round-trip; SOCKS5 - minimum.
Göreve göre ne seçilmeli: pratik bir çerçeve
Teori, bir karara dönüştüğünde değerlidir. Aşağıda bir seçim çerçevesi ve ana eşleme tablosu var. Seçimden önce kendinize sormanız gereken üç soruyla başlayalım.
Seçimden önce üç soru
- Hangi protokolü iletiyorum? Yalnızca HTTP ve HTTPS - her ikisi de işe yarar, ancak HTTP proxy önbellek ve log avantajları sağlar. Rastgele TCP veya UDP - yalnızca SOCKS5.
- Uygulama düzeyinde gözlemlenebilirliğe veya önbelleğe ihtiyacım var mı? Evetse - HTTP proxy. Temiz şeffaf bir boru gerekiyorsa - SOCKS5.
- DNS çözümlemesi nerede yapılmalı? Adların proxy tarafında çözümlenmesi önemliyse, ATYP davranışını ve istemci ayarlarını dikkate alın.
Ana tablo: görev - protokol - neden
- Web tarayıcısı, sıradan gezinme - HTTP proxy veya SOCKS5 - ikisi de çalışır; HTTP proxy önbellek ve kurumsal politikalarla uyumluluk ekler, SOCKS5 standart dışı portlar için daha basittir.
- API entegrasyonları için HTTP istemcisi - HTTP proxy - doğal destek, ortam değişkenleri üzerinden basit yapılandırma, hata ayıklama için ayrıntılı loglar.
- HTTPS üzerinden toplu veri toplama - SOCKS5 veya HTTP proxy - HTTPS'te ikisi de yalnızca taşıyıcıdır; SOCKS5 kısa ömürlü bağlantılarda round-trip tasarrufu sağlar, HTTP proxy bağlantı havuzuyla kullanışlıdır.
- Posta istemcisi (SMTP, IMAP, POP3) - SOCKS5 - posta protokolleri HTTP değildir; CONNECT üzerinden HTTP proxy genellikle portlar nedeniyle engellenir.
- İkili TCP protokollü kendi yazılımınız - SOCKS5 - özel destek olmadan herhangi bir TCP için evrensel taşıyıcı.
- UDP gerektiren uygulama - SOCKS5 - UDP ASSOCIATE üzerinden tek seçenek; HTTP proxy UDP'yi yapamaz.
- Yinelenen statiklere erişim hızlandırma - önbellekli HTTP proxy - önbelleğe alınmış yanıtları döndürebilir ve trafiği tasarruf edebilir.
- HTTP isteklerinin denetimi ve ayrıntılı logu - HTTP proxy - şifrelenmemiş HTTP'de metotları, URL'leri ve kodları görür.
- Tek uygulamadan aynı anda birden fazla protokolle çalışma - SOCKS5 - tek taşıyıcı tüm TCP alışverişlerini kapsar.
Seçim kontrol listesi
- Uygulama protokolünü belirleyin: HTTP, başka bir TCP veya UDP.
- Önbellek ve uygulama katmanı logu gerekip gerekmediğine karar verin.
- İstemcinizin istediğiniz proxy şemasını destekleyip desteklemediğini kontrol edin.
- 443 dışı tünelleme planlıyorsanız, sağlayıcıdan CONNECT için hangi portların açık olduğunu sorun.
- DNS çözümlemesinin nerede yapılması gerektiğini düşünün.
- Kimlik doğrulamayı planlayın: kullanıcı adı-parola veya IP üzerinden.
Popüler istemcilerde ve kütüphanelerde uyumluluk
Protokol seçimi, onu belirli araçlarda nasıl yapılandıracağınızı bilmeden anlamsızdır. Tipik olanları gözden geçirelim.
curl
curl her iki protokolü de destekler. HTTP proxy için -x http://..., SOCKS5 için --socks5 veya -x socks5://... kullanın. SOCKS5 proxy tarafında adın uzaktan çözümlenmesi için bir varyant da vardır; bu ayrı bir şemayla belirtilir, ayrıntılar özel bir materyale bırakılmıştır. Örnek:
curl -x socks5://user:pass@proxy.proxeon.net:1080 https://api.example.com/v1/statusOrtam değişkenleri
Birçok CLI aracı ve kütüphane http_proxy, https_proxy ve all_proxy değişkenlerine saygı gösterir. Sonuncusu genellikle SOCKS5 şemasını kabul eder. Bu, kod düzenlemeden uçtan uca yapılandırma için kullanışlıdır:
export https_proxy=http://user:pass@proxy.proxeon.net:8080
export all_proxy=socks5://user:pass@proxy.proxeon.net:1080Python: requests ve httpx
requests kütüphanesi bir proxies sözlüğüyle yapılandırılır. SOCKS5 için ek bir SOCKS destekli paket gerekir:
import requests
proxies = {"http": "http://user:pass@proxy.proxeon.net:8080", "https": "http://user:pass@proxy.proxeon.net:8080"}
r = requests.get("https://example.com/", proxies=proxies, timeout=10)
print(r.status_code)SOCKS5 için şema socks5 olarak değişir; uzaktan çözümleme için ayrı bir şema kullanılır. httpx kütüphanesi benzer çalışır ve asenkron istekleri destekler, bu toplu işlemlerde kullanışlıdır.
Node.js
Node ekosisteminde proxy özel ajanlar üzerinden ayarlanır. HTTP proxy için https-proxy-agent, SOCKS için socks-proxy-agent kullanılır. Şematik olarak:
const { SocksProxyAgent } = require('socks-proxy-agent');
const agent = new SocksProxyAgent('socks5://user:pass@proxy.proxeon.net:1080');
fetch('https://example.com/', { agent }).then(r => console.log(r.status));Tarayıcılar
Tarayıcılar her iki türü de sistem ayarları veya PAC dosyaları üzerinden destekler. Chromium ailesi, proxy sunucusunu belirten bir başlatma bayrağını kabul eder; Firefox'un ise SOCKS kullanırken DNS'i proxy'leme seçeneği dahil kendi ayarları vardır. Adı kimin çözümlediği sorusu en çok tarayıcılarda ortaya çıkar - ayrıntılar SOCKS şemalarıyla ilgili ayrı makalede.
Posta istemcileri
Klasik posta istemcileri genellikle SMTP ve IMAP için taşıyıcı olarak SOCKS5'i destekler. HTTP proxy posta için nadiren uygulanabilir ve yalnızca CONNECT üzerinden, o da genellikle port kısıtlamalarına takılır. Pratik sonuç: posta için varsayılan olarak SOCKS5'i düşünün.
Kendi yazılımınız
Uygulamayı kendiniz yazıyorsanız, SOCKS5 bir taşıma kütüphanesi veya soket üzerine bir sarmalayıcı ile uygulanır. Uygulama içindeki HTTP istemcisi için kullandığınız HTTP kütüphanesindeki yerleşik HTTP proxy desteğine güvenmek daha kolaydır. Kilit tavsiye: SOCKS el sıkışmasını elle ayrıştırmaya kalkmayın, kanıtlanmış kütüphaneler kullanın - ikili protokolü uç durumlarda hatasız uygulamak kolay değildir.
Tipik yanılgılar
Konu etrafında birçok mit birikmiştir. Yanlış varsayımlara zaman harcamamanız için bunları liste halinde ele alalım.
- "SOCKS5 her zaman HTTP proxy'den hızlıdır." Her zaman değil. Kısa bağlantılarda SOCKS5 round-trip tasarrufu sağlar, ancak önbellekli ve bağlantı havuzlu bir HTTP proxy yinelenen HTTP isteklerinde onu geçebilir.
- "SOCKS5 trafiği şifreler." Hayır. SOCKS5 şifreleme eklemez. Gizliliği tünel içindeki TLS sağlar, SOCKS5'in kendisi değil. Klasik SOCKS5'te kimlik bilgileri bile yerleşik şifreleme olmadan iletilir.
- "HTTP proxy HTTPS dahil her şeyi görür." Hayır. CONNECT üzerinden HTTPS için proxy yalnızca ana bilgisayar adını, portu ve hacmi görür. İçerik TLS ile korunur.
- "HTTP proxy ve SOCKS5 farklı portlarda aynı şeydir." Hayır. Bunlar farklı protokollerdir. Sunucu adresinin çakışması onları özdeş yapmaz.
- "SOCKS5 kimlik doğrulamayı desteklemez." Destekler - RFC 1929'a göre kullanıcı adı/parola yöntemiyle, ayrıca IP bağlaması da mümkündür.
- "HTTP proxy üzerinden HTTP dışı protokollerle çalışılamaz." CONNECT üzerinden çalışılabilir, ancak proxy'nin ilgili porta izin vermesi koşuluyla.
- "Tarayıcı SOCKS5'e ayarlıysa DNS her zaman proxy tarafından çözümlenir." Her zaman değil. İstemci ayarlarına ve ATYP alanında alan adı mı yoksa hazır IP mi iletildiğine bağlıdır.
- "CONNECT yalnızca 443 için çalışır." Teknik olarak hayır, ancak yöneticiler genellikle portları politikayla kısıtlar.
- "SOCKS5 önbelleğe alabilir." Hayır. İçeriği görmez ve fiziksel olarak önbelleğe alamaz.
Çalışma için araçlar ve kaynaklar
Her iki protokolle de güvenle çalışmak için elinizin altında bir dizi tanılama ve test aracı bulundurmak faydalıdır.
Bağlantı tanılaması
- -v bayraklı curl - gerçek diyaloğu görmenin en iyi yolu: CONNECT satırı, proxy yanıtı, TLS el sıkışması.
- Trafik analizörü - ikili SOCKS5 el sıkışmasını ve metinsel HTTP diyaloğundan farkını paket düzeyinde gösterir.
- Port açıklık kontrol araçları - proxy'nizde CONNECT için hangi portların erişilebilir olduğunu anlamanıza yardımcı olur.
Kütüphaneler
- Python için - SOCKS destekli eklentili requests ve httpx.
- Node.js için - https-proxy-agent ve socks-proxy-agent ajanları.
- Sistem entegrasyonu için - http_proxy, https_proxy, all_proxy ortam değişkenleri.
Proxeon'a bağlanırken kontrol edilecekler
- Doğru şema: HTTP proxy için http, SOCKS5 için socks5.
- Her mod için doğru port - bunlar farklıdır.
- Kimlik doğrulama yöntemi: kullanıcı adı-parola veya IP bağlaması.
- 443 dışı tünelleme planlıyorsanız, CONNECT için izin verilen portların listesi.
- DNS davranışı: adları tam olarak nerede çözümlemek istediğiniz.
Mini hata ayıklama çerçevesi
- İsteği proxy olmadan doğrudan tekrarlayın - hedefin erişilebilir olduğundan emin olun.
- Proxy ve -v bayrağıyla tekrarlayın - diyaloğu inceleyin.
- HTTPS kurulmuyorsa - CONNECT için portun izinli olup olmadığını kontrol edin.
- Ad çözümlenmiyorsa - proxy'ye alan adı mı yoksa IP mi gittiğini kontrol edin.
- 407 alıyorsanız - kimlik bilgilerini ve Proxy-Authorization başlığını kontrol edin.
Vaka örnekleri ve uygulama sonuçları
Birkaç tipik mühendislik senaryosunu ve protokol seçiminin sonucu nasıl etkilediğini ele alalım. Rakamlar koşulludur ve reklam vaadi değil, bağımlılıkların bir göstergesi olarak hizmet eder.
Vaka 1: Harici bir servisle API entegrasyonu
Bir ekip, giden adresi kontrol etmek için arka ucunu Proxeon üzerinden harici bir REST API'siyle entegre etti. Başlangıçta SOCKS5 seçtiler, ancak standart HTTP kütüphanesinin ortam değişkenleri üzerinden HTTP proxy'ye daha kolay yapılandırıldığı gerçeğiyle karşılaştılar. HTTP proxy'ye geçiş yapılandırmayı basitleştirdi ve şifrelenmemiş servis çağrılarına yönelik ayrıntılı access-log'lar, iş ortağı tarafındaki 5xx hatalarının nedenlerini hızla bulmaya yardımcı oldu. Sonuç: saf HTTP API için HTTP proxy daha uygundur.
Vaka 2: Posta ağ geçidi
Servis, sabit bir giden adres üzerinden SMTP ile bildirim gönderdi. CONNECT üzerinden HTTP proxy kullanma girişimi başarısız oldu: proxy yalnızca 443'e izin veriyordu. SOCKS5'e geçiş sorunu anında çözdü, çünkü SOCKS5 protokole tarafsızdır ve bağlantıyı uygulama katmanını anlama düzeyinde kısıtlama olmadan 587'ye taşıdı. Sonuç: HTTP dışı protokoller için SOCKS5 doğal bir seçimdir.
Vaka 3: HTTPS üzerinden toplu kamuya açık veri toplama
HTTPS ile çok sayıda sayfa toplarken mühendisler iki modu karşılaştırdı. Çok sayıda kısa ömürlü bağlantıda SOCKS5, ek CONNECT round-trip'i olmadığı için biraz daha düşük ortalama kurulum gecikmesi verdi. Ancak HTTP proxy üzerinden bağlantı yeniden kullanımı ve keep-alive etkinleştirildiğinde fark neredeyse kayboldu. Sonuç: kısa ömürlü bağlantılarda SOCKS5 el sıkışmada tasarruf sağlar, uzun olanlarda fark önemsizdir.
Vaka 4: Kendi ikili telemetri protokolü
Bir şirket telemetriyi kendi TCP protokolüyle iletiyordu. HTTP proxy kavramsal olarak uymuyordu - protokol HTTP değildi. SOCKS5 tek makul taşıyıcı oldu: uygulama SOCKS5 ajanı üzerinden normal bir soket açtı ve protokol değişiklik olmadan çalıştı. Sonuç: rastgele TCP için SOCKS5 vazgeçilmezdir.
Vaka 5: Statiklere erişimin hızlandırılması
Bir iç servis sık sık aynı statik kaynak kümesine HTTP üzerinden başvuruyordu. Önbellekli HTTP proxy, önbelleğe alınmış temsilleri döndürerek ve koşullu istekleri doğru işleyerek giden trafiği ve yanıt süresini belirgin şekilde azalttı. SOCKS5 prensipte böyle bir optimizasyon sağlayamazdı. Sonuç: HTTP isteklerinin tekrarlandığı yerlerde önbellekli HTTP proxy ölçülebilir fayda sağlar.
SSS: sık sorulan sorular
Aynı Proxeon hesabını hem HTTP hem de SOCKS5 için kullanabilir miyim?
Kural olarak evet - yalnızca bağlantı şeması ve portu değişir. Panelinizde hangi portların her moda karşılık geldiğini ve hangi kimlik doğrulama yönteminin ayarlandığını kontrol edin. Teknik olarak bu, iki modda sunulan aynı kaynaktır.
Hangi protokole ihtiyacım olduğundan emin değilsem ne seçmeliyim?
Uygulamanız yalnızca HTTP ve HTTPS ile çalışıyorsa - HTTP proxy ile başlayın, yapılandırması daha basittir ve log ile önbellek sağlar. En az bir HTTP dışı protokol veya UDP ortaya çıkarsa - daha evrensel bir taşıyıcı olarak SOCKS5'i seçin.
HTTPS'te HTTP proxy ile SOCKS5 arasındaki fark neden neredeyse görünmez?
Çünkü HTTPS'te içerik TLS ile korunur ve her iki proxy türü de yalnızca taşıyıcı olarak işlev görür. Bu durumda HTTP proxy, CONNECT üzerinden SOCKS5 gibi bir boru haline gelir. Yalnızca tünel üzerinde anlaşma biçimi farklıdır: metinsel CONNECT ile ikili el sıkışma.
Protokol seçimi DNS çözümlemesini kimin yaptığını etkiler mi?
Evet, dolaylı olarak. SOCKS5'te bu, ATYP alanıyla düzenlenir: alan adı iletilirse proxy çözümler, IP iletilirse istemci. HTTP proxy'de URL'deki veya CONNECT satırındaki ad da proxy tarafında çözümlenebilir. Kesin davranış istemciye ve ayarlarına bağlıdır; ayrıntılı analizi ayrı bir materyale bıraktık.
SOCKS5'te kullanıcı adı ve parola iletmek güvenli mi?
Klasik SOCKS5 kimlik bilgilerini yerleşik olarak şifrelemez. Bu nedenle onu güvenilir bir ortamda veya ek koruyucu önlemlerle birlikte kullanın. Servis proxy'leri için genellikle IP bağlaması mevcuttur ve bu, her bağlantıda parola iletme bağımlılığını azaltır.
CONNECT üzerinden herhangi bir portu tünelleyebilir miyim?
Teknik olarak spesifikasyon yasaklamaz, ancak pratikte proxy yöneticisi güvenlik nedeniyle port listesini sıklıkla kısıtlar. Çoğunlukla 443'e izin verilir. Standart dışı bir porta ihtiyacınız varsa, politikayı sorun veya portlara tarafsız olan SOCKS5'i düşünün.
SOCKS5, HTTP proxy'den daha yüksek anonimlik sağlar mı?
Tek başına hayır. Anonimlik, protokol türüyle değil, hangi meta verilerin iletildiği ve loglandığı ve trafiğin TLS ile korunup korunmadığıyla belirlenir. HTTP proxy, istemciyi açığa çıkaran servis başlıkları ekleyebilir, ancak doğru yapılandırmayla bundan kaçınılabilir. SOCKS5 uygulama katmanı başlığı eklemez çünkü onları görmez.
Proxy arkasındaki hedef sunucu erişilemezse ne olur?
HTTP proxy, HTTP düzeyinde bir hata kodu döndürür, örneğin 502 veya 504. SOCKS5, bağlantı komutuna verdiği yanıtta bir hata kodu döndürür - örneğin ana bilgisayara ulaşılamaması veya bağlantı reddi. Her iki durumda da istemci anlaşılır bir sinyal alır, ancak farklı biçimde: HTTP'de metinsel, SOCKS5'te ikili.
UDP için ayrı bir proxy gerekli mi?
UDP'yi yalnızca SOCKS5, UDP ASSOCIATE komutu aracılığıyla destekler. HTTP proxy UDP ile çalışmaz. Bu komutun mekaniğini ayrı bir makalede ayrıntılı olarak ele alıyoruz; burada yalnızca gerçeği akılda tutmak önemli: UDP gerekiyorsa, bu SOCKS5'in bölgesidir.
Proxy'nin gerçekten doğru modda çalıştığını nasıl anlarım?
En güvenilir yol, curl ile -v bayrağı kullanarak bir istek yapıp diyaloğu incelemektir. HTTP proxy için mutlak URI'yi veya CONNECT satırını göreceksiniz; SOCKS5 için istekten önce metinsel HTTP diyaloğunun olmamasını ve doğru yanıt kodunu göreceksiniz. Ek olarak, IP'nizi gösteren bir servis üzerinden giden adresi kontrol edebilirsiniz.
Sonuç: doğru kararı nasıl verirsiniz
İki protokolün felsefesinden somut kod satırlarına kadar bir yol kat ettik. Mühendisçe ve gereksiz laf kalabalığı olmadan özetleyelim.
HTTP proxy - uygulama katmanının akıllı aracısıdır. HTTP'yi anlar, şifrelenmemiş istekleri görür ve değiştirebilir, önbelleğe alabilir ve ayrıntılı loglar tutabilir. CONNECT metodu onu HTTPS ve diğer protokoller için bir TCP tüneline dönüştürür, ancak izin verilen portlar kaydıyla. Ağırlıklı olarak HTTP ve HTTPS ile çalışıyorsanız ve gözlemlenebilirlik ile önbelleğe değer veriyorsanız onu seçin.
SOCKS5
