OVH vs Hetzner vs Scaleway: which offers the best DDoS protection?

When evaluating OVH Hetzner Scaleway DDoS protection capabilities in 2026, infrastructure teams face a complex technical decision that directly impacts service availability and incident response costs. Each European provider has evolved distinct kernel-level and network-layer mitigation strategies, yet the conversation often overlooks a critical dimension: on-server protection that operates independently of upstream scrubbing capacity. This article dissects the DDoS defense architecture of OVH, Hetzner, and Scaleway—examining detection thresholds, mitigation latency, collateral filtering risks, and the technical case for deploying complementary XDP/eBPF protection directly on your instances.

Modern DDoS attacks in 2026 blend volumetric floods (UDP amplification, SYN floods exceeding 100 Gbps), protocol exploits (TCP state exhaustion, fragmentation attacks), and application-layer campaigns (HTTP GET floods, DNS query storms). Cloud providers respond with tiered defenses: edge scrubbing for volumetric threats, stateful inspection for protocol anomalies, and rate-limiting for application abuse. However, three variables determine real-world efficacy: activation latency (seconds to minutes before mitigation engages), false-positive rates (legitimate traffic discarded during cleanup), and cost structures (included vs. paid tiers). Understanding where OVH, Hetzner, and Scaleway differ—and where they converge—guides both provider selection and the necessity of kernel-level hardening with solutions like PAKKT.io.

OVH Anti-DDoS Infrastructure: Permanent Scrubbing and VAC Mitigation

OVH operates one of Europe's largest proprietary anti-DDoS systems, with scrubbing capacity exceeding multiple terabits per second distributed across global points of presence. Every OVH service—from VPS Starter to bare-metal HGR servers—benefits from permanent traffic analysis: all inbound packets traverse VAC (Vaksina Anti-DDoS Core) appliances that perform real-time behavioral analysis using custom ASICs and FPGA-accelerated pattern matching.

Detection and activation: OVH's VAC monitors per-IP flow statistics with sub-second granularity. When traffic deviates from learned baselines (sudden pps spikes, abnormal protocol distributions, known attack signatures), the system triggers mitigation automatically within 1–3 seconds. No manual intervention or support ticket is required for most volumetric attacks. Mitigation techniques include SYN cookie validation, UDP stateless filtering, fragment reassembly, and GRE tunneling to dedicated scrubbing nodes.

Strengths:

• Zero-cost inclusion: Anti-DDoS is bundled with every service tier; no separate subscription or bandwidth overage fees during attacks.
• Transparent operation: Legitimate traffic experiences negligible added latency (typically <5 ms) even under active mitigation.
• Proven scale: OVH has publicly mitigated attacks exceeding 1 Tbps, providing confidence for high-traffic workloads.

Limitations:

• Black-box tuning: Customers cannot adjust detection thresholds, whitelist specific source ASNs, or customize scrubbing rules. VAC operates as a managed service with limited visibility.
• False positives during edge cases: Legitimate spikes (product launches, viral content) occasionally trigger mitigation, temporarily dropping valid connections until the system recalibrates.
• Application-layer blindness: VAC excels at L3/L4 volumetric mitigation but offers minimal protection against HTTP floods, API abuse, or game protocol exploits that operate within normal bandwidth envelopes.

For workloads requiring sub-millisecond response or granular per-port rate-limiting, OVH's upstream scrubbing must be complemented by on-server XDP filtering. Tools like PAKKT.io deploy a single XDP program per interface, processing packets in the kernel's earliest network hook—before conntrack, before iptables, before the application even allocates socket buffers. This architecture allows you to enforce per-port max_pps limits (e.g., 10,000 pps on UDP 19132 for Minecraft Bedrock), block malformed packets, and rate-limit ICMP without waiting for VAC's global heuristics to converge.

Hetzner DDoS Protection: Tiered Defense and Manual Escalation

Hetzner's anti-DDoS posture reflects the company's cost-optimization philosophy: basic volumetric protection is included on all services, while advanced mitigation requires manual intervention or third-party partnerships. Hetzner collaborates with upstream carriers and edge providers to absorb large-scale floods, but the responsibility for fine-grained filtering often falls to the customer.

Detection and activation: Hetzner employs flow-based anomaly detection at network edge routers. When traffic to a specific IP exceeds predefined thresholds (proprietary, not publicly documented), the system triggers null-routing or rate-limiting at the border. Unlike OVH's instant scrubbing, Hetzner's mitigation can introduce 30–120 seconds of latency before activation, during which the target server may experience degraded performance or complete saturation.

Strengths:

