Hem VPN hem de ileri proxy, bir web sitesinin gördüğü adresi değiştirir ve karşılaştırmaların çoğu burada biter. Kurulumunuzu belirleyen fark kapsamdır: ileri proxy, uygulamanızın kendisinin kullanmayı seçtiği bir aracıdır; bir sitenin önünde duran ters proxy'den farklı olarak, VPN ise işletim sisteminin bir tünele yönlendirdiği her şeyi taşır. Şifreleme, DNS işleyişi ve hata davranışı bu ayrımdan doğar. Bu beş kontrolü sırayla yapın; ilk başarısız olan, gerçekte hangi araca ihtiyacınız olduğunu söyleyecektir.

Aracı hangi uygulamaları kapsar?

Tarayıcıdaki bir proxy uzantısı yalnızca o tarayıcı profili için geçerlidir. Posta istemcileri, paket yöneticileri ve ikinci bir tarayıcı kendi ayarlarını kullanmaya devam eder; bazı uygulamalar sistem proxy değişkenlerini tamamen yok sayar. VPN, yönlendirme tablosunun tünele gönderdiğini kapsar; bu, rotalara ve istemci ilkesine bağlı olarak tüm uygulamalar ya da bölünmüş tünelde bir alt küme olabilir.

Tek bir sayfa yüklemesinden genelleme yapmak yerine önemli uygulamaları test edin. curl https://ifconfig.me ortamın proxy değişkenlerini izler; bir masaüstü uygulaması izlemeyebilir. Windows'ta netsh winhttp show proxy, hizmetlerin kullandığı WinHTTP proxy'sini yazdırır ve bu tarayıcının ayarından farklı bir ayardır.

Sıçrama şifreli mi ve TLS nerede bitiyor?

Proxy protokolü bir buluşma noktasıdır, garanti değil. SOCKS5 TCP'yi şifrelemeden iletir ve düz HTTP proxy istek satırını ve başlıkları açık metin olarak taşır. Proxy üzerinden HTTPS CONNECT kullanır; böylece TLS oturumunuz yine de hedefte sonlanır, proxy'de değil. MDN'nin proxy sunucuları ve tünelleme kılavuzu bu farkı protokol tarafından açıklar.

VPN, cihazınız ile uç noktası arasındaki bölümü şifreler. Uç noktanın ötesinde herhangi bir ağdakiyle aynı kurallar geçerlidir; bu yüzden tek başına bir tünel, kimlik bilgilerini düz HTTP ile gönderen bir uygulamayı korumaz. İki tasarımın hiçbiri oturum açmış bir hesabı, çerezi veya tarayıcı parmak izini gizlemez.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Ayrıntılı çıktı, curl'ün 443 portuna CONNECT mi yoksa tam URL ile düz GET mi gönderdiğini gösterir. socks5h:// ile ana bilgisayar adı SOCKS5 isteğinin içinde proxy'ye verilir ve ardından proxy okuyamadığı TLS'i iletir; böylece adı ve bayt sayısını görür. http:// proxy üzerinden bir https:// URL'si CONNECT'tir; dolayısıyla o proxy de hedefin adını ve hacmini görür, ancak isteği veya yanıt gövdesini görmez.

Hangi çözümleyici adı görür?

Ad çözümlemesi istek çıkmadan önce yerel olarak gerçekleşebilir ya da proxy'de uzaktan. curl ile socks5h:// ana bilgisayar adını proxy'ye gönderirken socks5:// önce onu yerel olarak çözer. Tarayıcının proxy ayarları karşılaştırılabilir bir DNS seçeneği sunar ve PAC dosyaları farklı ana bilgisayarları farklı şekillerde yönlendirebilir.

