Helldivers 2 Proxy: Ölçmeden Karar Vermeyin

Helldivers 2’nin ağ tarafı ikiye ayrılır. Bir yanda kalıcı bileşenler vardır: giriş, ilerleme kaydı, eşleşme ve kampanya durumu. Bunlar merkezî hizmetlerde tutulur ve TCP üzerinde ilerler. Öbür yanda görev sırasındaki akış vardır; gerçek zamanlıdır, gecikmeye duyarlıdır ve UDP ağırlıklı çalışır.

Proxy kararının tamamı bu ayrımın üzerine oturur. Bir aracı ilk gruba dokunabilir, ikinciye çoğu kurulumda dokunamaz. Bunu baştan bilmek, “kural yazdım ama hiçbir şey değişmedi” cümlesine harcanan saatleri ortadan kaldırır.

Aşağıda önce trafiğin dağılımını, sonra SOCKS5’in UDP yolunun sınırını, ardından paket kaybı ve gecikme ölçümünün nasıl kurulacağını, son olarak da bu oyunda proxy’nin gerçek kullanım alanını bulacaksınız.

İstemci hangi uç noktalara dağılıyor?

Bir oturum boyunca istemci birbirinden bağımsız altı hedefe konuşur: giriş ve sıraya alma katmanı, ilerleme kaydının tutulduğu hizmet, eşleşme, görev sırasındaki gerçek zamanlı akış, mağaza istemcisi ve yama dağıtımı. Hepsi aynı ekranın arkasında olduğu için tek bir bağlantı gibi görünürler.

Bu hedeflerin protokolü aynı değildir. İlk üçü ve son ikisi TCP üzerinde ilerler; görev akışı ise gerçek zamanlıdır. Aradaki fark, bir proxy kuralının etkisini belirleyen tek değişkendir.

Yoğun dönemlerde giriş ve sıraya alma katmanı ayrı bir başlık hâline gelir. Sıra beklemesi kapasiteyle ilgilidir ve ağ yolunuzla ilgisi yoktur; başka bir ülkeden çıkmak sırayı kısaltmaz. Bu ayrımı yapmak, çözülemeyecek bir sorunu proxy ile çözmeye çalışmaktan sizi kurtarır.

Hedeflerin birbirinden bağımsız olmasının bir başka sonucu daha var: biri erişilemezken diğerleri sorunsuz çalışabilir. Mağaza istemcisi açılıyor ama oyun girişi ilerlemiyorsa sorun ağınızda değil, o katmandadır. Aynı biçimde indirme akarken eşleşmenin takılması, kuralınızın değil hizmetin durumunu gösterir. Belirtiyi hangi hedefe ait olduğunu ayırmadan okumak, yanlış yerde saatler harcamanın en hızlı yoludur.

Teşhise başlamadan önce basit bir liste tutun: hangi ekran açılıyor, hangisi takılıyor, hata aynı anda başkalarında da var mı. Bu üç yanıt, sorunun ağ tarafında mı yoksa hizmet tarafında mı olduğunu çoğu durumda tek başına belirler.

SOCKS5’in UDP yolu nerede tıkanır?

HTTP proxy, HTTPS hedefleri için bir tünel açar ve bu tünel TCP taşır. Yöntemin ayrıntısı CONNECT metodu yazısında anlatılıyor. Görev sırasındaki akış UDP taşıdığı için bu tünelin içine hiç girmez; kuralı ne kadar geniş yazarsanız yazın sonuç değişmez.

SOCKS5 tarafında UDP ASSOCIATE adında bir yol vardır. İşleyişi SOCKS5 UDP desteği yazısında adım adım duruyor. Uygulamada üç koşul birden gerekir: sunucu bu komutu desteklemeli, aradaki ağ ilişkilendirilen akışa izin vermeli ve istemci bu yolu kullanacak biçimde yazılmış olmalı. Üçüncü koşul oyun istemcilerinde neredeyse hiç sağlanmaz.

Bu yüzden gerçekçi beklenti şudur: proxy bu oyunda giriş, mağaza, yama ve eşleşme trafiğini kapsar. Görev akışını bir çıkışa taşımak istemci desteği olmadan mümkün değildir ve zorlama girişimleri genellikle oyunun hiç bağlanamamasıyla sonuçlanır. Protokol karşılaştırması için SOCKS5 proxy sayfasına bakabilirsiniz.

Bir yanılgıyı da burada kapatmak gerekir: cihazın tamamını saran bir tünel ile uygulama düzeyinde tanımlanan bir proxy aynı şey değildir. Birincisi ayrı bir taşıma katmanı kurar ve UDP dâhil her şeyi taşıyabilir; ikincisi yalnızca kendisine yönlendirilen bağlantıları alır. Bu sayfada anlatılan araç ikincisidir ve sınırları da buradan gelir.

İstemcide SOCKS5 alanı bulunmadığında bazı kullanıcılar trafiği zorla yönlendiren yardımcı yazılımlara yönelir. Böyle bir katman, UDP akışını taşıyamayan bir çıkışa yönlendirdiğinde sonuç hız kaybı değil, bağlantının hiç kurulamamasıdır. Belirti “oyun sunucuya bağlanamıyor” biçiminde göründüğü için nedeni de çoğu zaman geç fark edilir.

Proxy’nin gerçekten dokunduğu yer neresi?

