The Elder Scrolls Online and Proxies: Which Part of the Traffic Is Routed?

The quickest way to make sense of ESO and proxies is to clarify a single question: which traffic? The game itself, the downloader pulling an update package and the account page you open in a browser do not share the same network path. When you route one and leave the other in place, the resulting picture often looks like "the proxy is broken" — when in fact it is simply out of scope.

The second point is on the client side. Like most game clients, the ESO client has no field where you can enter a proxy server, port and password. That is why the routing decision is made not inside the game but at the operating system, application-rule or router level; the scope is determined together with that decision.

The third concerns expectations. A proxy is a path-changing decision, not an accelerator. Your exit IP address changes, your account's identity does not; the path gets longer, not shorter. Every recommendation on this page is built on those two sentences.

The ESO client does four separate jobs on the network

When you launch the game, the first component to run is the downloader that checks file versions. It fetches a version list, compares it with the files you have, and pulls the missing parts from a content delivery network. The traffic takes the form of ordinary HTTP/HTTPS downloads; it produces long, large transfers rather than small requests, and on a metered line it becomes the biggest item in the monthly quota.

The second part is login and account verification. When your credentials are verified, the address seen on the server side is your exit address; if you use a proxy, that of the proxy server. On this screen you also choose which megaserver to connect to, and that choice determines which cluster your session will live in. Your character lists are separate per megaserver; a character created on one does not appear on the other.

The third part is the actual game session. The volume of data transferred here is small but continuous: position updates, ability usage and world events flow as short messages. This traffic is not sensitive to bandwidth but to the stability of latency and the loss rate. A few hundred kilobits per second is enough, yet a single half-second stall is felt immediately in game.

The fourth part is the web side: account management pages, subscription and store pages, and files downloaded by add-on managers. All of this is ordinary HTTP traffic flowing through a browser or small helper programs, and it is the easiest part to route through a proxy.

What does SOCKS5's UDP ASSOCIATE method cover, and where does it stop?

An HTTP proxy opens a tunnel to encrypted destinations using the CONNECT method, and that tunnel carries only TCP. Every flow in which the game client uses UDP falls outside this tunnel: it either goes out directly, or, if UDP is blocked, the connection is never established at all. SOCKS5 differs at this point; the protocol's UDP ASSOCIATE command lets the client open a UDP relay point on the proxy, and datagrams are forwarded wrapped in a small SOCKS5 header.

In practice there are three obstacles in front of this capability. The first is the server side: many providers keep UDP relaying disabled because of abuse risk, meaning the SOCKS5 access you have works only for TCP. The second is the client side: for an application to speak SOCKS5 it must have implemented it in its own network stack, and the majority of game clients have no such capability. The third is the network side: the path to the relay point must stay open, the TCP control connection must not drop, and the mapping behind NAT must stay alive.

On top of that comes packet size. SOCKS5 encapsulation adds a few bytes to every datagram; in a flow running close to the MTU limit this can lead to fragmentation and to the loss of an entire fragmented packet. Since UDP itself does not retransmit, the application layer bears the consequences.

• Do not assume "I got SOCKS5, so UDP must work"; ask the provider explicitly.
• Test web and download traffic running over TCP separately from the game session.
• Even if relaying is enabled, the UDP path closes silently when the control connection drops; interpret disconnects accordingly.

For the protocol's general capabilities, the SOCKS5 proxy page, and for a technical description of relay behaviour, the SOCKS5 UDP support article goes into more detail. A one-sentence answer from your provider to "is UDP relaying enabled?" produces results faster than hours of trial and error.

Which tool measures packet loss, and how do you read the results?

Most of the "teleporting", ability delay and sudden disconnects you feel in game stem not from high latency but from some packets never arriving at all. Diagnosis therefore starts by separating two distinct quantities: round-trip time and loss rate. If the average time looks low but there is loss, the picture is not "good".

The measurement must be taken against a fixed target over a long period. A one-off result hides the fluctuation that appears at peak hours; take at least a few minutes of uninterrupted measurement and repeat it at different times of day. If you want to see the hops along the path, on Windows tracert and pathping, and on Linux and macOS mtr do the same job at different levels of detail.

The most common mistake is taking loss at an intermediate hop seriously. Routers along the path treat control packets aimed at themselves as low priority; loss that appears in the middle is often not real. What matters is loss persisting at the last hop, that is, at the destination, and that loss is carried along the whole path. Remember also that the outbound and return paths can differ: a one-way problem looks blurred in a two-way measurement.

Start the measurement with ping test , verify with with the proxy checker tool whether the exit is up, and always make the comparison in the same time window, with the proxy on and off.

What does the intervening hop add to latency, and where is the exception?

A proxy places an extra hop in your connection: the request first goes to the proxy server, from there it reaches the game server, and the response comes back along the same path. Because the physical distance covered grows, using a proxy increases latency in most setups; a proxy does not lower your ping and should not be marketed as an accelerator.

The size of the added time depends entirely on geography. An exit in the same city as you adds very little to the path; an exit on the same continent creates a noticeable difference; and an exit on a different continent can make the game session unplayable. Moreover, the price you pay is not just average time: every extra hop also means a new chance for jitter and loss.

The only real exception is when your default route is needlessly circuitous. On some lines, traffic to a nearby destination detours through a distant exchange point; in such a case an exit on a better-connected network can shorten the path. This is not a rule, it cannot be assumed without measurement, and it must be tested separately for every line.

The practical decision is simple: choose an exit close both to you and to the target, and measure every exit you choose before putting it to work. For a player connecting to the European megaserver, an exit within Europe is a reasonable starting point; the options are on the the location listside, for example Germany with a Frankfurt exit . For the components of latency, see the proxy latency article, and for common misconceptions specific to gaming, see the article on whether a proxy lowers gaming ping.