Squad Proxy: Sunucu Tarafı, Yönlendirici Kapsamı ve Sınırlar

Squad, büyük haritalarda kalabalık takımların aynı anda bulunduğu bir nişancı oyunudur ve ağ tarafında iki farklı rol üretir: sunucuya katılan istemci ve sunucuyu barındıran taraf. Proxy tartışması bu iki rolde tamamen farklı ilerler. İstemci tarafında soru “trafiğim tünelden geçiyor mu” iken, barındıran tarafta soru “dışarıdan bana ulaşılabiliyor mu” hâline gelir.

İkinci ayrım, yapılandırmanın nereye yazıldığıdır. Bir cihazda tanımlanan kural yalnızca o cihazı kapsarken yönlendirici üzerinde tanımlanan kural evdeki her şeyi kapsar. İkisi farklı sorunları çözer ve farklı riskler taşır.

Aşağıda önce sunucu topolojisini, sonra kapsam kararını ve son olarak kısıtlı ağlardaki teşhis sırasını ele alıyoruz.

Hangi sunucuda oynuyorsunuz, kim işletiyor?

Squad ekosisteminde sunucuların önemli bölümü topluluk tarafından işletilir. Klanlar, topluluklar ve barındırma sağlayıcıları kendi örneklerini çalıştırır; oyuncu bir liste üzerinden bunlardan birini seçer. Bu yapı, tek bir yayıncı veri merkezine bağlı oyunlardan farklı bir tablo üretir: sunucunun bulunduğu ülke, kuralları ve yapılandırması işletene göre değişir.

Bunun proxy tarafında iki sonucu vardır. Birincisi, bağlantı kalitesini belirleyen asıl değişken sizinle sunucu arasındaki fiziksel yoldur. Araya bir çıkış koymak bu yolu kısaltmaz; ek bir durak ekler. İkincisi, sunucu listesi sorgusu ile maç oturumu farklı davranır: liste bir sorgu-yanıt işidir, maç ise sürekli bir akıştır.

Üçüncü bir katman modlardır. Topluluk sunucularının bir bölümü ek içerikle çalışır ve bu içerik oyun içinden değil, dağıtım platformunun atölye altyapısından iner. Bu indirmeler web trafiğidir; proxy kuralınız platform istemcisini kapsıyorsa bu akış da tünelden geçer ve kotanızdan düşer.

Kendi sunucunuzu işletmeyi düşünüyorsanız denklem tersine döner: artık dışarıdan size gelen bağlantıları kabul etmeniz gerekir. Bir forward proxy bu işi yapmaz; iki kavramın farkı forward ve reverse proxy yazısında ayrıntılı anlatılıyor.

Sunucu barındırmak ile sunucuya katılmak aynı ağ işi değildir

Katılan taraf için bağlantı içeriden dışarıya kurulur. Ev yönlendiricisi bu isteği NAT tablosuna yazar, dönen yanıtları eşleştirir ve iş biter; çoğu evde ek bir ayar gerekmez. Barındıran taraf içinse yön terstir: bağlantı dışarıdan gelir ve yönlendiricinin bu isteği hangi iç cihaza götüreceğini bilmesi gerekir.

Burada sık karıştırılan iki kavram vardır. NAT bir adres çevirisidir ve bağlantıyı yönlendirir; proxy ise bir aracıdır ve isteği sizin adınıza kendisi kurar. Aradaki farkı proxy ve NAT karşılaştırması açıklıyor. Ev bağlantınız operatör seviyesinde paylaşımlı bir adres arkasındaysa dışarıdan erişim zaten mümkün olmayabilir; bu durumun ayrıntısı CGNAT yazısında.

Pratikte topluluk sunucularının büyük bölümü ev bağlantısında değil, barındırma sağlayıcısında çalışır. Sebebi basittir: kalabalık bir sunucu sürekli ve simetrik bant genişliği ister, ev hatlarının yükleme kapasitesi çoğu zaman buna yetmez. Ayrıca sunucunun kararlılığı doğrudan oyuncu deneyimine yansır; tek bir kopma, o an bağlı olan herkesi aynı anda düşürür.

