Proxy for Stellaris: Scope, UDP and the Facts About NAT

Peer-to-peer connections, NAT type and hole punching

In the model where one of the players hosts the session, the connection is established between two home networks. Both sides are behind NAT: the router maps the internal address to an external one and only lets an inbound connection through if a mapping was opened earlier. That is why a handshake method called hole punching is used to connect two NATs: both sides send packets outward at the same time, and matching mappings are created on both routers.

The proxy has no place in this picture. A proxy exit does not preserve the source port behaviour that hole punching requires; what is more, the intervening node establishes the mapping through itself, so the other side sees the exit's address rather than your router's. In most setups the result is that a peer-to-peer session cannot be established over the proxy at all. Why NAT and a proxy do different jobs difference between a proxy and NAT article.

On a line using symmetric NAT or carrier-grade address sharing (CGNAT), the situation is tighter still: inbound connections are not accepted, and you cannot even configure port forwarding on the router. Here the workable solution is not a proxy but asking your ISP for a real public address, or leaving the hosting to a player whose connection allows it.

One more distinction needs clearing up: hole punching is not a way of getting around a security measure but a standard connection-establishment technique in which both sides take part willingly. It is the step needed for routers to recognise the request when two players want to connect to each other. That a proxy does not support this step is not a shortcoming but a natural consequence of its design: the proxy establishes the connection itself on the client's behalf and does not preserve your socket's footprint in the outside world.

Post-setup verification: what do you prove, and how?

Writing a rule does not show that traffic is actually going through it. The first step in verification is reading the exit address; the second is measuring which processes are covered. These are different questions and call for different tools.

Domain name resolution is what most setups overlook. When using SOCKS5, the client may resolve the target on its own network and hand the proxy only an IP; in that case the server you connect to is visible to your local DNS server, and a delivery node close to you is selected while the connection exits from another country. DNS leak test measures this.

The second check is whether the proxy adds headers to the request. Some exits add the X-Forwarded-For or Via header; that means the other side sees on the very first request that the connection is coming through an intermediate node. Proxy anonymity test reports which headers are being carried.

The third is a resilience check. A game client and a background update service together open more concurrent connections than you would expect; when the ceiling is reached, the symptom is not an error message but a silent drop. What the limit means and how to plan for it concurrent connection limit article.

Which type of exit, which location?

The choice of type depends on the nature of the work. In download-heavy use the deciding variable is bandwidth; here a datacenter exit is both the fastest and the cheapest option. When an exit close to a home network profile is needed, residential or ISP is preferred, but their bandwidth depends on the line and the cost grows quickly on large transfers.

There is only one rule for the location decision: do not lengthen the path. Keeping the exit close to both you and the target avoids a needless intercontinental detour. If you are connecting from Turkey and playing with a friend in Turkey, an exit on another continent brings nothing but harm.

The degree of sharing matters no less than the type. An exit in a crowded pool behaves erratically at peak hours even when it is the right type. Over a long session that variability shows up as drops that a one-off measurement never reveals.

The address type also determines how easy diagnosis will be. With a static exit, you have fixed the variable when you hit a problem: you can try again from the same address and compare the results. With a setup that hands you a different address from the pool each time, you cannot run the same test twice, because the second attempt goes out over an entirely different path. In a game with long sessions, this is the difference you cannot read from a product's specifications but feel the most in practice.

Symptom and cause: a quick diagnostic table

The certificate warning is the most serious item on this list. A properly configured HTTPS proxy does not interfere with the TLS session; it only carries encrypted bytes. If you see a warning, your traffic is being decrypted and re-encrypted somewhere; clicking past it in a session that carries account details means handing your credentials to the intervening party in readable form.

The other items all share the same method: one variable at a time. If you change the exit, the protocol and the rule layer together, you will never learn why, whatever the outcome. Writing down what you have tried in a short list keeps you from walking the same path twice.

Latency budget and continuity in long sessions

A proxy adds a stop along the way; the total path grows longer. For that reason, setting up a proxy does not improve the game's latency and in most setups increases it somewhat. In a game with a slow turn tempo, a few tens of milliseconds go unnoticed, but in long sessions the real issue is not latency but continuity: even a brief interruption disrupts synchronisation and can drop you from the session.

Three things affect continuity. The first is the load on the exit: in shared pools, peak hours change the measurement. The second is the session window: if the sticky duration is set shorter than your working session, the address changes without your noticing and the connection drops. The third is the stability of your own home line; a proxy does not fix that, it adds its own share on top.

Do not measure once and leave it at that. Measuring the same exit at different times of day exposes the variable a one-off test hides. If you are planning a long session, take the measurement at the hour the session will start.

Finally, the scope decision bears repeating: what you can expect from a proxy in this game is access and auditability. If you are playing on your own line, from your own country, with players you know, adding a layer in between has no concrete payoff.

Compliance, privacy and cases where a proxy is unnecessary

This page covers access, privacy and network management scenarios. Complying with the terms of use of games and stores is the user's responsibility; no use involving account multiplication, automated play or interference with the game's security measures is described or recommended here.

On the privacy side, what you need to know is clear: a proxy provider cannot read encrypted content, but it can see and log which addresses you connect to. That makes choosing a provider a matter of trust as much as a technical decision. Do not entrust a stream carrying account details to an exit without reading its logging policy.

The cases where a proxy genuinely helps are narrow: using a single auditable address when going out from a corporate or campus network, managing multiple machines through a single exit, recording how a store page looks from another country, or isolating the source of a network problem by changing the path. In most scenarios outside these, the right answer is not to add the layer at all.