İki protokol, herhangi bir yanlış yapılandırma olmadan proxy'yi atlayabilir. WebRTC adayları STUN üzerinden toplar ve QUIC HTTP/3'ü UDP üzerinde çalıştırır; bir TCP proxy bunu taşıyamaz. UDP 443 engellenmişse tarayıcı TCP'ye geri döner; bu yüzden HTTP/3'ü proxy yolunda tutmanın güvenilir yolu tarayıcı bayrağı değil, ana bilgisayarın güvenlik duvarında (veya tüm ağ için yönlendiricide) UDP 443'ü engellemektir.

Çözümleyiciyi kendi dizüstü bilgisayarınızın değil, hedefin bakış açısından kontrol edin. Proxy'nin çıkış adresiyle ancak yerel olarak çözülmüş bir adla gelen bir istek, yerel çözümleyiciye hangi siteleri ziyaret ettiğinizi yine de söyler.

Aracı başarısız olduğunda ne olur?

Açık bir proxy kapalı biçimde başarısız olur: proxy sürecini durdurun, tarayıcı veya uygulama doğrudan gitmek yerine bağlantı hatası döndürür. PAC ve WPAD kurulumları açık biçimde başarısız olanlardır - betik alınamazsa istemci DIRECT'e geri döner ve site gerçek adresinizi yeniden görür. VPN, istemciye ve bir kill switch ya da güvenlik duvarı kuralının etkin olup olmadığına bağlı olarak açık veya kapalı biçimde başarısız olabilir.

Hata durumunu bilerek test edin: proxy hizmetini durdurun ve yeniden yükleyin; doğrudan yükleme yerine hata sayfası alırsanız, geri dönüşü görmek için PAC URL'sini ulaşılamaz bir ana bilgisayara yönlendirin. Sayfa hâlâ olağan rotanızdan yükleniyorsa proxy kendi kesintisine karşı hiçbir koruma sunmaz ve bu, ona güvenmeden önce bilmeniz gereken bir özelliktir.

Sıra, sitenin ne gördüğünü belirler. Giden trafiği VPN üzerinden geçen bir proxy, sitenin VPN uç noktasının adresini görmesini sağlar; proxy'yi tünelin dışına koyarsanız (uzak bir ana bilgisayardaki proxy'ye VPN), site bunun yerine o proxy'nin çıkış adresini görür. Her iki durumda da iki sıçrama farklı şeyler kaydedebilir.

Beş kontrol, sırayla

Aşağıdaki kontrol listesi tüm kararın tek bir yerde toplanmış halidir. Kapsam önce gelir çünkü uyumsuzlukların çoğunu ortadan kaldırır: kapsanması gereken uygulama ayara uymuyorsa, listede daha sonraki hiçbir şey onu kurtarmaz.

CheckForward proxyVPN
What is coveredThe app or browser you configureTraffic the OS routes into the tunnel, all or split
Encryption scopeProtocol-dependent; SOCKS5 alone encrypts nothingDevice to VPN endpoint
DNS pathLocal or remote, depending on the settingNormally inside the tunnel
Failure modeExplicit config: connection error; PAC/WPAD: DIRECT fallbackClient policy: fail-open or kill switch
What the site seesThe proxy's exit addressThe VPN endpoint's exit address

Ardından sonucu değişikliğe yol açan uygulamayla doğrulayın. Yapılandırılmış tarayıcıda bir sayfa yükleyin, aynı sayfayı curl ile alın ve her birinin bildirdiği adresi karşılaştırın. Uyuşmuyorlarsa hâlâ bir uzantı, bir PAC kuralı ya da uygulama düzeyinde bir geçersiz kılma devrededir ve hiçbir tünel ayarı bunu düzeltmez.

Neyi yapılandırdığınızı not edin: hangi uygulamalar proxy'yi kullanıyor, DNS yerel mi uzak mı, UDP engelli mi ve hata davranışı nedir. Tam da bu küçük envanter bir sonraki karşılaştırmayı mümkün kılar, çünkü „IP değişti“ size bu beş kontrolden hangisinin geçtiğini asla söylemedi.

İlgili makaleler