Likee Proxy Kullanımı: Ad Çözümleme, Medya Yolu ve Oturumlar

Likee, BIGO Technology tarafından işletilen kısa video platformlarından biridir ve ağırlık merkezi mobil uygulamadır. Web tarafı daha çok tekil video ve profil görüntüleme için kullanılır. Bu dengesizlik proxy kurulumunu etkiler: masaüstü tarayıcıda yaptığınız bir ayar, uygulamanın gerçekte ürettiği trafiğin küçük bir kısmını temsil eder.

Bir diğer belirleyici nokta, içeriğin nasıl taşındığıdır. Video dosyaları, kapak görselleri ve profil fotoğrafları ana alan adından değil, dağıtım için ayrılmış adreslerden gelir. Kısmi bir proxy kuralı yazdığınızda uygulama açılır, akış boş kalır; bu tablonun kaynağı kimlik doğrulama değil, kapsamdır.

Aşağıdaki bölümler önce ad çözümleme ve sızıntı konusunu, sonra taşıma katmanını ve trafik dağılımını, ardından oturum davranışı ile kurulum katmanlarını ele alıyor.

Alan adı nerede çözülür ve bu ne söyler?

Bir bağlantı kurulmadan önce alan adının adrese çevrilmesi gerekir. Bu işlem iki yerde yapılabilir: istemcinin bulunduğu cihazda veya proxy sunucusunda. Hangisinin geçerli olduğu, kullandığınız protokole ve istemci ayarına bağlıdır.

HTTP proxy üzerinden HTTPS bağlantısında istemci CONNECT sunucu:443 der ve adı proxy çözer. SOCKS5 ise adres türü olarak alan adı gönderebildiği için çözümlemeyi uzak tarafa bırakabilir; buna karşılık bazı istemciler adı yine de yerelde çözüp yalnızca IP gönderir. Ayrımın teknik detayı SOCKS5’te DNS nerede çözülür yazısında ele alınıyor.

Pratik sonuç şudur: ad yerelde çözülüyorsa hangi hizmete bağlandığınız, trafik şifreli olsa bile sağlayıcı tarafında görünür. Bu içeriğin okunması değil, hizmet adının açığa çıkması demektir. Ölçüm için DNS leak testi aracını kullanın.

Modern işletim sistemleri ve tarayıcılar bu tabloyu daha da karıştırır. Tarayıcının kendi şifreli DNS ayarı açıkken ad çözümleme ne yerel çözücüye ne de proxy’ye gider; tarayıcının seçtiği uzak çözücüye gider. Sonuç olarak aynı cihazda iki uygulama, aynı alan adını iki farklı yoldan çözebilir. Test yaparken hangi bileşenin çözümlemeyi yaptığını sabitlemeden ölçüm almak, birbiriyle çelişen sonuçlar üretir.

WebRTC ve UDP taşıma proxy tünelinin dışında kalır

Tarayıcı tarafındaki WebRTC arayüzü, bağlantı adaylarını toplarken STUN sunucularına başvurur ve bu süreçte yerel ağ adresinizi, çoğu yapılandırmada da genel adresinizi öğrenir. Bu bilgi sayfadaki bir betiğe verilebilir. HTTP proxy kuralı bu süreci kapsamaz, çünkü aday toplama ayrı bir yol izler. Durumu WebRTC leak testi ile ölçebilirsiniz.

Canlı yayın ve görüntülü etkileşim özellikleri düşünüldüğünde ikinci bir sınır devreye girer: taşıma katmanı. HTTP proxy yalnızca TCP taşır; UDP paketlerini iletmez. SOCKS5 protokolünde UDP ASSOCIATE komutu tanımlıdır ve UDP aktarımına izin verir, ancak birçok sağlayıcı bu özelliği kapalı tutar ve birçok istemci hiç talep etmez. Ayrıntı için SOCKS5 UDP desteği yazısına bakın.

Aynı sınır, modern web trafiğinin bir bölümünü de etkiler. HTTP/3 taşıma olarak QUIC kullanır ve QUIC UDP üzerinde çalışır. Yalnızca TCP taşıyan bir proxy arkasında istemci genellikle sessizce TCP tabanlı bir sürüme geri döner. Bu davranış çoğu zaman fark edilmez; yalnızca ölçüm yaparken beklenenden farklı bir performans tablosu olarak görünür.

Bu üç gerçeğin birleşimi şu anlama gelir: canlı yayın izlemek ya da yayın açmak, proxy kurulumunun en zayıf halkasıdır. Kural yalnızca TCP trafiğini yönlendirirken medya akışı başka bir yoldan gidebilir ve siz bunu arayüzde göremezsiniz.

Tarayıcı ile uygulama arasında hangi fark kalıyor?

Masaüstü tarayıcıda Likee içeriğine baktığınızda istekler klasik web trafiğine benzer: belge, betik, stil ve medya. Uygulama tarafında ise istemci kendi protokol tercihlerini uygular; sistem proxy ayarını yok sayıp doğrudan bağlanan uygulamalar yaygındır.

Bu yüzden mobil tarafta doğrulama daha önemlidir: kural tanımlandıktan sonra çıkış adresinin değiştiği, uygulamanın kendi arayüzünden değil harici bir kontrolle görülmelidir. Uygulama bazlı yönlendirme seçenekleri için SOCKS5 destekleyen uygulamalar yazısı işe yarar bir liste sunuyor.

İkinci fark, sertifika doğrulamasındadır. Tarayıcı, sertifika zincirini kendi güven deposuyla denetler ve bir uyumsuzlukta size görünür bir uyarı gösterir. Uygulamalar ise doğrulamayı sessizce yapar ve bir sorun varsa çoğu zaman yalnızca “bağlanılamadı” der. Araya giren bir kurumsal denetim katmanı varsa bu fark, tarayıcıda açıkça, uygulamada ise anlamsız bir hata olarak ortaya çıkar.

Aynı ekosistemdeki canlı yayın uygulaması için BIGO Live proxy sayfası yayın tarafındaki farkları ele alıyor.

Trafik ana alan adı, medya ve canlı kanal arasında nasıl bölünür?

Kısa video akışında baytların büyük çoğunluğu video ve kapak görseli indirmesinden gelir. Oturum istekleri, beğeni ve yorum çağrıları ise küçük ama sürekli bir trafiktir. Üçüncü kol, gerçek zamanlı bildirimler ve canlı yayın kanalıdır.

Bu dağılımın iki pratik sonucu vardır. Birincisi maliyet: hacim bazlı ücretlendirilen bir çıkış kullanıyorsanız faturanın büyük kısmını medya oluşturur. Hesaplama yöntemi için proxy bant genişliği hesaplama yazısına bakabilirsiniz. İkincisi kapsam: yalnızca ana alan adını yönlendiren bir kural, trafiğin küçük dilimini taşır ve büyük dilimi dışarıda bırakır.

Dağılımı kendi kullanımınız için ölçmek isterseniz basit bir yöntem yeterlidir: sabit bir süre boyunca normal kullanımınızı yapın ve proxy panelinizdeki hacim sayacını bu sürenin başında ve sonunda okuyun. Aynı ölçümü bir kez otomatik oynatma açıkken, bir kez kapalıyken tekrarladığınızda medya dilimin ağırlığı net biçimde ortaya çıkar.

Video önbelleğe alındığında aynı içerik ikinci kez indirilmez; önbellek temizlenmeden yapılan ölçümler bu yüzden yanıltıcıdır. Karşılaştırmalı testlerde her turdan önce önbelleği aynı biçimde sıfırlamak, sonucun tek anlamlı hâle gelmesini sağlar.