Game Server DDoS Protection (2026) — What Providers Actually Deliver vs What They Market

Most game-host marketing pages list "DDoS Protection" as a checkbox feature. The reality is that the term covers wildly different technologies, with very different effectiveness against different attack types and different game protocols — and most hosts don't tell you which version they're selling. This guide is the honest map of what actually exists in 2026: which providers really protect against which attacks, what the questions are that you need to ask before you buy, and the budget options (free Cloudflare Tunnel for Minecraft, €0.50/mo GRE tunnels, $10/mo Path.net resellers) that no affiliate listicle will ever tell you about. Written by someone who has personally been on the wrong end of five different "DDoS protected" hosts — and learned what actually works the hard way.

00 // The problem nobody publishes a guide about

If you have ever Googled "how to protect a game server from DDoS" you already know the genre: ten near-identical listicles ranking the same managed hosts, every one of them claiming "unmetered DDoS protection" or "enterprise-grade DDoS mitigation," with a star rating and an affiliate link. None of them tell you what kind of attacks the protection actually filters, what it costs the host to mitigate, or which games it works for. They just say "protected" and move on.

Then you rent the server, get attacked for the first time, and find out your "DDoS protection" was one of the following:

• A null-route plus auto-restart loop. Your server crashes, the host kills network to your IP for 15 minutes to "protect their infrastructure," then brings you back. Every player loses connection. Every save desyncs. The attacker watches the cycle and times his next burst. This is the most common form of "protection" sold on cheap shared boxes — and it is functionally identical to no protection from a player's point of view.
• L3/L4 volumetric only. The host filters obvious flood patterns at the edge (UDP amplification, SYN floods, simple reflection) but anything that mimics legitimate game traffic — spoofed login packets, malformed handshakes, application-layer floods aimed at your game port — passes straight through. Your tickrate collapses while bandwidth graphs look fine. The host tells you "the attack is mitigated" because their meter says so.
• Cloudflare-on-a-website-only. The host has Cloudflare on their billing site, which protects their shopping cart, not your game server. This is a real distinction many providers blur in their copy.
• A shared scrubbing center with a small budget. The protection is real but the capacity is shared across thousands of customers. When the network is hit hard or another customer is being targeted, your server sits in a queue. "Up to 1 Tbps protection" can mean "we have a 1 Tbps contract with a scrubber and you share it with everyone else."
• Genuine, dedicated, game-aware filtering. The real thing. Path.net, OVH Game, Combahton FPS Shield, Cloudflare Spectrum at the enterprise tier, Sharktech with custom rules. This is what a few players have, and what almost everyone thinks they are buying.

The gap between (1) and (5) is enormous. The price gap is often only $5 to $20 a month. The marketing copy on both is identical.

This guide does four things, in order:

1. Explains what "DDoS protection" actually means at the technical layer — volumetric vs protocol vs application vs game-protocol attacks — so you can read a host's claims and translate them.
2. Ranks the providers that really exist in 2026 by tier, with the technical reason each tier sits where it does. No star ratings, no "top 10" filler.
3. Maps game protocol → protection that actually works, with separate columns for Minecraft Java, Minecraft Bedrock, FiveM, Rust, CS2/TF2, ARK, Valheim, and the unprotected wasteland of Unreal-Engine UDP games like Mordhau, Squad, and Chivalry 2.
4. Lists the seven questions to ask a sales rep before you buy. The questions every dishonest host hates and every honest host will answer in writing.

If you want the budget options up front: free Cloudflare Tunnel for small Minecraft Java servers, €0.50/mo GRE-tunnel relay services for arbitrary games, $10 to $25/mo Path.net reseller VPS plans, and a self-hosted iptables hardening template. All four are covered in detail in the second half.

01 // The three categories of fake DDoS protection

Before we rank providers, you need a vocabulary. Almost every disappointing "DDoS protected" experience falls into one of three patterns. Each one looks great in marketing copy and behaves very differently in practice. Knowing which one you are about to buy is half the battle.

Pattern 1 — Null-route mitigation ("crash and come back")

The cheapest form of "protection." When the host's edge network sees an unusual amount of inbound traffic to your IP, it does the simplest possible thing: it blackholes that IP at the upstream router for a fixed window (commonly 10 to 30 minutes), then re-announces the route. From the host's perspective they protected the rest of their network. From your perspective:

• Every connected player is hard-disconnected.
• The game server process keeps running but is unreachable.
• Saves that depend on graceful shutdown (looking at you, Mordhau and Conan Exiles) can desync or rollback.
• The attacker only needs to send a small burst every 30 minutes to keep your server unreachable indefinitely while paying nothing.

How it sounds in marketing: "Automated DDoS protection," "Up to 1 Gbps inbound mitigation," "Layer 3/4 attack protection included." The careful absence of the word "filtering" or "scrubbing" is the tell.

How to detect it before you buy: ask the support agent "During an attack, is my server IP null-routed, or are bad packets dropped while legitimate ones still reach my game port?" A null-route shop will either dodge the question or admit "the IP is taken offline temporarily." That's your answer.

Pattern 2 — Volumetric-only filtering ("the bandwidth graph looks fine")