Kapsam dar ama işe yarar. Kurumsal ya da kampüs ağlarında mağaza istemcisinin dışarı çıkamadığı durumlarda bir çıkış, yükleme ve güncelleme tarafını çalışır hâle getirebilir. Kısıtın hangi katmanda olduğunu anlamadan kural yazmak zaman kaybıdır; teşhis sırası kurumsal ağlarda erişim engelleri yazısında listelenmiş durumda.

İkinci meşru kullanım, sabit bir çıkış adresi gerektiren ağ politikalarıdır. Bir kurumda dışarı çıkan tüm trafiğin bilinen bir adresten geçmesi isteniyorsa, indirme ve mağaza trafiği bu adrese bağlanabilir. Bu bir performans kararı değil, bir yönetim kararıdır.

Üçüncüsü doğrulama işleridir: farklı bir konumdan mağaza sayfasının, kampanya duyurularının veya destek içeriğinin nasıl göründüğünü görmek. Bu işlerin hiçbiri oyun oturumunu ilgilendirmez ve tamamı tarayıcı üzerinden yürür.

Bu üç senaryonun ortak yanı, proxy’nin bir performans aracı değil bir erişim ve görünürlük aracı olarak kullanılmasıdır. Hiçbirinde amaç oyunu hızlandırmak değildir; amaç ya kapalı bir yolu açmak ya da karşı tarafın bağlantınızı nereden gelmiş sayacağını belirlemektir. Beklentiyi bu çerçevede tutan kurulumlar öngörülebilir çalışır.

• Kısıtlı ağda önce hangi katmanın engellendiğini belirleyin.
• Kurumsal politika gereği sabit adres isteniyorsa kapsamı yalnızca gerekli süreçlere daraltın.
• Doğrulama işlerini oyun istemcisinde değil tarayıcıda yapın.

Paket kaybını nerede ölçmeli, nasıl okumalı?

Bağlantı sorunlarının teşhisinde en sık yapılan hata, farklı büyüklükleri tek bir sayıya indirmektir. Gecikme yolun uzunluğunu, jitter bu uzunluğun ne kadar oynadığını, paket kaybı ise hiç ulaşmayan paketlerin oranını anlatır. Üçü farklı nedenlerden doğar ve farklı çözümler ister.

Ölçüme kendi hattınızdan başlayın. Yönlendiriciye yapılan bir test kayıp gösteriyorsa sorun evin içindedir ve hiçbir çıkış bunu onarmaz. Dışarıdaki bir hedefe yapılan ölçüm için ping test aracı başlangıç noktası verir; yöntemi sıraya koymak için proxy hızı nasıl test edilir yazısındaki adımlar izlenebilir.

Yol boyu ölçümlerde bir uyarı gerekir: ara duraklar düşük öncelikli yanıt üretebildiği için orta noktalarda görünen kayıp her zaman gerçek kayıp değildir. Anlamlı olan, uçtaki hedefe ulaşan paketlerin oranıdır. Ölçümü birkaç kez ve farklı saatlerde tekrarlamadan sonuç çıkarmayın.

Kablosuz bağlantı ayrı bir başlıktır. Aynı frekansta çalışan komşu ağlar, mesafe ve duvarlar ölçümde kayıp ve değişkenlik olarak görünür; bu, hattınızın değil odanızın sorunudur. Kayıp şüphesi varsa ilk denemeyi kabloyla yapın. Kabloyla kayıp kayboluyorsa çıkış seçimiyle uğraşmanın hiçbir faydası olmaz.

Son olarak belirtiyi doğru adlandırın. Ani ve kısa donmalar genellikle değişkenlikten, sürekli gecikmeli tepki mesafeden, ara ara kopan hareketler ise kayıptan gelir. Aynı şikâyeti “laglıyor” diye tek kelimeye indirmek, hangi ölçümü alacağınızı belirsizleştirir ve teşhisi baştan zorlaştırır.

Ek durağın gecikme bütçesindeki payı

Toplam gecikme birkaç parçadan oluşur: sizden çıkış düğümüne olan mesafe, çıkıştan hedefe olan mesafe, çıkış düğümünün o anki yükü, şifreleme ve el sıkışma maliyeti, bir de yol üzerindeki ara duraklar. Proxy eklendiğinde bu kalemlerin sayısı artar, azalmaz.

Kullanıcıların en çok hafife aldığı kalem, çıkış düğümündeki kuyruktur. Aynı çıkışı paylaşan kullanıcı sayısı arttıkça yanıt süresi büyür ve bu etki gün içinde değişir. Sabah ölçülen bir değere bakıp akşam için karar vermek, en sık yapılan ölçüm hatasıdır. Gecikmenin parçalara ayrılması proxy latency nedir yazısında ayrıntılı ele alınıyor.

Şifreleme ve el sıkışma maliyeti küçük ama görmezden gelinemez bir kalemdir. Her yeni bağlantı için yeniden kurulan oturum, kısa ömürlü isteklerde toplamı belirgin biçimde büyütür. Açık bağlantıyı koruyan istemcilerde bu kalem düşer; çok sayıda küçük istek üreten araçlarda ise fark ölçülebilir hâle gelir.

Pratik sonuç nettir: bu oyunda proxy oyun içi tepki süresini iyileştirmek için kullanılmaz. Görev akışı zaten tünele girmediği için etkisi dolaylıdır; giren trafikte ise yol uzadığı için süre büyür.