Enshrouded and Proxies: Scope, Download Cost and the Account Side

The most common way to play together in Enshrouded is keeping the world on a separate server: the machine stays on continuously, players join whenever they want, and the save sits in a single place. This arrangement splits the connection into two separate parts, and the proxy debate becomes clear at exactly that split.

The first part is access to the server. Game data flows over UDP; a classic HTTP proxy does not carry it, and SOCKS5 carries it only under narrow conditions. The second part is the account and content side: store, library, update downloads. This traffic runs over TCP and can be routed.

The sections below address these two parts separately; they also explain what happens on the account side when you change location, why this relates to security measures, and how to manage it smoothly.

What parts does the connection consist of?

The first thing that runs before you launch the game is the platform client: library information, ownership verification and, where applicable, the update check happen here. All of these requests go over TCP, protected with TLS. The other side sees only your exit address; your session's identity is carried separately.

The second part is server selection. You can join a world directly by address or pick one from the list. The list request runs over TCP; the response times in the list, however, are calculated from probes the client sends directly and are not affected by the system proxy setting.

The third part is the game itself. Character position, world changes and events flow continuously as short packets. The transport type of this flow is UDP; the reason it is preferred is that in games, processing the next packet gives a better result than waiting for a delayed one. That same property is what makes this traffic hard to carry over a proxy.

The fourth part is content downloading. The initial install and large updates come from the distribution network over HTTPS. This is the decisive item in terms of quota and the side most often neglected in the proxy decision.

Update size, distribution node and download speed

Content delivery networks route a request to a node near you based on the resolved address and the network topology. When you connect directly, this usually works well: a nearby node is chosen and the download approaches your line's capacity. When a proxy comes into play, the equation can break, because the choice is now made according to the proxy's location rather than yours.

A second effect is added on top. If domain name resolution happens on your network, a nearby node is returned while the connection is made from the proxy's country; the result is that data packets take an unnecessary detour. Checking where resolution happens is therefore important, and it is a common cause of unexplained drops in download speed.

The practical conclusion is clear: keeping large downloads outside the proxy is both faster and cheaper in most setups. If you keep the scope per application, update traffic goes over your normal line while your browser and account traffic keeps going through the exit. To put numbers on it, you can use the method in the bandwidth calculation article.

The conditions for carrying UDP: how far does SOCKS5 go?

The SOCKS5 protocol defines a way to carry UDP. The client establishes a control connection with the proxy over TCP, sends the UDP ASSOCIATE request, and the proxy announces a relay point of its own. From then on the client sends UDP packets to that point; the proxy forwards the packets to the destination and carries the returning responses back.

This mechanism has two separate dependencies. The first is the proxy server: many providers offer TCP service only and never enable UDP relaying. The second is the client: if there is no SOCKS5 field in the game's settings, the client does not send this request on its own. If either condition is missing, game data never reaches the proxy and goes out over your normal line. A detailed description of the method is in SOCKS5 UDP support the article.

Even if the conditions are met, expectations must be set correctly. Because the relay point sits in between, packets travel a longer path and every relayed packet carries an extra header. If the packet size exceeds the smallest MTU value along the path, fragmentation begins; in fragmented UDP traffic, losing a single fragment renders the whole packet unusable. So the method makes carriage possible; it does not improve quality.

For that reason, with titles like Enshrouded where game data flows over UDP, the sensible approach is to apply the proxy to the account and content side and leave the game flow on your normal line. To compare protocol choices in general, the what port numbers mean article will also be useful.

What does a proxy cover, and what does it not?

Seeing the scope list up front eliminates most of the misdiagnoses that come later. A proxy definition carries the TCP connections of the applications routed to it. That includes account login, library requests, store pages and download sessions.

The things that fall outside the scope are at the lower layers of the network. The game's UDP flow, the latency probes in the server list, local network discovery and your router's NAT behaviour are among them. A proxy definition does not create a NAT mapping, does not accept incoming connections, and therefore does not solve the "nobody can connect to me from outside" problem. The conceptual difference is explained in proxy versus NAT comparison .

The practical upshot of this distinction is this: if after setup your exit address has changed when you check from the browser but the game behaves the same, the setup is working and the game was already out of scope. Verifying the address on the my IP address page lets you make this check in seconds.

The way to widen the scope is not a more aggressive setting but choosing the right layer. If you want a solution that wraps all device traffic, the tool you are looking for is not a proxy; a proxy is a routing rule and covers only where it is defined.