Proxies and Why Some Servers Hide Their Real Address

Some servers publish an address that is not their machine. Traffic arrives at that address, gets inspected, and is forwarded on to the real one, which is never advertised anywhere.

That arrangement solves two problems and introduces three, and it is worth understanding both halves before deciding you need it.

What a proxy actually does here

A player connects to an address you control. Something at that address receives the traffic, decides whether to pass it on, and forwards the accepted portion to the machine running the game.

The machine's own address is never given out, so an attacker aiming at what you published is aiming at the filtering layer rather than at your server.

That is the entire idea. Everything else is detail about where the layer lives and what it is allowed to inspect.

The two problems it solves

Hiding the origin. If the real address is unknown, a flood aimed at your published address hits infrastructure built to absorb it rather than a game server on a modest uplink. What DDoS protection buys you covers the wider subject; a proxy is one of the shapes protection comes in.

Giving you a stable address. The published address stays the same while the machine behind it changes. This makes moving hosts almost invisible to players, which is the same benefit a domain gives you and stronger, moving a server between hosts covers why the address is the hard part of a migration.

The three problems it introduces

Latency. Traffic takes a longer path. How much longer depends on where the proxy sits relative to the players and the server, and it can be anywhere from negligible to fatal. A proxy in the wrong place adds more delay than the protection is worth.

A second thing that can fail. Your server can be perfectly healthy and unreachable because the layer in front of it is not. This is a real category of outage that servers without a proxy simply do not have.

Protocol awareness. A generic TCP or UDP forwarder does not understand your game. That is usually fine for gameplay traffic and frequently breaks status queries, which is how a working server disappears from every listing at once. How game server queries work explains why the query path can fail independently of the game.

Which games this works well for

Minecraft is the best case, because the protocol is TCP and there are proxies built specifically for it. BungeeCord, Velocity and Waterfall exist primarily to let one address serve several backend servers, and they understand the protocol properly: including the handshake, so player identity survives the hop.

That multi-server capability is frequently the actual reason to run one rather than the protection: a network with a lobby, a survival world and a creative world behind one address is a proxy setup, and when to run a second server covers whether you want that at all.

Source-engine games are harder. UDP, and the query and game ports are separate. Proxies exist and the configuration is fussier, and the failure mode is the invisible-server problem above.

FiveM reports over HTTP, which behaves differently again and is its own source of listing confusion, why a FiveM server shows offline covers it.

The mistake that makes all of it pointless

Leaking the origin.

A proxy protects nothing if the real address is discoverable, and it is discoverable more often than owners assume:

Historical DNS. What your domain resolved to a year ago is public. An A record from before you set up the proxy is a permanent hole.

A web panel or website on the same machine. If your panel answers on the origin, the origin is published.

Subdomains. mc.example.com behind a proxy and panel.example.com pointing straight at the box is a common and complete failure.

Plugins that phone home, status pages, and screenshots of a console.

Checking this takes an afternoon and it is the difference between protection and the appearance of it. Game server security basics covers the wider surface.

When you should not bother

Most servers, honestly.

If nobody has attacked you, the latency cost and the extra failure point are real and the benefit is hypothetical. Baseline filtering from a reasonable host covers the common case.

If your host already filters, you may be adding a second layer that does the same job worse.

If you cannot control where the proxy sits, you are accepting an unknown latency penalty for your entire population.

If it is a single small server, the multi-server benefit does not apply and the protection question is the only one, which is better answered by choosing a host that filters.

The case where it clearly makes sense: you have been attacked, or you are running several backends behind one address, or both.

If you set one up

Test the query path from outside. Before announcing anything. A server that plays fine and does not answer queries is invisible on every listing and looks identical to a dead one.

Measure the added latency from your actual players, not from your own connection. The person furthest away is the constraint.

Firewall the origin to accept traffic only from the proxy. Otherwise the origin is still directly reachable by anyone who finds it, and the whole arrangement is decoration.

Monitor both layers. Monitoring uptime covers why finding out before your players do is most of the value, and with a proxy there are now two things that can be the reason.

Keep it patched. It is internet-facing software with access to your traffic.

The Minecraft case, in more detail

Worth separating, because it is the one situation where most operators end up running a proxy for reasons that have nothing to do with attacks.

BungeeCord is the oldest and the least maintained of the three in common use. It works, it is widely documented, and it is where most older guides point.

Waterfall was a fork of BungeeCord with performance and correctness fixes. It is no longer developed and its own maintainers point at Velocity.

Velocity is the current answer for a new setup. Faster, better designed, and with a security model that does not have the historical holes the older proxies did.

The security model is the part worth understanding rather than copying from a guide. A backend server behind a proxy trusts the proxy to say who each player is. If that backend is reachable directly, anybody can connect to it and claim to be anybody, including an administrator. This is not a theoretical hole; it is the standard way networks running a proxy get compromised.

Two things close it. Firewall the backends so they accept connections only from the proxy, and enable the proxy's own forwarding authentication so a connection without the right secret is rejected. Doing one without the other leaves the door open, and doing neither is the default state of a setup somebody followed a tutorial for.

Where the proxy should sit

The single decision that determines whether the latency cost is acceptable.

Close to the players, not close to the server, if the two differ. Traffic goes player to proxy to server, and the leg you can improve is the first one. A proxy in the same region as your population and a longer hop to the backend is usually better than the reverse.

In the same facility as the backend, if your population is spread evenly. Then the proxy adds almost nothing and you get the origin protection for free.

Never on the same machine as the game server. It defeats the entire purpose: the address you are protecting and the address absorbing the flood are the same one.

Measure rather than assume. The number that matters is what your furthest regular sees, before and after, and it is a five-minute test that most people skip.

Cheaper things that solve most of it

Worth trying in order before adding a layer.

A domain with an SRV record gives you the stable-address benefit with none of the latency or failure cost. If moving hosts without telling anybody was your reason for considering a proxy, this is the whole answer. Custom domains and SRV records covers setting one up.

A host that filters at the network edge gives you the protection benefit without running anything. Most reputable game hosts include baseline filtering, and it handles the volumetric attacks that a hobby server sees. Choosing a host covers asking about it specifically.

Not publishing the origin in the first place is free. Keep the panel on a different machine, keep the website elsewhere, and check what your domain resolved to before you cared.

Rate limiting at the game layer handles a category of abuse that no proxy sees, because it arrives as legitimate connections. Game server security basics covers the parts of the surface that filtering does not touch.

The summary

A proxy is a tool for two specific situations — hiding an origin that is being attacked, and putting several backends behind one address, and it is overhead in every other case.

If you are considering one because it sounds like good practice rather than because you have one of those two problems, the honest answer is that a domain, a host that filters, and an origin nobody has published gets you most of the benefit with none of the cost.