One step up. The host actually has a scrubbing appliance or upstream provider (Voxility, Corero, Path's commodity tier, Arbor) that filters obvious flood signatures: NTP/DNS/CLDAP amplification, SYN floods, fragmented UDP storms, ICMP floods, and so on. These are the easy attacks — the kind a 14-year-old with a $5 booter sends. They get filtered. The bandwidth graph stays clean. The host writes you a status update saying the attack was "successfully mitigated."

Then a slightly smarter attacker sends spoofed game-protocol packets — for example, a flood of fake Source Engine A2S_INFO queries, FiveM endpoint POSTs, or Mordhau session-join requests — and they sail right through, because to a generic L3/L4 scrubber they look like legitimate game traffic. Your tickrate collapses. Players rubber-band. The host's dashboard still says "clean."

The technical reason this happens: generic scrubbers operate on packet-level heuristics — rate-per-source, signature matches against known reflection vectors, TCP-state correctness. They do not understand the wire format of your specific game. A flood that is shaped like a real game packet, even from spoofed sources, is invisible to them. This is what game-aware filtering (Path.net, Combahton FPS Shield, OVH Game) does differently.

How it sounds in marketing: "Up to 500 Gbps DDoS protection," "Layer 3/4 mitigation," "Anti-DDoS Pro." Big numbers, generic descriptions, no mention of game-protocol awareness.

How to detect it before you buy: ask "Can your filter parse the wire format of {Source Engine / FiveM / Minecraft / RakNet} and rate-limit malformed application packets?" If the answer is "we filter all DDoS attacks" without engaging with the question, you have a volumetric-only host.

Pattern 3 — Real protection on a shared budget ("queue position 47")

The most subtle failure mode and the one I have personally hit on three separate hosts. The protection is technically real — the host has a contract with a competent scrubber, the equipment understands game protocols, the engineering team is competent. The capacity, however, is shared across every customer on that node. When you are the only one being attacked at 3 GB/s, you are protected. When two other customers are being attacked at the same time, or when the entire network is hit during a Friday-night event, the scrubbing capacity gets allocated by some opaque internal priority and your traffic might end up queued or sampled.

This is the "protection works except when you really need it" pattern. It is also why "up to X Tbps protection" is meaningless without a written commitment that your server is guaranteed a slice of that capacity.

How it sounds in marketing: "Up to 1 Tbps shared scrubbing capacity," "Network-level DDoS protection across all plans." The word "shared" is rarely present.

How to detect it before you buy: ask "Is the protection capacity dedicated per server, dedicated per node, or shared across all customers? What happens when multiple customers are attacked simultaneously?" An honest shared-budget host will acknowledge it openly; a dishonest one will deflect.

02 // The four kinds of DDoS attacks (and why hosts confuse them on purpose)

Almost everything you read about "DDoS protection" lumps every attack into a single bucket. The reality is that attacks fall into four very different categories, each requiring different defenses. A host that filters Layer 3 floods well may be useless against an application-layer attack — and vice versa. Knowing the difference is what separates a customer who buys protection that works from one who buys a marketing word.

Layer 3 — Volumetric / network-layer floods

What it is: raw bandwidth attacks. Massive amounts of UDP packets, ICMP packets, fragmented IP traffic, or amplified reflection from open NTP/DNS/CLDAP/Memcached servers, all aimed at saturating the bandwidth of either your server's pipe or the host's upstream uplink. The goal is to make the network upstream of your server unable to deliver legitimate packets at all.

Sizes: small attacks are 1 to 10 Gbps (a single booter site can produce this for a few dollars). Medium attacks are 10 to 100 Gbps. Large modern reflection attacks reach 1 to 3 Tbps in extreme cases. The 2024-2025 record sits above 5 Tbps from Mirai-variant botnets.

What stops it: upstream scrubbing capacity larger than the attack, applied by ASes with global Anycast presence (Cloudflare, OVH, Path.net, Tier 1 carrier scrubbing). This is the cheapest kind of attack to launch and the easiest kind to filter if your host's edge has the capacity. If they do not, nothing you do at the server level matters — the packets never reach you anyway.

Hosts that handle this well: any host with a real CDN partner, OVH (anti-DDoS Game on dedicated), Path.net (17 Tbps network), Cloudflare Magic Transit, Combahton.

Hosts that fake it: any single-location budget VPS provider claiming "unlimited DDoS protection." Their pipe is not large enough; the truth is they null-route during volumetric events.

Layer 4 — Protocol attacks (TCP/UDP state exhaustion)

What it is: attacks that exploit the network-protocol layer rather than raw bandwidth. SYN floods, TCP RST/ACK floods, fragmented TCP, malformed UDP packets, Christmas-tree packets. Goal is to exhaust connection-tracking tables, kernel sockets, or stateful firewall capacity rather than bandwidth. A 100 Mbps SYN flood can take down a server with 10 Gbps of bandwidth headroom because the bottleneck is conntrack, not bps.

Sizes: measured in packets per second (pps), not Gbps. Anything from 100 kpps for cheap booters to 100+ Mpps from large botnets. PPS is the metric that matters here.

What stops it: stateless filtering at the network edge that drops malformed packets before they hit a stateful firewall. SYN cookies, TCP-state validation, conntrack hardening (net.netfilter.nf_conntrack_max tuning, tc-bpf), eBPF/XDP filters that operate before the kernel network stack. OVH Anti-DDoS Game, Path.net, and competent self-hosted iptables-with-XDP setups handle this well.

Hosts that fake it: any host whose "DDoS protection" is a stateful Cisco ASA or pfSense in front of your server. Stateful firewalls are themselves vulnerable to L4 floods — you are just moving the problem one hop upstream.

Layer 7 — Application-layer attacks (HTTP/HTTPS)

What it is: attacks against application-layer services. Slowloris, HTTP GET/POST floods, RUDY, SSL renegotiation floods, JSON-flood against API endpoints. For most game servers this matters in two specific places:

• FiveM /players.json, /info.json, /dynamic.json — flooding these endpoints can DoS the txAdmin web interface and degrade the master-list publishing
• Web admin panels — Pterodactyl, AMP, Pelican, WISP, all sit on HTTPS and can be targeted
• BattlEye / EAC / Steam Web API endpoints — rare but real

What stops it: a Web Application Firewall (WAF). Cloudflare's free tier is genuinely effective here. Rate-limiting at the reverse proxy (nginx limit_req_zone), JS challenges, hCaptcha, and IP reputation. None of this requires a paid host with "DDoS protection" — you can put Cloudflare free in front of any HTTPS endpoint today and it will absorb 99% of L7 attacks.

Hosts that fake it: any host that says "DDoS protected" but routes admin-panel HTTPS straight to the box without a WAF in front. You are responsible for that layer yourself in almost every plan tier.

Layer 7+ — Game-protocol attacks (the kind that actually take down game servers)

What it is: attacks that imitate your specific game's wire protocol from spoofed sources, designed to either (a) consume the server's per-player budget by pretending to be many fake players, or (b) trigger expensive code paths in the game's network parser. Examples:

• Source Engine — A2S_INFO query floods, fake CONNECT/0x12 packets, malformed challenge responses targeting CS2/TF2/Garry's Mod servers.
• Minecraft Java — SLP (Server List Ping) floods, malformed handshake packets, half-completed login flows that leave per-IP slots reserved.
• Minecraft Bedrock / RakNet — Open Connection Request 1 floods, MTU negotiation abuse.
• FiveM — spoofed connect POSTs against the Cfx endpoint, fake heartbeat traffic.
• Unreal Engine UDP games (Mordhau, Squad, Chivalry 2, Conan Exiles, ARK, Ground Branch, Squad 44) — fake session-join packets on the game port, malformed handshake floods. This is the category that took down all five of the hosts I tried.
• Steam Master Server / GameSpy descendants — floods of registration packets to confuse server browsers.

What stops it: game-aware deep-packet-inspection filters that understand the wire format and can distinguish a malformed handshake from a real one, then rate-limit per-source and per-handshake-state. This is what Path.net, OVH Anti-DDoS Game, and Combahton FPS Shield specialize in. It is also what almost no "DDoS protected" managed game host actually runs — they have generic L3/L4 scrubbers and no game-protocol logic.

The Cloudflare Spectrum reality: Cloudflare Spectrum can do this beautifully for TCP-based games (Minecraft Java is the canonical case) on the Pro plan at roughly $20 to $25 a month. For UDP-based games the equivalent service exists but is gated behind Cloudflare Magic Transit / Spectrum Enterprise, which has a pricing floor that quoted to small operators starts in the low thousands per month with custom contracts running higher. This is the protection desert that traps every UDP-game admin and the single biggest reason the FiveM, Rust, ARK, and Mordhau scenes have suffered DDoS problems for years with no clear budget answer.

03 // Provider tiers — what actually exists in 2026

Instead of "top 10 ranked by affiliate commission," we sort providers by the technical reality of their network. Tiers are: S (game-aware, dedicated capacity, holds against motivated attackers), A (real volumetric and L4 protection, weaker on game-protocol), B (genuine basic protection, will hold against amateur attacks), and C ("protection" exists in marketing only).

All claims below are based on each provider's published documentation, peering data, and community reports as of April 2026. References to my personal experience are dated to the 2020-2024 window I rented those providers and may not reflect current networks — tier placement reasoning is independent of those rentals.

Tier S — Game-aware, dedicated, holds against motivated attackers

Path.net

Network: 17 Tbps published mitigation capacity. Multi-continent presence (US, EU, APAC). Game-specific filter profiles for Source Engine, FiveM, Minecraft, RakNet, and Unreal Engine session traffic.

What makes it S-tier: the filter is application-aware. It does not just see "UDP packets to port 7777" — it parses the wire format and rate-limits per-source per-handshake-state. The filter dashboard exposes per-rule counters, which is itself rare and a sign that operations treats DDoS mitigation as a serious product rather than a marketing checkbox.

How to actually buy it: Path.net itself sells dedicated servers in the "if you have to ask, you can't afford it" range — typically $80-$150+/mo for a starter dedicated box. However, Path.net has a reseller program, and a number of small operators sell VPS plans on Path-protected nodes for $10 to $25/mo. This is the under-publicized budget option. Names that have come up in 2024-2026 LowEndTalk and reddit threads as Path.net resellers (verify current network at order time):

• VibeGames.net — explicitly markets Path-protected game-server VPS. EU/US/APAC.
• Tempest Hosting — small UK-based reseller running on Path infrastructure.
• GoodLeaf Networks — APAC-oriented Path reseller.
• Elemental Nodes — small reseller; verify network on order page.

Recommended for: any UDP-based game with no other realistic budget option (Mordhau, Squad, Chivalry 2, Conan Exiles, Rust at scale, FiveM, ARK clusters).

OVH (Game tier)

Network: 17+ Tbps published, the largest dedicated-DDoS capacity in the EU. The "Anti-DDoS Game" addon on Game Range dedicated servers enables specific filtering rules tuned for game-protocol attacks. The base Anti-DDoS protection on every OVH server is volumetric and L4 only and is genuinely good at that level.

What makes Anti-DDoS Game S-tier (when enabled): game-protocol-aware filters maintained by OVH's network engineers, including signatures for Source Engine, GTA / RAGE multiplayer protocols, Minecraft, and various UDP session types. Per-port firewall rules you control via the OVH manager.

The catch: Anti-DDoS Game is a product tier you have to specifically order, only available on Game Range dedicated servers (not VPS, not Eco range). The cheapest Game Range box starts around €60-80/mo and the protection only activates on those specific machines. Other OVH boxes get the standard Anti-DDoS, which is L3/L4 only and has been reported to fail against game-protocol floods.

Recommended for: serious community servers with budget for a Game Range dedicated box. Not the right tier for a casual VPS.

Cloudflare Spectrum (TCP) / Magic Transit (UDP enterprise only)

Network: Cloudflare's full Anycast network — 320+ cities, 280+ Tbps total capacity, the largest DDoS-mitigation network in the world. Mitigation is fully application-aware via Magic Transit and Spectrum.

For Minecraft Java specifically: Cloudflare Spectrum on the Pro plan ($20-25/mo) lets you proxy your TCP game port through Cloudflare's edge. The Minecraft community has used this configuration for years. It is the cheapest real S-tier protection available for any game, and most managed Minecraft hosts that claim great DDoS protection are quietly running TCPShield or a Spectrum-equivalent in front of their fleet.

For UDP games: the protection desert. Cloudflare's UDP forwarding (Spectrum UDP, Magic Transit) is officially Enterprise-tier only. Real quoted prices to small operators have started in the $5,000+/mo range and frequently far higher with custom commitment. Functionally unavailable for everyone except commercial hosting providers. This is the single most important fact this guide can give you, and the one that explains why Mordhau, Rust, FiveM, and ARK admins have suffered for years with no clear answer.

TCPShield (Minecraft only)

What it is: a Minecraft-Java-specific reverse proxy that puts a real DDoS-mitigation network in front of your server's IP. Functionally similar to Cloudflare Spectrum but purpose-built for the Minecraft Java protocol, with Bedrock and Forge variants.

Pricing: free tier with a usage cap, paid tiers from a few dollars per month. The free tier is genuinely usable for small to medium servers and is one of the most under-publicized assets in the Minecraft hosting world.

Limitation: only works for Minecraft Java protocol (and Bedrock on the dedicated tier). Useless for any other game.

Recommended for: every self-hosted Minecraft Java server, full stop. There is no reason not to put TCPShield in front of a public Minecraft server in 2026.

Tier A — Solid volumetric and L4, weaker on game-protocol

Combahton (FPS Shield)

What it is: a German hosting and network provider with a published DDoS-mitigation product called FPS Shield specifically aimed at game traffic. Strong reputation in the European LowEndTalk community for actually understanding game-protocol attacks. Some 2024-2025 community reports note occasional infrastructure issues; quality is widely seen as still good but not as consistent as Path.

Recommended for: EU-based community servers wanting a real protection product without paying OVH Game prices. Verify current network performance and uptime SLAs at order time.

Sharktech

What it is: US-based dedicated provider with custom DDoS-mitigation rules available on request. Long history of supporting game servers. Published mitigation capacity in the multi-Tbps range.

Recommended for: US-based dedicated servers needing custom mitigation rules and willing to talk to a sales engineer.

Physgun (managed, North America-focused)

What it is: a managed game-host with strong DDoS-mitigation infrastructure across their network. They run their own protection rather than reselling generic upstream filtering and have a good reputation in the Minecraft, Garry's Mod, and Source Engine community for actually holding up under attack.

Caveat: Physgun is a managed game host, not a raw VPS. You are buying a game-server slot, not Linux root. That is a feature for many users and a limitation for others.

See our full Physgun review for the detailed write-up.

Hostinger VPS (with self-hosted hardening)

What it is: Hostinger's KVM VPS line includes basic L3/L4 DDoS protection at the network edge across all plans. It is real protection at the volumetric layer; it is not game-protocol-aware. To get S-tier behavior on UDP games you pair it with a self-hosted hardening stack (covered in section 06): tuned iptables/nftables, fail2ban, optional Cloudflare Tunnel for HTTPS endpoints, and for UDP games a GRE tunnel to a Path-protected relay or a Tailscale mesh setup.

Why it lands in Tier A: the price-to-performance is the best in the category if you are willing to do the hardening work yourself. A Hostinger KVM 4 at €12.99/mo plus a $10 Path-reseller relay used as a GRE endpoint gives you genuine game-aware protection at roughly $25/mo total — a fraction of OVH Game pricing or Cloudflare UDP enterprise.

See our Hostinger VPS review for the detailed write-up. Affiliate links to Hostinger appear in section 11 with a clear disclosure.

Tier B — Basic protection that holds against amateurs but not motivated attackers

Shockbyte

What it is: a budget managed Minecraft host with a price-leader reputation. They publish that they include DDoS protection on every plan; the protection is at the network edge and is L3/L4 volumetric in nature. They are not running game-protocol-aware filtering on their fleet; they rely on upstream and on putting Minecraft-specific reverse proxies in front of customer servers.

Reality check: good enough to absorb a casual booter attack on a Minecraft server, especially given Minecraft Java's TCP nature lets cheap proxies do most of the work. Not a host you would pick if you were specifically being targeted by a motivated attacker, but most servers never face that — and at $2.50/mo for a starter Minecraft plan the value is real for what it is.

See our Shockbyte review for the full write-up.

ZAP-Hosting

What it is: a German managed game host, official CFX/FiveM partner. DDoS protection on the network edge is real basic L3/L4 mitigation. For FiveM specifically the CFX partnership and proxying through their infrastructure absorbs casual attacks.

Reality check: good for FiveM and managed-game use cases at the casual-attack tier. Not a host I would pick if I expected to be a target. See our ZAP-Hosting review.

BuyVM

What it is: a Las Vegas / Luxembourg / NYC budget VPS provider with a long history in the LowEndTalk community. They include a published DDoS-protection feature, and at one point routed protection traffic through Path.net's network for an additional fee.

Reality check: when I rented BuyVM (2020-2024 window) for a UDP game server, the protection did not hold against the attacks we were facing — the server kept crashing. Reading the LowEndTalk threads more carefully later, the OP of the most-cited Path.net thread specifically notes that he ordered from providers using Path who still went offline from 5 Mbps attacks due to misconfiguration. That matches the pattern: the upstream protection product is real, but the configuration glue between provider and customer can fail. Disclaimer: BuyVM may have improved their integration since 2024; verify current network on order.

Evolution Host

What it is: a UK-based managed game host with published DDoS protection on their game-server plans. Marketing positions it as a strong protection product.

Reality check: in my 2020-2024 rental experience for a UDP-based Unreal Engine game, the protection did not hold and the server kept crashing during attacks. Disclaimer: Evolution Host may have rebuilt their protection stack since then; this is a disclosed personal experience from a specific window, not a current technical audit. The technical pattern that fits my experience is volumetric-only filtering against an attacker sending game-protocol-shaped packets — the same pattern that explains why the entire UDP-game scene has suffered.

Tier C — "Protection" that exists primarily in marketing copy

G-Portal

Marketing claim: "Cosmic Guard DDoS Protection" advertised across the product line. The branding suggests proprietary protection technology.

Reality check: in my 2020-2024 rental for a UDP-based competitive game, the server crashed under attack, the auto-restart kicked in, and the attack continued past the restart. This is the textbook null-route-mitigation behavior described in section 01 — the host's network was protected, my IP was not. Disclaimer: G-Portal may have changed their protection stack since then. The technical fingerprint of my experience (crash + auto-restart + continued attack) is the signature of a volumetric-only or null-route product, regardless of branding.

GTXGaming

Marketing claim: "DDoS Protected" servers across the product line.

Reality check: in my 2020-2024 rental for a competitive game, the server console flooded with what looked like attacker source IPs while the server lagged through the entire attack. This is the fingerprint of a host whose "protection" is downstream of the game server — the bad packets reached the game process, were logged by the game's own connection-attempt logger, and the host's edge filter did nothing. Disclaimer: GTXGaming may have improved their network since 2024. See our GTXGaming review for additional context.

Nitrado (for UDP / Unreal Engine games specifically)

Marketing claim: "DDoS protection included" on game-server plans.

Reality check: in my 2020-2024 rental for Mordhau (an Unreal Engine UDP game), the server went down under attack repeatedly. After multiple tickets, Nitrado support eventually admitted in writing that they could not protect Mordhau servers against the attacks we were seeing. To their credit, this was an honest disclosure — the technical reality is that the entire UDP / Unreal Engine session-flood category was, and largely still is, the protection desert covered in section 02. Disclaimer: Nitrado is a competent host for many use cases (ARK and Minecraft especially — see our Nitrado review); the failure was specific to UDP-game-protocol attacks against Unreal Engine titles.

04 // Game-by-game protection matrix — what to actually buy

This section is the practical answer to "I host {game}, what do I do?" Each row is a real recommendation, ordered by cost. We split games into TCP-friendly (where Cloudflare-style tunneling works) and UDP (where the protection desert lives and creative solutions are needed).

TCP-friendly games (Cloudflare and TCPShield work)

Minecraft Java Edition

The good news: Minecraft Java uses TCP for the player connection, which means every modern reverse-proxy DDoS solution works. This is the most well-protected game in this entire guide.

Recommended stack (under $5 total):

• Self-host on Hostinger KVM 2 (€8.49/mo) or any decent VPS.
• Put TCPShield free tier in front of your server IP. Configure Minecraft to bind only to localhost or to TCPShield's whitelisted backend IPs. Enable haproxy-protocol in server.properties via the proxy-protocol setting.
• Optional: add ip-forward Velocity/BungeeCord support if running a network.

Recommended stack (under $25 total):

• Same Hostinger KVM 2 or 4 backend.
• Cloudflare Spectrum on the Pro plan ($25/mo). Configure a Spectrum application pointing TCP traffic on your custom port to your origin IP. Whitelist Cloudflare IP ranges in iptables so attackers cannot bypass Spectrum by hitting your origin directly.

If you prefer managed: Shockbyte is the budget choice ($2.50/mo Minecraft Java, see our Shockbyte review). Physgun is the higher-tier managed option (see our Physgun review) with stronger DDoS resilience for community servers facing real targeting.

Minecraft Bedrock Edition

The catch: Bedrock uses RakNet over UDP, not TCP. TCPShield does not work on the free tier — you need TCPShield Bedrock (paid tier) or alternative UDP-aware solutions.

Recommended stack:

• TCPShield Bedrock paid tier (~$5/mo entry), or
• Geyser/Floodgate proxy — bridge Bedrock players to a Java-protocol backend, then protect the Java side with Cloudflare Spectrum or TCPShield free. This is the under-publicized hack: convert Bedrock to Java at the proxy layer and use Java-side protection.

See our Minecraft Bedrock setup guide for the Geyser configuration steps.

Counter-Strike 2 / Team Fortress 2 / Garry's Mod (Source Engine)

The protocol: Source Engine uses UDP for game traffic, but the wire format is well-documented and Path.net / Combahton FPS Shield maintain explicit signatures for it. This puts Source Engine games in a better position than Unreal Engine games — real protection products understand the protocol.

The attack pattern to expect: A2S_INFO query floods (server-browser-discovery abuse), spoofed CONNECT packets, and "server stress" attacks via misused query reflection. The A2S query reflection problem was so bad in 2020 that Valve added sv_max_queries_sec and related rate-limits to the engine itself.

Recommended stack (under $20):

• Self-host on Hostinger KVM 2 (€8.49/mo) or KVM 4 (€12.99/mo) for higher tickrate community servers.
• Tune Source Engine's built-in query rate-limits: sv_max_queries_sec 30, sv_max_queries_sec_global 60, sv_max_queries_window 30.
• Add iptables rate-limiting on the game port for connection-state floods (full ruleset in section 06).
• Enable SourceMod's anti-spam plugins if running TF2 community.

If you face motivated attackers: rent a Path.net reseller VPS (VibeGames, Tempest) at $10-25/mo — their game-aware filter actively understands Source Engine and will rate-limit malformed query traffic upstream of your server.

See our CS2 server setup guide and TF2 community server guide for full configuration.

UDP-only games (the protection desert — creative solutions required)

This is the part of the internet nobody writes a useful guide for, because the honest answer is uncomfortable: there is no $5/mo solution. The price floor for genuine UDP game-protocol protection sits in the $10-25/mo range (Path.net resellers) for a competent setup, with the failure mode for anything cheaper being "works fine until you get targeted, then you discover the truth." The strategies below are ranked by effectiveness, not cost, and each carries a clear tradeoff.

Unreal Engine games (Mordhau, Squad, Chivalry 2, Conan Exiles, Squad 44, Ground Branch)

The protocol problem: Unreal Engine's UDP session protocol is not in the public signature list of generic scrubbers and is poorly documented compared to Source Engine. Game-aware filters that explicitly cover UE session traffic are rare; most that claim to do so actually rate-limit on packet shape rather than wire-format awareness. This is the protection desert and the reason Mordhau, Squad, and Chivalry 2 admins have shared a decade of frustration.

Recommended stack (the honest one, ~$25/mo):

• Backend: Hostinger KVM 4 (€12.99/mo, 16GB RAM) for the actual game server.
• Front: a Path.net reseller VPS (~$10-15/mo from VibeGames, Tempest, or similar) used as a GRE tunnel relay. Configure your game server to bind to the relay's tunneled IP only, drop everything else at iptables. The relay's Path-protected IP is what players connect to; attackers hit the relay, the relay's filter understands UE-shaped traffic enough to rate-limit it, and your backend stays clean.
• Cost: roughly $25/mo total, dramatically less than Cloudflare Spectrum UDP enterprise pricing.
• GRE tunnel setup: covered with full commands in section 06.

Recommended stack (the premium one, ~$80/mo):

• OVH Game Range dedicated server with Anti-DDoS Game enabled. Single-tenant, dedicated capacity, official UE filter signatures. The cleanest answer if budget allows.

Recommended stack (managed, no Linux):

• Honestly: there isn't a great answer here. Nitrado support has explicitly admitted (to me, in writing during 2020-2024) that they cannot protect Mordhau, and the same protocol category covers Squad, Chivalry 2, and Conan Exiles. If you must go managed, ask the host the seven questions in section 05 before ordering and get the protection commitment in writing for your specific game.

Rust (Facepunch's protocol)

The protocol situation: Rust runs on a custom Facepunch protocol over UDP (legacy used RakNet, current builds use a custom stack). Path.net, OVH Anti-DDoS Game, and Combahton FPS Shield all maintain Rust signatures. Some smaller hosts run their own community-maintained Rust filters that are surprisingly effective.

Recommended stack: Hostinger KVM 4 (€12.99/mo) backend + Path-reseller relay (~$10/mo) for community servers under 100 players, OR a Path.net dedicated for 200+ player community servers. Add the Carbon/Oxide anti-grief plugin layer on top.

See our Rust dedicated server setup guide for backend configuration.

FiveM / RedM (GTA V/RDR2 multiplayer over Cfx.re)

The protocol situation: FiveM combines a TCP HTTPS endpoint (the Cfx connection negotiation, players.json, etc.) with UDP for actual game traffic. The TCP side can be put behind Cloudflare free-tier WAF. The UDP side faces the same protection-desert problem as Unreal Engine games.

Recommended stack:

• ZAP-Hosting (official CFX partner) for the managed path — their CFX partnership absorbs casual attacks and they understand the protocol better than generic hosts.
• For self-hosted: Hostinger KVM 4 backend + Path-reseller relay + Cloudflare free in front of the HTTPS endpoint for txAdmin and Cfx server-list registration.

See our FiveM server setup guide for full configuration.

ARK / Valheim / Palworld / V Rising / Conan Exiles (other survival UDP)

The protocol situation: these games use various UDP variants — ARK uses Source-Engine-derived networking (despite being on Unreal), Valheim uses Steam Networking, Palworld and V Rising use custom UE-derived stacks. Generic L3/L4 protection covers casual attacks. None are well-covered by game-aware filters.

Recommended stack: for community-scale (10-50 players) Hostinger KVM 4 backend with the iptables hardening from section 06 is realistic, especially if your server is not a high-profile target. For larger or targeted servers, the Path-reseller relay strategy applies the same way as for UE games. ARK clusters in particular benefit from running each map on a separate VPS so an attack on one map does not take down the cluster.

See our ARK setup guide and Valheim setup guide.

Friends-only servers (the privacy-first answer)

The trick nobody talks about: if your server is friends-only, you don't need DDoS protection — you need obscurity. Set up a Tailscale mesh network (or WireGuard, ZeroTier, or Twingate) and have every player join the mesh. The game server binds only to the Tailscale interface (typically 100.x.x.x). Players connect to the server's Tailscale IP, not a public IP. There is no public attack surface to DDoS. Total cost: $0 (Tailscale free tier covers up to 100 devices).

Why this is brilliant: a determined attacker cannot DDoS what they cannot find. Without a public IP and port, there is no target. This is the genuinely-free, genuinely-bulletproof answer for any private server, and it is buried in basically zero hosting guides because it doesn't generate affiliate commissions.

Full Tailscale setup with game-server-specific configuration is in section 06.

05 // The seven questions to ask before you pay for "DDoS protected" hosting

These are the questions that would have saved me from five separate bad rentals between 2020 and 2024. Send them to a host's pre-sales support before you order. The way they answer is more important than what they answer — an honest "we don't do that" is more useful than a hand-wavy "we filter all attacks." Hosts that engage technically with these questions earn your money. Hosts that deflect, over-promise, or pivot to marketing copy save you a refund battle.

Question 1: "Is the DDoS protection capacity dedicated to my server, dedicated to my node, or shared across all customers?"

Why it matters: the difference between "protection works" and "protection works except when you really need it" (Pattern 3 from section 01). A host with shared capacity may protect you fine on a normal day and silently fail when multiple customers are attacked simultaneously.

What a good answer looks like: "Capacity is shared at the network edge but we have X Tbps of total scrubbing and we have not seen sustained capacity exhaustion. Per-server dedicated capacity is available on our Premium tier for $Y extra." Honest, technical, prices the upgrade.

What a bad answer looks like: "All our servers are protected, you don't need to worry about that."

Question 2: "During an attack, is my IP null-routed (taken offline temporarily) or are bad packets dropped while legitimate traffic still reaches the game port?"

Why it matters: this is the direct test for Pattern 1 (null-route mitigation). A null-routing host is selling you protection-for-them, not protection-for-you.

What a good answer looks like: "We do not null-route customer IPs as a first response. Mitigation runs at our edge scrubbers and bad traffic is dropped while your IP remains reachable. Null-routing is a last-resort action only used if the attack exceeds our scrubbing capacity, in which case you receive a status notification."

What a bad answer looks like: "During very large attacks the IP may be temporarily unreachable to protect our network." That's null-routing as the primary response.

Question 3: "Does your filter understand the wire format of {my specific game}, and what does that mean technically?"

Why it matters: direct test for Pattern 2 (volumetric-only filtering). A host running a generic L3/L4 scrubber will not protect you against game-protocol-shaped attacks.

What a good answer looks like: "Yes, our filter has signatures for {Source Engine / RakNet / Cfx / etc} and rate-limits malformed handshakes per source IP. Here's a link to our documentation page that lists supported protocols."

What a bad answer looks like: "Our DDoS protection covers all attack types" or "We use enterprise-grade Voxility/Corero/Arbor mitigation." Big-name upstream scrubbers without game-protocol awareness are exactly the volumetric-only stack that fails on game-shaped traffic.

Question 4: "Has your protection been tested against {Mordhau / Squad / Rust / your specific game} specifically? Do you have customer references for it?"

Why it matters: avoids buying based on marketing about a game category your host has never actually defended. Nitrado support honestly admitted to me they could not protect Mordhau when asked this question directly — saving everyone time. Most hosts do not actively know which games their filter has been tested against; the act of asking forces them to find out.

What a good answer looks like: "Yes, we host {N} {game} servers actively. The largest one we've defended took a {size} Gbps attack on {date}. Here's a customer testimonial."

What a bad answer looks like: "All games are supported." That's not an answer; that's a sales script.

Question 5: "What attack sizes are included in my plan tier, and what happens if an attack exceeds that?"

Why it matters: some hosts publish protection capacity in marketing but cap individual customer protection at much lower levels in the fine print. "Up to 1 Tbps network protection, individual servers protected up to 5 Gbps" is a real pattern that traps customers.

What a good answer looks like: "Your plan covers attacks up to X Gbps inbound. Above X Gbps, your IP is null-routed for Y minutes while we evaluate, and you receive a notification email. Premium plans raise the threshold to Z Gbps."

What a bad answer looks like: "Unlimited DDoS protection." That phrase is meaningless — no host has unlimited capacity, and the upper bound matters precisely when you most need it.

Question 6: "What is your refund policy if my server is unreachable during an attack?"

Why it matters: separates hosts who stand behind their product from hosts whose protection promise is asymmetric — they keep your money whether the protection works or not. A host with no SLA-backed refund commitment is selling you marketing, not infrastructure.

What a good answer looks like: "We offer pro-rated refunds for any downtime caused by mitigation failure under our SLA, see {link}." Pterodactyl-tier managed hosts and serious dedicated providers will have written SLAs. Budget hosts often won't.

What a bad answer looks like: "DDoS attacks are force-majeure and not covered by our SLA." Walk away. The host whose entire product category is DDoS protection is excluding DDoS from their SLA.

Question 7: "If I want to put Cloudflare Spectrum / TCPShield / a GRE tunnel in front of your server, do you support that?"

Why it matters: a host confident in their network welcomes you adding additional protection in front of it; a host with a fragile setup will refuse, claiming "network conflicts." The answer is also useful as a Plan B — if their protection fails, can you stack a real one in front?

What a good answer looks like: "Yes, we support customers running their own reverse proxy or tunnel. We can configure your server to bind to specific IPs and we accept GRE tunnel termination on request."

What a bad answer looks like: "That's not supported on our platform." That tells you the host's protection is the only protection you'll get, and if it fails you have no recourse.

06 // Self-hosted hardening — the iptables ruleset every game server should have

Everything in part 1 was about choosing the right upstream protection. This section is about the layer beneath that one: what your own Linux box does when an attack actually reaches the network interface. Even on a Tier S host, kernel-level packet filtering is your last line of defense against the small attacks that slip past the scrubber, the malformed-packet probes that aren’t volumetric enough to trip mitigation, and the slow application-layer floods that look like ten extra players. Without this layer, a 50 Mbps trickle of bad UDP can degrade your server while bandwidth graphs at the host stay flat.

The minimum viable ruleset (Ubuntu 22.04 / Debian 12, iptables-legacy)

Save this as /etc/iptables/rules.v4 or run line-by-line and persist with iptables-persistent. It assumes a Source Engine game on UDP 27015, Minecraft on 25565/tcp, SSH on a non-default port (replace 2222 with yours), and that you’ve already locked down SSH with key-only auth.

# --- /etc/iptables/rules.v4 ---
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# 1. allow established/related and loopback
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP

# 2. drop obviously bad packets early
-A INPUT -p tcp --tcp-flags ALL NONE        -j DROP   # null packets
-A INPUT -p tcp --tcp-flags ALL ALL         -j DROP   # XMAS
-A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
-A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
-A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -f                                 -j DROP   # fragments
-A INPUT -p icmp --icmp-type address-mask-request -j DROP
-A INPUT -p icmp --icmp-type timestamp-request    -j DROP

# 3. ICMP echo rate limit (drop the rest)
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 5 -j ACCEPT
-A INPUT -p icmp -j DROP

# 4. SSH on 2222 with brute-force throttle
-A INPUT -p tcp --dport 2222 -m conntrack --ctstate NEW -m recent --set --name SSH
-A INPUT -p tcp --dport 2222 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
-A INPUT -p tcp --dport 2222 -j ACCEPT

# 5. SYN-flood protection on Minecraft TCP
-A INPUT -p tcp --dport 25565 --syn -m recent --set --name MC_SYN
-A INPUT -p tcp --dport 25565 --syn -m recent --update --seconds 1 --hitcount 60 --name MC_SYN -j DROP
-A INPUT -p tcp --dport 25565 -j ACCEPT

# 6. UDP per-source rate-limit on Source Engine port (kills single-IP floods)
-A INPUT -p udp --dport 27015 -m hashlimit \
   --hashlimit-name srcengine --hashlimit-mode srcip \
   --hashlimit-above 50/second --hashlimit-burst 100 -j DROP
-A INPUT -p udp --dport 27015 -j ACCEPT

# 7. drop Source Engine A2S_INFO challenge spam
-A INPUT -p udp --dport 27015 -m string --algo bm --hex-string "|FFFFFFFF54|" \
   -m hashlimit --hashlimit-name a2s --hashlimit-mode srcip \
   --hashlimit-above 5/second --hashlimit-burst 20 -j DROP

# 8. log dropped packets at low rate (forensics, not flood)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-drop: " --log-level 4

COMMIT

Apply with:

sudo apt-get install -y iptables-persistent
sudo iptables-restore < /etc/iptables/rules.v4
sudo netfilter-persistent save

Test it before you log out. Open a second SSH session before applying and verify it stays connected. Lock yourself out and you’re walking through provider rescue-mode hell to recover.

Sysctl tuning — the kernel-level half nobody mentions

The iptables rules above are the visible half. The other half is sysctl — tuning the kernel’s TCP stack and conntrack table so an attack doesn’t exhaust your server’s resources before iptables has a chance to filter. Add to /etc/sysctl.d/99-ddos.conf:

# SYN cookie protection (turns on when SYN backlog overflows)
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3

# stop accepting source-routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# enable reverse-path filtering (anti-spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# log spoofed/source-routed packets
net.ipv4.conf.all.log_martians = 1

# bigger conntrack table so volumetric floods don't fill it
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_tcp_timeout_established = 7200
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120

# reduce TIME_WAIT pile-up
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# socket buffers (more headroom for legitimate burst traffic)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 16384

Apply with sudo sysctl --system. The conntrack table size is the most important line for game servers: a default 65k table fills up in seconds during a moderate UDP flood, at which point new legitimate connections silently drop. Bumping it to 524k buys you orders of magnitude more headroom. This single change alone has more practical impact than half the iptables rules above — and almost no "DDoS protection" guide mentions it.

nftables — the modern equivalent (Debian 12+ default)

If you’re on a fresh Debian 12 / Ubuntu 24.04, nftables is the default and iptables-legacy is a wrapper. The same logic in nftables syntax (save as /etc/nftables.conf):

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        # bad TCP flag combos
        tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop
        tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg drop
        tcp flags & (fin|syn) == fin|syn drop
        tcp flags & (syn|rst) == syn|rst drop

        # ICMP rate limit
        ip protocol icmp icmp type echo-request limit rate 1/second burst 5 packets accept
        ip protocol icmp drop

        # SSH brute-force throttle (4 conns/min per IP)
        tcp dport 2222 ct state new \
            meter ssh_throttle { ip saddr limit rate 4/minute } accept

        # Minecraft SYN-flood limit (60 SYNs/sec per IP)
        tcp dport 25565 tcp flags syn \
            meter mc_syn { ip saddr limit rate 60/second } accept

        # Source Engine UDP rate limit (50 pps per IP)
        udp dport 27015 \
            meter src_udp { ip saddr limit rate 50/second burst 100 packets } accept
        udp dport 27015 drop

        # log dropped at low rate
        limit rate 5/minute log prefix "nft-drop: " level info
    }
    chain forward { type filter hook forward priority 0; policy drop; }
    chain output  { type filter hook output  priority 0; policy accept; }
}

