Proxy in Europa Universalis IV: Which Traffic Goes Through the Tunnel?

The shortest way to understand this game's network side is to accept that even though you see a single program on screen, several independent processes on your computer are talking. The Paradox launcher makes its own HTTPS requests, the store client pulls updates with its own downloader, and the game client connects to an entirely different endpoint once the session is established. From the proxy's point of view these are three separate clients.

In practice this means: an exit defined in your browser does not affect the game at all; an exit defined in the store client may cover the launcher but may not cover session traffic. Behind the sentence "I enabled the proxy but nothing changed" there is usually this scope mistake.

Let the second point be clear from the start: a proxy is not a speed tool but a routing decision. It adds an extra hop to your connection. What changes is the exit address the other side sees; not the game's response time.

How many separate pieces does an EU4 session split into on the network?

When you start the game, the first window that opens is not the game but the launcher. The launcher is an application in its own right: it compiles the list of installed add-ons and mods, fetches content information, determines which configuration the game will start with, and only then runs the actual client. These two processes sit in the same folder but are two separate programs as far as the operating system is concerned; a network setting applied to one does not automatically carry over to the other.

The third piece is the store client you got the game from. It handles patch and content downloads, it carries authentication, and in most cases the first step of a multiplayer invitation also goes through it. The store client has its own proxy field and does not always do the same thing as the system-wide setting.

The fourth piece is the actual game session. Here the other end does not have to be a company server; in grand strategy games one of the players usually hosts the session and the others connect to them. In other words, the address at the other end of the tunnel is most often your friend's home connection.

Any setup made without separating these four pieces remains half-finished. The correct order is this: first decide which piece you want to route, then write the rule where that piece reads it, and finally verify through an independent path that that piece's exit has actually changed.

TCP or UDP: which packet enters the tunnel?

What proxy protocols can carry is fixed and independent of what the game wants. An HTTP proxy opens a tunnel for HTTPS targets with the CONNECT method; this tunnel carries only TCP. SOCKS5 sits at the transport layer and by default also establishes a TCP connection. For UDP to be carried, SOCKS5's UDP ASSOCIATE command must be used, and for that command to work two conditions must hold: the proxy server must support it, and the client must know how to use it.

The second condition fails far more often in the field than the first. Many SOCKS5 services on the market never enable UDP; and among those that do, there is practically no game client that speaks UDP over SOCKS5. Game clients open their own sockets directly; they are not required to read the system's proxy setting. So the realistic expectation is this: your proxy rule covers login, store, launcher and patch download traffic; it most likely does not cover real-time game packets.

If you really want to widen the scope, you need to make the decision not in the protocol choice but in the layer choice: a per-application routing tool or a device-wide tunnel works regardless of whether the application supports proxies. For the differences in overhead and authentication between the protocols, the SOCKS5 proxy page and the SOCKS5 UDP support article are a good starting point; if you want to see how the tunnel is established, the the HTTP CONNECT method article explains it step by step.

The launcher is a separate application and is configured separately

What the launcher does is largely ordinary HTTPS traffic: fetching the content list, getting mod information, comparing versions. This is the most proxy-compatible part. The launcher usually runs with a network stack that uses the operating system's proxy setting; a system-wide rule therefore works here in most setups.

Patch and content downloads are a different story. The download is mostly handled by the store client, and in terms of size this is the heaviest traffic of the day. A version update is measured in gigabytes; pushing that through a residential or mobile exit billed by data transferred is the fastest way to burn your quota without playing at all. Moreover, if the download comes from the store's nearby distribution node while the tunnel exits from another country, it takes an unnecessary detour and the time lengthens.

A practical rule of thumb: small, frequent requests (list, version, identity) are suitable for routing, while large, infrequent transfers (patches, full installs) should stay on your ordinary line. To see where to enter the store client's proxy field, the steps in the Steam proxy settings article can be adapted to other stores with the same logic.

There are also setups that share the mod folder over the network. In these, file access stays on the local network and is not the proxy's business; if you can't reach the shared folder while the tunnel is up, the problem is most likely that local network traffic has also been routed into the tunnel. Adding an exception to your rule that excludes local address ranges solves this.

The session is hosted by a player: what does that change for the proxy?

In grand strategy games, a multiplayer session is not established by entering a matchmaking server pool and connecting to a data centre assigned to you. Usually one of the players hosts the session; the others join via an invitation or a list. In other words, the address at the other end of the tunnel is not on a company's backbone but behind a home connection.

The first consequence of this is on the routing side. If two players are in the same city, the path between them is already short; putting an exit in another country in between does not shorten the path, it lengthens it. The case where a proxy is meaningful is the rare one where the default path between you and the host is circuitous and the exit sits on a more direct backbone; this is not a rule but an exception that cannot be assumed without measurement.

The second consequence is on the reachability side. The hosting side must be able to accept incoming connections; this is usually a matter of port forwarding or NAT behaviour on their router and is not solved by changing your exit. If you have problems on the joining side, first work out which side is blocked: is the host unreachable at all, or does the handshake start and then drop?

The third consequence concerns corporate and campus networks. On these networks the outbound port range is narrow and game sessions are often closed off from the start. Here the proxy's function is not to shorten the distance but to find a traffic form that can pass over a closed path; what the limits are is detailed in the access blocks on school and workplace networks article. The network administrator's rules are your responsibility; none of the steps on this page are recommended for use that violates institutional policy.