Rocket League Proxy: Hangi Trafik Yönlendirilebilir, Hangisi Kalır?

Rocket League için proxy sorusunun doğru hâli “çalışır mı” değil, “neyi kapsar” biçimindedir. Oyunun ürettiği trafiğin bir bölümü sıradan HTTPS istekleridir ve bir proxy kuralına sorunsuz yazılır; bir bölümü ise maç sırasında sürekli akan, gecikmeye duyarlı paketlerden oluşur ve klasik bir proxy tünelinin taşıyamadığı yerdedir.

Bu ayrım bilinmeden yapılan kurulumlar hep aynı yanılgıyı üretir: menüler açıldığı için kurulumun tamamen çalıştığı sanılır, oysa asıl oyun trafiği hiç yönlendirilmemiştir. Aşağıdaki bölümler önce bu sınırı çizer, sonra kuralın nereye yazılacağını, güncelleme günlerinde neyin değiştiğini ve ölçümün nasıl yapılacağını anlatır.

Baştan bir not: proxy bir yönlendirme kararıdır, kimlik değiştirme aracı değil. Çıkış adresiniz değişir; hesabınız, oturum jetonunuz, istemci sürümünüz ve satın alma geçmişiniz olduğu gibi kalır.

Oturumun hangi parçası bir proxy kuralına yazılabilir?

İstemci açıldığında tek bir sunucuya bağlanmaz. Hesap doğrulama, hak sahipliği kontrolü, arkadaş listesi, sezon ilerlemesi ve mağaza vitrini birbirinden ayrı uç noktalara düşen HTTPS istekleridir. Bunlar sıradan web trafiği gibi davranır: istek gider, yanıt gelir, bağlantı ya kapanır ya bir süre açık tutulur. Bir HTTP proxy bu oturumları CONNECT yöntemiyle tünelleyebilir; SOCKS5 de aynı TCP bağlantılarını taşır.

Eşleşme kuyruğundan maça geçtiğiniz anda taşıma türü değişir. Araçların konumu, topun fiziği ve girdi bilgisi saniyede çok sayıda küçük paket hâlinde akar. Bu akışta kaybolan bir paketi yeniden istemek anlamsızdır, çünkü yerine gelecek olan bir sonraki paket zaten daha güncel bilgiyi taşır. Gerçek zamanlı oyunların çoğu bu yüzden UDP kullanır ve HTTP proxy’nin açtığı tünel yalnızca TCP taşıdığı için bu akış tünele hiç girmez.

SOCKS5’in buna bir yanıtı vardır: UDP ASSOCIATE. İstemci önce TCP üzerinden bir denetim bağlantısı kurar, proxy ona bir UDP aktarma adresi bildirir ve datagramlar küçük bir başlıkla o adrese gönderilir. Koşulu ağırdır: hem proxy sunucusunun UDP aktarmayı açmış olması hem de oyun istemcisinin SOCKS5 UDP’yi kendi ağ kodunda desteklemesi gerekir. Masaüstü oyun istemcilerinin çoğunda proxy alanı bile bulunmaz. Yöntemin ayrıntısı SOCKS5 UDP desteği yazısında.

Bu sınır pratikte nasıl görünür?

Kurulumdan sonra menüler açılıyor, mağaza yükleniyor ve arkadaş listesi geliyorsa TCP tarafı proxy üzerinden çalışıyor demektir. Buna karşılık eşleşme arama uzuyor, oturum kurulmadan düşüyor ya da bağlantı maçın ortasında kopuyorsa akış tarafı ya hiç tünele girmiyordur ya da girmeye çalışırken bir yerde durdurulmuştur. Bu iki belirtiyi ayırmak, kurulumu baştan sökmeden önce atılacak ilk adımdır.

Güncelleme günleri: indirme hacmi ve dağıtım ağı davranışı

Sezon geçişinde ya da büyük bir içerik güncellemesinde inen veri, aynı ay boyunca maç oynayarak ürettiğiniz trafikten kat kat büyüktür. Maç akışı küçük paketlerden oluşur, yama ise sıkıştırılmış büyük dosyalardan. Kotalı bir çıkış kullanıyorsanız aylık tüketiminizi belirleyen şey oynadığınız süre değil, güncelleme günleridir.

Yama dosyaları bir içerik dağıtım ağından çekilir ve hangi düğümün size döneceği, isteğin çıkış adresine ve alan adını çözen sunucunun konumuna göre belirlenir. Proxy devredeyken bu yakınlık hesabı sizin konumunuza değil proxy’nin konumuna göre yapılır. Çözümü kendi ağında yapan bir istemci daha da ters bir tablo üretir: size yakın bir düğüm seçilir, ama bağlantı başka ülkedeki proxy’den kurulur ve her parça gereksiz bir tur atar. Ayrımın kaynağı SOCKS5’te DNS’in nerede çözüldüğü sorusudur.