• Transparent pricing: No hidden DDoS mitigation fees. If an attack is absorbed by infrastructure, no surcharge applies.
• High-bandwidth allocations: Dedicated servers ship with 1 Gbps unmetered or 10 Gbps metered connections, providing headroom to absorb moderate floods before mitigation engages.
• Direct hardware access: Bare-metal customers retain full kernel control, enabling deployment of XDP/eBPF programs, custom nftables rulesets, and third-party agents without hypervisor restrictions.

Limitations:

• Reactive, not proactive: Hetzner's system prioritizes infrastructure stability over per-customer granular mitigation. If your IP is under sustained attack, Hetzner may null-route your service for hours until the flood subsides, leaving you offline.
• No stateful scrubbing: Basic mitigation blocks obvious floods but does not validate TCP handshakes, reassemble fragments, or filter application-layer payloads. Sophisticated attacks (e.g., ACK floods, DNS amplification with spoofed sources) may pass through.
• Support-driven escalation: Advanced mitigation often requires opening a ticket and waiting for NOC review. For mission-critical workloads, this latency is unacceptable.

Given Hetzner's hands-off approach, on-server kernel protection is not optional—it is mandatory for production environments. Deploying an XDP-based firewall with stateless filtering at line rate (several million pps on modern NICs) ensures that malicious traffic is dropped before consuming CPU cycles or filling conntrack tables. PAKKT's dual-layer architecture—XDP for high-speed discard + nftables for stateful refinement—integrates seamlessly on Hetzner hardware:

# Example nftables rule in PAKKT's isolated inet pakkt table
nft add rule inet pakkt input ip saddr @pakkt_blacklist drop
nft add rule inet pakkt input tcp dport 22 ct state new limit rate 5/minute accept
nft add rule inet pakkt input udp dport 27015 meter ddos_udp { ip saddr limit rate 500/second burst 1000 packets } accept

This configuration blocks blacklisted IPs at XDP, enforces SSH rate-limiting with conntrack, and applies per-source-IP UDP rate-limits using nftables meters—all without conflicting with Docker, fail2ban, or iptables-persistent rules, because PAKKT operates in a dedicated inet pakkt table.

Scaleway DDoS Shield: API-Driven Mitigation and FlexibleIP Integration

Scaleway's anti-DDoS offering, branded DDoS Shield, targets cloud-native workloads with API-driven activation, FlexibleIP mobility, and integration with Scaleway's edge network. Unlike OVH's always-on scrubbing or Hetzner's reactive null-routing, Scaleway positions DDoS protection as an opt-in service with tiered pricing based on mitigation capacity.

Detection and activation: DDoS Shield monitors traffic at Scaleway's border routers. When anomalies are detected, traffic is redirected through scrubbing appliances that validate TCP handshakes, filter amplification vectors, and enforce rate-limits. Activation occurs within 10–30 seconds of attack onset. Customers with FlexibleIPs can programmatically remap IP addresses to alternate instances during incidents, minimizing downtime.

Strengths:

• API-first design: DDoS Shield integrates with Scaleway's REST API, enabling Infrastructure-as-Code workflows (Terraform, Ansible) to provision protection alongside compute resources.
• Granular visibility: The Scaleway console exposes per-IP traffic graphs, attack classifications (SYN flood, UDP amplification, ICMP storm), and mitigation event logs.
• FlexibleIP failover: Decoupling IPs from instances allows rapid migration to standby servers if primary resources are overwhelmed.

Limitations:

• Paid tiers for advanced mitigation: Basic protection (included) covers volumetric attacks up to ~10 Gbps. Larger floods or sustained campaigns require purchasing higher-capacity plans.
• Regional coverage gaps: Scaleway's scrubbing capacity is concentrated in Paris (PAR) and Amsterdam (AMS) regions. Instances in other zones may experience higher mitigation latency or rely on upstream transit providers.
• Application-layer gaps: Like OVH and Hetzner, Scaleway's DDoS Shield focuses on L3/L4. HTTP floods, game protocol exploits, and API abuse require application-layer defenses (rate-limiting middleware, WAF, or kernel-level filtering).

For Scaleway customers running containerized workloads (Kubernetes, Docker Swarm), combining DDoS Shield with PAKKT's lightweight Go agent (mTLS, 30s heartbeat, <1% CPU overhead) provides defense-in-depth. The agent manages XDP rules via BPF maps, synchronizes IP blacklists/whitelists, and streams per-port metrics to a centralized TimescaleDB dashboard—all without disrupting existing orchestration or firewall configurations.

On-Server Kernel Protection: Why XDP/eBPF Complements Upstream Scrubbing