Enable with sudo systemctl enable --now nftables. nftables is faster than iptables under load, uses one unified syntax for v4/v6, and the meter primitive is cleaner than recent + hashlimit. If you’re starting fresh in 2026, prefer nftables.

fail2ban for game-server-specific log monitoring

iptables/nftables filter at the packet level. fail2ban filters at the application-log level — it watches your game server’s log file, detects patterns (failed RCON auth, repeated connection storms from one IP, suspicious A2S queries), and adds the offender to a temporary ban list. Install with sudo apt-get install -y fail2ban, then create /etc/fail2ban/jail.d/gameserver.conf:

[rust-rcon-bruteforce]
enabled  = true
port     = 28016
filter   = rust-rcon
logpath  = /home/rust/server/my_server_identity/Log.Console.txt
maxretry = 3
findtime = 600
bantime  = 86400

[mc-connection-spam]
enabled  = true
port     = 25565
filter   = mc-connect
logpath  = /home/mc/logs/latest.log
maxretry = 30
findtime = 60
bantime  = 3600

You’ll need to write the filter regexes in /etc/fail2ban/filter.d/rust-rcon.conf and similar — they’re game-specific, and the right patterns depend on your server’s log format. The point is: fail2ban catches application-layer patterns that packet filtering can’t see, like 50 failed RCON password attempts from one IP that look like normal traffic at the packet level.

