Bluesky Proxy Kullanımı: XRPC, Akış Bağlantısı ve Çıkış Kararı

Bluesky istemcisi ekranda tek bir uygulama gibi görünür, ancak arkasındaki protokol işi üç ayrı role böler: hesabınızın verisini tutan sunucu, ağdaki değişiklikleri toplayan aktarım katmanı ve akışı okunabilir hâle getiren dizinleme katmanı. Proxy tanımladığınızda bu rollerin hepsi aynı kuralın içine girmeyebilir.

Pratik sonuç şudur: tarayıcıda proxy açıp oturum açabiliyor ama zaman tüneli boş kalıyorsa, sorun genellikle kimlik doğrulamada değil, dizinleme katmanına giden sorguların kural dışında kalmasındadır. Aynı biçimde, bir masaüstü aracı ile canlı akış dinlerken bağlantının düzenli aralıklarla kopması çoğunlukla proxy’nin boşta kalan tünelleri kapatmasıyla ilgilidir.

Aşağıdaki bölümler önce bu yapıyı çözüyor, ardından çıkış türü seçimi, akış bağlantısı, oran sınırı davranışı ve kurumsal ağ kısıtlarına geçiyor.

Bir Bluesky oturumu hangi uç noktalara dağılır?

AT Protocol’de hesabınız bir kişisel veri sunucusunda (PDS) barınır. Oturum açma, gönderi yazma, takip listesini değiştirme gibi yazma işlemleri doğrudan bu sunucuya gider. Varsayılan kurulumda bu sunucu Bluesky’nin kendi barındırdığı alan adıdır; kendi sunucusunu işleten kullanıcılarda ise tamamen başka bir alan adıdır. Proxy kuralınızı yalnızca uygulamanın açıldığı alan adına göre yazarsanız, kendi sunucusunu kullanan bir hesapta yazma istekleri kuralın dışında kalabilir.

Zaman tünelini, arama sonuçlarını ve profil sayfalarını dolduran okuma sorguları ayrı bir dizinleme katmanından gelir. Bu katman ağdaki gönderileri toplayıp sorgulanabilir hâle getirdiği için istemcinin en yoğun konuştuğu taraf genellikle burasıdır. Görseller ve bağlantı önizlemeleri ise üçüncü bir yoldan, statik dosya servisinden iner.

Tüm bu çağrılar ortak bir çağrı biçimini kullanır: HTTPS üzerinden /xrpc/ ile başlayan yollar ve nokta ile ayrılmış ad alanları. Yani protokol tarafında tek bir düzen vardır, ancak bu düzen birden fazla ana bilgisayar adına dağılmıştır. Proxy tarafında doğru davranış, uygulamayı çalıştıran süreci bütünüyle yönlendirmek ya da tüm ilgili alan adlarını kapsayan bir kural yazmaktır.

Kimlik, alan adı doğrulaması ve DNS’in rolü

Bluesky’de kullanıcı adı bir alan adı biçimindedir ve arka planda kalıcı bir tanımlayıcıya bağlanır. Kendi alan adınızı kullanıcı adı olarak bağlamak istediğinizde doğrulama iki yoldan biriyle yapılır: alan adınıza bir TXT kaydı eklemek ya da sunucunuzda belirli bir yolda küçük bir metin dosyası yayımlamak. Her iki yöntem de doğrulama anında sizin ağınızdan değil, platform tarafından çözümlenir.

Buna karşılık istemcinin gördüğü alan adı çözümlemesi sizin tarafınızda gerçekleşir ve proxy kurulumunda en çok gözden kaçan nokta budur. HTTP proxy kullanıyorsanız istek satırında ana bilgisayar adı proxy’ye iletilir ve çözümleme çoğunlukla proxy tarafında yapılır. SOCKS5’te ise iki farklı davranış vardır: istemci adı kendisi çözüp IP gönderebilir ya da adı olduğu gibi proxy’ye bırakabilir. Birincisinde gerçek DNS sunucunuz hangi ana bilgisayara gittiğinizi görür.

Bu farkın ne anlama geldiğini ve istemci tarafında nasıl ayarlanacağını SOCKS5’te DNS nerede çözülür yazısı adım adım açıklıyor. Kurulumdan sonra çözümlemenin gerçekten beklediğiniz tarafta yapıldığını bir sızıntı testiyle doğrulayın; istemcinin ayar ekranında yazan değer ile ağda gözlenen davranış her zaman örtüşmez.

