Honkai: Star Rail ve Proxy: Hangi Trafik Tünele Girer?

Honkai: Star Rail açıldığında tek bir bağlantı kurulmaz. Başlatıcı sürüm bilgisini sorar ve gerekiyorsa gigabayt ölçeğinde dosya çeker, hesap katmanı kısa ve sık istekler üretir, oyun oturumu ise açık kaldığı sürece sunucuyla konuşan uzun ömürlü bir kanaldır. Bu üçünün ağ davranışı birbirine benzemez.

Proxy bu tablonun tamamını kendiliğinden kapsamaz. Yazdığınız kuralın kapsamı, kuralı hangi katmana koyduğunuza ve istemcinin o katmanı okuyup okumadığına bağlıdır. Tarayıcıdan açılan hesap sayfası tünele girerken oyunun kendi soketi olağan hattınızdan çıkabilir; ekranda bunu gösteren bir uyarı belirmez.

Üçüncü nokta beklentiyle ilgilidir: proxy bir hızlandırıcı değildir, araya bir durak koyar. Aşağıdaki bölümler bu durağın yol süresine ne kattığını, hangi ölçümün neyi söylediğini ve hangi belirtinin proxy ile ilgisi olmadığını ayrı ayrı ele alıyor.

Sıra tabanlı bir oyunda ağ ne zaman konuşur?

Savaş sıra tabanlı olduğu için istemci, her karo hareketini sunucuya bildiren bir aksiyon oyunu gibi davranmaz. Karar verdiğiniz anda giden istek, sunucunun döndüğü sonuç ve arayüzün güncellenmesi tek bir gidiş-dönüş içinde biter. Bu yüzden birkaç on milisaniyelik bir gecikme farkı oynanışta çoğu zaman fark edilmez; fark edilen şey, bağlantının tamamen kopması ya da isteğin yanıtsız kalmasıdır.

Buna karşılık oyun her açılışta bir doğrulama zinciri yürütür: başlatıcı sürüm karşılaştırması yapar, hesap katmanı oturumu tazeler, ardından oyun kendi ağ geçidine bağlanır. Bu zincirin herhangi bir halkası tünel dışında kalırsa belirti genellikle "oyun açılmıyor" değil, "giriş ekranında takılıyor" biçiminde görünür. Kullanıcı bunu sunucu arızası sanır; oysa kuralın kapsamı eksiktir.

Dördüncü ve beşinci katman arka plandadır: web üzerinden yürüyen etkinlik ve kod sayfaları tarayıcıda açılır, telemetri ve hata raporlaması ise siz fark etmeden küçük paketler gönderir. Bu ikisinin yönlendirilip yönlendirilmemesi oynanışı etkilemez, ama trafiğin nereden çıktığını doğrularken tabloyu karıştırır: tarayıcıdan yaptığınız IP sorgusu oyunun çıkışını değil, tarayıcının çıkışını gösterir.

Araya konan durak yol süresine ne ekler?

Proxy kullandığınızda paket doğrudan hedefe gitmez: önce proxy sunucusuna ulaşır, oradan hedefe iletilir, yanıt aynı yoldan döner. Toplam süre bu nedenle üç parçadan oluşur — sizinle proxy arasındaki mesafe, proxy ile oyun sunucusu arasındaki mesafe ve proxy makinesinin o anki yükü. Üçünün toplamı doğrudan bağlantıdan küçük olamaz; olağan sonuç, gecikmenin artmasıdır.

Ne kadar arttığı coğrafyaya bağlıdır. Çıkışınız sizinle oyun sunucusu arasındaki hattın üzerindeyse ek yük görece küçüktür. Çıkış ters yönde, örneğin Asya sunucusuna bağlanırken Kuzey Amerika’da seçilmişse, paket her iki yönde de fazladan bir okyanus geçer ve fark oynanışta hissedilir hâle gelir. Bu yüzden lokasyon seçimi, tür seçiminden önce gelen karardır.