Barındırma tarafında proxy’nin karşılığı oyun trafiğinde değil, çevresindeki yönetim işlerindedir. Sunucunun kayıtlarını okumak, yapılandırma dosyalarını güncellemek, oyuncu listelerini yönetmek için kullanılan arayüzler sıradan web uygulamalarıdır ve tünelden sorunsuz geçer. Oyunun kendi akışını taşımaya çalışmak yerine bu arayüzlere erişimi düzenlemek, proxy’nin bu senaryodaki en gerçekçi katkısıdır.

Kuralı cihaza mı, yönlendiriciye mi yazmalı?

Cihaz seviyesinde tanımlanan bir proxy yalnızca o cihazı, çoğu zaman da o cihazdaki belirli uygulamaları kapsar. Avantajı denetimdir: bir şey ters giderse evdeki diğer cihazlar etkilenmez ve geri almak saniyeler sürer. Dezavantajı, aynı ayarı her cihazda tekrarlamanız gerekmesidir.

Yönlendirici seviyesindeki tanım tam tersidir. Tek noktada yapılır, ağdaki her cihazı kapsar ve ayar ekranı olmayan cihazları da içine alır. Bedeli ise şudur: yanlış bir kural tüm evi etkiler, teşhis zorlaşır ve ev yönlendiricilerinin bir bölümü bu tür yapılandırmayı standart arayüzünde hiç sunmaz. Seçenekleri karşılaştırmak isterseniz yönlendirici üzerinden proxy kullanımı yazısı adımları gösteriyor.

Squad özelinde bu kararın sonucu şaşırtıcı olabilir. Yönlendiriciye yazılan bir kural dahi oyunun UDP akışını kendiliğinden tünele almaz; ev ağındaki tüm cihazları kapsayan bir HTTP proxy tanımı, taşıma modeli farklı olan bir akışı taşıyamaz. Kapsamın genişlemesi, protokolün sınırını ortadan kaldırmaz.

Bu yüzden çoğu ev kullanıcısı için doğru yol, dar kapsamda kalıp proxy’yi yalnızca web ve platform işleri için kullanmaktır. Geniş kapsam, evde birden çok cihazla aynı bölgesel görünümü test etmek gibi belirli bir ihtiyaç varsa anlam kazanır.

İki protokolün bu işteki profili

HTTP proxy uygulama katmanında durur; düz HTTP isteklerini yorumlar, HTTPS için CONNECT ile bir tünel açar ve yalnızca TCP taşır. SOCKS5 taşıma katmanındadır, taşıdığı protokolü yorumlamaz ve UDP ASSOCIATE yöntemiyle UDP taşıma imkânı sunar. Kâğıt üzerinde ikincisi oyun için daha uygun görünür.

Pratikte tablo daha dardır. UDP taşıma zincirinin çalışması üç koşula bağlıdır: sunucunun bu yöntemi açık tutması, istemcinin SOCKS5 üzerinden UDP göndermeyi desteklemesi ve aradaki ağın ilgili trafiğe izin vermesi. Oyun istemcilerinin çoğunda ikinci koşul karşılanmaz; bu nedenle SOCKS5’in teorik avantajı sahada nadiren kullanılabilir hâle gelir.

Karar bu yüzden basitleşir: web, platform ve yönetim arayüzü işleri için iki protokol de uygundur, tercih istemcinizin hangisini desteklediğine bakar. İkisinin ayrımını derinleştirmek isterseniz HTTP ve SOCKS5 farkı yazısı karşılaştırma tablosu içeriyor; seçim gerekçelerini protokol seçim rehberi topluyor.

Bir üçüncü değişken daha var: eşzamanlı bağlantı sayısı. Modlu bir sunucudan içerik indirirken ve aynı anda tarayıcıda topluluk sayfaları açıkken paralel istek sayısı hızla artar. Paketinizin tavanını bilmiyorsanız eşzamanlı bağlantı limiti yazısı bu tavanın nasıl okunacağını anlatıyor.