How to Protect a Minecraft Server From DDoS Attacks

A DDoS attack floods your server's address with junk traffic until real players can't get a connection through, and you can't out-spec your way out of it — more RAM or a faster CPU doesn't help, because the traffic doesn't need to reach your server software to knock everyone offline. The fix is architectural: stop letting attack traffic ever arrive at your real machine. That means a filtering proxy out front, an origin that's hidden and firewalled behind it, real player IPs forwarded through, and some lighter limits inside the server. Each layer covers a gap the others can't, which is why the order matters more than any one piece. No single setting makes you immune, so don't go looking for one.

It costs you on the listing too, which is the part owners underestimate. A server that's down or lagging out bleeds the regulars who keep coming back, and those regulars are exactly the people who vote month after month. So the damage outlasts the attack — you lose the session, and you lose some of the standing you built up. If you've read how server rankings work, you already know the board rewards consistent uptime, so frequent downtime leaves votes on the table you'd otherwise have earned.

What a DDoS attack actually does to a Minecraft server

A denial-of-service flood aims overwhelming traffic at your server's IP and port so the pipe or the machine gets saturated and legitimate connections can't complete. From the player's side it looks like timeouts, lag spikes, or a flat "can't connect."

There are two shapes of attack, and they matter because the defenses are different. Volumetric, network-layer floods — Layer 3/4 stuff like SYN floods and UDP reflection — try to saturate your bandwidth and your connection tables. These get stopped upstream, before the traffic ever reaches you. Then there are application-layer bot attacks at Layer 7, which open real-looking connections and hammer your login flow. Those pass straight through network filtering and need Minecraft-aware handling instead.

The listing side of this is worth being concrete about. Listing sites poll your status on an interval, and a server that keeps getting knocked offline reads as unreliable. Players drift off, and votes dry up with them. Since the board is ordered by votes earned in the current calendar month, a genuinely-down server just earns fewer of them. So the rest of this is architectural, not a config tweak.

The core defense: put a filtering proxy in front of your server

A DDoS-mitigation proxy is a TCP reverse proxy that sits between players and your server. Players connect to the proxy's address, the proxy filters out junk traffic, and it forwards only clean connections to your origin. Your server's real address stays off the public path entirely.

It works because volumetric floods land on the proxy's network, which is built to absorb and drop them at the edge before they ever touch your bandwidth, not your single machine. And nothing changes for players — they join the same domain they always did, and the proxy hands them off transparently. The connection just routes through the filter first.

There are two common places to get this. One is a dedicated Minecraft DDoS-proxy service that gives you a filtered IP and a protected domain. The other is a host that bundles network-level protection on the IP they assign you, which is the lowest-effort path and gets its own section later. When you're sizing up either one, the questions to ask are practical: does it filter at Layer 3/4, does it pass real player IPs through, and does it publish the IP range you'll need to firewall to. That's how you evaluate the category without getting lost in marketing.

Hide your origin IP — and keep it hidden

A proxy only protects you if attackers can't find and hit your origin directly. If your real address leaks, an attacker just bypasses the filter and floods you anyway, and the proxy isn't doing anything for you anymore. So this step is what makes the previous one real.

Point your public DNS at the proxy, never at the origin. The A record for your join domain has to resolve to the proxy's filtered IP, so anyone resolving your domain only ever sees the proxy.

This is where the SRV-record misconception trips people up, so it's worth being precise. An SRV record by itself does not hide your IP. It points to a target hostname plus a port, and that hostname still needs its own A record — the value fields are priority, weight, port, and target host, and Minecraft reads it off the _minecraft._tcp name on your domain. The protection comes from making that target's A record point at the proxy, not from the SRV record existing. SRV is what lets players use a clean address even on a non-default port; it isn't a cloaking device on its own.

DNS history is the classic leak. If your domain ever had an A record pointing at your real server, archival DNS tools can dig it back up, so you need to clear or stop relying on any old records aimed at the backend. Treat any IP you've exposed in the past as known. Plugins or status pages that echo the server IP, error messages, and any direct-connect address you handed out before moving behind the proxy are all leak paths too. Once an IP is public it's effectively permanent, so moving behind a proxy also means retiring the old address for good.

Firewall the origin so only the proxy can reach it

This is the step most owners skip, and it's the decisive one. Hiding the IP raises the bar, but a determined attacker can still rediscover it. So you make the origin refuse everyone except the proxy.

Lock the game port at the firewall: configure the origin to accept connections on your Minecraft port only from the proxy provider's published IP ranges, and drop everything else. Now even if an attacker learns your real IP, packets aimed straight at it get rejected before they cost you anything. On a self-hosted box that's a host-firewall rule — allow the proxy's CIDR ranges on the game port, default-deny the rest. On managed hosting the host might apply it for you or hand you a firewall panel, so it's worth checking whether your protection is actually enforced at the network or only relies on hiding the IP.

Locking direct access this way is also why the next step exists. Once you've done it, every connection genuinely arrives from the proxy, which means your server can no longer see who any individual player is. The goal here is plain: the origin accepts Minecraft traffic from the proxy ranges and nothing else.

Keep real player IPs visible through the proxy

Routing through a proxy has a side effect — every connection now appears to come from the proxy's IP. That breaks per-IP rate limiting, IP bans, geolocation, and your anti-bot tools, because they all see one address for everyone.

Do not confuse two different features here. HAProxy PROXY protocol (often version 2) is a transport header sent by HAProxy or another compatible upstream; enable it only when that upstream is configured to send it. Velocity modern forwarding and BungeeCord legacy forwarding are separate Minecraft player-information forwarding modes, configured in the proxy and backend settings.

