eFootball Proxy: Which Packets Go Through the Tunnel and Which Do Not?
eFootball, the series that people searching for its former name PES also find, contains two very different network behaviours within the same client: static HTTPS requests and latency-sensitive real-time packets. A proxy decision cannot be made without separating the two. Below we cover the protocol boundary, the configuration points and the account side.
The protocol boundaryThe sharp distinction between requests carried over TCP and UDP packets.
02
Setup orderThe correct sequence of scope, protocol, access credentials and verification steps.
03
Account sideTwo-step verification, session tokens and the effect of changing location.
04
Compliance frameworkWhere to draw the line with respect to anti-cheat and terms of service.
The fastest way to understand a football game's network behaviour is to see the client not as a single program but as four separate jobs running one after another: identifying itself, downloading content, searching for a match and playing the match. The first three of these four work on classic request-response logic; the last one does not.
This difference is decisive from the proxy's point of view. Request-response traffic is carried over TCP and passes through a tunnel without trouble. The match session, however, runs on a continuous stream of small packets; here the priority is not reliable delivery but timely delivery, and that choice changes the transport layer.
The sections below first clarify this boundary, then explain where to write the rule, and finally what to watch out for on the account and compliance side. The aim is not to circumvent a restriction but to let you see what your setup actually does.
The client's four stops: identification, download, queue and match
At startup the client connects to the account service and identifies itself. What is carried in this step is not your password but a session token stored on the device; the password only comes into play at first sign-in or when the session drops. The address the other side sees is the address your connection is exiting from at that moment.
The second stop is the content side: version updates, data packages and interface assets. These requests are no different from downloading a web page; volume accumulates here, and if you use a metered exit this step generates most of the bill.
The third stop is the matchmaking queue. The client sends a match request, joins the queue on the server side, and when a match is found receives information on how the match session will be established. This stage is still request-response logic and can pass through the tunnel in most setups.
The fourth stop is the match itself, and it is unlike the others. Both sides continuously send small packets; if a packet is lost, it is better to process the next one than to wait for it. This choice makes UDP mandatory, and a classic HTTP proxy cannot carry these packets.
DIAGRAMThe eFootball client's four stops on the network
You can scroll the diagram horizontally to inspect it
The first three stops work on request-response logic and are carried over TCP; the fourth runs on a continuous stream of packets and therefore prefers a different transport.
How well does each traffic class fit the rule?
Whether your rule will work is determined by the protocol. For encrypted connections, an HTTP proxy opens a TCP tunnel with CONNECT and carries the bytes without touching the content; this structure is closed to UDP. HTTP proxy operating at the transport layer with the difference between SOCKS5 produces a practical consequence exactly here.
In theory SOCKS5 can carry UDP, but this requires the UDP ASSOCIATE method on both sides: the proxy server must offer the method and the client must use it. Game clients rarely meet the second condition. As a result, configuring SOCKS5 does not mean that match packets will enter the tunnel.
A third detail is QUIC. Some requests using HTTP/3 go over UDP 443 and do not enter the CONNECT tunnel; in that case the request either goes out directly or, if UDP is blocked, falls back to TCP. So even within the same client, some HTTPS requests may fall outside the scope of the rule.
Postponing the protocol decision and entering access credentials first is a common sequencing mistake. Which protocol suits which job is explained the protocol selection guide step by step.
DIAGRAMHow well traffic classes fit the proxy rule
You can scroll the diagram horizontally to inspect it
The bars show relative suitability, not a measured ratio: classes carried over TCP enter the tunnel, while the UDP side largely stays outside.
What happens if the client does not read the system setting?
A proxy definition applies to the applications that read it. Browsers read the system setting; some game clients do not and go out directly with their own network stack. Nothing changing after you write the setting is usually not a configuration error but the result of this behaviour.
The way to find out is an indirect test. Check the exit address shown in a browser on the same device; if the address has changed, the rule is working on the system. If there is still no difference on the game side, the client is ignoring the setting. On mobile the situation is even narrower: a proxy written into the phone's wireless network settings applies only on that network and is silently disabled when you switch to cellular data. For step-by-step setup, see Android proxy settings article.
At this point you have two options. The first is to narrow the scope and route only the jobs that can be covered: account pages, the store and the browser side. The second is to use a separate tool that provides per-application routing; that means extra software and maintenance, and it still does not remove the UDP limit on match packets.
Note
A client ignoring the proxy setting is not a fault. Applications are free to use their own network stacks; this choice is usually made for connection stability and update reliability.
Order matters in setup, because each step narrows the options of the next. First determine the scope: will only the browser, the entire operating system, or a single process be routed? Choosing a protocol before making this decision produces a choice you will later have to undo.
The second step is the protocol, decided by looking at which field the client offers: some tools show only an HTTP proxy field, others also accept SOCKS5. In the third step you enter the access credentials. The table below shows only the format of the fields; the real values are in your provider panel.
Field
Example format
What to watch for
The server sends
proxy.example.com
Check whether a hostname or an IP is requested
Port
8080
The port number alone does not determine the protocol
Username
username
May be left empty if you use IP authorisation
Password
password
Obtained from the panel, not shared with third parties
The fourth step is verification, and it is the most frequently skipped step. After writing the rule, with the proxy checker tool confirm that the exit is up, then verify the address shown in the browser. In the fifth step, test the connection separately with the proxy on and off and compare; an assessment made without measuring is misleading.
DIAGRAMThe five steps of setup and their correct order
You can scroll the diagram horizontally to inspect it
Each step narrows the options of the next; breaking the order produces choices you will later have to undo.
A suitable exit for the eFootball side
Stability matters for account and store tasks, while generous quota matters for update traffic; evaluate the two separately.
Choose whichever you need from our residential proxies, datacenter proxies, IPv6 and ISP solutions. Every plan comes with unlimited options, 99.9% uptime, rotating proxies, sticky sessions and 24/7 support. Ideal for web scraping, ad verification, SEO monitoring and digital data collection.
ISP ProxyStatic Turkish IPs registered to an ISP
ISP-registered static Türkiye IPs; they combine datacenter speed with the reputation of a real carrier. Ideal for long sessions and low-ping use.
Account verification and the effect of changing location
Your account is tied to an e-mail address and your in-game progress is held on the server side. The first step in protecting the account is to enable two-step verification: even if your password is compromised, no session can be opened without the second step. The verification code usually arrives by e-mail or through an authenticator application.
On the proxy side, it helps to know that the session token is independent of the IP. The token stays on the device; even if your exit address changes, the session identity remains the same. On the other hand, suddenly switching to an exit far from the account's usual country of use may trigger an additional verification step on the security side. This is expected behaviour.
The third topic is privacy. The proxy provider cannot read HTTPS content but can see which hostname you connect to and can log it. What a logging policy means is covered in the logging and privacy article; in scenarios where you sign in, this is a criterion to check before price.
Enable two-step verification before experimenting with proxies.
Keep the exit country consistent with the account's usual country.
Do not change exits frequently within the same session.
Read the provider's logging policy before you buy.
Anti-cheat and terms of service: where should you draw the line?
Online games run mechanisms that check client integrity. The purpose of these mechanisms is to protect fair play, and attempting to interfere with them both breaches the agreement and permanently puts your account at risk. No such method is described or implied on this page.
The relationship between proxy use and integrity mechanisms is often misconstrued. A proxy does not touch the client itself; it only changes the path by which certain requests go out. On the other hand, the game's terms of service may contain rules about how you connect, and those rules apply regardless of your provider's technical capabilities. The document to read before setup is not your proxy panel's help page but the game's terms of use.
If you are on a corporate or campus network, there is a second layer: the network's own acceptable use policy. If the network is not yours, a configuration that is technically possible may create an administrative problem. The right step is not to try to circumvent the filter but to ask the network administrator for permission; the details of this discussion are in access restrictions on school and workplace networks the article.
Caution
Circumventing account restrictions, running multiple accounts automatically or interfering with integrity software is not the subject of this page. Such attempts can result in the account being permanently closed.
Measurement: how do you see the cost of a proxy?
You can only decide whether an exit suits you by measuring. Three items are measured: round-trip time, transferred data and connection stability. For the first item, ping test is enough, and the measurement should be repeated at different times of day, because load in shared pools varies by hour.
Remember that a proxy adds a stop along the way: that is why a proxy does not reduce ping, and you will almost always see an increase in the measurement. The right question here is not "did it go down" but "is the added latency acceptable for what I am doing". For store and account pages an increase of a few tens of milliseconds goes unnoticed; for a real-time match it is not even in question, because that traffic falls outside the rule.
The second item is data. Download and update traffic produces most of the consumption; leaving it outside the scope provides meaningful savings on a metered residential exit . The third item is stability: if an exit is fast on average but drops intermittently, the average value misleads you. Measurements repeated at short intervals make this fluctuation visible.
From symptom to cause: common situations
Most problems fall under one of three headings: scope, authentication or name resolution. The table below links symptoms to these three headings.
Symptom
Possible cause
What to do
The setting was written, nothing changed
The client does not read the system proxy setting
Verify the exit address from a browser
Menus open, no match is established
Real-time traffic is outside the scope
Expected behaviour; narrow the scope
The domain name cannot be resolved
Resolution is done locally and is blocked
Try the setup that leaves resolution to the proxy side
Authentication is rejected
The authorised address list is not up to date
Authorise your current exit address from the panel
Updates download very slowly
The exit's bandwidth is insufficient
Move the download out of scope
The connection drops shortly after
Concurrent connection limit or end of quota
Check the limit and remaining quota in the panel
The name resolution heading deserves particular attention. When using SOCKS5, where the domain name is resolved depends on the client: some clients resolve the target on their own network and give the proxy only an IP, others leave resolution to the proxy. The difference has consequences for both privacy and access; details in DNS resolution in SOCKS5 the article.
On the authentication side, the most common scenario is that the line of a user recognised via IP authorisation is renewed. The moment the address changes, access drops and the error looks like a credential problem. If you use a dynamic IP, the username-password method requires less maintenance.
Who does it make sense for, and who does not need it?
If you play from your own country, use the store in the usual way and are happy with your connection, a proxy adds nothing for you. For in-match stutters, the places to look are the stability of your line, the quality of your wireless connection and the load produced by other devices on your home network.
The scenarios where a proxy helps are narrower: verifying how an account page or a campaign announcement looks in a different region, working with a fixed exit address, testing the source of an access problem via a second path. All of these stay on the HTTPS side and fall within the area the rule can cover. The basic security questions to ask when choosing a provider are gathered in the is using a proxy safe article.
The picture is similar for other games in the same category, but the details differ; the EA SPORTS FC page covers the peer-to-peer connection side separately. For a general overview you can take a look at the game proxy guides section.
Frequently asked questions about eFootball and proxies
01Do guides written for PES still apply to this version?
In terms of the fundamental network behaviour distinction, yes. Back when the series was known as PES, the account, content and matchmaking side worked on request-response logic, while the match side ran on a continuous stream of packets. The setup screens may have changed, but the boundary of proxy coverage sits in the same place.
02I entered the setting but nothing changed on the eFootball side; why?
The most likely reason is that the client does not read the system proxy setting. Applications are free to use their own network stacks. Verify that the rule is working on the system by checking the exit address shown in a browser on the same device; if the address has changed but the game side is unchanged, the client is ignoring the setting.
03Does a proxy shorten matchmaking time?
No, there is no reason to expect that. Matchmaking time depends on queue load on the server side and the mode settings you choose. Adding a stop along the way lengthens the time requests take to arrive, and that does not improve queue behaviour.
04How is a proxy configured on the mobile version?
On iOS and Android you fill in the HTTP proxy field in the wireless network settings. This definition applies only to that network, does not cover cellular data, and is disabled when you change networks. Whether the application reads this setting at all is a separate question.
05Do requests using QUIC pass through the tunnel?
They do not. QUIC runs over UDP 443 and CONNECT cannot enter a TCP tunnel opened with it. These requests either go out directly or, if UDP is blocked on the network, the client falls back to a TCP-based path. As a result, some HTTPS requests within the same application may fall outside coverage.
06Does using a proxy pose a risk to my account?
Technically a proxy does not touch the client; it only changes the exit path of certain requests. The risk comes mainly from two places: routing traffic through an untrusted provider, and use that conflicts with the game's terms of service. Both are matters of choice, not of technology.
07Can the provider see my in-game conversations?
It cannot see content carried over HTTPS; the proxy only transports encrypted bytes. However, the name of the destination you connect to is readable on the proxy side and may end up in retained logs. That is why the logging policy is a decisive criterion when choosing a provider.