Proxy and DDoS Protection

A DDoS attack tries to keep real users out by sending your server more traffic or requests than it can handle. Even with a protection layer in front, an attacker who knows the server's real IP address can skip that layer and hit the server directly. So the first step is making sure the origin IP is not leaking through DNS records, email headers, subdomains or old historical records.

If the IP has already been exposed, the server usually needs to move to a new address; otherwise attackers keep the old one. We then harden the server's firewall with nftables so it only accepts connections coming from the proxy layer. Even if someone finds the address, direct connections are dropped before they reach the application.

For websites we put Cloudflare in front of the site and configure WAF rules, bot management and caching to match how the site is built. We write separate rate limits for the endpoints attackers lean on most, such as login pages, search and API routes. With the right caching, static content reaches users without touching your server at all, which takes a large share of the load off it during an attack.

On the server side we set up a reverse proxy with nginx or HAProxy. This layer spreads traffic across multiple application servers, manages TLS certificates in one place, limits timeouts against slow-connection attacks and rejects requests that do not come through Cloudflare. It is one of the most effective ways to gain both security and performance without touching your application code.

Game servers are not like websites: most of their traffic is UDP, and Cloudflare's standard web protection does not carry it. For FiveM, Rust and Minecraft servers we set up proxy servers that forward the TCP and UDP ports the game uses, so players connect to the proxies instead of the real server. On Minecraft networks this layer sits in front of Velocity; on FiveM it works with the game's own proxy settings.

We write filtering rules around the game's protocol: unused ports are closed, connections per address are limited and packets that do not match the protocol are dropped. The proxies run on infrastructure with network-level DDoS protection, and where needed we spread the load across several proxies in different locations. Placing proxies close to your players keeps the added latency low.

To see whether the protection actually works, we monitor traffic continuously. When connection counts, request rates or bandwidth rise above normal levels we raise an alert, and during an attack we record which rules kicked in. Those records also reveal real users who were blocked by mistake, so the rules can be relaxed where needed.

When an attack is over we share what happened in a plain report: the type of attack, which layer it targeted, how long it lasted and which measures worked. Preparation for the next attack is based on that information. For the wider security, backups and monitoring of your servers, see our infrastructure and DevOps service.