Sina Weibo Proxy: Çözümleme, Medya Yolu ve Eşzamanlı Oturumlar

Weibo akışını proxy arkasından açtığınızda ilk bakışta her şey yolunda görünebilir: gönderiler yüklenir, arama çalışır. Sorunlar genellikle iki noktada belirir. Birincisi, tarayıcının bazı istekleri proxy’ye hiç uğratmadan göndermesidir; ikincisi, medya isteklerinin ana alan adından farklı bir yoldan gelmesi ve bu yolun kuralınızın dışında kalmasıdır.

Bu iki nokta birbirini gizler. Sızıntı varsa görünen içerik doğru olsa bile çıkışınız düşündüğünüz yer değildir. Medya yolu kapsam dışındaysa çıkışınız doğrudur ama akış eksik görünür. Doğru sıra önce sızıntıyı kapatmak, sonra kapsamı genişletmektir.

Üçüncü başlık çoklu cihazdır. Aynı hesabı telefondan ve masaüstünden kullanıyorsanız platform tarafında iki ayrı oturum vardır ve bunlar farklı adreslerden gelebilir. Bu, kendiliğinden bir sorun değildir; sorun, farkın nereden geldiğini bilmeden yorumlamaktır.

Bir Weibo oturumunun tekrar eden döngüsü

Akışı her yenilediğinizde aynı üç adım tekrarlanır. Önce hedefin adresi çözülür ve bağlantı kurulur; bu aşamada TLS el sıkışması yapılır. Sonra oturum devreye girer: istemci çerezini veya jetonunu gönderir ve sunucu bunu tanır. Son olarak içerik gelir; mikroblog akışında bunun büyük kısmı metin değil, görsel ve videodur.

Döngü olarak düşünmek teşhis için kullanışlıdır, çünkü her adım farklı bir hata üretir. Çözümleme aşamasındaki hata zaman aşımı olarak görünür. Oturum aşamasındaki hata giriş ekranına dönüş ya da yeniden doğrulama olarak görünür. İçerik aşamasındaki hata ise en yanıltıcı olanıdır: sayfa açılır, yalnızca bazı parçalar eksik kalır.

Proxy döngünün neresinde durur?

Proxy yalnızca paketin hangi yoldan çıktığını belirler. Oturumu taşıyan çerez cihazınızda kalır; bu yüzden çıkış adresini değiştirmek oturumu sıfırlamaz. Aynı şekilde, oturumu kapatmak da çıkış adresinizi değiştirmez. İkisi ayrı katmanlardır ve ayrı ayrı yönetilir (proxy nedir).

Alan adı nerede çözülür ve bu neyi açığa çıkarır?

Bir bağlantı kurulmadan önce hedefin adı bir adrese çevrilir. Bu çevirinin nerede yapıldığı, proxy kullanırken sanıldığından çok daha belirleyicidir. HTTP proxy’de istemci hedefi CONNECT ornek.example:443 biçiminde düz metin olarak bildirir; çözümü proxy yapar. SOCKS5’te davranış istemciye bağlıdır: kimi istemci adı kendi ağında çözer ve proxy’ye yalnızca adresi verir, kimi de adı proxy’ye bırakır.

Çözüm sizin ağınızda yapılırsa iki şey olur. Birincisi, hangi alan adına bağlandığınız yerel DNS sunucunuza görünür; proxy kullanıyor olmanız bunu değiştirmez. İkincisi, size yakın bir dağıtım düğümü döner ama bağlantı proxy’nin bulunduğu ülkeden kurulur; sonuçta rota gereksiz yere uzayabilir. Ayrım SOCKS5’te DNS nerede çözülür yazısında ayrıntılı anlatılıyor.

Kontrol yöntemi basittir: proxy açıkken DNS leak testini çalıştırın ve görünen çözümleyicinin sizin sağlayıcınıza mı yoksa çıkışın bulunduğu ağa mı ait olduğuna bakın. Testi bir de proxy kapalıyken çalıştırıp iki sonucu yan yana koyun; fark yoksa çözümleme proxy’ye hiç gitmiyor demektir.

