Bumble İçin Proxy: Kalıcı Bağlantı, Erişim Teşhisi ve Oran Sınırı

Bumble istemcisinin ağ davranışı iki ayrı kalıba oturur. Birincisi klasik istek–yanıt trafiğidir: profil listesini çekmek, bir ayarı kaydetmek, medya indirmek. İkincisi sohbetin anlık çalışması için açık tutulan kalıcı bir bağlantıdır; bu bağlantı kurulduktan sonra kapanmadan yaşar ve iki yönde de veri taşır.

Proxy tarafından bakıldığında bu ikisi aynı şey değildir. Kısa istekler bir tünel açılıp kapanarak rahatça taşınır. Kalıcı kanal ise tünelin dakikalarca açık kalmasını ister; boşta kalma süresi kısa ayarlanmış bir proxy bu kanalı sessizce düşürür ve siz yalnızca mesajların gecikmeli gelmesiyle fark edersiniz.

Üçüncü bir ayrım da şudur: uygulamanın kullandığı uç noktalar herkese açık, genel amaçlı bir arayüz değildir. Otomatik erişim hizmet şartlarıyla sınırlandırılmıştır ve bu sayfa böyle bir kullanımı anlatmaz. Burada ele alınan konu, olağan bir oturumun proxy arkasında neden çalıştığı ya da neden çalışmadığıdır.

Kısa istek ile kalıcı kanal: tünel ömrü neden ayrışır?

Uygulamanın ağ davranışını ikiye ayırmak teşhisin yarısını halleder. Birinci tür, arayüzü dolduran kısa ömürlü HTTPS çağrılarıdır: listeyi çekmek, bir ayarı kaydetmek, bir profili açmak. Bunların her biri açılır, yanıtını alır ve kapanır; tünel ömrü saniyelerle ölçülür. İçlerinden biri takılsa istemci sessizce yeniden dener ve siz çoğu zaman fark bile etmezsiniz. Proxy için taşınması en kolay trafik budur.

İkinci tür, sohbeti anlık çalıştıran kalıcı kanaldır. İstemci normal bir HTTPS isteğiyle başlar, Upgrade başlığıyla WebSocket’e geçer ve bağlantı kapanmadan dakikalarca açık kalır. HTTP proxy’nin CONNECT tüneli bunu sorunsuz taşır: tünelin içinde yalnızca şifreli baytlar akar, yükseltmenin yapılmış olduğu bile dışarıdan görünmez (WebSocket ve proxy).

Aradaki fark kurulumda değil, ömürdedir. Kısa çağrı için hiç önemi olmayan tek bir ayar — tünelin boşta kalma süresi — kalıcı kanal için başat değişkendir. Sohbet sessizleştiğinde kanalda veri akmaz; boşta kalma süresi dar ayarlanmış bir ara nokta bu sessizliği ölü bağlantı sayıp tüneli kapatır. İstemci yeniden bağlanır, biriken mesajlar toplu iner ve tablo dışarıdan "yavaş internet" gibi görünür. Bu yüzden bir çıkışı değerlendirirken sorulacak soru "ne kadar hızlı" değil, "ne kadar uzun süre kopmadan duruyor" olmalıdır.

Kalan iki yol tek cümlede özetlenir. Profil ve sohbet görselleri ana alan adından değil ayrı adreslerden iner; kapsam yalnızca ana alan adıyla sınırlıysa sohbet listesi yüklenirken profil görselleri boş kalır. Arka plandaki mesaj uyarısı ise işletim sisteminin bildirim servisinden düşer: o soket uygulamanın ağ ayarlarından bağımsız açılır, dolayısıyla proxy tamamen düşmüşken bile bildirim almaya devam edebilirsiniz.

Kalıcı kanal ve bildirimler kuralın kapsamına giriyor mu?

Aşağıdaki yoğunluk şeması beş trafik türünün, kuralın kapsamı genişledikçe nasıl karşılandığını gösteriyor. Satırlar protokolü değil kapsamı ayırır: kuralı yalnızca ana alan adına yazmak, alt alan adlarını da kapsatmak ve sistem geneli bir ayar kullanmak. Değerler mutlak ölçüm değil, görece kapsama ağırlığıdır; amaç hangi hücrenin dışarıda kaldığını göstermektir.

Şemanın iki sütunu bilerek düzdür. Bildirim sütunu her satırda sıfırdır, çünkü o kanal işletim sisteminin bildirim servisine ait ayrı bir sokettir. WebSocket sütununun kapsam kademeleri arasında hiç değişmemesi de rastlantı değildir: tünelin ne kadar açık kalabildiği protokolden ya da kuralın kapsamından gelmez. Belirleyici olan, proxy sunucusunun boşta kalma (idle timeout) ayarı ile yol üzerindeki NAT ve güvenlik duvarı oturum ömrüdür; HTTP CONNECT tüneli de SOCKS5 bağlantısı da kurulduktan sonra opak bir TCP aktarımıdır ve içeriği yorumlamaz (HTTP ve SOCKS5 farkı). Kanal ömrü sorusunun cevabı bu yüzden ürün sayfasında değil, sağlayıcının zaman aşımı ayarındadır.