Verifying it works

Run these regularly:

# live drop counter (watch this during a real attack)
sudo iptables -L INPUT -v -n --line-numbers

# nftables equivalent
sudo nft list ruleset

# conntrack table usage (alarm if approaching nf_conntrack_max)
cat /proc/sys/net/netfilter/nf_conntrack_count

# top source IPs by current connection count
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# fail2ban current bans
sudo fail2ban-client status
sudo fail2ban-client status rust-rcon-bruteforce

During a real attack, watch iptables -L INPUT -v -n in one terminal and nf_conntrack_count in another. If the drop counters on your rate-limit rules are climbing fast and conntrack is below 50% capacity, your hardening is working. If conntrack is pegged at max, the attack is bigger than your VPS can handle alone — this is when upstream protection (the next two sections) matters.

07 // The GRE-tunnel-to-Path-reseller setup — budget UDP protection that nobody publishes

This is the section that would have saved me from five wasted host rentals if any of the existing “DDoS protection” guides had bothered to write it. The setup costs $10–25/month, protects UDP-protocol games (Mordhau, Squad, Rust, ARK, Conan, FiveM, Valheim, V Rising, Palworld — the games Cloudflare Spectrum’s budget tier doesn’t cover), and uses a topology that only network-engineering blogs and a handful of LowEndTalk threads document. If you came to this guide for one specific actionable thing, this is probably it.

