Lemmy Proxy Kullanımı: Sunucu Yığını, Moderasyon ve Oturum

Lemmy, gönderilerin topluluklar altında toplandığı ve oylamayla sıralandığı bir bağlantı paylaşım ağıdır. Mimarisi ActivityPub üzerine kuruludur: her sunucu kendi veritabanını tutar, uzak sunucularla mesajlaşarak içerik kopyalarını senkronize eder. Kullanıcı olarak siz her zaman kendi sunucunuzla konuşursunuz.

Bu yapı, proxy kararını iki ayrı soruya böler. Birincisi, sizin istemcinizden çıkan trafiğin nereye gittiği; ikincisi, sunucular arası federasyon trafiğinin nereden geçtiği. İkincisi kullanıcının proxy ayarıyla ilgisizdir ve bu ayrımı bilmemek gereksiz beklentilere yol açar.

Aşağıda önce yığını katmanlarına ayırıyor, sonra bildirim mekanizması, moderasyon görünürlüğü, hesap güvenliği ve kurulum başlıklarına geçiyoruz.

Lemmy trafiği hangi katmanlardan geçer?

Tarayıcıda gördüğünüz arayüz, sunucudan indirilen bir istemci uygulamasıdır. Bu uygulama içeriği doğrudan veritabanından değil, sunucunun uygulama programlama arayüzünden alır; çağrılar /api/ altındaki sürümlü yollara gider ve JSON döner. Üçüncü taraf mobil istemciler de aynı yolları kullanır, yalnızca arayüzü kendileri çizer.

Bir alt katmanda sunucu süreci vardır. Gelen isteğin kimlik bilgisini doğrular, veritabanına yazar ve gerekirse federasyon işini kuyruğa alır. En alttaki katman, sunucular arası mesajlaşmayı yürüten federasyon katmanıdır; burada konuşma sizin istemcinizle değil, iki sunucu arasında geçer.

Proxy yalnızca en üstteki iki katmanı kapsar: tarayıcınızdan ya da istemcinizden sunucuya giden bağlantıyı. Sunucunuzun uzak sunucularla kurduğu bağlantı sizin çıkışınızı kullanmaz. Bu yüzden bir uzak topluluğa erişemiyorsanız ve sorun federasyon tarafındaysa, proxy değiştirmek sonucu değiştirmez; çözüm sunucu yöneticisinin tarafındadır.

Ayrım pratikte şöyle kontrol edilir: aynı içeriği kendi sunucunuz üzerinden göremiyor ama başka bir sunucunun web arayüzünden görebiliyorsanız, mesele ağ erişiminiz değil federasyon durumudur. Aksine her iki sunucu da açılmıyorsa mesele sizin ağınızdadır ve proxy kontrol aracı ile uç noktanın canlılığına bakmak ilk adımdır.

Bildirimler nasıl geliyor: kalıcı kanal mı, yoklama mı?

Lemmy’nin erken sürümleri istemciye kalıcı bir WebSocket kanalı sunuyordu; arayüz yeni yorumları ve oyları bu kanaldan anlık alıyordu. Proje bu arayüzü daha sonra kaldırdı ve istemcileri sürümlü HTTP çağrılarına yönlendirdi. Bugün yaygın kurulumda arayüz, okunmamış bildirim sayısını düzenli aralıklarla soran bir yoklama döngüsü çalıştırır.

Bu değişimin proxy tarafında iki sonucu vardır. Birincisi olumludur: kalıcı bağlantı olmadığı için tünelin boşta kalma zaman aşımına takılma sorunu ortadan kalkar. Uzun süre açık kalan bir sekmede bağlantının sessizce kopması ve bildirimlerin durması beklenmez.

İkincisi dikkat gerektirir: yoklama, düzenli aralıklarla tekrarlanan ayrı ayrı isteklerdir. Uzun süre açık bırakılan çok sayıda sekme ya da istemci, tek bir çıkış adresinden sürekli istek üretir. Sunucu tarafındaki adres başına eşikler bu birikimi görebilir. Birden fazla oturumu aynı anda açık tutuyorsanız, kullanmadıklarınızı kapatmak hem sunucuyu hem kendi bağlantı havuzunuzu rahatlatır.

Bağlantı yeniden kullanımı burada işe yarar. Yoklama istekleri aynı bağlantı üzerinde tekrar kullanılabiliyorsa her seferinde yeni bir el sıkışma maliyeti ödenmez. Proxy tarafında bu davranışın nasıl korunduğunu keep-alive ve bağlantı havuzu yazısı açıklıyor.

Moderasyon kararları ve bölgesel görünürlük teknik olarak ne anlama gelir?

