DDoS Protected Server: What to Look for Beyond Capacity

A DDoS protected server is only as good as its filtering: how accurately it separates attack traffic from real users, how fast it reacts, and which layers it covers. The headline capacity number on a sales page tells you the least about that, so judge a provider on filtering quality, L3/L4/L7 coverage, always-on mitigation, and what you can verify yourself.

This guide explains what to ask, how game and web workloads differ, and how to test a protected server without guessing.

Why capacity is the wrong first question

Every provider can quote a big number. Few can tell you what happens to your legitimate players or customers while that capacity is being used. In practice, outages on "protected" servers usually come from one of these:

• False positives. The filter drops real users along with the attack, so you're technically online but unusable.
• Slow detection. Traffic reaches your server for minutes before mitigation starts.
• Wrong layer. The network absorbs a volumetric flood, but a low-rate application attack walks straight through.
• Collateral damage. Mitigation for one customer on a shared path hurts others, or the whole IP gets null-routed.
• Unreachable origin. The attacker finds your real IP and bypasses the protection entirely.

Capacity matters, but it is a floor, not a feature. A network that can absorb a flood and then lets half your game clients time out has not solved your problem.

L3, L4, and L7: know which layer you need covered

"DDoS protection" is not one thing. Ask exactly which layers are covered and how.

Two practical points:

1. L3/L4 mitigation works on packets, so it can run in the network path. It doesn't need to see inside your traffic. This is what protects arbitrary TCP/UDP services, including game servers and custom protocols.
2. L7 mitigation needs to understand the application protocol. For HTTPS, that normally means terminating TLS somewhere, which brings certificates, source-IP handling, and privacy considerations. If a provider says "L7 protection," ask where TLS terminates and how your origin sees the real client IP.

If you run a game server, L7 is mostly irrelevant. If you run a web app, you need all three, and your WAF and application-level rate limits remain your job either way.

Always-on vs. on-demand mitigation

• Always-on: Traffic always flows through the filtering path. Mitigation starts at the first malicious packet, with no switchover delay. Latency overhead is constant and should be small and measurable.
• On-demand / detection-triggered: Traffic goes direct until an attack is detected, then gets diverted. This can work for some sites, but there is a gap between attack start and mitigation, and BGP-based diversion adds convergence time.

For real-time workloads like game servers, voice, and trading, a gap of even a minute can empty a server. Players disconnect and often don't come back that session. For those, prefer always-on. For a low-traffic website that tolerates brief degradation, on-demand may be acceptable.

Ask the provider:

• Is mitigation inline and always-on, or triggered?
• What triggers it, and what is the typical time to mitigation?
• Does your IP get null-routed (blackholed) as a last resort? Under what conditions?

Null-routing stops the attack by making the target unreachable. That is a failure mode, not protection.

Game servers vs. web servers

The two workloads need different things from a protection stack.

Game servers (mostly UDP, latency-sensitive)

• Filtering must be protocol-aware for your game: query ports, handshake packets, session tokens. Generic UDP rate-limiting often breaks legitimate traffic, especially during player join bursts.
• Latency and jitter matter more than raw throughput. Check the path with mtr before and after protection.
• Source IP preservation is essential for bans, anti-cheat, and per-IP limits.
• Ask whether you can adjust rules for your own ports, or whether you depend on a ticket to change them.
• Hosting location matters: put the server near your players, with the protection in the same path, not hairpinned through a distant scrubbing site.

Web servers (TCP, HTTP/S)

• L7 awareness is the main differentiator. Raw L3/L4 filtering won't stop an HTTP flood that looks like valid requests.
• If protection is proxy-based, your origin sees the proxy's IP. Restore the client IP correctly and lock the origin so only the proxy can reach it:

# nginx: trust the client IP header only from your protection provider's ranges
set_real_ip_from 198.51.100.0/24;
real_ip_header   X-Forwarded-For;
real_ip_recursive on;

# nftables: only accept web traffic from the protection ranges
nft add rule inet filter input ip saddr != 198.51.100.0/24 tcp dport { 80, 443 } drop

