Always-On vs On-Demand DDoS Mitigation: What Your Plan Actually Covers in 2026
Last updated: July 2026
Every hosting provider claims "DDoS protection," but the fine print hides one variable that decides whether an attack takes a server offline: is mitigation always-on, or does it only activate on-demand once traffic crosses a threshold? The always-on vs on-demand DDoS protection question isn't academic — it determines how much downtime a customer eats before scrubbing kicks in. This post breaks down both mitigation modes in plain terms and maps exactly what's covered across X-ZoneServers' VPS, streaming, and dedicated lines.
Always-On vs On-Demand DDoS Protection: The Core Difference
The distinction comes down to when mitigation actually engages. Always-on protection routes all inbound traffic through inline scrubbing infrastructure permanently — every packet is inspected against Layer 3, 4, and 7 attack signatures before it ever reaches the origin server, whether or not an attack is in progress. On-demand protection sits passively until a monitoring system detects abnormal traffic, then triggers a route change (typically a BGP announcement) that redirects traffic to a scrubbing center. That redirect is not instant: it depends on detection thresholds, BGP propagation time, and how quickly upstream routers converge on the new path.
Neither mode is inherently "better" in isolation — the real question is what happens during the gap between attack onset and mitigation being active. That gap is where always-on and on-demand diverge most sharply.
How On-Demand (BGP-Triggered) Mitigation Actually Works
On-demand DDoS mitigation is the traditional model most budget hosts still run. Traffic flows directly to the server under normal conditions — no inline inspection, no added latency. When a volumetric spike is detected, the provider's system announces a more specific BGP route (or triggers a Remote Triggered Black Hole in cruder implementations) that pulls traffic through a scrubbing center. The upside is zero baseline latency overhead. The downside is a detection-and-propagation delay measured in seconds to minutes, depending on how sensitive the trigger threshold is and how quickly upstream routers converge on the new route — a window that attacks ramping quickly, or staying just under the detection threshold, can exploit to saturate a link or exhaust connection tables before the redirect ever activates.
This model also tends to be coarser in what it protects. Many on-demand setups only cover Layer 3/4 volumetric floods and don't inspect application-layer (Layer 7) traffic at all, since Layer 7 mitigation typically requires the traffic to already be flowing through an inline proxy or WAF layer.
How Always-On Inline Mitigation Works
Always-on mitigation puts scrubbing infrastructure permanently in the traffic path, across the provider's network backbone rather than as a bolt-on redirect. Because inspection is continuous, there's no detection window to wait out — a Layer 3/4 flood or a Layer 7 application attack is filtered inline before it reaches the server, regardless of how long the attack lasts. This is the model X-ZoneServers runs across its network: DDoS protection covering Layer 3, 4, and 7 is included on every plan, delivered as always-on inline mitigation rather than a threshold-triggered redirect.
Detection Time Is the Tradeoff That Actually Matters
When you compare mitigation modes side by side, the single most important variable is time-to-mitigation, not headline bandwidth numbers. A provider can advertise a huge scrubbing capacity and still leave a server exposed for the detection-and-propagation delay described above. Short, sharp attacks — the kind increasingly used against game servers, APIs, and checkout flows — are specifically designed to land damage inside that window and stop before mitigation engages. Always-on inline filtering removes the window entirely because there's nothing to trigger; the mitigation path is the only path traffic ever takes.
| Factor | On-Demand (BGP-Triggered) | Always-On (Inline) |
|---|---|---|
| Baseline traffic path | Direct to origin | Routed through scrubbing at all times |
| Activation | After detection threshold is crossed | No activation needed — always active |
| Exposure window | Detection + BGP propagation delay | None |
| Layer 7 (application) coverage | Often limited or add-on | Included as part of inline inspection |
| Best suited for | Large, sustained volumetric floods | Short bursts, application-layer attacks, always-online services |
What Coverage Looks Like Across the VPS and Dedicated Line
Mitigation mode matters less if it isn't applied consistently across every plan tier — a common gap where entry-level VPS instances get weaker or no DDoS coverage while only premium dedicated servers get the full stack. X-ZoneServers applies the same always-on Layer 3/4/7 coverage regardless of plan size, backed by a Tier-1 backbone network:
- KVM VPS (/vps-hosting) — every tier from Nano through Business runs on the same 1 Gbps unmetered network with always-on mitigation, not a scaled-down version reserved for higher tiers.
- Streaming VPS (/streaming-vps) — 10 Gbps unmetered ports get identical inline coverage, relevant for workloads where even a brief redirect window would visibly disrupt output.
- Dedicated servers (/dedicated) — port capacity scales from 1 Gbps up to 200 Gbps depending on configuration, with the same DDoS coverage plus AI-optimized routing included.
Because mitigation runs at the network level rather than per-server, coverage is consistent across all 12 datacenter cities in the footprint, including Frankfurt and Amsterdam — there's no "protected location" versus "unprotected location" split to check for before ordering.
VPS vs Dedicated DDoS Protection Coverage: What Doesn't Change
A frequent question when evaluating VPS vs. dedicated DDoS protection coverage is whether upgrading to a dedicated server unlocks protection that a VPS doesn't get. It doesn't. The mitigation mode and Layer 3/4/7 coverage are identical; what changes with a dedicated server is raw port capacity (up to 200 Gbps) and the addition of AI-optimized routing on top of the same baseline coverage. The 99.9% uptime SLA applies across the line, not as a dedicated-only perk.
What This Means for Latency-Sensitive and Always-Online Workloads
Game servers, real-time APIs, and anything with active user sessions are exactly the workloads that suffer most from an on-demand model's exposure window — even brief saturation can mean dropped connections or a full session reset. Since X-ZoneServers' own game hosting product is not yet live, self-hosted game servers currently run best on the KVM VPS line (/vps-hosting), where full root access lets an operator run any game server binary while still sitting behind the same always-on network mitigation as every other plan — no separate DDoS add-on required.
Reading Any Provider's Plan: What to Actually Check
- Does DDoS protection apply to all plan tiers, or only premium ones?
- Is mitigation inline (always-on) or redirect-triggered (on-demand), and what's the stated detection/activation time?
- Does coverage include Layer 7 application attacks, or only Layer 3/4 volumetric floods?
- Is coverage uniform across every datacenter location, or does it vary by region?
- Is there an uptime SLA that actually covers DDoS-related downtime?
Verdict
On-demand, BGP-triggered mitigation still has a place for pure volumetric-flood scenarios where a short detection delay is tolerable, but for anything latency-sensitive or continuously online, the exposure window it creates is a real liability. X-ZoneServers avoids that tradeoff entirely by running always-on inline mitigation covering Layer 3, 4, and 7 across every plan — VPS, streaming, and dedicated alike — on a Tier-1 backbone spanning 12 datacenter cities, backed by a 99.9% uptime SLA. There's no threshold to wait for and no premium tier required to get full coverage.