Regardless of provider—OVH, Hetzner, or Scaleway—upstream DDoS mitigation introduces three unavoidable trade-offs:

• Latency: Traffic must traverse scrubbing appliances, adding milliseconds (OVH) to seconds (Hetzner, Scaleway) of round-trip delay.
• Opacity: Providers control detection logic, whitelisting, and mitigation rules. Customers receive post-incident reports, not real-time tuning.
• Scope: Upstream defenses excel at volumetric floods but struggle with low-bandwidth, high-pps attacks (e.g., 50k DNS queries/sec, TCP ACK floods) that stay below scrubbing thresholds yet exhaust server resources.

Deploying XDP (eXpress Data Path) programs on the server itself addresses these gaps. XDP hooks into the kernel's network driver layer, processing packets before the skb (socket buffer) is allocated—orders of magnitude faster than iptables or even nftables. A well-tuned XDP program can drop malicious packets at line rate (10+ million pps on commodity hardware) with sub-microsecond per-packet overhead, preventing CPU exhaustion and preserving conntrack capacity for legitimate traffic.

PAKKT's engine loads a single XDP program per interface, eliminating conflicts when multiple tools attempt to attach competing programs. Rules are stored in BPF maps, enabling dynamic updates (add/remove blacklist IPs, adjust rate-limits) without recompiling or reloading the XDP program. Example use cases:

• Game servers: Enforce 10,000 pps max on UDP 25565 (Minecraft Java), 5,000 pps on UDP 27015 (Source Engine), blocking query floods that bypass OVH VAC.
• Web APIs: Drop packets with min_packet_size < 64 bytes (TCP SYN floods with no payload) or max_packet_size > 1500 bytes (fragmentation attacks).
• Infrastructure services: Allow-list specific source IPs for SSH (port 22), rejecting all other traffic at XDP before conntrack state is created.

Complementing XDP, PAKKT provisions a stateful nftables firewall in an isolated inet pakkt table. This dual-layer design leverages XDP for brute-force discard and nftables for connection tracking, TCP flag validation, and per-connection rate-limits:

# XDP: drop blacklisted IPs at line rate (BPF map lookup)
# Nftables: validate TCP handshake, enforce SYN rate-limit
nft add rule inet pakkt input tcp flags syn ct state new limit rate over 100/second drop
nft add rule inet pakkt input ct state established,related accept

This architecture coexists peacefully with Docker (which manipulates the nat and filter tables), fail2ban (which injects rules into filter INPUT), and iptables-persistent (which restores legacy rules). PAKKT never touches these tables, avoiding the conflicts that plague traditional firewall stacks.

Beyond packet filtering, PAKKT integrations provide centralized visibility across multi-server deployments. The web dashboard aggregates GeoIP data (world map, top source countries), per-port throughput (pps, active connections), and audit logs (rule changes, blacklist updates). For managed hosting providers or game server networks, the public API enables programmatic rule deployment and template sharing via the community marketplace. Pricing remains transparent: €3/agent/month with a 7-day free trial on the first agent, no hidden bandwidth fees or mitigation surcharges.

Comparative Matrix: OVH vs. Hetzner vs. Scaleway DDoS Defense in 2026

Criterion	OVH	Hetzner	Scaleway
Activation latency	1–3 seconds (automatic)	30–120 seconds (reactive)	10–30 seconds (API-driven)
Included capacity	Unlimited (VAC scrubbing)	Best-effort (~10 Gbps)	~10 Gbps (higher tiers paid)
False-positive risk	Low–Medium (opaque tuning)	High (null-routing under load)	Low (scrubbing with validation)
Customer control	None (managed service)	Full (bare-metal kernel access)	Medium (API-driven policies)
Application-layer protection	Minimal	None (customer responsibility)	Minimal
On-server XDP/eBPF compatibility	Yes (full kernel control)	Yes (full kernel control)	Yes (full kernel control)
Recommended complement	XDP for per-port pps limits	XDP mandatory for production	XDP + API orchestration

This matrix clarifies that no provider offers a complete, hands-off solution. OVH's VAC excels at volumetric defense but lacks granular tuning. Hetzner provides cost-effective bandwidth and hardware freedom but demands customer-driven mitigation. Scaleway balances automation with API control yet tiers advanced capacity behind paywalls. All three leave application-layer and low-bandwidth, high-pps attacks to the customer—justifying kernel-level XDP/eBPF deployment as a standard hardening practice, not an edge case.

Operational Recommendations: Choosing a Provider and Deploying Kernel Protection

