Itnetic TechnologiesWhy the address matters more than it does for a website
Protection for a Minecraft server works by being in the path. Connections arrive at the protection network, get screened, and only the survivors are relayed to your machine. Everything described in Minecraft server DDoS protection depends on that.
An attacker who knows your machine's real address does not have to use that path. They send the flood directly, and every layer you paid for is standing in a corridor nobody is walking down. This is the single most common reason a server operator says "we have protection and we still went down".
How the address leaks
Old DNS records. By far the most common. You point play.example.com at the protection network, and an A record on the bare domain, on an old subdomain, or on something like mc.example.com or map.example.com still points at the machine. Historical DNS is archived by several public services, so a record you deleted last year is still queryable.
Something else on the same machine. A website, a dynmap, a control panel, a Git server, a mail service. If any of them resolves directly to the box, the box is public. This is why "the Minecraft port is protected" is not the same as "the machine is protected".
Server listing sites. Many record the resolved address at the time you submitted your server, and some display it. If you listed the server before moving behind protection, assume the old address is on record somewhere.
Your own history. Screenshots in a Discord, a forum post from when you were troubleshooting, an old client's server list on a member's machine, a support ticket. Addresses persist in places you do not control.
Error messages and headers. Anything on the machine that reports its own hostname or address in an error page, an email header, or a certificate can publish it without anybody attacking anything.
What to actually do
1. Assume it leaked and move. If the address has ever been public, changing it is the only real fix. Get a new address, and make sure it has never appeared anywhere — a fresh IP on the same provider that you already used for something else is not fresh.
2. Firewall the server to the protection network. This is the step people skip and it is the one that matters most. The server should accept connections on the game port from the protection network's addresses and from nowhere else. Without this, knowing the address is enough to bypass everything, and with it, knowing the address is worth much less.
3. Move everything else off the machine, or behind protection too. Your website, your map, your panel. One unprotected service is enough to publish the address of all of them.
4. Clean up DNS. Every record that resolves to the origin, including ones you think nobody uses. Check the bare domain, common subdomains, and any mail records that point at the same host.
5. Do not put the real address in the MOTD, in a Discord channel topic, or in a support reply. It sounds obvious. It is still the most common way an address comes back after a move.
The general web version of this problem is covered in How to hide your origin IP; the same reasoning applies, with the addition that a game server usually has more services bolted to the same machine.
The trap on the other side: offline mode behind a proxy
There is a second address-related failure that is specific to Minecraft, and it is worth understanding before choosing how your protection works.
Many proxies authenticate the player themselves and then log into your server on the player's behalf. For that to work, your server has to be set to offline mode, because the player has already proven themselves to the proxy and will not prove themselves twice. The proxy then tells the server who the player is.
That message is the whole identity model. In the modern forwarding scheme it is signed with a shared secret, so your server can refuse a join that did not come from your proxy. In the legacy scheme it is four strings in the handshake with no signature at all — anyone who can reach the backend can claim to be anyone, including your administrators.
So with a forwarding proxy in front of an offline-mode server, a leaked address is not merely a way to send you a flood. It is a way to join as any username you like. Your firewall is the only thing standing between an attacker and your server's entire permission system, which is a lot of weight for one iptables rule to carry.
The alternative: keep your server's own authentication
There is a design that avoids this entirely. Instead of terminating the player's session and forwarding it, the protection acts as a gate: it completes the login itself, proves the account, hands the client a token, and ends the connection. The client comes back — automatically on modern versions, by clicking the server again on older ones — and the returning connection is relayed straight through.
The consequences are worth spelling out, because they are the reason to prefer it:
- Your server stays in online mode and authenticates every player itself, exactly as it does today. No reconfiguration.
- The "leaked address means anyone can be anyone" hole never opens, because the server is still doing its own authentication. A leaked address is back to being a DDoS problem instead of an identity problem.
- No forwarding secret to manage, and no version-specific session translation on the login path.
The cost is one reconnect the first time a player is asked to verify. On clients from 1.20.5 onwards the game does it automatically and the player does not notice; on older clients they click the server once more.
What "hiding" actually buys you
Be clear-eyed about it. Putting a proxy in front of your server means the address your community passes around is not your machine's address, and that is genuinely most of the benefit — casual attackers use the address they were given. It does not un-publish an address that has already been published, and it does not help at all if your machine still accepts connections from the internet at large.
Hiding is a layer. The firewall is the enforcement.
Itnetic's game protection uses the gate design described above, so your server keeps its own authentication and stays in online mode.