Xiaohongshu Proxy: Kapsam Farkı, Süreklilik ve Paylaşımlı Erişim

Xiaohongshu tarafında proxy kurulumu iki ayrı işe bölünür. Tarayıcıdan çalışıyorsanız kural öngörülebilir davranır: tek bir ağ motoru vardır, istekler oradan geçer. Mobil uygulamadan çalışıyorsanız durum değişir, çünkü uygulamanın kendi ağ yığını devrededir ve bu yığının sistem ayarını ne kadar dikkate alacağı uygulamanın tasarımına bağlıdır.

İkinci ayrım süreklilikte ortaya çıkar. Akış ve arama istekleri kısa ömürlüdür; bildirim ve gerçek zamanlı güncelleme kanalı ise açık kalmak ister. Kısa isteklerde sorunsuz görünen bir çıkış, uzun ömürlü bağlantıda boşta kalma süresi nedeniyle düşebilir.

Üçüncüsü ekip boyutudur. Tek kişilik kullanımda proxy bir ayardır; bir ajansta aynı çıkışı birden fazla kişi kullandığında erişim yönetimi, limit planlaması ve kayıt tutma işin parçası hâline gelir.

Aynı içerik, iki ayrı istemci: uygulama ve tarayıcı

Xiaohongshu içeriği hem mobil uygulamada hem web arayüzünde görünür, ancak iki istemci aynı isteği aynı yoldan göndermez. Tarayıcıda bütün istekler tek bir ağ motorundan çıkar; proxy ayarını nereye yazdıysanız kapsam oradan belirlenir. Mobil uygulamada ise ağ çağrılarını uygulamanın kendi kütüphanesi yönetir ve bu kütüphanenin sistem ayarını okuyup okumayacağı garanti değildir.

Bu fark yüzünden aynı çıkış iki istemcide farklı sonuç verebilir. Tarayıcıda beklediğiniz bölgesel görünümü alırken uygulamada almamanız olağandır: uygulama isteği proxy’ye hiç uğramadan çıkmış olabilir. Doğrulamayı uygulamanın içinden değil, aynı cihazın tarayıcısından IP adresim ile yapın; uygulama size yalnızca içerik gösterir, çıkış adresini göstermez.

Neyi nerede tanımlarsınız?

Masaüstünde üç yer vardır: işletim sistemi ayarı, tarayıcı profili ve uygulama bazlı yönlendirme. Mobilde pratikte tek yer vardır: bağlı olduğunuz Wi-Fi ağının proxy alanı. Bu alan yalnızca o ağda geçerlidir, mobil veriyi kapsamaz ve başka bir ağa geçtiğinizde devre dışı kalır. Adımlar için iPhone ve Android proxy ayarları yazıları.

Mobil uygulamada proxy kuralı nerede biter?

Wi-Fi ayarındaki HTTP proxy alanı, sistemin uygulamalara bildirdiği bir tercihtir; zorlayıcı bir yönlendirme değildir. Uygulama bu tercihi okumayı seçerse istekler proxy’ye gider, okumazsa doğrudan çıkar. Aradaki fark kullanıcıya bildirilmediği için, kurulumun çalıştığını varsaymak en sık yapılan hatadır.

İkinci sınır taşıma protokolüdür. HTTP proxy’nin CONNECT yöntemi yalnızca TCP taşır. Modern istemcilerin bir kısmı UDP 443 üzerinde QUIC kullanır ve bu trafik CONNECT tüneline girmez; ya doğrudan çıkar ya da UDP yolu kapalıysa TCP’ye geri düşer. SOCKS5’in UDP ASSOCIATE yöntemi UDP taşıyabilir, ancak bunu kullanan mobil istemci sayısı sınırlıdır (SOCKS5 UDP desteği).

Üçüncü sınır sertifika tarafındadır. Uygulamalar sunucu sertifikasını kendi listesine sabitleyebilir. Böyle bir uygulamada araya giren ve TLS oturumunu kendi sertifikasıyla kuran bir nokta varsa bağlantı kurulmaz; tarayıcıdaki gibi bir uyarı ekranı da çıkmaz, istek sessizce başarısız olur. Doğru kurulmuş bir proxy zaten oturuma karışmaz (HTTP CONNECT metodu).

Web istemcisinde kapsamı doğru çizmek

Tarayıcı tarafında kurulum daha öngörülebilir olsa da kapsam kararı yine size aittir. Sistem geneli ayar bütün uygulamaları etkiler; bu en geniş kapsamdır ve aynı makinedeki diğer işlerinizi de proxy’ye sokar. Tarayıcıya özel profil yalnızca o profili etkiler ve günlük işinizi bozmaz, buna karşılık kapsamı siz daraltmış olursunuz.

Daraltılmış kapsamda en sık atlanan şey statik varlık adresleridir. Arayüz açılır, metin gelir, görseller boş kalır. Kuralınızı yazarken yalnızca ana alan adını değil, içerik servis eden alt alan adlarını da kapsayın. Yapılandırma biçimi tarayıcıya göre değişir (Edge, Opera).

Protokol tarafında tarayıcı işlerinde hem HTTP hem SOCKS5 çalışır. Aradaki en görünür fark alan adı çözümünün nerede yapıldığıdır; SOCKS5’te bu davranış istemciye bağlıdır ve ayrımı SOCKS5’te DNS nerede çözülür yazısı açıklıyor. Kurulum sonrası çözümünüzün sızmadığını DNS leak testi ile doğrulayın.

Son olarak bir profilde birden fazla katman çalıştırmayın. Aynı anda hem sistem VPN’i hem tarayıcı proxy’si açıksa hangi katmanın hangi isteği taşıdığını ayırt edemezsiniz; sorun çıktığında ölçüm yapacak zemin kalmaz.

Bildirim kanalı ve uzun ömürlü bağlantı davranışı

Akış ve arama istekleri kısa ömürlüdür: açılır, yanıt alınır, kapanır. Bildirim ve gerçek zamanlı güncelleme tarafı ise farklı çalışır; istemci bir bağlantıyı açık tutar ve sunucu veri geldikçe aynı kanaldan gönderir. Tarayıcıda bu genellikle bir Upgrade el sıkışmasıyla kurulan WebSocket bağlantısı ya da uzun ömürlü bir akış isteğidir.

Proxy tarafında kritik nokta şudur: açık ama sessiz bir bağlantı, birçok yapılandırmada boşta sayılır ve bir süre sonra kapatılır. Kısa isteklerde hiç sorun çıkarmayan bir çıkış, bu yüzden bildirimlerde gecikme veya kopma üretebilir. Belirti tipiktir: sayfa çalışır, ama yenilemeden yeni içerik düşmez. Mekanizma WebSocket ve proxy yazısında ayrıntılı.

İkinci risk kesinti anındadır. Bağlantı düştüğünde istemci yeniden bağlanır; bu sırada çıkış adresiniz değişmişse kanal başka bir adresten kurulur. Oturum aynı kalır, yalnızca görünen konum kayar. Sticky pencereyi çalışma sürenizden geniş tutmak bu kaymayı önler (rotasyon ayarları).

Pratik öneri: uzun ömürlü kanal kullanan bir arayüzü test ederken sekmeyi en az on beş dakika açık bırakın ve sonra yeni bir bildirim gelip gelmediğine bakın. İlk otuz saniyede yapılan test bu sorunu hiçbir zaman göstermez.