eFootball Proxy: Hangi Paket Tünelden Geçer, Hangisi Geçmez?
eFootball, önceki adıyla PES’i arayanların da bulduğu seri, aynı istemci içinde birbirinden çok farklı iki ağ davranışı barındırır: durağan HTTPS istekleri ve gecikmeye duyarlı gerçek zamanlı paketler. Proxy kararı bu ikisini ayırmadan verilemez. Aşağıda protokol sınırı, kurulum noktaları ve hesap tarafı ele alınıyor.
Protokol sınırıTCP üzerinde taşınan istekler ile UDP paketleri arasındaki keskin ayrım.
02
Kurulum sırasıKapsam, protokol, erişim bilgisi ve doğrulama adımlarının doğru dizilimi.
03
Hesap tarafıİki adımlı doğrulama, oturum jetonu ve konum değişiminin etkisi.
04
Uyum çerçevesiAnti-cheat ve hizmet şartları karşısında nerede durmak gerektiği.
Bir futbol oyununun ağ davranışını anlamanın en hızlı yolu, istemciyi tek bir program değil arka arkaya çalışan dört ayrı iş olarak görmektir: kendini tanıtma, içerik indirme, eşleşme arama ve maçı oynama. Bu dörtlünün ilk üçü klasik istek-yanıt mantığıyla çalışır, sonuncusu çalışmaz.
Bu fark proxy açısından belirleyicidir. İstek-yanıt trafiği TCP üzerinde taşınır ve bir tünelden sorunsuz geçer. Maç oturumu ise sürekli akan küçük paketlerle yürür; burada öncelik güvenilir teslimat değil, zamanında teslimattır ve bu tercih taşıma katmanını değiştirir.
Aşağıdaki bölümler önce bu sınırı netleştiriyor, sonra kuralı nereye yazacağınızı, en sonda da hesap ve uyum tarafında nelere dikkat etmeniz gerektiğini anlatıyor. Amaç bir kısıtı dolanmak değil, kurulumunuzun gerçekte ne yaptığını görmenizdir.
İstemcinin dört durağı: tanıtım, indirme, kuyruk ve maç
Açılışta istemci hesap servisine bağlanır ve kendini tanıtır. Bu adımda taşınan şey parolanız değil, cihazda saklı bir oturum jetonudur; parola yalnızca ilk girişte ya da oturum düştüğünde devreye girer. Karşı tarafın gördüğü adres, o an bağlantınızın çıktığı adrestir.
İkinci durak içerik tarafıdır: sürüm güncellemeleri, veri paketleri ve arayüz varlıkları. Bu istekler bir web sayfasının indirilmesinden farksızdır; hacim burada birikir ve kotalı bir çıkış kullanıyorsanız faturanın büyük kısmını bu adım üretir.
Üçüncü durak eşleşme kuyruğudur. İstemci bir eşleşme talebi gönderir, sunucu tarafında sıraya girer ve bir eşleşme bulunduğunda maç oturumunun nasıl kurulacağına dair bilgi döner. Bu aşama hâlâ istek-yanıt mantığındadır ve çoğu kurulumda tünelden geçebilir.
Dördüncü durak maçın kendisidir ve diğerlerine benzemez. Her iki taraf da sürekli küçük paketler gönderir; bir paket kaybolursa onu beklemek yerine bir sonrakini işlemek daha doğrudur. Bu tercih UDP’yi zorunlu kılar ve klasik bir HTTP proxy’si bu paketleri taşıyamaz.
ŞEMAeFootball istemcisinin ağdaki dört durağı
Şemayı yatay kaydırarak inceleyebilirsiniz
İlk üç durak istek-yanıt mantığıyla çalışır ve TCP taşır; dördüncüsü sürekli akan paketlerle yürüdüğü için farklı bir taşıma tercih eder.
Hangi trafik sınıfı kurala ne kadar uygun?
Kuralınızın işe yarayıp yaramayacağını protokol belirler. HTTP proxy, şifreli bağlantılar için CONNECT ile bir TCP tüneli açar ve içeriğe karışmadan baytları taşır; bu yapı UDP’ye kapalıdır. HTTP proxy ile taşıma katmanında duran SOCKS5 arasındaki fark tam da burada pratik sonuç doğurur.
SOCKS5 teorik olarak UDP taşıyabilir, ancak bunun için UDP ASSOCIATE yöntemine iki tarafta da ihtiyaç vardır: proxy sunucusu yöntemi sunmalı, istemci de onu kullanmalıdır. Oyun istemcileri bu ikinci şartı nadiren karşılar. Sonuç olarak SOCKS5 tanımlamak, maç paketlerinin tünele gireceği anlamına gelmez.
Üçüncü bir ayrıntı QUIC’tir. HTTP/3 kullanan bazı istekler UDP 443 üzerinden gider ve CONNECT tüneline girmez; bu durumda istek ya doğrudan çıkar ya da UDP kapalıysa TCP’ye geri düşer. Yani aynı istemci içinde bile bazı HTTPS istekleri kuralın kapsamına girmeyebilir.
Protokol kararını erteleyip önce erişim bilgisi girmek, yaygın bir sıralama hatasıdır. Hangi protokolün hangi işe uygun olduğunu protokol seçim rehberi adım adım anlatıyor.
ŞEMATrafik sınıflarının proxy kuralına uygunluğu
Şemayı yatay kaydırarak inceleyebilirsiniz
Çubuklar göreli uygunluğu gösterir, ölçülmüş bir oran değildir: TCP üzerinde taşınan sınıflar tünele girer, UDP tarafı büyük ölçüde dışarıda kalır.
İstemci sistem ayarını okumuyorsa ne olur?
Bir proxy tanımı, onu okuyan uygulamalar için geçerlidir. Tarayıcılar sistem ayarını okur; oyun istemcilerinin bir bölümü okumaz, kendi ağ yığınıyla doğrudan çıkar. Ayarı yazdıktan sonra hiçbir şeyin değişmemesi çoğu zaman kurulum hatası değil, bu davranışın sonucudur.
Bunu anlamanın yolu dolaylı testtir. Aynı cihazın tarayıcısından görünen çıkış adresini kontrol edin; adres değişmişse kural sistemde çalışıyor demektir. Buna rağmen oyun tarafında hiçbir fark yoksa istemci ayarı yok sayıyordur. Mobil sürümde durum daha da dardır: telefonun kablosuz ağ ayarına yazılan proxy yalnızca o ağda geçerlidir ve hücresel veriye geçildiğinde sessizce devre dışı kalır. Adım adım kurulum için Android proxy ayarları yazısına bakabilirsiniz.
Bu noktada iki seçeneğiniz kalır. Birincisi kapsamı daraltıp yalnızca kapsanabilen işleri yönlendirmek: hesap sayfaları, mağaza ve tarayıcı tarafı. İkincisi uygulama bazlı yönlendirme kuran ayrı bir araç kullanmaktır; bu, ek yazılım ve bakım anlamına gelir ve maç paketlerinin UDP sınırını yine ortadan kaldırmaz.
Not
Bir istemcinin proxy ayarını yok sayması bir arıza değildir. Uygulamalar kendi ağ yığınlarını kullanmakta serbesttir; bu tercih genellikle bağlantı kararlılığı ve güncelleme güvenilirliği için yapılır.
Kurulumda sıra önemlidir, çünkü her adım bir sonrakinin seçeneklerini daraltır. Önce kapsamı belirleyin: yalnızca tarayıcı mı, tüm işletim sistemi mi, yoksa tek bir süreç mi yönlendirilecek? Bu karar verilmeden protokol seçmek, sonradan geri alınacak bir tercih üretir.
İkinci adım protokoldür ve istemcinin hangi alanı sunduğuna bakılarak verilir: bazı araçlar yalnızca HTTP proxy alanı gösterir, bazıları SOCKS5’i de kabul eder. Üçüncü adımda erişim bilgisi girilir. Aşağıdaki tablo yalnızca alanların biçimini gösterir; gerçek değerler sağlayıcı panelinizdedir.
Alan
Örnek biçim
Dikkat edilecek
Sunucu
proxy.example.com
Ana bilgisayar adı mı, IP mi istendiğine bakın
Port
8080
Port numarası protokolü tek başına belirlemez
Kullanıcı adı
username
IP yetkilendirmesi kullanıyorsanız boş kalabilir
Parola
password
Panelden alınır, üçüncü kişilerle paylaşılmaz
Dördüncü adım doğrulamadır ve en sık atlanan adımdır. Kuralı yazdıktan sonra proxy kontrol aracıyla çıkışın ayakta olduğunu, ardından tarayıcıdan görünen adresi teyit edin. Beşinci adımda proxy açık ve kapalıyken bağlantıyı ayrı ayrı deneyip karşılaştırın; ölçmeden yapılan değerlendirme yanıltıcıdır.
ŞEMAKurulumun beş adımı ve doğru sırası
Şemayı yatay kaydırarak inceleyebilirsiniz
Her adım bir sonrakinin seçeneklerini daraltır; sırayı bozmak sonradan geri alınacak tercihler üretir.
eFootball tarafı için uygun çıkış
Hesap ve mağaza işlerinde sabitlik, güncelleme trafiğinde kota genişliği öne çıkar; ikisini ayrı ayrı değerlendirin.
Residential proxyler, Datacenter Proxyleri, IPv6 ve ISP çözümlerimizden dilediğinizi seçin. Tüm planlar sınırsız seçenekler, %99,9 çalışma süresi, rotating proxyler, sticky oturumlar ve 7/24 destek sunar. Web scraping, reklam doğrulama, SEO izleme ve dijital veri toplama için idealdir.
ISP ProxyStatik ISP kayıtlı Türkiye IP'leri
ISP kayıtlı statik Türkiye IP'leri; veri merkezi hızını gerçek operatör itibarıyla birleştirir. Uzun oturumlu ve düşük pingli kullanım için idealdir.
Hesabınız bir e-posta adresine bağlıdır ve oyun içi ilerlemeniz sunucu tarafında tutulur. Hesabı korumanın ilk adımı iki aşamalı doğrulamayı açmaktır: parolanız ele geçse bile ikinci adım olmadan oturum açılamaz. Doğrulama kodu genellikle e-posta veya bir kimlik doğrulayıcı uygulama üzerinden gelir.
Proxy tarafında ise oturum jetonunun IP’den bağımsız olduğunu bilmek işinizi kolaylaştırır. Jeton cihazda durur; çıkış adresiniz değişse de oturumun kimliği aynı kalır. Buna karşılık hesabın olağan kullanım ülkesinden uzak bir çıkışa aniden geçmek, güvenlik tarafında ek doğrulama adımı tetikleyebilir. Bu beklenen bir davranıştır.
Üçüncü konu gizliliktir. Proxy sağlayıcısı HTTPS içeriğini okuyamaz ama hangi ana bilgisayar adına bağlandığınızı görebilir ve kayıt altına alabilir. Kayıt politikasının ne anlama geldiği log kayıtları ve gizlilik yazısında ele alınıyor; giriş yapılan senaryolarda bu, fiyattan önce bakılacak kriterdir.
İki aşamalı doğrulamayı proxy denemelerinden önce etkinleştirin.
Çıkış ülkesini hesabın olağan ülkesiyle tutarlı tutun.
Aynı oturum içinde sık sık çıkış değiştirmeyin.
Sağlayıcının kayıt politikasını satın almadan önce okuyun.
Anti-cheat ve hizmet şartları: nerede durmak gerekir?
Çevrimiçi oyunlar istemci bütünlüğünü denetleyen mekanizmalar çalıştırır. Bu mekanizmaların amacı adil oyunu korumaktır ve bunlara müdahale etmeye çalışmak hem sözleşmeye aykırıdır hem de hesabınızı kalıcı olarak riske atar. Bu sayfada böyle bir yöntem anlatılmaz ve ima edilmez.
Proxy kullanımı ile denetim mekanizmaları arasındaki ilişki çoğu zaman yanlış kurulur. Bir proxy, istemcinin kendisine dokunmaz; yalnızca belirli isteklerin hangi yoldan çıktığını değiştirir. Buna karşılık oyunun hizmet şartları, bağlantı biçiminize dair kurallar içerebilir ve bu kurallar sağlayıcınızın teknik yeteneklerinden bağımsız olarak geçerlidir. Kurulumdan önce okunması gereken belge, proxy panelinizin yardım sayfası değil, oyunun kullanım koşullarıdır.
Kurumsal ya da kampüs ağındaysanız ikinci bir katman daha vardır: ağın kendi kullanım politikası. Ağ size ait değilse, teknik olarak mümkün olan bir yapılandırma idari olarak sorun doğurabilir. Doğru adım filtreyi dolanmaya çalışmak değil, ağ yöneticisinden izin istemektir; bu tartışmanın ayrıntısı okul ve işyeri ağlarındaki erişim engelleri yazısında.
Dikkat
Hesap kısıtlarını dolanmak, birden çok hesabı otomatik biçimde işletmek veya denetim yazılımına müdahale etmek bu sayfanın konusu değildir. Bu tür girişimler hesabın kalıcı olarak kapanmasıyla sonuçlanabilir.
Ölçüm: proxy’nin maliyetini nasıl görürsünüz?
Bir çıkışın size uygun olup olmadığına ancak ölçerek karar verebilirsiniz. Üç kalem ölçülür: gidiş-dönüş süresi, aktarılan veri ve bağlantının kararlılığı. Birinci kalem için ping testi yeterlidir ve ölçümü günün farklı saatlerinde tekrarlamak gerekir, çünkü paylaşımlı havuzlarda yoğunluk saate göre değişir.
Proxy’nin araya bir durak eklediğini unutmayın: bu nedenle proxy pingi düşürmez, ölçümde neredeyse her zaman bir artış görürsünüz. Buradaki doğru soru “azaldı mı” değil, “eklenen gecikme yapacağınız iş için kabul edilebilir mi” sorusudur. Mağaza ve hesap sayfaları için birkaç on milisaniyelik artış fark edilmez; gerçek zamanlı bir maç için ise zaten söz konusu bile değildir, çünkü o trafik kuralın dışındadır.
İkinci kalem veridir. İndirme ve güncelleme trafiği tüketimin çoğunu üretir; bunu kapsam dışında bırakmak kotalı bir residential çıkışta anlamlı bir tasarruf sağlar. Üçüncü kalem kararlılıktır: bir çıkış ortalama olarak hızlı ama ara ara kopuyorsa, ortalama değeri sizi yanıltır. Kısa aralıklarla tekrarlanan ölçümler bu dalgalanmayı görünür kılar.
Belirtiden nedene: sık karşılaşılan tablolar
Sorunların çoğu kapsam, kimlik doğrulama veya ad çözümü başlıklarından birine düşer. Aşağıdaki tablo belirtileri bu üç başlığa bağlıyor.
Belirti
Olası neden
Ne yapmalı
Ayar yazıldı, hiçbir şey değişmedi
İstemci sistem proxy ayarını okumuyor
Tarayıcıdan çıkış adresini teyit edin
Menüler açılıyor, eşleşme kurulmuyor
Gerçek zamanlı trafik kapsam dışında
Beklenen davranış; kapsamı daraltın
Alan adı çözülemiyor
Çözüm yerelde yapılıyor ve engelli
Çözümü proxy tarafına bırakan kurulumu deneyin
Kimlik doğrulama reddediliyor
Yetkili adres listesi güncel değil
Panelden mevcut çıkış adresinizi yetkilendirin
Güncelleme çok yavaş iniyor
Çıkışın bant genişliği yetersiz
İndirmeyi kapsam dışına alın
Bağlantı kısa sürede kopuyor
Eşzamanlı bağlantı limiti veya kota sonu
Panelden limit ve kalan kotayı kontrol edin
Ad çözümü başlığı özel bir dikkat ister. SOCKS5 kullanırken alan adının nerede çözüldüğü istemciye bağlıdır: kimi istemci hedefi kendi ağında çözer ve proxy’ye yalnızca IP verir, kimi çözümü proxy’ye bırakır. Fark hem gizlilik hem de erişim tarafında sonuç doğurur; ayrıntı SOCKS5’te DNS çözümleme yazısında.
Kimlik doğrulama tarafında en sık görülen senaryo, IP yetkilendirmesiyle tanınan bir kullanıcının hattının yenilenmesidir. Adres değiştiği anda erişim düşer ve hata kimlik bilgisi sorunu gibi görünür. Dinamik IP kullanıyorsanız kullanıcı adı–parola yöntemi daha az bakım ister.
Kimin için mantıklı, kimin için gereksiz?
Kendi ülkenizden oynuyor, mağazayı olağan biçimde kullanıyor ve bağlantınızdan memnunsanız proxy size bir katkı sunmaz. Maç içi takılmalar için bakılacak yer hattınızın kararlılığı, kablosuz bağlantı kalitesi ve ev ağındaki diğer cihazların ürettiği yüktür.
Proxy’nin işe yaradığı senaryolar daha dardır: bir hesap sayfasının ya da kampanya duyurusunun farklı bir bölgede nasıl göründüğünü doğrulamak, sabit bir çıkış adresiyle çalışmak, bir erişim sorununun kaynağını ikinci bir yoldan test etmek. Bunların hepsi HTTPS tarafında kalır ve kuralın kapsayabildiği alandadır. Sağlayıcı seçerken güvenlik tarafındaki temel soruları proxy kullanmak güvenli mi yazısı topluyor.
Aynı kategorideki diğer oyunlarda tablo benzer ama ayrıntılar değişir; EA SPORTS FC sayfası eş-eş bağlantı tarafını ayrıca ele alıyor. Genel bir bakış için oyun proxy rehberleri bölümüne göz atabilirsiniz.
eFootball ve proxy hakkında merak edilenler
01PES için yazılmış rehberler bu sürümde geçerli mi?
Ağ davranışının temel ayrımı açısından evet. Seri PES adıyla bilinirken de hesap, içerik ve eşleşme tarafı istek-yanıt mantığıyla, maç tarafı ise sürekli akan paketlerle çalışıyordu. Kurulum ekranları değişse de proxy kapsamının sınırı aynı yerde durur.
02Ayarı girdim ama eFootball tarafında hiçbir fark oluşmadı, sebebi ne?
En olası neden istemcinin sistem proxy ayarını okumamasıdır. Uygulamalar kendi ağ yığınlarını kullanmakta serbesttir. Kuralın sistemde çalıştığını aynı cihazın tarayıcısından görünen çıkış adresine bakarak doğrulayın; adres değiştiği hâlde oyun tarafı aynıysa istemci ayarı yok sayıyordur.
03Eşleşme süresi proxy ile kısalır mı?
Hayır, bunu bekleyin diye bir gerekçe yok. Eşleşme süresi sunucu tarafındaki kuyruk yoğunluğuna ve seçtiğiniz mod ayarlarına bağlıdır. Araya bir durak eklemek isteklerin ulaşma süresini uzatır; bu da kuyruk davranışını iyileştirmez.
04Mobil sürümde proxy nasıl tanımlanır?
iOS ve Android’de kablosuz ağ ayarlarından HTTP proxy alanı doldurulur. Bu tanım yalnızca o ağ için geçerlidir, hücresel veriyi kapsamaz ve ağ değiştiğinde devre dışı kalır. Ayrıca uygulamanın bu ayarı okuyup okumadığı ayrı bir sorudur.
05QUIC kullanan istekler tünelden geçer mi?
Geçmez. QUIC, UDP 443 üzerinde çalışır ve CONNECT ile açılan TCP tüneline giremez. Bu istekler ya doğrudan çıkar ya da ağda UDP kapalıysa istemci TCP tabanlı bir yola geri düşer. Sonuç olarak aynı uygulama içinde bazı HTTPS istekleri kapsam dışında kalabilir.
06Proxy kullanmak hesabım için risk oluşturur mu?
Teknik olarak proxy istemciye dokunmaz, yalnızca belirli isteklerin çıkış yolunu değiştirir. Risk daha çok iki yerden gelir: güvenilmeyen bir sağlayıcı üzerinden trafik geçirmek ve oyunun hizmet şartlarına aykırı bir kullanım. İkisi de teknik değil, tercih meselesidir.
07Sağlayıcı oyun içi konuşmalarımı görebilir mi?
HTTPS ile taşınan içeriği göremez; proxy yalnızca şifreli baytları taşır. Ancak bağlantı kurduğunuz hedefin adı proxy tarafında okunabilir durumdadır ve tutulan kayıtlara girebilir. Kayıt politikası bu yüzden sağlayıcı seçiminde belirleyici bir kriterdir.