Substack Proxy Kurulumu: Yayın Adresi, Canlı Kanal ve Oran Sınırı

Substack ile proxy arasındaki ilişkiyi kuran ilk gerçek şudur: okuduğunuz yayın çoğu zaman tek bir merkezî alan adında durmaz. Yazarın kendi alan adını bağladığı bir yayın tarayıcınıza tamamen farklı bir ana bilgisayar adıyla gelir; görseller ve ek dosyalar ayrı bir dağıtım ağından, gönderilerin e-posta kopyası ise tarayıcınızın hiç görmediği bir kanaldan iletilir.

Bu dağınıklık kurulum sırasında doğrudan hissedilir. Yalnızca ana alan adını kapsayan bir uzantı kuralı yazdıysanız arayüz açılır, ama özel alan adına taşınmış yayınlar kapsam dışında kalır ve o istekler sizin gerçek çıkışınızdan gider. Sonuç, yarısı yönlendirilmiş bir oturumdur.

İkinci gerçek proxy’nin ne olmadığıyla ilgilidir. Proxy çıkış adresinizi değiştirir; abonelik çerezinizi, tarayıcı sürümünüzü, dil tercihinizi veya e-posta adresinizi değiştirmez. Ücretli bir yayına erişiminiz aboneliğinize bağlıdır, bağlandığınız ülkeye değil.

Bir Substack yayını kaç ayrı adrese bağlanır?

Bir gönderiyi açtığınızda istemciniz en az üç farklı yere konuşur. Birincisi yayının barındığı ana bilgisayar adıdır: bu ya platformun alt alan adı ya da yazarın bağladığı özel alan adıdır. İkincisi hesabınızı ve abonelik durumunuzu taşıyan oturum katmanıdır. Üçüncüsü kapak görselleri, gömülü ses ve video dosyalarını servis eden dağıtım ağıdır; sayfanın metninden kat kat büyük hacmi bu üçüncü grup üretir.

Özel alan adı bu tablonun en çok gözden kaçan parçasıdır. Aynı platformda barınan iki yayından biri platform alt alan adında kalmışsa, diğeri yazarın kendi alan adına taşınmışsa, alan adı temelli bir proxy kuralı yalnızca birini kapsar. Kuralınızı yayın listesine göre değil, tarayıcı profilinin tamamına göre kurmak bu sorunu kökten kaldırır.

Gönderilerin e-posta kopyası bambaşka bir yoldan gelir. Posta kutunuza düşen bülteni okurken tarayıcı proxy ayarınız devrede değildir; posta istemciniz kendi bağlantısını kurar ve o bağlantı ancak istemci düzeyinde yapılandırılırsa yönlendirilir. Protokol tarafındaki ayrım burada belirleyicidir: posta istemcisi kendi bağlantı ayarlarını okur ve tarayıcıya tanımladığınız kural bu trafiği hiç görmez.

Alan adı çözümü nerede yapılıyor?

HTTP proxy kullanıyorsanız istemci hedefi CONNECT ornek.example:443 satırıyla bildirir ve çözümü proxy üstlenir. SOCKS5’te karar istemciye aittir: bazı istemciler adresi kendi ağında çözüp proxy’ye yalnızca IP verir, bazıları alan adını proxy’ye bırakır (socks5h). Fark özel alan adlarında keskinleşir, çünkü çözüm sizin ağınızda yapılırsa hangi yayını okuduğunuz yerel DNS sunucunuza görünür. Ayrıntı: SOCKS5’te DNS nerede çözülür.

Kurumsal ağ ve okul ağında erişim neden tutarsız?

Kurum ağları erişimi genellikle alan adı listeleriyle veya kategori etiketleriyle yönetir. Substack yayınlarının bir kısmı özel alan adında yaşadığı için tek bir kategori kuralı hepsini aynı biçimde yakalayamaz: bir yayın açılırken bir diğeri bağlantı hatası verir. Kullanıcı bunu platform arızası sanır, oysa listeleme farkıdır.

İkinci mekanizma TLS el sıkışmasındaki sunucu adı göstergesidir. Filtre, şifreli trafiği açmadan da hedef ana bilgisayar adını görebilir ve bağlantıyı el sıkışma aşamasında düşürebilir. Belirti tipiktir: sayfa hiç yüklenmeden bağlantı sıfırlanır, hata mesajı sunucudan değil ağdan gelir.