• Keep your origin IP private. Old DNS records, mail headers, and certificate transparency logs commonly reveal it. If it leaks, change it.

How protection is delivered

Three common models:

1. Protection in the hosting network. The server sits behind the provider's filtering, and traffic is cleaned before it hits you. This is the simplest option for game servers and general services.
2. Reverse proxy (typically web only). DNS points to a proxy. Good for HTTP, but it doesn't help non-HTTP services.
3. Tunnel delivery for your own IP space. If you have your own ASN and prefixes, a provider can announce them and deliver clean traffic back over a tunnel, typically GRE with a BGP session. You keep your IP addresses and can move without renumbering. See our walkthrough on GRE + BGP tunnels for how that fits together.

If you already operate your own network, ask whether the provider supports BGP sessions, validates prefix ownership (RPKI ROA, RIR/IRR records), and publishes an AS-SET so upstreams accept your routes.

How to test a DDoS protected server

Never run attack simulations against infrastructure without the provider's written permission, and never use "booter" or "stresser" services. Many providers prohibit stress tests or require scheduling. Within those rules, you can verify a lot with no attack traffic at all.

1. Check the path and baseline latency

mtr -rwzc 100 192.0.2.10

Look at loss and latency at the last hops, and note the baseline. Compare it later during a busy period.

2. Confirm what actually reaches your server

# Game server example: watch inbound UDP on the game port
tcpdump -ni eth0 'udp and dst port 27015' -c 50

# Connection and socket state
ss -s
conntrack -S

Unexpected sources, spoofed-looking traffic, or huge conntrack growth during a test suggest filtering isn't doing enough upstream.

3. Run a small, authorized synthetic test

With permission, send a low-rate SYN test to a port and confirm your service stays responsive:

hping3 -S -p 443 -c 1000 -i u10000 192.0.2.10

This is not a stress test. It is a sanity check that the path accepts and handles unusual-but-small traffic. For anything larger, coordinate a scheduled test with the provider.

4. Measure legitimate traffic during the test

While the test runs, monitor real behavior from a separate host:

curl -o /dev/null -s -w "connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/

For games, join from a real client and watch ping and packet loss. The question is not "did the server stay up?" but "did real users still have a good session?"

5. Verify visibility

You can't improve what you can't see. Ask whether you get flow-based visibility into attack type, source distribution, and timing. Flow-based monitoring and detection lets you confirm what was mitigated and spot attacks that the provider's filter missed.

A pre-purchase checklist

• Which layers (L3/L4/L7) are covered, in writing?
• Always-on or triggered? Typical time to mitigation?
• Can you tune rules for your ports and protocol?
• Is the real client IP preserved?
• When does null-routing happen?
• Can you test, and under what rules?
• Is there a public looking glass so you can inspect routes and paths yourself?
• Do you get attack reporting and flow visibility?
• Is there a human on the other end when your rules need adjusting?

Common mistakes

• Buying on the capacity number alone. Ask about filtering behavior instead.
• Leaving the origin exposed. If attackers can hit the real IP directly, the protection is bypassed. Firewall the origin and rotate leaked IPs.
• Assuming the web protection covers everything. A reverse proxy for HTTP doesn't protect your game port, SSH, or mail server.
• Skipping baseline measurements. Without before-and-after data, you can't prove whether protection hurts latency.
• Never reviewing logs after an attack. Each incident tells you which rules need tightening.

Where Nixcon fits

Nixcon Group LLC operates its own network (AS40368) with its main data center in İzmir, Türkiye, and POPs in Frankfurt, Germany and Fremont, California. Our DDoS protection and firewall service is built around these principles. If you operate your own ASN and IP block, NixGuard Edge delivers clean traffic through a GRE tunnel with a BGP session, with AS-SET support. You can also run BGP directly on a VDS and choose between unprotected or DDoS-protected announcements.

You can inspect routes, ping, and traceroute from İzmir, Frankfurt, and the US on our public looking glass before you decide, which is a simple way to check path quality yourself.