The architecture in one diagram

                    +----------------------+
                    |  Path.net network    |
                    |  17 Tbps mitigation  |
                    |  game-aware filters  |
                    +----------+-----------+
                               |
                  Players ---> | (clean traffic on UDP 27015)
                               |
                    +----------v-----------+
                    |  Reseller VPS        |   ← rent this ($10-25/mo)
                    |  (e.g. VibeGames)    |       Public IP advertised to players.
                    |  Path-protected IP   |       Filters all DDoS at the edge.
                    +----------+-----------+
                               |
                               | GRE tunnel over the public internet
                               |  (encapsulates UDP 27015 inside protocol 47)
                               |
                    +----------v-----------+
                    |  Your game VPS       |   ← Hostinger / OVH / wherever
                    |  (Hostinger KVM 4)   |       Real IP never advertised.
                    |  Game runs here      |       Players never connect direct.
                    +----------------------+

The game runs on your cheap unprotected VPS. Players connect to the relay’s public IP, which sits inside Path.net’s mitigation network. Path filters the attacks at 17 Tbps of edge capacity. Clean UDP packets enter the relay, get encapsulated in a GRE tunnel (IP protocol 47), and arrive at your game server’s real IP. Replies go back through the tunnel and out the relay’s public IP. Players never learn your real IP, and an attacker who somehow finds it can’t reach your game port because the game only listens on the GRE interface.

Step 1 — Pick a Path-protected reseller

You don’t buy from Path.net directly — their dedicated tier starts at hundreds of dollars per month. Instead, you buy from one of their resellers: small hosts that lease Path-protected VPS or game-server slots and resell them affordably.

Before you order: open a pre-sales ticket and ask three things. (1) Is your network upstreamed by Path.net? (2) Do you allow GRE tunnels (IP protocol 47) outbound from the VPS? (3) Do you charge extra for DDoS-protection bandwidth, or is the protection included with the listed price? A real Path reseller will answer all three in plain technical language. A reseller who pivots any of those questions to marketing copy is reselling something else.

Step 2 — Configure the relay (Path-protected VPS)

SSH into the relay. Enable IP forwarding and create the GRE tunnel pointing at your real game VPS:

# on the RELAY (public IP: 1.2.3.4, real game VPS public IP: 5.6.7.8)
sudo sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-forward.conf

sudo modprobe ip_gre
echo 'ip_gre' | sudo tee /etc/modules-load.d/gre.conf

