Windows ayarlarında proxy'yi tanımladınız, programı yeniden başlattınız - ama yine de ev IP'si ile çıkıyor. Ya da tam tersi: tarayıcı doğru bir şekilde proxy üzerinden çıkıyor, ama masaüstü istemcisi yanındaki gerçek adresi göstermeye devam ediyor. Bu bir proxy hatası değil ve yanlış kimlik bilgileri de değil. Bu, işletim sistemlerinin "sistem proxy'si" ile nasıl çalıştığına dair temel bir özelliktir: zorlamaz, sadece önerir.
Aşağıda, belirli bir uygulamanın SOCKS5 üzerinden çalışmasını sağlamak için dört etkili yöntem bulunmaktadır; her birinin sınırlamaları ve ayarların en çok hangi noktalarda sorun çıkardığına dair ipuçları da yer almaktadır.
Sistem proxy'si neden çalışmıyor: kısa teknik gerçek
Windows'ta tek bir "sistem proxy'si" yoktur. En az iki bağımsız ayar seti vardır. Birincisi - WinINET: "Ayarlar → Ağ ve İnternet → Proxy Sunucusu" kısmında düzenlediğiniz şey. Bunu Internet Explorer/Edge, bazı .NET uygulamaları ve standart kullanıcı HTTP yığını kullanan her şey okur. İkincisi - WinHTTP, sistem hizmetleri ve arka plan süreçleri tarafından kullanılır. Ve işte anahtar nokta: WinHTTP, WinINET ayarlarını kullanmaz, onları açıkça içe aktarmadığınız sürece. Bunu netsh winhttp import proxy source=ie komutuyla yaparsınız ve - Microsoft belgelerinden önemli bir detay - bu komut mevcut ayarların anlık görüntüsünü alır. Ayarları daha sonra değiştirdiniz mi? Anlık görüntü kendiliğinden güncellenmez, komutu yeniden çalıştırmanız gerekir.
Ama içe aktarma bile ana sorun kategorisinden kurtarmaz. Çok sayıda program sistemden hiç sormaz: kendi ağ yığınlarını kullanır ve TCP soketlerini doğrudan açar. Sosyal medya ve mesajlaşma uygulamalarının birçok masaüstü istemcisi, oyun başlatıcıları, torrentler, gömülü yapılandırmaya sahip bazı Electron uygulamaları, derlenmiş Go ve Rust araçları bu şekilde çalışır. Bu tür uygulamalar için işletim sistemi ayarlarında "proxy" satırı kavramı yoktur.
Bundan dolayı kural: Eğer uygulama kendi proxy alanına sahip değilse, tek güvenilir yol - trafiğini uygulama seviyesinin altında yakalamaktır. Dört ana yöntem vardır ve bunlar fiyat, güvenilirlik ve gerekli izinler açısından temelde farklıdır.
Adım 0: Sorunun gerçekten bu olduğundan emin olun
- Uygulamayı başlatın ve hangi IP'yi gösterdiğine bakın (hesap profili, hizmetin hizmet sayfası, herhangi bir yerleşik gösterge).
- Aynı anda tarayıcıyı aynı proxy üzerinden açın ve adresi kontrol edin. Farklı IP'ler = uygulama sistem ayarını görmezden geliyor.
- Programın kendi proxy ayarlarının olup olmadığını kontrol edin - genellikle "Ağ", "Bağlantı" veya yapılandırma dosyasında gizlidir. Yerel destek her zaman dışarıdan yakalamadan daha iyidir: daha az katman, daha az arıza.
- Ayrıca DNS'i kontrol edin. Eğer uygulama isimleri yerel olarak çözüyorsa ve trafik proxy üzerinden gidiyorsa, gerçek sağlayıcınız yine de nereye gittiğinizi görecektir.
Yöntem 1. Proxifier - Windows ve macOS için ticari standart
Proxifier, uygulamaların bağlantılarını yakalar ve belirlenen proxy üzerinden kurallar çerçevesinde yönlendirir: "bu exe - proxy A üzerinden, o - proxy B üzerinden, geri kalan - doğrudan" şeklinde ayarlayabilirsiniz, portlar ve hedef adreslere göre ayırabilir, birkaç proxy'den oluşan bir zincir oluşturabilirsiniz.
Yazım anındaki güncel sürümler: 4.14 Windows için (23 Nisan 2025'te yayımlandı) ve 3.15 macOS için (18 Eylül 2025). Lisans - 39.95 $ kopya başına, tek seferlik satın alma, süresiz, ücretsiz küçük güncellemeler ile; 31 günlük tam işlevsel deneme sürümü, iki kopyadan itibaren toplu indirimler ve 30 gün içinde iade imkanı bulunmaktadır.
Ayar pratiği:
- Proxy Sunucuları → Ekle: adresi, portu, SOCKS5 protokolünü ve kimlik bilgilerini belirtin. Kuralları oluşturmadan önce testin geçmesi için Check'e tıklayın, aksi takdirde iki sorunu aynı anda çözmeye çalışacaksınız.
- Proxification Kuralları → Ekle: Uygulamalar kısmında belirli bir çalıştırılabilir dosyayı seçin, Eylem kısmında proxy'nizi belirtin.
- Varsayılan kuralı Doğrudan bırakın, eğer tüm makineyi proxy üzerinden yönlendirmek istemiyorsanız. Bu, yeni başlayanların en sık yaptığı hatadır: Varsayılan → Proxy, işletim sistemi güncelleyicisini, antivirüsü ve gigabayt başına ödeme yaptığınız gereksiz trafiği tünel içine alır.
- Gerçek zamanlı olarak Connections sekmesine bakın: hangi bağlantının proxy üzerinden gittiğini, hangisinin doğrudan gittiğini görebilirsiniz.
Güçlü yönleri - olgunluk, kararlı kurallar ve anlaşılır teşhis. Zayıf yönleri - ücretli olması ve agresif anti-hile sistemlerinde sürücü yakalamanın fark edilebilmesi.
Yöntem 2. ProxiFyre - UDP desteği olan ücretsiz Windows alternatifi
Bütçeniz sıfırsa ve platform Windows ise, ProxiFyre (AGPL-3.0 lisansı) adlı açık bir proje bulunmaktadır. NDISAPI/Windows Paket Filtreleme üzerinde çalışır - yani paket filtreleme sürücüsü seviyesinde çalışır ve genellikle eksik olan şeyi yapar: her uygulama için yalnızca TCP değil, aynı zamanda UDP'yi de şeffaf bir şekilde yönlendirme yeteneğine sahiptir. Bu, UDP ve QUIC üzerinde çalışan her şey için kritik öneme sahiptir - ses kanalları, oyun istemcileri, modern tarayıcı bağlantılarının bir kısmı.
Yeni sürümlerdeki faydalı özellikler: IPv6 desteği v2.3.0'da, SOCKS5-over-TLS v2.4.0'da, uygulamalar için istisna kuralları ve diğer tüm uygulamalar için catch-all bulunmaktadır. Gereksinimler: kurulu Windows Paket Filtreleme, Visual Studio çalışma zamanı kütüphaneleri ve yönetici izinleri.
Ayarlar, uygulamaların ve onlara bağlı SOCKS5 uç noktalarının listesini içeren bir yapılandırma dosyası aracılığıyla yapılır. Giriş eşiği Proxifier'dan daha yüksektir, ancak ödeme yapmazsınız ve UDP alırsınız.
Yöntem 3. proxychains-ng - Linux için hızlı bir seçenek, bazı kısıtlamalarla
Unix sistemleri için klasik: proxychains4 curl https://example.com. Mekanizma - LD_PRELOAD: kütüphane, dinamik olarak bağlantılı programdaki soket çağrılarını değiştirir ve onları SOCKS'a yönlendirir.
Bu çalışma sürecini kurmadan önce bilmeniz gereken kısıtlamalar:
- Yalnızca TCP. UDP ve ICMP hiç yönlendirilmez - proxychains üzerinden ping atmak anlamlı bir şey kontrol etmez.
- Yalnızca dinamik olarak bağlantılı ikili dosyalar. Statik olarak derlenmiş araçlar (Go için tipik bir durum) LD_PRELOAD'u sessizce yok sayar - trafik doğrudan gidecek ve bunu fark etmeyeceksiniz.
- macOS'ta SIP ile sınırlıdır. Sistem Bütünlüğü Koruması, kütüphanenin sistem ikili dosyalarına yüklenmesini engeller:
proxychains4 ssh user@hostçalışmaz. Çalışan bir geçici çözüm - ikili dosyayı kendi dizininize kopyalamak (cp /usr/bin/ssh ~/.local/bin/) ve kopyayı başlatmaktır. Kolaylık için SIP'i devre dışı bırakmanızı önermiyorum: bu, tüm sistemin güvenliğini bir araca karşı zayıflatır.
Hedefli görevler (curl, python betiği, konsol aracı) için proxychains, en hızlı yöntem olmaya devam ediyor - tek bir komutla kuruluyor ve root gerektirmiyor.
Yöntem 4. TUN modu: sanal arayüz seviyesinde yakalama
En evrensel çözüm sınıfı. Sanal bir ağ arayüzü oluşturulur, sistemin yönlendirmeleri buna yönlendirilir ve kullanıcı TCP/IP yığını paketleri işler ve dışarıya SOCKS5 üzerinden verir. tun2socks (gVisor yığını kullanır, TCP ve UDP'yi destekler, tüm platformlar için mevcuttur) ve sing-box TUN modunda bu şekilde çalışır.
LD_PRELOAD'a göre temel avantajı: her şeyi, statik ikili dosyalar ve kendi yığınına sahip uygulamalar dahil olmak üzere yakalar. Sing-box'ta ayrıca süreçlere göre yönlendirme vardır - process_name, process_path ve process_path_regex alanları, gerçek per-app kurallarını sağlar; belgelerde bunun Linux, Windows ve macOS'ta desteklendiği belirtilmektedir (mobil platformlarda kurallar paket adı veya bundle ID ile belirlenir).
Hemen hemen herkesin takıldığı iki tuzak:
- Yönlendirme döngüsü. Eğer tüm trafik TUN'a giderse, SOCKS5 sunucusuna olan bağlantı da TUN'a gitmeye çalışır - tünel kendini sarmaya başlar. Bu, fiziksel arayüz üzerinden proxy IP'sine açık bir yönlendirme ile çözülür. Bu, sing-box yapılandırmalarında sıkça karşılaşılan bilinen bir sorundur.
- İzinler. TUN arayüzü oluşturma ve yönlendirme tablosunu düzenleme, root/yönetici gerektirir. Kurumsal bir makinede politikalar nedeniyle bu erişim olmayabilir.
Linux'ta iki benzer yaklaşım daha vardır: redsocks - iptables kuralları aracılığıyla yakalama ve yerel bir porta yönlendirme (sadece Linux, root gerektirir) ve sshuttle, sıradan SSH erişiminin üzerine VPN benzeri yönlendirme kurar ve klasik "TCP'nin TCP üzerindeki" sorununu aşar.
En sık ne bozulur
- DNS sızıntısı. Doğru yapılandırılmış SOCKS5 ile bile uygulama yerel olarak alan adlarını çözebilir. Çözümün proxy tarafına gittiğinden emin olun, sağlayıcınıza değil.
- SOCKS4 yerine SOCKS5 seçildi. SOCKS4, UDP'yi hiç desteklemez ve bazı uygulamalarda alan adını iletemez. Rastgele trafiği yakalamak için yalnızca SOCKS5 kullanın - neden böyle olduğunu detaylı olarak SOCKS5'in çalışma prensipleri makalesinde inceleyebilirsiniz.
- HTTP proxy yerine SOCKS. HTTP proxy, HTTP'yi ve CONNECT üzerinden TLS bağlantılarını proxy'leyebilir. Rastgele TCP trafiği, oyun istemcisi veya mesajlaşma uygulaması üzerinden yönlendirilmez.
- Tüm trafik için varsayılan kural. Tüm makineyi yönlendirirken, güncellemeler ve telemetri için ikamet eden havuzun trafiğini yakarsınız.
- Ayarlardan sonra kontrol eksikliği. Her zaman uygulamanın gerçek çıkış IP'sini kontrol edin, yanındaki tarayıcıdan değil.
Hangi tür proxy ile yakalama yapılmalı
Teknik olarak, yakalama herhangi bir SOCKS5 uç noktası ile çalışır, ancak tür seçimi, senaryonuzun başarıya ulaşıp ulaşmayacağını belirler.
- İkamet edenler - uygulama, IP'nin itibarını değerlendiren bir hizmetle çalışıyorsa: sosyal medya, pazar yerleri, reklam panelleri, ödeme formları. Veri merkezi adresi neredeyse anında tanınır. SOCKS5 ve sticky oturumları destekleyen ikamet eden proxy'ler uygundur - bu son derece önemlidir çünkü aktif oturum sırasında IP'nin değiştirilmesi, "yabancı" IP'nin başlangıçta görünmesinden daha kötü görünür.
- Veri merkezi - sıkı anti-hile olmadan teknik görevler için: API erişimi, iç hizmetler, test standları, hız ve bağlantı kararlılığının önemli olduğu her şey. Burada veri merkezi proxy'leri en iyi ping ve öngörülebilirlik sağlar.
- Mobil - uygulama doğası gereği mobil olduğunda (emülatör, sosyal medya istemcisi) ve platforma maksimum güven gerektirdiğinde.
Ayrıca: uygulama seviyesinde yakalama, VPN değildir ve birini diğerinin yerine koymak doğru değildir. Eğer tüm makine için tek bir güvenli kanala ihtiyacınız varsa ve farklı programlar için farklı IP'ler istemiyorsanız, yaklaşımları karşılaştırmak için WireGuard ve proxy makalesine göz atabilirsiniz.
Bir dakikada nasıl yöntem seçilir
- Uygulama kendi proxy ayarlarına sahip → onları kullanın, hiçbir şeyi yakalamayın.
- Windows, bugün sonuç gerekiyor, bütçe var → Proxifier.
- Windows, UDP gerekiyor ve ücretsiz → ProxiFyre.
- Linux, konsol aracı ile tek seferlik bir görev → proxychains-ng.
- Statik bir ikili dosyayı, oyunu veya hepsini per-app kuralları ile yakalamak gerekiyorsa → TUN modu (sing-box, tun2socks), proxy'ye açık yönlendirmeyi unutmayın.
Temel sonuç basit: "proxy çalışmıyor" ifadesi, dokuz durumda on anlamına gelir "proxy yanlış seviyede ayarlanmış". Sistem ayarı, uygulamaya nazik bir istektir, sürücü, LD_PRELOAD veya TUN arayüzü seviyesinde yakalama ise zorlamadır. Doğru katmanı seçin, uygulamanın gerçek çıkış IP'sini kontrol edin ve DNS'i unutmayın - sorun bir kez kapatılır, her program güncellemesinden sonra tekrar ortaya çıkmaz.
```