Düzeltme genellikle istemci tarafındadır: SOCKS5 kullanıyorsanız alan adını proxy’ye bırakan yapılandırmayı seçin, tarayıcıda ise güvenli DNS ayarının proxy kuralınızla çelişmediğini kontrol edin. Komut satırı araçlarında da aynı ayrım vardır; kimi araç adresi kendisi çözer ve proxy’ye yalnızca sonucu verir. Hangi davranışın geçerli olduğunu belgeden okumak yerine ölçmek daha güvenilirdir, çünkü sürümler arasında değişebilir.

Tarayıcının proxy’yi atladığı iki yol

Proxy tanımlamak, bütün trafiğin proxy üzerinden gittiği anlamına gelmez. Tarayıcıda bunun iki klasik istisnası vardır ve ikisi de sessizce çalışır; hata mesajı görmezsiniz.

Birincisi WebRTC’dir. Tarayıcıdaki WebRTC arayüzü, proxy ayarından bağımsız olarak yerel ve genel adreslerinizi bir sayfaya bildirebilir. Görsel ve video ağırlıklı bir akışta bu arayüzün kullanılması şaşırtıcı değildir; ölçmek için WebRTC leak testi yeterlidir. Sonuç beklenmedikse ilgili tarayıcı ayarını o profilde kapatın.

İkincisi IPv6 tarafıdır ve burada varsaymak yerine ölçmek gerekir: aynı hedefe önce IPv6 kapatılmış bir profilden, sonra açık bir profilden bağlanın ve IP adresim sonucunu iki durumda karşılaştırın. İki sonuç farklıysa istekleriniz çift yığında bölünüyor ve bir kısmı çıkışınızı hiç kullanmıyor demektir. Karşılığı tek cümledir: ya IPv6 destekli bir çıkış tanımlayın ya da test profilinde IPv6’yı kapatıp ölçümü tek yığına indirin (IPv4 ile IPv6 proxy farkı). Ölçümü akış sayfasında değil sade bir test sayfasında yapın; medya istekleri karıştığında hangi isteğin nereden çıktığını ayırt edemezsiniz.

Medya trafiği ana alan adından neden ayrılır?

Büyük ölçekli platformlar sayfanın kendisini ve içindeki medya varlıklarını aynı sunucudan servis etmez. Metin ve arayüz uygulama sunucularından gelirken görsel ve video, coğrafi olarak dağıtılmış bir içerik dağıtım ağından çekilir. Bu, hem yükü dağıtmak hem de varlığı kullanıcıya yakın bir düğümden vermek içindir (proxy ve CDN farkı).

Sonuç, proxy kullanıcısı için doğrudan bir kapsam sorunudur. Kuralınız yalnızca ana alan adını eşliyorsa arayüz proxy üzerinden gelir, medya doğrudan çıkar. Belirti tanıdıktır: akış açılır, gönderi metinleri görünür, görseller boş kutu kalır ya da video başlamaz. Çözüm kuralı alt alan adlarını kapsayacak biçimde yazmak veya sistem geneli ayara geçmektir.

İkinci sonuç hacimdir. Bir mikroblog akışında indirilen verinin büyük kısmı metin değildir; kotayı bitiren de budur. Aktarılan veri üzerinden ücretlendirilen paketlerde uzun süre açık kalan bir sekme sessizce tüketim üretir. Planlama için bant genişliği hesaplama yazısı bir hesap şablonu veriyor.

Üçüncü sonuç rota ile ilgilidir ve adı kimin çözdüğüne bağlıdır: çözümleme proxy tarafında yapılıyorsa dağıtım düğümü çıkışa yakın seçilir, çıkış ülkesi uzaksa medya yolu da uzar. Çözümleme yerel ağınızda yapılıyorsa düğüm size yakın seçilir ama bağlantı yine çıkıştan kurulduğu için rota gereksiz bir tur atabilir. Bazı çözümleyiciler istemcinin ağ bloğunu sorguya ekler (EDNS Client Subnet); böyle bir kurulumda seçimi belirleyen şey çıkış değil, doğrudan sizin ağınızdır. Hangi hâlde olduğunuzu bir önceki bölümdeki çözümleme ayrımıyla belirleyin; lokasyon seçimi bu yüzden yalnızca görünüm meselesi değildir, akışın akıcılığını da etkiler.