# create tunnel: relay-end has 10.0.0.1, game-end has 10.0.0.2
sudo ip tunnel add gre1 mode gre remote 5.6.7.8 local 1.2.3.4 ttl 255
sudo ip link set gre1 up
sudo ip addr add 10.0.0.1/30 dev gre1

# forward UDP 27015 (Source Engine) from public to game server
sudo iptables -t nat -A PREROUTING -p udp --dport 27015 -j DNAT --to-destination 10.0.0.2:27015
sudo iptables -t nat -A POSTROUTING -o gre1 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o gre1 -p udp --dport 27015 -j ACCEPT
sudo iptables -A FORWARD -i gre1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# persist
sudo netfilter-persistent save

Step 3 — Configure the game VPS (Hostinger / OVH / wherever)

SSH into your real game VPS and create the matching tunnel endpoint:

# on the GAME VPS (its public IP: 5.6.7.8, relay's public IP: 1.2.3.4)
sudo modprobe ip_gre
echo 'ip_gre' | sudo tee /etc/modules-load.d/gre.conf

sudo ip tunnel add gre1 mode gre remote 1.2.3.4 local 5.6.7.8 ttl 255
sudo ip link set gre1 up
sudo ip addr add 10.0.0.2/30 dev gre1

# bind your game server to the GRE interface IP, NOT the public IP.
# In your game's startup script, set bind-IP to 10.0.0.2.
# Source Engine example: -ip 10.0.0.2
# Rust example:          +server.ip 10.0.0.2
# Minecraft Java:        server-ip=10.0.0.2 in server.properties

# tighten iptables: drop direct attacks on the public IP's game port
sudo iptables -A INPUT -i eth0 -p udp --dport 27015 -j DROP
sudo iptables -A INPUT -i gre1 -p udp --dport 27015 -j ACCEPT
sudo netfilter-persistent save

To make the tunnel survive reboot, add a /etc/systemd/network/gre1.netdev + .network pair (systemd-networkd) or drop the ip tunnel commands into /etc/rc.local. The mechanics are the same.

Step 4 — Point your DNS at the relay, not the game VPS

Update your domain’s A record (or the IP you tell players) to the relay’s public IP. The game VPS’s public IP should appear nowhere — not in DNS, not in Steam group descriptions, not in screenshots, not in BattleMetrics. Treat the real IP as a secret. If a screenshot of your console window shows the bind-IP in your status bar, an attacker can find your real IP through Steam server browser caches and bypass the relay. Always bind to 10.0.0.2, not 0.0.0.0.

Step 5 — Verify

# on relay: see GRE encapsulated traffic
sudo tcpdump -i eth0 proto 47 -nn

# on game VPS: see decapsulated game traffic on tunnel interface
sudo tcpdump -i gre1 udp port 27015 -nn

# from a third box (your laptop): connect to relay IP normally
# game traffic should arrive on game VPS via gre1, not via eth0.

Caveat — latency. Adding a relay hop adds 5–30 ms of one-way latency depending on geographic alignment between your relay and your game VPS. Pick a relay region that matches your player base (EU relay for EU players), and pick a game VPS in the same region or a directly-peered datacenter. Done correctly, players see <10 ms additional ping. Done badly (EU players, Frankfurt relay, US-Phoenix game server), they see 80+ ms and complain.

08 // Cloudflare Tunnel — free protection for your admin panel (and only your admin panel)

Section 07 solved the game-traffic half of the problem. This section solves the part most admins forget about: your control panel, RCON web UI, and stats dashboard are also DDoS targets, and they’re often hosted on the same VPS as the game. An attacker who can’t crash your game by flooding UDP 27015 will happily try to crash your Pterodactyl panel by flooding TCP 443 instead. If your panel goes down, you can’t restart the game, can’t see logs, can’t kick the bad actor — and the panel runs on the same kernel that runs your game.

The fix is Cloudflare Tunnel (also called cloudflared), and it is one of the most under-utilized tools in self-hosted game infrastructure. It is free on Cloudflare’s default plan, has no bandwidth limit for tunnel traffic, and uses Cloudflare’s 300+ POP edge network to absorb attacks before they reach your VPS.

How it works

Instead of opening port 443 on your VPS’s public IP and pointing DNS at it (the standard setup, which exposes your VPS’s real IP and makes it directly attackable), you run the cloudflared daemon on your VPS. The daemon makes an outbound persistent connection to Cloudflare’s edge. Browser requests for panel.yourdomain.com hit Cloudflare’s edge, get filtered (DDoS, WAF, bot management), and Cloudflare forwards the clean request through the existing outbound tunnel to your cloudflared daemon, which proxies it to localhost:8080 (your panel). Your VPS never opens an inbound port for the panel. The real IP is never advertised in DNS.

Step 1 — Install cloudflared on the VPS

# Debian / Ubuntu
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install -y cloudflared

# verify
cloudflared --version

Step 2 — Authenticate and create the tunnel

# opens a browser to authorize cloudflared with your Cloudflare account
cloudflared tunnel login

# create a named tunnel
cloudflared tunnel create gameserver-panel

# this prints a tunnel UUID and creates ~/.cloudflared/<UUID>.json (the tunnel credentials)

Step 3 — Configure the tunnel routing

Create ~/.cloudflared/config.yml:

tunnel: <UUID-from-step-2>
credentials-file: /root/.cloudflared/<UUID-from-step-2>.json

ingress:
  # Pterodactyl panel
  - hostname: panel.yourdomain.com
    service: http://localhost:8080
  # Optional: a separate hostname for SFTP-over-Cloudflare-Access (advanced)
  # - hostname: files.yourdomain.com
  #   service: http://localhost:8080
  # catch-all (required as last entry)
  - service: http_status:404

Point DNS by running:

cloudflared tunnel route dns gameserver-panel panel.yourdomain.com

This creates a CNAME in Cloudflare DNS pointing panel.yourdomain.com at <UUID>.cfargotunnel.com. The DNS record is automatically proxied (orange cloud) and your origin IP appears nowhere.

Step 4 — Run as a systemd service

sudo cloudflared service install
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

Step 5 — Lock down the panel’s direct port

Now that the tunnel is the only path to the panel, close the panel’s direct port to the public internet. Edit your iptables rules to bind the panel to localhost only (or drop inbound 8080/443):

# in your panel's nginx/Apache config, change:
#   listen 443 ssl;
# to:
#   listen 127.0.0.1:8080;
# Cloudflare Tunnel reaches it via localhost; the public internet cannot.

# extra belt-and-braces: drop 8080 from the public interface
sudo iptables -A INPUT -i eth0 -p tcp --dport 8080 -j DROP

Bonus — Cloudflare Access for admin-only panels

If your panel is for you and 1–2 trusted moderators only (not for end-users registering accounts), enable Cloudflare Access in front of the tunnel. Free tier covers 50 users. It puts an authentication wall (Google login, GitHub login, email-OTP, or hardware-key) before Cloudflare even forwards the request to your tunnel. Result: even a zero-day in Pterodactyl can’t be exploited by an unauthenticated attacker, because Cloudflare won’t pass the request to your VPS until they’ve logged in. Configure at one.dash.cloudflare.com → Access → Applications → Add a self-hosted application.

Cost summary: Cloudflare Tunnel itself is free, unlimited bandwidth on any Cloudflare plan including the free tier. Cloudflare Access for up to 50 users is also free. The protection level is genuinely enterprise-grade because you’re using Cloudflare’s real edge network. There is no equivalent in the “managed game host” market — this is something you can only do by self-hosting and running cloudflared yourself, which is exactly why so few admins know it exists.

09 // Tailscale mesh — the $0 bulletproof solution for friends-only servers

If your server isn’t public — if it’s a Minecraft realm for ten friends, a private Rust wipe with a known group, a small co-op Valheim world — the cheapest and most effective DDoS protection in existence is to not have a public IP at all. Tailscale (or its self-hosted twin Headscale) lets you do exactly that: your game server has no port open to the public internet, your friends connect over a WireGuard mesh, and there is literally no attack surface for a DDoS to land on.

This solution is invisible to almost every game admin because every “how to host a server” tutorial assumes a public IP and port forwarding. Once you stop assuming that, the entire DDoS problem disappears. You cannot DDoS what isn’t reachable.

How it works

Tailscale builds a virtual private network over WireGuard between every device that joins your tailnet (your private mesh). Every device gets a 100.x.x.x IP that’s only routable inside the tailnet. Your game server binds to its tailnet IP. Your friends, after installing Tailscale on their machine and joining your tailnet, can reach that IP. The wider internet cannot — there’s no public IP, no public port, no DNS record. There is nothing for a DDoS to target. The worst an attacker can do is DDoS the public IP your VPS happens to have for SSH/management traffic, which is a different IP than the game server is bound to.

Step 1 — Install Tailscale on the game VPS

# Debian / Ubuntu
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# follow the printed URL, log in with Google/GitHub/Microsoft, authorize this machine

# verify and grab the tailnet IP
tailscale ip -4
# example output: 100.64.12.34

Step 2 — Bind the game server to the tailnet IP

Same approach as the GRE setup in Section 07: tell the game to listen on the tailnet IP only, not 0.0.0.0.

# Source Engine (CS2/TF2):  -ip 100.64.12.34
# Rust:                     +server.ip 100.64.12.34
# Minecraft Java:           server-ip=100.64.12.34 in server.properties
# Valheim:                  -public 0 (don't list on community server browser)
# ARK:                      ?MultiHome=100.64.12.34 in startup

Then drop direct public access to the game port:

sudo iptables -A INPUT -i eth0 -p udp --dport 27015 -j DROP
sudo iptables -A INPUT -i eth0 -p tcp --dport 25565 -j DROP
sudo netfilter-persistent save

Step 3 — Onboard each friend