Lemmy’de içerik üzerinde iki farklı işlem vardır ve karıştırılmaları sık görülür. Topluluk moderatörünün ya da sunucu yöneticisinin yaptığı kaldırma işlemi, içeriği yerel sunucuda görünmez kılar. İçeriği yazan kişinin yaptığı silme işlemi ise kaydı sahibi tarafından geri çeker. İkisi de federasyonla uzak sunuculara bildirilir, ancak uzak sunucunun bu bildirimi uygulaması kendi yapılandırmasına bağlıdır.

Buradan çıkan sonuç önemlidir: bir gönderi sizin sunucunuzda görünmüyor olabilir ama başka bir sunucuda hâlâ duruyor olabilir. Bu, bir hata değil federasyonun doğal sonucudur. Proxy bu tabloyu değiştirmez; farklı bir çıkıştan bağlanmak yerel moderasyon kararını ortadan kaldırmaz, çünkü karar adresinize değil içeriğe uygulanmıştır.

Sunucu düzeyinde de kısıtlar vardır. Bir sunucu, başka bir sunucuyla federasyonu tamamen kesebilir ya da yalnızca belirli sunucularla konuşacak biçimde yapılandırılabilir. Bu tercihler yönetim kararıdır ve dışarıdan değiştirilemez. Bir topluluğa erişmek istiyor ama kendi sunucunuz o sunucuyla konuşmuyorsa, doğru yol ilgili sunucuda hesap açmak ya da yöneticiyle iletişime geçmektir.

Bölgesel görünürlük ise üçüncü bir başlıktır ve genellikle platformun değil ağın kararıdır: bazı ülkelerde belirli alan adlarına erişim sağlayıcı düzeyinde kısıtlanabilir. Bu durumda gördüğünüz şey bir moderasyon kararı değil, bir ağ erişim sorunudur; ikisini ayırt etmek için aynı adresi farklı bir ağdan denemek yeterlidir.

Bir gönderi yerel ve uzak sunucular arasında nasıl ilerler?

Gönderi oluşturduğunuzda kayıt önce kendi sunucunuzun veritabanına yazılır. Bu adım tamamen yereldir ve sizin çıkış adresinizden gelen bir istekle tetiklenir. Ardından sunucunuz, bu gönderiyi takip eden uzak sunuculara bir federasyon mesajı gönderir; bu mesaj sunucudan sunucuya gider.

Uzak sunucu mesajı aldığında kendi kopyasını oluşturur. Artık iki kayıt vardır: sizin sunucunuzdaki asıl kayıt ve uzak sunucudaki kopya. Yerel moderasyon kararı asıl kayda uygulanır ve kopyaya bildirilir; uzak sunucunun kendi moderasyon kararı ise yalnızca kendi kopyasını etkiler.

Bu iki şeritli yapıyı anlamak sorun gidermeyi kolaylaştırır. Gönderiniz kendi sunucunuzda görünüyor ama uzak toplulukta görünmüyorsa sorun federasyon teslimindedir; gecikme, kuyruk birikmesi ya da sunucular arası bir kesinti olabilir. Kendi sunucunuzda bile görünmüyorsa sorun istek tarafındadır ve proxy yapılandırmanızla ilgili olabilir.

Federasyon tesliminin sizin proxy’nizle ilgisi olmadığını hatırlamak, boşa giden denemeleri önler. Çıkış değiştirerek bir federasyon gecikmesini düzeltemezsiniz.

Çıkış kararında hangi etken ne kadar ağırlık taşır?

Lemmy kullanımında çıkış seçimini belirleyen etkenler, görsel ağırlıklı platformlardan farklıdır. Trafiğin büyük bölümü metindir; büyük medya aktarımı görece azdır. Bu yüzden bant genişliğinden çok kararlılık ve tutarlılık öne çıkar.

En yüksek ağırlık oturum sabitliğindedir. Jeton taşıyan bir oturumun adres değiştirmesi gereksiz sürtünme yaratır. Hemen ardından çıkış ülkesinin tutarlılığı gelir: sunucunuzun barındığı bölgeye göre bağlantı gecikmesi ve bölgesel erişim davranışı değişebilir. Üçüncü sırada eşzamanlı bağlantı payı vardır; yoklama yapan çok sayıda sekme tek adresten birikir. En düşük ağırlık rotasyon ihtiyacındadır: oturumlu kullanımda rotasyon bir avantaj değil, bir sorun kaynağıdır.

Bu sıralama, ürün seçimini doğrudan belirler. Sabitlik öncelikliyse ISP proxy ya da sabit uçlu bir residential çıkış uygundur. Yalnızca herkese açık gönderileri okuyan, giriş yapmayan bir araştırma işi yürütüyorsanız datacenter proxy daha ekonomik ve yeterlidir. Rotasyonun ne zaman anlamlı olduğunu rotating ve statik proxy farkı yazısı ayrıntılandırıyor.

Protokol tarafında ise seçim istemciye bağlıdır. Tarayıcı kullanıyorsanız HTTP proxy yeterlidir; masaüstü ya da komut satırı aracı kullanıyorsanız SOCKS5 daha geniş uyum sağlar.