Letterboxd Proxy: Kapsam Farkı, Oturum Davranışı ve Araştırma Kurgusu

Letterboxd, film günlüğü tutmak ve liste paylaşmak üzerine kurulu bir topluluk sitesidir. Sayfaların büyük bölümü sunucu tarafında üretilen HTML olarak gelir, afişler ve arka plan görselleri ayrı bir görsel adresinden servis edilir, arama ve derecelendirme gibi işlemler arka planda küçük isteklerle yürür. Proxy kurarken bu üç akışın aynı kuralın içinde kaldığından emin olmanız gerekir.

Sitenin mobil uygulamaları da var ve buradaki davranış tarayıcıdan farklıdır. Bir mobil uygulama sistemin Wi-Fi proxy ayarını okuyabilir, kısmen okuyabilir ya da hiç okumayabilir; bu tamamen uygulamanın ağ yığınına bağlıdır. Aynı cihazda tarayıcı proxy üzerinden çıkarken uygulamanın doğrudan çıkması olağan bir durumdur ve kurulum hatası gibi görünmez.

Üçüncü konu araştırma tarafı. Bir dağıtımcı ya da ajans, bir filmin topluluk içindeki açık görünürlüğünü izlemek isteyebilir. Bu meşru bir iştir ve tek bir adresten yürütüldüğünde hız sınırlarına takılır; proxy burada yükü dağıtmak için kullanılır, kimlik üretmek için değil.

Hangi kurulum noktası hangi isteği gerçekten kapsıyor?

Kapsam sorusunu somutlaştırmanın yolu, istekleri sınıflara ayırıp her kurulum noktasının bu sınıfları ne ölçüde yakaladığını görmektir. Sayfa gövdesi, afiş dağıtımı, arka plan istekleri, oturum çerezi taşıyan çağrılar ve mobil uygulama trafiği birbirinden ayrı davranır.

Tarayıcı profiline yazılan bir ayar, o profilden çıkan her isteği kapsar ve mobil uygulamayla hiç ilgilenmez. İşletim sistemi ayarı masaüstündeki uygulamaları da içine alır, ama telefon tarafında karşılığı yoktur. Telefonun Wi-Fi ayarına yazılan proxy o ağdaki HTTP trafiğini kapsar; uygulama bu ayarı yok sayıyorsa ya da mobil veriye geçildiyse kapsam düşer.

Bu tabloyu bilmeden yapılan testler yanıltıcı sonuç verir. En sık rastlanan hata, telefonun tarayıcısında çıkış adresini doğrulayıp uygulamanın da aynı yoldan gittiğini varsaymaktır. Doğrulamayı istemci bazında yapın: her istemci için ayrı bir kontrol turu geçin.

Giriş sonrası kimlik nerede duruyor, IP neyi değiştiriyor?

Letterboxd’a giriş yaptığınızda tarayıcınıza bir oturum çerezi yazılır ve sonraki isteklerde bu çerez gönderilir. Sunucu sizi bu çerezle tanır. Çıkış IP’si değiştiğinde çerez yerinde kaldığı için oturum kendiliğinden kapanmaz; sunucu açısından fark eden yalnızca paketin hangi çıkıştan geldiğidir.

Bu, proxy’nin sınırını gösteren en açık örnektir. Adres değişir ama tarayıcının gönderdiği dil listesi, saat dilimi, ekran ölçüleri ve sürüm bilgisi aynı kalır. Çıkışı başka bir kıtaya alıp diğer her şeyi olduğu gibi bırakırsanız ortaya kendi içinde çelişen bir profil çıkar. Amacınız yalnızca erişim ise bu bir sorun değildir; amacınız bir bölgenin görünümünü doğru yansıtmaksa profili bütün olarak kurmanız gerekir.