Bir uyarı: alan adı doğrulaması yaparken proxy’yi kapatmanız gerekmez, çünkü doğrulamayı platform yapar. Ancak kendi alan adınızın DNS kayıtlarını yönetirken bulunduğunuz ülkeye göre farklı yanıt veren bir yönlendirme kullanıyorsanız, kaydın yayılıp yayılmadığını kontrol ederken çıkış ülkenizi sabit tutun; aksi hâlde kayıt yayılmış olsa bile her denemede farklı bir sonuç görürsünüz.

Hangi çıkış türü hangi Bluesky işine oturur?

Çıkış türü kararı, işin oturum taşıyıp taşımadığına ve ne kadar uzun sürdüğüne göre değişir. Herkese açık gönderileri okuyan, giriş yapmayan bir çalışma için kararlılık ve bant genişliği önceliklidir; burada datacenter proxy çoğu kurulumda fazlasıyla yeterlidir ve maliyeti en düşük seçenektir.

Giriş yapılan istemci kullanımında tablo değişir. Oturum jetonu taşıyan bir istemcinin kısa aralıklarla farklı ülkelerden görünmesi tutarsız bir tablo üretir ve gereksiz yeniden doğrulama adımlarına yol açabilir. Bu senaryoda sabit çıkışlı bir ISP proxy ya da sabit uçlu bir residential çıkış daha öngörülebilir davranır. Mobil çıkış, uygulamanın telefondan kullanıldığı durumları yeniden üretmek istediğinizde anlamlıdır; operatör ağı çok sayıda aboneyi aynı adres havuzunun arkasında topladığı için oradaki çıkış doğası gereği paylaşımlıdır ve tek bir kullanıcıya ait değildir.

Uzun süreli akış dinleme, üçüncü bir kategoridir. Burada asıl belirleyici IP’nin türü değil, bağlantının saatlerce ayakta kalabilmesidir. Sık rotasyon yapan bir havuz bu iş için uygun değildir; her rotasyon açık tüneli kopardığı için akışta boşluk oluşur. Bunun yerine sabit bir uç nokta seçin ve adres değişimini yalnızca bağlantı gerçekten koptuğunda, tercihen yeniden bağlanma mantığının içinden devreye alın.

Maliyet tarafında da sıralama nettir: veri merkezi çıkışları en ucuz, ev ve operatör çıkışları daha pahalıdır. İş herkese açık veri okumaktan ibaretse pahalı çıkış almanın bir karşılığı yoktur.

Protokol bileşenleri arasında proxy nereye oturur?

Proxy, istemci ile ağ arasındaki ilk durakta oturur. Yani PDS’e giden yazma isteği de, dizinleme katmanına giden okuma sorgusu da aynı çıkıştan görünür. Ağın kendi içindeki sunucudan sunucuya trafiği ise sizin proxy’nizle ilgisizdir; bir gönderinin ağda dolaşması sizin çıkışınızdan geçmez.

Bu ayrım iki yaygın yanlış beklentiyi ortadan kaldırır. Birincisi, proxy kullanmak gönderinizin ağda kimlere ulaşacağını değiştirmez; dağıtım tamamen protokol tarafında karar verilir. İkincisi, proxy kullanmak bağlantıyı hızlandırmaz. Aksine araya bir durak daha girdiği için gecikme genellikle artar. Tek istisna, varsayılan rotanın dolambaçlı olduğu ve proxy çıkışının hedefe daha doğrudan bağlandığı nadir durumlardır; bu bir kural değildir ve satın alma gerekçesi yapılmamalıdır.

Kurulum yeri kararında da aynı mantık geçerlidir. Tarayıcıda tanımlanan bir kural yalnızca o tarayıcıyı etkiler; masaüstü istemcisi ya da komut satırı aracı kendi bağlantısını açar ve o kuralı görmez. Sistem geneli ayar en geniş kapsamı verir ama tüm uygulamaları etkiler. Ara çözüm, işletim sistemi düzeyinde uygulama bazlı yönlendirmedir; hangi aracın kendi proxy alanına sahip olduğunu, hangisinin sistem ayarını izlediğini kurulum ekranlarından tek tek görmek, sorunu sonradan aramaktan çok daha hızlı sonuç verir.

Kurulum bittiğinde çıkışın gerçekten değiştiğini IP adresim aracıyla doğrulayın. Tarayıcı değişmiş ama istemci değişmemişse, iki farklı sonuç görürsünüz ve sorunun nerede olduğu hemen anlaşılır.