Each friend installs the Tailscale client (Windows, macOS, Linux, iOS, Android — all free), logs in with the same identity provider you set up the tailnet with, and authorizes their device. They’ll show up in your tailnet’s admin console. Connection to your server is then just connect 100.64.12.34:27015 in the in-game console — same flow as connecting to any LAN server.

The free tier of Tailscale covers 3 users and 100 devices per tailnet. For a friends-only Rust wipe with 8 friends, that’s plenty — but note “users” is the limit, not “devices”. If you have more than 3 friends, either upgrade to the Personal Plus plan (~$5/month) or switch to Headscale, the open-source self-hosted Tailscale coordination server that has no user limits.

Alternative — ZeroTier and Headscale

Two equivalents worth knowing about:

• ZeroTier — same model, different protocol. Free tier covers 25 nodes (devices, not users), which is often more practical for friend groups than Tailscale’s 3-user limit. zerotier.com
• Headscale — you self-host the coordination server (a small Go binary, ~50 MB RAM); the official Tailscale clients connect to it. No artificial user limits, no SaaS dependency. Best for large friend groups or paranoid setups. github.com/juanfont/headscale

Cost: Tailscale free tier or ZeroTier free tier — $0/month. Headscale on a $5 VPS — $5/month and unlimited everything. Game VPS still costs whatever it costs, but it can be the cheapest possible host because nobody on the public internet can reach it. A $4/month KVM 1 from Hostinger is sufficient because there is no DDoS attack surface to defend.

This is the strategy I’d recommend to anyone hosting for <30 known people. The reason it isn’t the default in every guide is that hosting blogs make affiliate money from large servers and managed hosts, not from telling people they don’t need either. Honest answer: for friend groups, you don’t need either.

10 // Five case studies — what "DDoS protected" actually delivered, from 5 different providers

I (Keishin) ran community game servers from roughly 2020 to 2024, primarily Mordhau (UDP / Unreal Engine) plus a few Minecraft and Source Engine servers along the way. Over that period I rented “DDoS protected” service from five different providers trying to find one that could keep my Mordhau community alive during repeated targeted attacks. None of them worked. Below are the five case studies, in the order I rented them, with technical translation of why each failure happened.

Case study 1 — G-Portal with Cosmic Guard (Mordhau, ~2021–2022)

The marketing: G-Portal markets “Cosmic Guard DDoS Protection” on every game-hosting product page, including for Mordhau slots. The implication, like most managed-host marketing, is that protection is included and proactive.

What actually happened: When attacks hit the server, the server crashed. After it crashed, G-Portal’s management layer detected the dead instance and automatically restarted it. The attack was still in progress, so the freshly-restarted instance crashed again within seconds. This loop continued until the attacker stopped voluntarily. From the player perspective, the server was effectively unreachable for the entire duration of every attack — but it never showed as “offline” on the billing portal because something was always either running or restarting.

Technical translation: What G-Portal called “DDoS Protection” was, in my experience, crash-and-restart resilience marketed as protection. The infrastructure caught the fact that the game process had died and respawned it, which is a useful feature for handling crashes from bad mods or memory leaks — but it is not DDoS mitigation. Real mitigation prevents the attack packets from ever reaching the game process. A restart loop is what happens when the upstream network has no scrubbing capability for the specific protocol under attack. This is the failure pattern Section 01 calls Lie #1 — the “null-route then auto-restart” pattern, just with the null-route step skipped because the attack was small enough to crash the process directly.

Case study 2 — GTXGaming (Mordhau, ~2022)

The marketing: GTXGaming’s Mordhau product page during this period advertised “DDoS Protected” without further qualification on attack types or capacity.

What actually happened: The server didn’t crash — that was the only positive. But during every attack, the in-game admin console was flooded with connection attempts from thousands of attacker IPs, the server lagged catastrophically (TPS visibly dropped, players rubber-banded across the map, hits didn’t register), and the lag continued for the entire duration of the attack until the attacker stopped on their own. There was no point at which the host’s mitigation kicked in to restore performance.

Technical translation: GTXGaming had some form of L3/L4 protection — the server stayed up and the game process kept running, which would not have happened with a pure volumetric flood reaching the kernel uncontested. But there was no L7 / game-protocol layer. Attacker traffic that looked like legitimate Unreal Engine UDP packets passed straight through the L3/L4 filter and arrived at the game tickrate, dragging it down to single-digit TPS. This is the failure pattern Section 01 calls Lie #2 — L3/L4-only protection sold as full-stack protection. It works for kiddie ICMP floods. It does not work for protocol-aware attacks against UDP games.

Case study 3 — Nitrado (Mordhau, ~2022–2023)

The marketing: Nitrado’s product pages advertise “DDoS Protection included” across all their game offerings.

What actually happened: I emailed Nitrado support directly to ask whether their DDoS protection covered Mordhau. They replied admitting it did not. The email confirmed that their DDoS filtering recognises a whitelist of specific game protocols (Source Engine query traffic, Minecraft handshake patterns, Rust’s Facepunch query format, a handful of others) and that Mordhau’s Unreal Engine traffic was not on that whitelist. Without protocol recognition, traffic to my server was treated as generic UDP and effectively unprotected.

Technical translation: This was the most honest answer I got from any of the five providers, and it taught me the most important single fact about budget-tier game DDoS protection: most of it is a protocol whitelist, not a generic filter. The provider’s scrubber has fingerprint rules for specific games. If your game isn’t on the list, the protection doesn’t apply to your traffic regardless of what the marketing page says. This isn’t Nitrado-specific — it’s how almost every “included DDoS protection” on a managed game host actually works, and it’s why the “UDP / Unreal Engine desert” (Mordhau, Squad, Chivalry 2, Conan Exiles, V Rising, Palworld) is so hard to protect on budget hosting.

Case study 4 — Evolution Host (Mordhau, ~2022–2023)

The marketing: Evolution Host (evolution-host.com) marketed DDoS protection on their VPS and game-server tiers during this period.

What actually happened: I tried Evolution Host as a VPS to self-host Mordhau (giving me more control than the managed offerings above). When attacks hit, the server kept crashing. The result was indistinguishable from the G-Portal case — protection on paper, crashes in practice. I cancelled within the contract minimum.

