Game servers get attacked, and CS 1.6 is an easy target: it is UDP-based, its connectionless query protocol (A2S) can be abused for amplification, and knocking a rival server offline at peak hours is a depressingly common tactic in the 1.6 scene. "DDoS protection" is a marketing sticker on almost every host now, so the useful question is not whether a provider claims it, but what specifically it filters and how. This guide is vendor-neutral — it gives you the features to demand and the questions to ask.
1. Understand what you are defending against
- L3/L4 volumetric floods — raw UDP/SYN/amplification traffic aimed at saturating your port or the provider's uplink. Measured in Gbps/Mpps. This is what "DDoS protection" usually means.
- UDP amplification — attackers spoof your IP and bounce traffic off open reflectors (DNS, NTP, and game query services). A2S itself can be reflected, which is why open, unprotected query ports are a liability.
- L7 / application floods — floods of valid-looking A2S query packets or fake connection attempts that exhaust the single game thread. These are small in bandwidth but lethal to a single-threaded HLDS, and generic volumetric scrubbing often misses them.
A host that only advertises "500 Gbps mitigation" is talking about the first two. The third — the game-aware layer — is where CS 1.6 servers actually fall over.
2. Always-on beats on-demand
Ask whether filtering is always-on or on-demand (triggered after detection). On-demand mitigation has a detection window — often 10–60 seconds — during which your server is already down. For a game server where an attack lands exactly at peak to clear the room, that window is the whole attack. Prefer always-on filtering for game IPs.
3. Game-aware UDP filtering is the feature that matters
Generic scrubbing struggles with legitimate game UDP because it looks like the flood. The providers worth paying for offer game-aware or GoldSrc/Source-aware filtering that:
- validates A2S query structure and drops malformed query packets,
- rate-limits queries per source IP so a query flood cannot exhaust the game thread,
- challenges/validates new connections to filter spoofed and fake connects,
- whitelists established, legitimate player sessions.
If a provider cannot tell you how it distinguishes a real CS 1.6 player from a flood, its "protection" is generic and will either pass the attack through or drop your real players with it.
4. Capacity and latency trade-off
Look at two numbers: scrubbing capacity (Gbps/Mpps the network can absorb) and added latency. Scrubbing routes your traffic through filtering infrastructure, which can add ping. Good providers keep this to a few milliseconds via local scrubbing; bad ones reroute you across the world and add 80 ms permanently. Since ping is everything for retention, verify the protected latency to your player region, not just the raw capacity headline.
5. Harden the server itself — protection is layered
Upstream filtering is only half the job; the engine has its own defenses. On ReHLDS, set the anti-flood and connection cvars, and use the ban filter:
sv_filterban 1 sv_rcon_maxfailures 5 sv_rcon_minfailures 5 sv_rcon_minfailuretime 30 sv_rehlds_force_dlmax 1
ReHLDS also has query-flood and connectionless-packet protections that plain HLDS lacks — another reason to run it. Close every port you are not using, and keep RCON locked down; a leaked RCON password is its own denial-of-service. See which ports to open and installing ReHLDS.
6. Questions to ask before you buy
- Is DDoS filtering always-on or on-demand for game IPs?
- Do you offer game-aware / GoldSrc-aware UDP filtering, or only generic L3/L4 scrubbing?
- What latency does the protection add for players in [my region]?
- Is protection included on the dedicated IPv4, or extra?
- What is your policy when an attack exceeds capacity — null-route (blackhole) the IP, or keep filtering?
That last one matters: some budget hosts "mitigate" by null-routing your IP for hours, which is indistinguishable from the attack succeeding. Avoid providers whose response to a large attack is to take you offline to protect themselves.
Common mistakes
- Trusting a Gbps number alone — volumetric capacity says nothing about surviving a small, targeted A2S query flood.
- Accepting on-demand protection for a game IP — the detection window is the attack.
- Ignoring added latency — protection that adds 80 ms trades one problem for another.
- Skipping server-side hardening — no upstream filter replaces ReHLDS anti-flood cvars and a locked-down RCON.
- Assuming a null-route is protection — it is the attacker's goal, achieved by your host.
Verification
You cannot ethically DDoS-test someone else's network, so verify indirectly. Confirm always-on filtering is active on your IP (the provider can show this in a panel), measure your protected ping from your player region and ensure it is acceptable, and stress the server-side layer by hammering your own query port from a single machine and watching that ReHLDS rate-limits it without dropping real players. If the provider is vague about the game-aware layer and can only talk in Gbps, treat the "protection" as unproven and keep your server-side hardening tight regardless.