Buradan çıkan pratik öneri nettir: indirme trafiğini proxy’den ayrı tutun. Kuralı sistem geneline yazmak yerine yalnızca ihtiyacınız olan sürece uygularsanız yama olağan hattınızdan iner, kota tahmin edilebilir kalır ve güncelleme gününde hızınız proxy’nin bant genişliğine bağlı olmaz. Aylık planı sayıya dökmek isterseniz bant genişliği hesaplama yazısı bir yöntem veriyor.

Maçı kim barındırıyor: adanmış havuz ile topluluk sunucusu farkı

Rocket League maçları yayıncının bölgesel olarak işlettiği adanmış sunucularda yürür. Oyuncular birbirine doğrudan bağlanmaz; herkes aynı sunucuya konuşur ve oyunun durumu orada tutulur. Kullanıcı tarafındaki sonucu şudur: bağlanacağınız adresi siz seçmezsiniz, eşleştirme sistemi atar.

Bu, topluluk sunucusu modeliyle çalışan oyunlardan temelden farklıdır. Minecraft gibi başlıklarda sunucu bir topluluk üyesinin ya da bir barındırma sağlayıcısının makinesinde çalışır; adresini siz yazarsınız, bağlantının nereye gittiği bellidir ve araya bir durak koymak teknik olarak anlamlı olabilir. Adanmış havuzda böyle bir adres alanı yoktur, dolayısıyla “şu sunucuya proxy üzerinden bağlanayım” cümlesinin karşılığı da yoktur.

Özel maçlarda da aynı altyapı devrededir: arkadaşınızın bilgisayarı sunucuya dönüşmez, oturum yine barındırma havuzunda açılır. Özel maç, eşleştirmenin değil davetin belirlediği bir oturumdur; taşıma davranışı değişmez. Turnuva ve topluluk etkinliklerinde de bağlantı mimarisi aynı kalır, değişen yalnızca kimin kiminle eşleştiğidir.

Proxy’nin bu tabloda gerçekten işe yaradığı yer başkadır: çıkış adresinin sabit ve bilinir olması gereken senaryolar. Kurumsal bir ağdan tek bir adresle görünmek, etkinlik ağında trafiği tek noktadan denetlemek veya mağaza ve web tarafının farklı ülkelerden nasıl göründüğünü kontrollü biçimde test etmek bunlara örnektir. Çıkış ülkesi seçenekleri için proxy lokasyonları sayfasına bakabilirsiniz; hiçbiri maç akışını yönlendirmekle ilgili değildir.

Kuralı nereye yazarsınız ve hangi sırayla ilerlersiniz?

Kurulumun ilk adımı bir ayar ekranı değil, bir kapsam kararıdır: hangi trafiğin proxy üzerinden gitmesini istiyorsunuz? Sistem geneline yazılan bir ayar her şeyi kapsar, bu yüzden yama indirmeyi ve güncelleme servislerini de içine alır. Uygulama bazlı bir kural yalnızca seçtiğiniz süreci yönlendirir ve yan etkisi en az olanıdır.

İkinci adım protokoldür. Yalnızca TCP taşıyacaksanız HTTP proxy yeterlidir; UDP aktarma ihtimalini açık tutmak istiyorsanız SOCKS5 tarafına geçmeniz gerekir, ancak istemci desteği olmadan bu yeteneğin karşılığı olmaz. Üçüncü adım kuralın yazılacağı noktadır: işletim sistemi ayarı, uygulama bazlı yönlendirme ya da yönlendirici üzerinde tanımlanan bir kural. Windows tarafındaki ayar ekranları Windows proxy ayarları yazısında adım adım anlatılıyor.

Dördüncü adım kimlik doğrulamadır. Sabit bir hattan çalışıyorsanız IP yetkilendirmesi pratiktir, ama adresiniz değiştiğinde erişim sessizce kesilir. Kullanıcı adı ve parola her yerden çalışır, buna karşılık paylaşılabilir bir sırdır ve oyun istemcilerinin çoğunda bu bilgiyi girecek bir alan yoktur. Beşinci adım doğrulamadır: kurulumun çalıştığını varsaymak yerine çıkış adresinizi ve ad çözümünüzü ayrı ayrı kontrol edin.

• Kuralı yazmadan önce hangi sürecin yönlendirileceğine karar verin.
• Yama indirmeyi bilinçli olarak kapsam dışında bırakın.
• Aynı anda hem sistem ayarı hem uygulama kuralı çalıştırmayın.
• Kimlik doğrulama yöntemini hattınızın sabit olup olmadığına göre seçin.
• Değişiklikten sonra oyunu tamamen kapatıp yeniden açın; süreç eski ayarı taşıyabilir.