One security caveat you can't skip: when your upstream really does use PROXY protocol, whitelist only that upstream's IPs and default-deny the rest. If just anyone could send a PROXY header, an attacker could spoof any source IP they liked. This is exactly why the firewall lockdown and the protocol whitelist reinforce each other — only the trusted upstream can reach the origin and supply transport headers. If your network uses Velocity or Bungee forwarding instead, configure that forwarding mode and its backend secret/settings; do not enable unrelated PROXY-protocol parsing. And if your server runs with online-mode handled at the proxy, it has to be unreachable except through the proxy, or it's wide open; lock direct access as covered above.

Add rate limits and anti-bot at the application layer

Network filtering stops the volumetric floods, but Layer-7 bot attacks open real-looking connections and spam the login flow, and those slip right past L3/L4 filtering. They have to be handled closer to the server.

Start with connection throttling: limit new connections and logins per IP per interval. You can configure this at the proxy layer — BungeeCord and Velocity both have throttle settings — and partly through server settings. It blunts a single source trying to open hundreds of connections a second. On top of that, anti-bot plugins inspect the handshake and login packets and rate-limit or drop suspicious joins, using connection-rate limits, nickname-pattern checks, and geographic filtering. There are solid free and open-source options in that category, so you don't need to reach for anything paid.

Be honest about the limit, though. An anti-bot plugin runs inside the server, after a connection has already completed the handshake and sent its login packet, so it can't stop a bandwidth-saturating flood — it only filters connections that already reached you. It's a complement to the proxy, never a replacement.

The low-effort path: let your host handle the network layer

If you'd rather not run your own proxy, the simplest route is a host that includes network-level (Layer 3/4) DDoS protection on the IP they assign you, so the filtering applies automatically to your instance's traffic.

When you're comparing hosts, check what the protection actually does: whether it filters at the network layer or just hides the IP, whether it's always-on or only kicks in once an attack is detected, whether it covers the Minecraft port and protocol, and whether real player IPs still come through. Some large cloud platforms bake L3/L4 protection in by default. The gap to know about is that host-bundled network protection usually covers volumetric floods but not Layer-7 bot attacks, so you'll still want connection throttling and an anti-bot layer inside the server even on a protected host.

While you're tuning hosting, keep your listed version accurate so players reach you cleanly when you're up — list 26.2 in that dotted format if that's what you're running, matching how the directory filters by version. Protected hosting trades a little control for a lot less setup, and for most small-to-mid communities it's the pragmatic default.

Putting it together

Here's the whole thing as a checklist, in order:

1. Route players through a filtering proxy, or a protected host.
2. Point public DNS at the proxy and stop exposing the origin.
3. Firewall the origin to accept Minecraft traffic only from the proxy's IP ranges.
4. Enable proxy protocol with a strict IP whitelist so player IPs still work.
5. Add connection throttling and an anti-bot layer for login-flood resilience.

The order matters because these are a chain, not a menu. Skip the firewall and the proxy is bypassable; skip proxy protocol and your bans stop working.

And the payoff is the thing the intro started with: staying online. Stable uptime keeps the community that votes for you, and consistent availability is what climbs the monthly board — the mechanics are all in how server rankings work. Set this up before you need it, because the time to harden against an attack isn't during one.

FAQ

Will hiding my server IP alone stop a DDoS attack?

No — hiding it raises the bar, but it isn't enough on its own. Two gaps remain. First, an origin IP that was ever public (in DNS history, an old direct-connect address, or a plugin that echoed it) can be rediscovered, and once it's known it's effectively permanent. Second, even a hidden IP can be hit directly if your origin still accepts connections from anywhere. Hiding only works when it's paired with a firewall that makes the origin refuse every source except your filtering proxy's IP ranges. Hiding plus firewalling is the combination that holds; hiding by itself just delays the problem.

Can I just use a CDN like Cloudflare to protect my Minecraft server?

Not the standard web product. Cloudflare's free and Pro plans proxy HTTP/HTTPS traffic, and Minecraft's protocol isn't HTTP, so a regular website CDN won't sit in front of your game port the way it does a website. What you actually need is a TCP/UDP-level proxy — Cloudflare offers that under its Spectrum product, and there are Minecraft-specific proxy services that do the same job. The thing to verify before committing is that whatever you pick filters the raw Minecraft connection at Layer 3/4 and passes the real player IP through, because the web-only tier does neither for a game server.

Should I change my server IP after an attack, and will that fix it?

Changing the origin IP only helps if you change it and close the door behind you. A fresh IP that you immediately hide behind the proxy and firewall to proxy-only access gives you a clean slate, since the old address attackers were hitting now points at nothing reachable. But if you swap IPs and leave the new one exposed the same way — DNS pointing straight at it, no firewall, the address echoed by a plugin — it gets rediscovered and you're back where you started within days. So the rotation buys you nothing on its own; it only matters as the moment you also stop exposing the origin.

How long do DDoS attacks against a server usually last, and do I have to do anything during one?

Most are short bursts — minutes to a few hours — because sustained attacks cost the attacker more and draw more attention. The point of setting up the proxy, hidden origin, and firewall ahead of time is that during an attack you ideally do nothing: the filtering soaks it up and players stay connected, often without noticing. If you're getting hit and you haven't set any of this up yet, there's no good in-the-moment fix beyond riding it out and standing the architecture up afterward, before the next one. Reacting mid-attack is always worse than the boring work of hardening when nothing's wrong.