Uzun süren çalışmalarda sticky pencere kritik hale gelir. Bir liste düzenlerken ya da toplu bir günlük girişi yaparken adresin ortada değişmesi, isteklerin bir kısmının başka bir ülkeden gitmesine yol açar. Gateway mimarisinde sticky genellikle ayrı bir port ya da kullanıcı adına eklenen bir oturum kimliğiyle verilir ve süre dolduğunda uyarı almazsınız (gateway mimarisi).

Kimlik doğrulama yönteminiz de bu resme dahildir. IP whitelist sabit hatlı bir ofiste pratiktir, dinamik IP alan bir kullanıcıda hat yenilendiğinde erişim kopar ve bunu 407 yanıtı olarak görürsünüz. Kullanıcı adı–parola her yerden çalışır ama paylaşılabilir bir sırdır (kimlik doğrulama yöntemleri).

Tarayıcı ile mobil uygulama arasındaki gerçek fark nedir?

Tarayıcıda tüm istekler tek bir ağ motorundan geçer, bu yüzden bir kural yazdığınızda sonucu öngörebilirsiniz. Mobil uygulamada durum farklıdır: uygulama kendi ağ kitaplığını kullanır ve sistem proxy ayarını okuyup okumaması bir tasarım tercihidir. Okumadığı durumda trafiğin doğrudan çıkması bir arıza değil, beklenen davranıştır.

İkinci fark taşıma protokolündedir. HTTP proxy’nin açtığı tünel yalnızca TCP taşır; UDP üzerinden çalışan modern taşıma katmanları bu tünele girmez, ya doğrudan çıkar ya da UDP kapalıysa TCP’ye geri düşer. SOCKS5 tarafında UDP ASSOCIATE yöntemi UDP taşıyabilir, ancak bunu kullanan mobil istemci sayısı azdır (SOCKS5 UDP desteği).

Üçüncü fark ayarın ömrüdür. Telefondaki proxy tanımı bir ağa bağlıdır: başka bir Wi-Fi ağına geçtiğinizde ya da mobil veriye düştüğünüzde devre dışı kalır. Cihazınız arka planda ağ değiştirdiğinde bunu fark etmezsiniz; bu yüzden telefonda yapılan uzun testlerde çıkışı arada bir yeniden doğrulamak gerekir. Kurulum adımları için iPhone proxy ayarları ve Android proxy ayarları.

• Her istemciyi ayrı doğrulayın: masaüstü tarayıcı, telefon tarayıcısı ve uygulama.
• Telefonda test ederken mobil veriyi kapatın; aksi halde ağ sessizce değişebilir.
• Uygulama sistem ayarını okumuyorsa uygulama bazlı yönlendirmeye bakın.
• Aynı anda hem VPN hem proxy çalıştırmayın; hangisinin etkili olduğunu ayırt edemezsiniz.

Sticky mi, rotating mi? Kararı hangi ölçüt verir?

Bu soru genellikle yanlış yerden sorulur. Doğru ölçüt “hangisi daha iyi” değil, “işiniz oturum taşıyor mu” sorusudur. Oturum taşıyan her işte adres sabitliği kazanır; oturum taşımayan, herkese açık sayfaların okunduğu işlerde çeşitlilik ve kapasite kazanır.

Sticky bir çıkış, aynı adresin belirli bir pencere boyunca korunması demektir. Giriş yapılmış bir hesapla çalışırken bu, isteklerin tek bir yerden geldiği tutarlı bir tablo üretir. Rotating çıkış ise her istekte ya da belirli aralıklarla adresi değiştirir; tek bir adres üzerindeki yükü dağıttığı için hız sınırına takılma olasılığını düşürür (rotating ile statik proxy farkı).

Havuzun genişliği kadar dağılımı da önemlidir: adreslerin hepsi aynı alt ağdan geliyorsa çeşitlilik kâğıt üzerinde kalır. Bu konuyu subnet çeşitliliği yazısı açıklıyor; havuzun nasıl yönetildiği ise proxy havuzu nedir yazısında.