Technical translation: I never got a clear technical answer from support about what their actual filtering capability was, which by itself is a Section 05 red flag. With hindsight, the symptoms suggest either a shared protection budget failure (Lie #3 — the host has X Gbps of total scrubbing capacity shared across all customers, and during peak attacks others on the same shared protection consumed it) or simply L3/L4-only filtering hitting the same UDP-game gap as GTXGaming. I have no way to confirm which without packet captures from the host, which I did not have access to.

Case study 5 — BuyVM (Mordhau, ~2023)

The marketing: BuyVM (buyvm.net) is well-known on LowEndTalk and explicitly markets DDoS protection on their VPS plans — including, depending on the plan and node, mention of Path.net upstream filtering on some routes.

What actually happened: The server kept crashing under attack. Same outcome as the others. I want to be specific: this was my experience with BuyVM during ~2023 with a Mordhau workload. LowEndTalk threads from 2024 onward report that BuyVM’s Path.net-routed nodes do hold up well against attacks for many users, and BuyVM is widely respected in the LET community for transparent communication. My data point is one workload, on one VPS plan, in one specific timeframe.

Technical translation: The most likely explanation, looking back, is that the specific plan I was on did not route through Path.net upstream — BuyVM has multiple node locations and not all of them are equally protected. Without a pre-sales conversation that explicitly confirmed Path was upstream of my exact node, I had no guarantee my traffic was scrubbed at all. This is the lesson for readers: even with a reputable host, the protection is location- and plan-specific. The seven questions in Section 05 (especially Q3, “what is your upstream transit and is your DDoS scrubbing performed by your transit provider or by you?”) would have caught this before I paid.

The pattern across all five

Five providers. One game (Mordhau). Five different failure modes — restart-loop, L3/L4-only, protocol-whitelist gap, opaque-shared-budget, location-specific-routing. Every single one of them advertised “DDoS protection” on their product page. None of the marketing copy on any of those product pages, in 2020–2024, would have warned me about any of these failure modes. I had to discover each one by paying for the service, getting attacked, and watching it fail.

Eventually I learned the only protection that worked reliably for a Cloudflare-routed Minecraft server I ran in the same period was Cloudflare Spectrum on the TCP tier. For Mordhau (UDP), the Cloudflare equivalent would have been Spectrum UDP — which, as Section 13 covers in detail, is enterprise-tier only at $5,000+/month and was completely out of reach for a community server. That gap — the gap between “Cloudflare Spectrum TCP for Minecraft works

Eventually I learned the only protection that worked reliably for the Minecraft server I ran in the same period was Cloudflare Spectrum on the TCP tier. For Mordhau (UDP), the Cloudflare equivalent would have been Spectrum UDP — which, as Section 13 covers in detail, is enterprise-tier only at $5,000+/month and was completely out of reach for a community server. That gap — the gap between “Cloudflare Spectrum TCP for Minecraft works for $20/mo” and “Cloudflare Spectrum UDP for everything else costs $5,000/mo” — is the protection desert this entire guide exists to map. The closest budget-tier substitutes are documented in Sections 06–09: Path.net resellers via GRE tunnel, Combahton FPS Shield direct, Tailscale mesh for friend groups, and where applicable, switching the public-facing layer to Cloudflare Tunnel for any TCP-based admin interface.

If you take one thing from these five case studies: marketing claims of “DDoS protection” mean nothing without a specific technical answer to the seven questions in Section 05. Ask before you pay. Get the answer in writing. Verify with the host’s own status page and forum mentions. If they won’t answer specifically, that is the answer.

11 // "I'm being attacked RIGHT NOW" — the panic checklist

If you landed on this section because your server is currently down or lagging and you suspect a DDoS, bookmark this page now and work through the steps in order. Every minute matters, but acting in the wrong order makes things worse — e.g. switching IPs before you’ve confirmed it’s actually a DDoS just hands the attacker a fresh target.

First 5 minutes — confirm it’s actually a DDoS

1. Check your host’s status page. If the host has a network-wide incident, your server’s symptoms aren’t about you. Don’t change anything yet.
2. SSH in and check basic load. uptime, top, htop. CPU pegged at 100% on the game process is a game-side problem (mod or plugin). CPU pegged on ksoftirqd kernel threads is the network stack drowning — that’s a real DDoS signal.
3. Check inbound packet rate. Run vnstat -l -i eth0 for 30 seconds, or iftop -nNP. If you’re seeing >100k packets/sec on a server that normally handles <5k pps, you’re being attacked.
4. Snapshot the source distribution. sudo tcpdump -i eth0 -nn -c 1000 'port 27015' | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20. If the top 20 source IPs are each contributing roughly equal traffic from geographically scattered networks, it’s a botnet flood. If one or two IPs dominate, it might just be a buggy client — ban those and see if it stops.
5. Confirmed attack? Move to the next block. Not confirmed? STOP — investigate the game side first.

Minutes 5–30 — immediate damage control

1. Pause the public game port at the firewall. Better to be cleanly offline for 10 minutes while you set up mitigation than to lag for 6 hours. sudo iptables -I INPUT -p udp --dport 27015 -j DROP (or whatever your game port is). Announce on Discord: “Server is offline while we mitigate a DDoS, ETA 30 minutes.”
2. Open a support ticket with your host. Subject: “Active DDoS on IP [your.ip.here], port [27015], started at [timestamp UTC]”. Include the tcpdump source-IP snapshot from step 4 above. Honest hosts will null-route the attacked IP and either give you a fresh IP or escalate to their upstream scrubber. Less honest hosts will tell you to upgrade plans — that’s a Section 05 red flag, but for now you need them to act.
3. If you have GRE+Path.net or similar pre-configured (Section 07), stop the public-IP listener entirely and bring up the protected listener on the GRE interface only. Update Discord with the new connect IP.
4. If your panel (Pterodactyl/AMP/Pelican) shares the public IP, close its port at the firewall too. Many DDoS tools probe panel ports as part of reconnaissance — locking it during an attack reduces your overall surface. sudo iptables -I INPUT -p tcp --dport 8080 -j DROP (adjust port for your panel).
5. Save evidence. sudo tcpdump -i eth0 -w /root/attack-$(date +%s).pcap -G 600 -W 1 'port 27015'. This captures 10 minutes of attack traffic for later forensics, NOC reports, or police reports.

Minutes 30–120 — deploy real mitigation

1. Cheapest path: if your host won’t escalate or their mitigation isn’t working, spin up a Path.net reseller VPS (Section 07) in the same region. ~$10–25/mo, hourly billing on most providers. Configure GRE tunnel from your origin VPS through it. Bring the game back up bound to the GRE-tunnel interface only. Total time from signup to back-online with real protection: 60–90 minutes if you’ve never done it before.
2. For Minecraft Java specifically: point your domain at TCPShield’s free tier (Section 06 covers the setup). 5-minute fix. Update your community: “new connect address: play.yourcommunity.com (don’t use the IP anymore).”
3. For friend-only servers: install Tailscale (Section 09), bind the game to the tailnet IP, drop the public port. Onboard your handful of regulars over Discord one-by-one. Total time: 30 minutes including the “help my Discord, how do I install Tailscale” messages from non-technical friends.
4. Whatever path you took, verify the protection is working by trying to nmap -sU -p 27015 your.public.ip from outside — if the public IP no longer responds on the game port but the protected route does, you’ve cleanly migrated.

Hours 2–24 — consolidate and harden

1. Re-IP your VPS (most hosts allow one free IP change per quarter or per attack). Decommission the attacked IP entirely. The new IP should never appear in any DNS record — only the GRE tunnel exit, TCPShield CNAME, or Tailnet should be public-facing.
2. Lock down DNS. No A record for the bare play.yourcommunity.com pointing at the origin. Either CNAME to your protected proxy, or A-record only to the GRE/Path exit IP. The origin’s real IP must never appear in any public record.
3. Strip metadata leaks. Server query response, MOTD, server-list listing — check that none of them leak the origin IP. For Source Engine, use sv_lan 0 and +ip 10.x.x.x (the GRE-tunnel IP, not the public one). For Minecraft, set server-ip= to the tunnel IP.
4. Review who knew the IP. Most targeted attacks against community servers come from inside the community — a banned player, an ex-staff member, a rival server’s admin. The attacker either had the IP from when they were a regular player, or they pulled it from a public source. Audit who had admin/console access in the last 90 days. Audit which Discord channels mentioned the IP. Audit BattleMetrics, server lists, and any public listing for IP exposure.
5. File reports. If the attack was severe and prolonged, report to your host’s NOC (they often take action upstream), and file a report with your local cybercrime unit (in the EU, via your national CERT; in the US, via FBI IC3 at ic3.gov). It rarely results in arrests but it builds the legal record if you ever sue or if the attacker is caught for unrelated reasons.

12 // The Cloudflare Spectrum UDP reality — the $5,000/month truth nobody publishes

Anywhere on the internet you read “just put your game server behind Cloudflare,” the writer either runs Minecraft Java only, or doesn’t know what they’re talking about. Here is the reality, in plain numbers, that almost no hosting blog will tell you because it doesn’t generate affiliate revenue.

Cloudflare Spectrum TCP — the affordable tier

• Pro plan: $20/month, includes one TCP application via Spectrum.
• Business plan: $200/month, includes more applications and SLAs.
• What it protects: any TCP-based game (Minecraft Java, Minecraft Bedrock over TCP proxy, anything wrappable via TCP).
• What it doesn’t protect: UDP-based games — which is most of them.

For a Minecraft Java community, $20/month for Cloudflare Pro plus Spectrum gives you essentially the same scrubbing infrastructure that protects banks. It’s the single best protection-per-dollar in the entire industry. If you run Minecraft Java, you should already be on Spectrum.

Cloudflare Spectrum UDP — the wall

Cloudflare offers Spectrum support for UDP traffic, but only on the Enterprise tier. Enterprise plans at Cloudflare are custom-quoted, not self-serve. Public reports from sales conversations and industry sources put the realistic floor at:

• Entry-level Enterprise: ~$5,000–$10,000/month, annual contract.
• Spectrum UDP add-on: often quoted as additional usage fees on top.
• Minimum commit: typically 12-month contracts; no monthly opt-out.

For a community game server — Mordhau, Squad, Chivalry 2, Rust, ARK, V Rising, Conan Exiles, Palworld, Valheim, every Source Engine UDP game — Cloudflare Spectrum UDP is functionally not an option. Even successful monetized servers running 200+ players on Patreon-funded budgets typically operate on $200–$500/month total infrastructure spend. $5,000/month for protection alone is a non-starter for 99.9% of game admins.

Why this matters strategically

The reason this reality is rarely published clearly is that it changes the entire framing of the problem. If “just use Cloudflare” were a real answer for UDP games, every guide could end after one sentence. Because it isn’t, every UDP game admin faces a choice between three real paths:

1. Pay a managed host’s “DDoS protection” that often isn’t real — the path my five case studies in Section 10 took.
2. Self-route via a Path.net reseller VPS over GRE (Section 07) — $10–25/month, requires Linux and networking knowledge, but actually works. This is the path no listicle publishes because it has no affiliate program.
3. Switch to a fundamentally different model — Tailscale mesh for friend-only servers (Section 09), or accept that you’re running a public UDP server on the open internet and budget for occasional downtime when you’re targeted.

The TCPShield exception (Minecraft only)

Worth restating because it’s the single most cost-effective branded protection for any game: TCPShield is purpose-built for Minecraft Java, has a free tier (yes, actually free) sufficient for most communities, and a paid tier under $10/month that handles most of the rest. It works because Minecraft Java is TCP and because TCPShield runs its own proxy network at the edge. There is no equivalent service for UDP games — the closest analogues are Path.net resellers (which require GRE tunnel setup) and Combahton FPS Shield (for the specific games Combahton fingerprints).

The bottom line

Cloudflare is excellent for everything except the games most people actually want to play. For UDP titles, the budget-grade alternatives in Sections 06–09 are not a downgrade from a Cloudflare-tier solution — they are the entire viable solution space. Anyone telling you otherwise is either trying to sell you Enterprise Cloudflare, doesn’t know what protocol your game uses, or is repeating something they read in a listicle.

13 // Key takeaways

1. “DDoS protected” on a product page means almost nothing. Demand specific answers to the seven questions in Section 05 before paying anyone.
2. Most budget-tier game host protection is a protocol whitelist, not a generic filter. If your game isn’t on their list, you’re unprotected.
3. For Minecraft Java, the answer is TCPShield free tier or Cloudflare Spectrum Pro at $20/month. No exceptions, no excuses, no need to overthink it.
4. For UDP games on a budget, the answer is a Path.net reseller VPS at $10–25/month with a GRE tunnel from your origin. This is the most under-published budget protection on the internet.
5. For friend-only servers, the answer is Tailscale. Zero dollars per month, zero attack surface, takes 30 minutes to set up.
6. Cloudflare Spectrum UDP is enterprise-only at $5,000+/month. Stop reading guides that pretend otherwise.
7. Self-hosting hardening (iptables, conntrack tuning, fail2ban) is necessary but not sufficient. It buys you time during low-grade attacks; it does not stop a real botnet.
8. The first action when you’re attacked is not to change your IP — it’s to confirm it’s actually a DDoS. Most “DDoS” reports from panicked admins are mod, plugin, or capacity issues.
9. Most targeted attacks against community servers come from inside the community. Audit who knew the IP after every incident.
10. Hosting blogs don’t publish honest DDoS guides because honesty doesn’t pay affiliate commission. That’s why this guide exists.