Elden Ring Proxy: Which Flow Enters the Tunnel and Which Stays Outside?

On PC, Elden Ring runs under a store client. The process that downloads the game and the process that runs it are not the same, and the two do not read network settings in the same way. Most of the confusion on the proxy side arises from this distinction: the rule is written in one place and the expected effect is looked for in another.

The second distinction is the type of traffic. Sign-in, version checks and matchmaking calls travel over TCP; a classic proxy can carry them. The session established between players, however, is real-time and mainly uses UDP. Only TCP sessions can pass through the tunnel an HTTP proxy establishes with CONNECT ; that is why the last piece stays outside the scope in most setups.

The sections below build the scope step by step: which flow is caught by which configuration, where the SOCKS5 UDP path ends, how a peer-to-peer connection is affected by an intermediate stop, and where to read the measurement.

Which processes reach the network, and in what order, when you launch the game?

The order is almost the same in every setup. First the store client verifies its own session and compares the installed version. This step is a low-volume HTTPS exchange over TCP; if your proxy rule is defined system-wide it passes through here and the sign-in screen opens without trouble.

Next comes the patch check. If a version is missing, the download is served not from the endpoint the game talks to during play but from a content delivery network. The number of transferred bytes jumps here; if you use a metered exit, this is also the item that determines the bill.

In the third step the game process starts and sets up its own network stack. Calls to the matchmaking service are still over TCP. Once matchmaking completes, the session is established between players and the flow becomes real-time; this is exactly the part that most often falls outside the rule you wrote.

There is one more detail. The asynchronous online layer, that is the signs and traces left in the world, runs in the background with small calls even if you are not matched with anyone. Because this layer travels over TCP, it falls within the proxy's scope. If the exit is slow or distant, the first symptom you notice is these elements loading late; the game runs smoothly on its own while the world looks empty.

Why do the store client and the game process need separate rules?

A store client may keep its own connection setting or read the operating system's proxy definition. The game process, however, usually cares about neither: the engine's network layer opens sockets directly and does not ask about the system's HTTP proxy definition. That is why a setting written in the store client is not automatically applied to the game's own traffic.

The practical consequence is this: while downloads and library operations go through the tunnel, the in-game connection leaves over your normal line. Rather than mistaking this for a fault and widening the rule, it is healthier to set the scope deliberately. To see where the fields on the store client side are written, store client proxy settings article.

If you are going to run both your normal work and routed traffic on the same machine, a definition that narrows the scope to a single process produces far fewer surprises than a system-wide setting. When you write a rule covering the whole machine, update services, cloud backup and background tasks you do not even know the names of also flow through the same exit; the item that exhausts your quota at the end of the month is usually not Elden Ring but this silent traffic.

• Note where you wrote the rule: system, client or single process.
• Verify downloads and the game session separately.
• With a system-wide definition, account for background services adding to your quota.

Why do patch packages not catch the rule you wrote?

Update files are served from the distribution network's node nearest to you. That choice is made according to the address the request comes from; when you use a proxy, "nearest" is now calculated from the exit node's location, not yours. A patch downloaded from an overseas exit may come down slower than the same file over your normal line.

The second effect is quota. Patch packages can reach gigabyte scale, and on residential or mobile packages pricing is based on transferred data. Downloading one version through the tunnel can consume a significant portion of the monthly quota in a single session. If you want to do the maths in advance, the bandwidth calculation article helps you set the scale.

The third point is interruption. If the exit address changes during a long download, the transfer may break and the client will have to fetch the chunk again. In a rotating pool this behaviour is normal; for large downloads, using a fixed exit is the simplest way to avoid paying for the same byte twice.

After the download finishes, the client verifies the files and re-requests any missing chunks. On an unstable exit this verification step continually generates new requests; from the outside the download looks finished while traffic continues. If you are monitoring your quota, take the measurement not the moment the download ends but after the client has gone completely idle.

The SOCKS5 UDP gate: where does ASSOCIATE end?

When you want to reach an encrypted destination, an HTTP proxy establishes a pipe between the two ends with a CONNECT request, and only TCP sessions can flow through that pipe. The proxy does not produce the encryption; once the pipe is established, the client and the destination perform the TLS handshake between themselves and the intermediate stop cannot read that content. The details of the method are in the the CONNECT method article. For Elden Ring, the conclusion fits in a single sentence: the real-time data flowing while you roam the world never enters this pipe.

On paper, SOCKS5 can close this gap; the protocol's UDP ASSOCIATE step defines a separate path for flows other than TCP. But three conditions must be met at once: the proxy server must support UDP association, the intervening network must allow this flow and, most importantly, the client must know how to use this path. The vast majority of game clients have no SOCKS5 setting field at all; when they do, most use only the TCP side. How the mechanism works is SOCKS5 UDP support article.

So the honest picture is this: in Elden Ring a proxy in practice covers sign-in, store, patch and matchmaking traffic. Moving the game session itself onto a SOCKS5 exit is not possible unless the client supports it, and attempts to force it usually end with the connection never being established at all.

Peer-to-peer sessions, NAT mapping and hole punching

In a session established between players, both sides are behind a home router. The connection is established by both sides sending packets outward to open a temporary mapping on the router, and by the matchmaking service announcing these mappings to each other. This is called hole punching and depends entirely on the mapping remaining predictable.

When an intermediate stop is added, this predictability weakens. How address translation works and how it differs from a proxy is explained in detail in the proxy versus NAT comparison . In short: a proxy is not a translation layer but an intermediary, and it does not establish the direct path the game expects.

With mobile exits the picture gets harder still. On carrier networks the same public address is shared by a large number of subscribers; the details of that structure are in the What is CGNAT article. A connection request cannot be opened from outside towards a shared address, so a peer-to-peer session cannot be expected to be established towards you. A wired line and a normal router configuration are far more decisive in this game than a proxy.

The diagnostic order follows from this. First try a wired connection instead of wireless, then check whether two routers are chained one after another at home, then find out whether your provider gives you a public address of your own. These three steps either solve most connection problems or narrow down their source. A proxy is not a repair tool on this list; it comes up only after you have exhausted the list, and only for the TCP side.

How much do four different definitions touch Elden Ring's four flows?

Rather than describing the scope in a single sentence, placing the setup types side by side is more illuminating. The table below summarises to what extent four different definitions that can be written on the same machine touch the game's four separate flows.

The "typical mistake" column in the table shows the false expectation most often encountered in the field. Before deciding whether the rule works, you need to see that the exit itself is up; proxy checker tool shows whether the address you have responds and which protocol it speaks over.

When choosing a setup, this order makes things easier: first write down which flow you want to route, then choose the narrowest scope that can carry it. A broad scope is not always more control; more often it is just an extra variable that makes diagnosis harder.