Kuralın tek istisnası şudur: varsayılan rotanız dolambaçlıysa ve proxy sağlayıcısının omurgası hedefe daha doğrudan bağlanıyorsa, ek durak toplamda kazanç üretebilir. Bu bir vaat değil, ölçülmeden varsayılamayacak bir istisnadır ve doğrulanması gerekir. Ölçmeden önce hangi rakamın neyi anlattığını bilmek için proxy latency tanımına ve oyunlarda ping beklentisi yazısına bakın.

Pratik yöntem basittir: proxy kapalıyken ve açıkken aynı hedefe ölçüm alın, ölçümü günün farklı saatlerinde tekrarlayın ve iki sonucu yan yana koyun. Ping testi tek seferlik bir fotoğraf verir; karar için en az birkaç fotoğraf gerekir, çünkü paylaşımlı çıkışlarda yoğun saat farkı tek ölçümün gizlediği değişkendir.

Paket kaybı mı gecikme mi? İkisini ayırmak

Oyuncular iki farklı sorunu aynı kelimeyle anlatır. Gecikme, paketin varması için geçen süredir; paket kaybı, paketin hiç varmamasıdır. Belirtileri farklıdır: yüksek gecikmede her şey geç ama düzenli ilerler, kayıpta ise arayüz bir an donar, sonra sıçrayarak yetişir. Kayıp, gecikme ortalaması düşük görünürken bile oyun deneyimini bozabilir.

Ölçümü doğru okumak için üç rakamı birlikte değerlendirin: ortalama gecikme, gecikmenin dalgalanması (jitter) ve kayıp oranı. Ortalama iyi, dalgalanma yüksekse sorun genellikle hattın kendisinde ya da paylaşımlı bir çıkışın yoğunluğundadır. Kayıp varsa önce kaybın nerede başladığını bulmak gerekir; ortalama rakama bakarak çıkarım yapmak yanıltır.

Teşhis sırası şöyle kurulur: önce proxy kapalıyken ölçün. Kayıp proxy kapalıyken de varsa kaynağı ev hattınız, kablosuz bağlantınız veya sağlayıcınızın omurgasıdır; bu durumda proxy açmak sorunu gizlemez, üstüne bir katman daha koyar. Kayıp yalnızca proxy açıkken çıkıyorsa çıkışı değiştirip aynı ölçümü tekrarlayın; sorun tek bir çıkış makinesinde olabilir. Canlılık ve yanıt sınaması için proxy kontrol aracı ilk adımdır.

SOCKS5 UDP aktarımının pratikteki sınırı

HTTP proxy, HTTPS trafiğini CONNECT yöntemiyle tünelleyerek taşır ve bu tünel yalnızca TCP taşır. Oyun trafiğinin önemli bir kısmı UDP kullandığı için klasik bir HTTP proxy, oyunun gerçek zamanlı kanalını taşıyamaz. Bu bir yapılandırma eksikliği değil, protokolün tanımıdır.

SOCKS5 bu noktada farklıdır: standart, UDP ASSOCIATE adında bir yöntem tanımlar ve UDP datagramlarının proxy üzerinden aktarılmasına izin verir. Ancak iki koşul birlikte sağlanmalıdır. Birincisi, proxy sunucusu bu yöntemi gerçekten desteklemelidir; birçok kurulum yalnızca TCP bağlama izni verir. İkincisi, istemcinin bu yöntemi kullanmayı bilmesi gerekir — oyun istemcilerinin çoğu kendi soketini açar ve sistemdeki SOCKS5 ayarını hiç okumaz.

Bu iki koşul birlikte sağlanmadığında sonuç sessizdir: uygulama hata vermez, UDP paketleri tünele girmeden olağan hattınızdan çıkar. Uygulamada karşılığı şudur — hesap sayfası, başlatıcı ve yama indirmesi tünelden geçerken oyunun kendi oturumu geçmez. Kapsamı genişletmek isteyen kullanıcılar bu yüzden çoğunlukla uygulama bazlı yönlendirmeye ya da cihaz seviyesinde bir tünele yönelir. Protokolün UDP tarafının ayrıntısı için SOCKS5 UDP desteği yazısı ayrıntılıdır; genel karşılaştırma için SOCKS5 proxy sayfasına bakabilirsiniz.