When selecting between OVH, Hetzner, and Scaleway for DDoS resilience, evaluate:

• Attack profile: If you face multi-terabit volumetric floods (booter services, nation-state actors), OVH's VAC provides the highest included capacity. For lower-volume, higher-sophistication attacks (protocol exploits, application abuse), all three providers require on-server hardening.
• Budget constraints: Hetzner offers the lowest base cost for high-bandwidth dedicated servers, but mitigation responsibility shifts to you. Scaleway's tiered pricing suits variable workloads where you pay for protection only during incidents.
• Control requirements: Bare-metal (OVH, Hetzner) grants full kernel access for XDP/eBPF deployment. Scaleway's cloud instances also support XDP on recent kernel versions (5.x+).

Regardless of provider, follow these deployment steps to layer kernel protection:

1. Verify kernel support: Ensure kernel 5.x or higher with CONFIG_BPF_SYSCALL=y, CONFIG_XDP_SOCKETS=y. Check with uname -r && grep BPF /boot/config-$(uname -r).
2. Install PAKKT agent: Register at PAKKT.io, deploy the Go agent via mTLS-secured install script. The agent auto-updates (SHA256 verification), consumes <5 MB RAM, and self-obfuscates with garble.
3. Configure XDP rules: Define per-port policies (block, rate_limit, allow_only), set global max_pps, specify min/max packet sizes. Rules are stored in BPF maps and enforced at line rate.
4. Provision nftables stateful firewall: PAKKT creates an isolated inet pakkt table with conntrack, TCP flag validation, and per-connection rate-limits, coexisting with Docker/fail2ban.
5. Synchronize IP lists: Blacklist/whitelist entries propagate to both XDP (BPF map) and nftables, ensuring consistent enforcement.
6. Monitor dashboard: Review GeoIP maps, per-port metrics (TimescaleDB), and audit logs. Integrate with Pterodactyl game panels or orchestrate via public API.

For multi-server deployments (game networks, SaaS clusters), PAKKT's centralized panel eliminates configuration drift. A single rule template (community-shared or custom) deploys across all agents in seconds, with real-time enforcement confirmation via 30s heartbeats.

Conclusion

Comparing OVH Hetzner Scaleway DDoS protection in 2026 reveals that upstream scrubbing—while essential for absorbing volumetric floods—cannot substitute for on-server kernel defenses. OVH's VAC provides the most robust included mitigation but lacks granular control. Hetzner offers cost-effective bandwidth and full hardware access, shifting mitigation responsibility to the customer. Scaleway balances automation with API-driven policies, though advanced capacity requires paid tiers. All three leave low-bandwidth, high-pps attacks and application-layer exploits unmitigated, making XDP/eBPF deployment a pragmatic necessity for production resilience.

FAQ

Can I run XDP/eBPF firewall rules on OVH, Hetzner, and Scaleway instances simultaneously with their built-in DDoS protection?

Yes. OVH VAC, Hetzner edge filtering, and Scaleway DDoS Shield operate at the network layer upstream of your server. XDP programs attach to the network interface driver on your instance, processing packets after they pass upstream scrubbing but before they reach the kernel's network stack. There is no conflict—upstream mitigation handles volumetric floods, while XDP enforces per-port rate-limits and blocks protocol exploits that bypass provider-level defenses.

How does PAKKT's dual-layer XDP + nftables architecture avoid conflicts with Docker, fail2ban, and iptables-persistent?

PAKKT provisions an isolated inet pakkt nftables table with its own chains and rules. Docker manipulates the nat and filter tables for container networking. Fail2ban injects dynamic rules into filter INPUT. Iptables-persistent restores legacy filter, nat, and mangle tables. Because nftables supports multiple independent tables, PAKKT's inet pakkt table coexists without overwriting or conflicting with these tools. XDP operates even earlier—at the driver layer—so it never interacts with iptables or nftables rule evaluation.

If Hetzner null-routes my IP during a sustained attack, will deploying XDP prevent the null-route?

No. Hetzner's null-routing occurs at the network edge (border routers) when aggregate traffic to your IP exceeds infrastructure protection thresholds—typically to preserve shared uplink capacity. XDP on your server cannot prevent upstream null-routing because the traffic never reaches your NIC. However, XDP reduces the likelihood of null-routing by dropping malicious packets at line rate, lowering aggregate inbound traffic and keeping you under Hetzner's threshold. For attacks that exceed your link capacity (e.g., 100 Gbps flood on a 1 Gbps port), upstream scrubbing or provider escalation remains necessary, but XDP ensures smaller attacks are mitigated locally without triggering null-routes.