Üçüncüsü TLS denetimidir. Kurum ağı trafiği kendi sertifikasıyla açıp yeniden şifreliyorsa tarayıcıda sertifika uyarısı görürsünüz. Kurum cihazında bu bilinçli bir politika olabilir; tanımadığınız bir ağda ise durmanız gereken bir işarettir. Konunun ayrımı proxy ve TLS sertifika doğrulama yazısında ele alınıyor.

Bu üç durumda da proxy sihirli bir anahtar değildir; yalnızca çıkışınızı başka bir noktaya taşır. Kurum ağı proxy portlarını da kapatıyorsa bağlantı hiç kurulamaz. Kendi cihazınızda ve kendi hattınızda çalışıyorsanız SOCKS5 çıkışı genellikle daha az kural gerektirir; okul ve işyeri ağlarındaki genel davranış için ağ engelleri yazısı iyi bir başlangıçtır.

Okuma, arşiv taraması ve ekip erişimi için çıkış türü

Substack işleri üç kabaca farklı profile ayrılır ve her biri farklı bir çıkış ister. Kendi aboneliğinizle gönderi okumak en hafif senaryodur: metin ağırlıklıdır, oturum sabit kalmalıdır, hacim düşüktür. Yayın arşivlerini ölçekli okumak bunun tersidir: oturum gerekmez ama istek sayısı yüksektir. Üçüncüsü, birden fazla editörün aynı yayını yönettiği ekip kullanımıdır; orada çıkışın öngörülebilir olması hızdan önce gelir.

Tablodaki en sık hata son satırda yapılır: ekipler çıkışı kişiye bağlar. İki editör iki ayrı ülkeden aynı yayına girdiğinde tablo tutarsız görünür. Çıkışı hesaba bağlamak, yani herkesin aynı sabit adresten geçmesi daha sade bir iz bırakır. Bu yaklaşımın genel çerçevesi sosyal medya yönetimi için proxy sayfasında anlatılıyor.

Çıkışın kaç kişiyle paylaşıldığı da türden az önemli değildir. Paylaşımlı bir havuzda adresin geçmişi sizin oturumunuza da yansır; farkı paylaşımlı ve özel proxy yazısı açıklıyor.

Chat, Notes ve bildirimler açık bağlantıda nasıl taşınır?

Bir arayüzde mesajın anında görünmesi iki yoldan biriyle olur: ya istemci kısa aralıklarla sunucuyu yoklar ya da bir kez kurulan bağlantıyı açık tutar. İkinci yol web tarafında genellikle WebSocket ile kurulur ve normal bir HTTPS isteği gibi başlayıp Upgrade başlığıyla kalıcı bir kanala dönüşür.

Proxy açısından kritik ayrım şudur: wss:// bağlantısı zaten bir CONNECT tüneli içinde kurulduğu için proxy tünelin içindeki yükseltmeyi görmez ve sorun çıkmaz. Düz ws:// bağlantısında ise proxy yükseltme başlığını anlamak zorundadır; eski veya kısıtlı yapılandırılmış bir proxy bunu reddedebilir. Mekanizma WebSocket ve proxy yazısında adım adım anlatılıyor.

İkinci risk boşta kalma zaman aşımıdır. Açık kalan bir kanal dakikalarca veri taşımayabilir; araya giren proxy bunu ölü bağlantı sayıp kapatırsa arayüz sessizce güncellenmeyi bırakır. Belirti hata mesajı değildir, "yeni mesaj gelmiyor" hissidir. Sayfayı yenilemek geçici olarak düzeltir. Bağlantı ömrü ayarları için keep-alive ve bağlantı havuzu yazısına bakın.

Üçüncüsü rotasyondur. Her istekte adres değiştiren bir rotating proxy uzun ömürlü bir kanalla bağdaşmaz; açık soket ilk rotasyonda kopar. Canlı kanal kullanan senaryolarda sticky oturum şarttır, kurulumu sticky oturum rehberinde.

• Canlı kanal kullanacaksanız sticky süresini çalışma sürenizden uzun seçin.
• Mobil uygulamanın anlık bildirimi işletim sisteminin push kanalından gelir ve Wi-Fi proxy ayarınızı kullanmaz.
• Kanalın koptuğunu anlamak için tarayıcı geliştirici araçlarındaki ağ sekmesini açık bırakın.