Kanalın canlı kalması için istemci ve sunucu düzenli aralıklarla küçük denetim çerçeveleri gönderir. Araya giren bir nokta bu çerçeveleri geciktirirse bağlantı sağlıklı görünürken mesajlar geç düşer. Bağlantının yeniden kurulma maliyetini azaltmak için açık bağlantıların korunması önemlidir; mekanizma keep-alive ve bağlantı havuzu yazısında anlatılıyor.

Yükleme sütunu da dikkat ister. Sohbette görsel göndermek yukarı yönlü kapasite ister ve kalıcı kanalla aynı tünel havuzunu paylaşır. Eşzamanlı bağlantı tavanınız dar ise yükleme sırasında kanalın kopması olağan bir yan etkidir (eşzamanlı bağlantı limiti).

Kampüs, ofis ve misafir ağlarında erişim neden kesilir?

Kurumsal ve kampüs ağlarında kategori bazlı filtreleme yaygındır; tanışma ve sosyal ağ kategorileri bu listelerde sık bulunur. Engel üç ayrı katmanda uygulanabilir ve her birinin belirtisi farklıdır. Ad çözümü katmanında engel varsa alan adı hiç çözülmez ya da yanlış bir adrese yönlenir. Güvenlik duvarı katmanında engel varsa ad çözülür ama bağlantı kurulmaz. TLS denetimi yapan ağlarda ise bağlantı kurulur, buna karşılık sertifika uyarısı çıkar.

Bu noktada teknik cevaptan önce bir kural var: kurumunuzun veya okulunuzun ağ politikası size ait değildir. Kurum kaynağını politikaya aykırı biçimde kullanmak, teknik olarak mümkün olsa bile kurum kuralları açısından sonuç doğurur. Kişisel kullanım için en temiz yol kendi mobil verinizi kullanmaktır; kurumsal bir ihtiyaç söz konusuysa doğru adres bilgi işlem ekibidir. Buradaki sınır teknik değil kurumsaldır; teknik bir çözüm aramak sorunun yanlış ucundan tutmak olur.

Misafir Wi-Fi ağlarının kendine özgü iki davranışı vardır. Birincisi giriş portalıdır: ağa bağlandığınızda trafiğiniz siz portalı onaylayana kadar yakalanır ve proxy dâhil hiçbir şey çalışmaz. İkincisi UDP kısıtlamasıdır; kimi misafir ve kurumsal ağlarda UDP 443 kapalıdır. QUIC kullanan istemciler bu durumda TCP’ye geri düşer, bu da açılışın ilk saniyelerini uzatır ama bağlantıyı kurtarır.

Erişim sorununu kademe kademe ayıklamak

Teşhisi rastgele denemeler yerine üç kademeye bölmek süreyi kısaltır. Her kademe bir öncekini varsayar: alt basamak çalışmıyorsa üsttekini denemenin anlamı yoktur.

Birinci kademe — ad çözümü. Hedef alan adı çözülüyor mu, çözülüyorsa çözümü kim yapıyor? Proxy kullanırken bu iş ya proxy tarafında yapılır ya da sizin ağınızda. SOCKS5’te davranış istemciye bağlıdır; socks5h biçimi adı proxy’ye bırakır. Çözümün nerede gerçekleştiğini DNS leak testi gösterir: sorgu sizin çözümleyicinizden çıkıyorsa çıkış adresi gizlenmiş olsa bile bağlandığınız alan adları yerel ağda iz bırakır.

İkinci kademe — taşıma ve el sıkışma. Adres biliniyorsa TCP bağlantısı kuruluyor mu, TLS el sıkışması tamamlanıyor mu? Proxy sunucusunun kendisine erişilebildiğini proxy kontrol aracıyla, yol üzerindeki gecikmeyi ise ping testiyle ölçebilirsiniz. Bu kademede alınan zaman aşımı genellikle port kapalılığına ya da proxy’nin erişilemez olmasına işaret eder.

Üçüncü kademe — uygulama katmanı. Bağlantı kuruluyor ama uygulama hata veriyorsa sorun kimlik doğrulama, kapsam ya da sınır tarafındadır. 407 proxy kimlik doğrulamasını, 401 uygulama oturumunu, 429 istek sınırını işaret eder. Çıkış adresinizi IP adresim aracıyla okuyun ve panelde yazan adresle karşılaştırın; iki değer tutmuyorsa istek proxy’ye hiç uğramamış demektir ve bu kademede hata aramanın anlamı kalmaz.