An OVHcloud DDoS test answers a question the marquee feature quietly talks you out of asking: when the protection you were given for free actually engages, what does it let through, and what does it drop that it should not?
OVHcloud leads with one of the largest anti-DDoS networks any host advertises, included on every IP, unmetered, and on by default. It is a real capability, and it is genuinely good. It is also the reason the platform produces a particular kind of false confidence.
Because the protection is free and always present, teams read it as a wall that is simply there. It is closer to a scrubbing service that switches on: it analyzes traffic continuously, activates mitigation when it recognizes an attack, and filters at the network and transport layers. That design has a detection window, a mode setting, a heuristic that occasionally catches legitimate traffic, and a hard ceiling on which layers it covers at all.
This is the OVHcloud instance of structured DDoS testing. The methodology is the same one that governs any environment. The contour is OVHcloud's: a free, always-on L3/L4 scrubbing system that is a mode rather than a moat, a stateless edge firewall in front of it, and a compute layer, much of it single-tenant bare metal, that the anti-DDoS system was never designed to defend.
Where OVHcloud's protection is a mode, not a moat
The platform's anti-DDoS runs on a mitigation infrastructure, historically called the VAC, that traffic can be routed through when an attack is detected. Under the default auto-mitigation behavior it is not inline all the time; it engages on detection and diverts the targeted address into scrubbing.
Two things follow, and both are testable rather than assumed. The mitigation has a moment when it turns on, so there is an interval before it does. And it filters at L3 and L4: volumetric and protocol floods are its domain, and the application layer is not.
The gap that defines an OVHcloud estate is not a control someone forgot to enable. The control is enabled for everyone. It is the difference between what "protected by default" sounds like and what the default protection actually does.
At a glance: what an OVHcloud DDoS test validates
| OVHcloud control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Anti-DDoS (VAC) mitigation | Free, always-on L3/L4 volumetric and protocol absorption on every IP | The detection-to-mitigation interval under auto-mitigation, and whether the target stays reachable while it engages |
| Auto vs permanent mitigation | Two ways to run the same scrubbing: on-detection or always-inline | Whether the workload needs the detection gap closed, and what permanent mitigation costs in steady state |
| Edge Network Firewall | Stateless L3/L4 packet filtering in front of the anti-DDoS | Whether direct-to-server access is denied, and where the stateful ceiling moves once the edge holds no state |
| The L7 layer | (not provided by the platform for servers and instances) | Whether anything rate-limits, scores, or filters application requests |
| Compute (VPS, dedicated, Public Cloud) | Serve the application | The single-node ceiling, and for bare metal, that there is no scale-out recovery behind it |
| Mitigation heuristics | Filter attack traffic during scrubbing | Whether legitimate traffic that resembles the attack is dropped as collateral while mitigation is active |
The recurring theme: on OVHcloud the L3/L4 floor is not in question, so the test moves past "is it on" to the questions the free floor cannot answer for you. When does it engage, what does it cost when it does, and what happens at the layer it never touches.
The protection surface you are testing
Be precise about what each layer does, and how it behaves, before designing the test. On OVHcloud that precision starts not with whether a control exists but with how the always-on one actually operates.
The anti-DDoS system: free, always-on, and L3/L4
This is the control that makes an OVHcloud test different from a budget-VPS test. The anti-DDoS is included on every service at no extra cost, it is unmetered, and it is active by default across the fleet. Nothing to enable, no region where it is absent, no add-on to buy. In that respect it is the opposite of Vultr's opt-in add-on, and it is a stronger floor than the free L3/L4 mitigation on DigitalOcean. It shares the free, always-on posture with Hetzner's automatic protection, but where OVHcloud exposes a mode choice per address, Hetzner exposes no setting at all.
The property that matters for testing is what "always-on" means in practice. The system continuously analyzes traffic and, under auto-mitigation, activates scrubbing when it recognizes an attack signature against a given IP. It absorbs volumetric and protocol floods, a SYN flood, a UDP reflection flood, carpet-bombing across an address range, at a scale most single hosts could never absorb alone. That is the scrubbing-center pattern, productized and given away, and it is worth understanding as exactly that: a scrubbing service, not an inline force field.
Treat the advertised mitigation capacity and the exact detection behavior as published-doc material to confirm at test time. The numbers move, and a figure quoted here would be stale before you read it. The durable test step is not the number. It is measuring the interval and the behavior on your own traffic.
Auto-mitigation versus permanent mitigation
The same scrubbing system can run two ways, and the choice is the most consequential tuning decision on the platform.
Under auto-mitigation, the default, traffic flows directly until an attack is detected, at which point the address is diverted into scrubbing. This keeps steady-state latency clean, at the cost of a detection-to-mitigation window during which the attack reaches the server before filtering starts.
Permanent mitigation keeps the address routed through the scrubbing path continuously. It collapses the detection gap toward zero, because there is nothing to trigger, at the cost of a constant path through the mitigation infrastructure. It is an always-on mitigation posture rather than an on-demand one.
Neither is universally right, and choosing between them is exactly the kind of decision a test informs. A workload that cannot tolerate even a short window of direct exposure, a real-time API, a game server, a payment path, may warrant permanent mitigation on its critical addresses. A latency-sensitive service that rarely draws fire may prefer the clean default. The test measures the gap under auto-mitigation so the trade-off is a decision, not a guess.
The stateless Edge Network Firewall
In front of the anti-DDoS, OVHcloud offers a network-level firewall applied per IP at the infrastructure edge. Its defining characteristic under attack is that it is stateless.
A stateless filter matches on packet fields, source, destination, port, flags, without tracking connection state. That has a useful property and a limiting one. It cannot be exhausted the way a stateful table can, because it holds no table, so a flood of half-open connections does not fill anything at the edge. But it also cannot make decisions that require state, so it cannot distinguish an established session from a fresh one, and it offers a small, ordered rule budget rather than rich policy.
This inverts a finding from the stateful-firewall platforms. On DigitalOcean the free Cloud Firewall is stateful, which makes its connection table a candidate layer of first failure. On OVHcloud the edge holds no state, so the stateful ceiling does not sit at the edge at all. It moves back to the server's own kernel. The test has to know where state is tracked, because that is where a connection flood lands.
The missing L7 layer
Like the budget-VPS platforms, OVHcloud's server and instance products ship no managed web application firewall and no application-layer DDoS service in front of your compute. The anti-DDoS stops at L4.
The mechanics of that gap, why the single-node kernel becomes the layer of first failure, how an HTTP flood or a Slowloris-style slow attack lands directly on compute, and how to build the L7 layer the platform omits, are covered in full for the near-identical shape in DigitalOcean DDoS testing. Rather than re-derive it, the short version for OVHcloud is the same: if an application-layer flood reaches the server, the only thing in its way is what you put there. The free anti-DDoS will not see it, because from L3/L4 it looks like valid traffic to a valid port.
Many teams front an OVHcloud origin with a third-party edge or CDN to fill the L7 gap. That is a sound pattern, and it changes what origin exposure means on this platform, covered below.
Dedicated servers, VPS, and Public Cloud
OVHcloud's heritage is single-tenant bare metal, and dedicated servers remain central to its catalog alongside VPS and Public Cloud instances. The distinction matters under attack.
A VPS or Public Cloud instance is a fixed-size machine whose kernel limits, conntrack table size, accept queue depth, ephemeral port range, cap concurrent work. It does not grow under load; once saturated it stays saturated until the attack stops or you intervene.
A dedicated server removes even that abstraction. It is one physical machine, so there is no hypervisor elasticity and nothing to scale out from under a flood. Its ceiling is the hardware, and when an attack finds that ceiling the failure is abrupt with no cushion behind it. The anti-DDoS defends the pipe to that machine; it does nothing about a connection flood or an L7 flood that the machine itself must absorb. Test a dedicated server as a fixed constraint to measure, not a surprise to discover. If you run Managed Kubernetes instead, the failure modes shift to ingress chokepoints and autoscaler timing, covered in Kubernetes DDoS testing.
What OVHcloud DDoS testing actually surfaces
A useful test is organized around the gaps that recur on OVHcloud estates. They follow from the shape above: a free L3/L4 scrubber that engages on detection, a stateless edge, and a fixed compute ceiling with no managed layer above L4.
The detection window is the headline finding
On a platform with an opt-in floor, the first question is whether mitigation is enabled. On OVHcloud it is enabled, so the first real question is when it engages.
Under auto-mitigation there is an interval between the attack arriving and scrubbing activating, and during that interval the server absorbs the flood directly. For a volumetric attack against a well-provisioned machine that window may be a non-event. For a burst against a service with a low connection ceiling, it can be the whole outage, over before mitigation would have mattered.
The test measures that window on your traffic: how long the target absorbs the attack before mitigation visibly engages, and whether the service stays reachable throughout. That single measurement drives the auto-versus-permanent decision for each address. It is invisible from the dashboard, which shows the protection as present and says nothing about its activation latency against your workload.
False-positive collateral during mitigation
A scrubbing system that filters at L3/L4 decides which packets are attack and which are legitimate using heuristics, and heuristics are imperfect. While mitigation is active, legitimate traffic that resembles the attack pattern can be caught in the filter.
This is the false-positive cost of automated mitigation, and it is a specific thing a test should look for rather than assume away. A protocol the heuristics treat as suspicious, a client whose traffic shape happens to match a flood signature, a legitimate spike arriving during an attack, any of these can be dropped as collateral while scrubbing is engaged.
The measurement is goodput during active mitigation, not just whether the attack was absorbed. A test that only confirms "the flood was filtered" misses the question that matters to real users: were any of them filtered with it. Availability and correctness of filtering are two different outcomes, and only one of them shows up if you watch the attack instead of the users.
Origin exposure changes shape on OVHcloud
Origin exposure works differently here, and the difference is instructive. On most platforms leaking your origin IP strips your protection. On OVHcloud every IP carries the anti-DDoS, so leaking the server's address does not remove the L3/L4 floor.
What it removes is whatever you added above L4. If you front an OVHcloud origin with a third-party WAF or CDN for the L7 protection the platform does not provide, and the origin's real address leaks, an attacker who connects directly still meets the anti-DDoS, but walks around your application-layer controls entirely. The flood that gets through is precisely the L7 flood OVHcloud never covered.
The leak vectors are the usual ones: historical DNS, certificate transparency logs at crt.sh, a stale A record, an address hard-coded in a client bundle. The full mechanics are in how attackers bypass CDN protection. The lock uses the tools OVHcloud gives you: an Edge Network Firewall rule that admits your application ports only from the edge provider's published ranges, plus an origin secret the edge presents and the application requires, so a direct connection to the raw IP is refused before it reaches your code.
The stateful ceiling behind a stateless edge
Because the edge firewall holds no state, the stateful layer of first failure is the server itself. A connection flood, a slow-read attack, or a burst of half-open connections fills the server's conntrack table, exhausts its accept queue, or burns CPU on TLS handshakes, all at a request rate that looks idle on a bandwidth graph and well under anything the anti-DDoS would treat as volumetric.
This is the class most likely to slip between the platform's controls. It is too low-rate to trip volumetric mitigation, it carries no state at the edge to exhaust there, and it lands on a fixed-size machine that does not scale out. The offered rate at which goodput collapses for this class is the single most valuable number an OVHcloud test produces, and no datasheet contains it.
OVHcloud authorization: the acceptable-use gate
OVHcloud's terms prohibit using its network to attack others, and its systems watch for traffic that resembles an attack, including traffic you generate against your own service. Respecting that is a prerequisite, not a formality.
There is a wrinkle specific to testing a platform whose defense is automatic. A high-volume simulated flood against an OVHcloud target will, if it is convincing, trigger the anti-DDoS to engage exactly as it would for a real attack. That is useful, it is in fact part of what you are measuring, but it must be a planned observation rather than a surprise, because the same event can read to the platform's abuse systems as hostile traffic and draw automated action against the account.
The durable instruction is procedural, because specific policies and contact processes change. Before any OVHcloud DDoS test, read the current acceptable-use and testing guidance, and coordinate the test window with OVHcloud's support channel if your plan approaches volumes their systems would flag. Authorization from the legal owner of the target is mandatory regardless of platform policy; the acceptable-use gate sits on top of that owner authorization, never in place of it. The same discipline of running the test without disrupting production applies in full.
Designing the test: environment, scope, and measurement
The structure that keeps an OVHcloud test informative and safe is the one that governs any production-adjacent test, with an OVHcloud contour.
Environment selection
The strongest first target is a staging environment built from the same provisioning as production: the same server or instance types, the same Edge Network Firewall rules, the same mitigation mode per address, and the same third-party edge in front if production uses one. A mirror that runs permanent mitigation when production runs auto, or omits the edge that production depends on, tests the wrong stack.
Where a finding can only be confirmed in production, the reachability of a leaked origin, for instance, or the true detection window against live traffic, a tightly scoped canary with explicit abort criteria does the job.
Scope as a bounding document
The scope names the exact resources: the servers and instances and their public IPs, the mitigation mode set on each, the Edge Network Firewall rules in force, any third-party edge, and any Managed Kubernetes clusters in play. It sets the vectors and maximum rates, the test windows, the kill switch, and the escalation path.
On OVHcloud specifically, the scope should record the mitigation mode per address, because the test will deliberately compare behavior under auto-mitigation against the same attack, so the detection window and the mode decision are characterized rather than assumed.
Measurement per control
Each control gets a measured outcome. Anti-DDoS: the detection-to-mitigation interval under auto-mitigation and whether the target stayed reachable through it. Mitigation heuristics: goodput during active scrubbing, to catch false-positive collateral. Edge Network Firewall: whether direct-to-server connections were refused. Compute: the offered rate at which goodput collapsed and which kernel limit gave way first, noting whether a dedicated server had any recovery path. Any third-party edge: whether the origin was reachable around it.
The deliverable is not "the site stayed up." It is a per-layer characterization: what engaged, when, at what threshold, and what a real user experienced while it did. Folding those numbers into a defensible posture is the subject of DDoS resilience testing.
Mapping attack classes to OVHcloud controls
A thorough test exercises each layer against the control meant to defend it, including the layers where the platform's control stops. The mechanics of each class are covered in DDoS attack vectors, and real adversaries rarely send one class at a time, which is the subject of multi-vector DDoS testing, where a simultaneous, adaptive delivery is the frontier of the discipline.
- L3/L4 volumetric and protocol (SYN flood, UDP reflection, ACK flood, carpet-bombing) are the anti-DDoS system's domain, absorbed once auto-mitigation detects and engages. The test confirms it engages for this profile, measures the detection window, and checks that legitimate traffic survives the scrubbing.
- Connection-state floods (TCP connection flood, slow-read, half-open) pass the stateless edge without exhausting it and land on the server's own kernel. This class reveals the connection ceiling and the state-table limit, which sit well below the bandwidth ceiling and below the volumetric threshold that would trigger scrubbing.
- L7 application floods (HTTP floods, HTTP/2 abuse, slow attacks) have no managed defender on the platform. They complete valid handshakes, look legitimate to an L3/L4 filter, and land on the server directly, testing whatever L7 control you added or proving none exists.
- Application-logic abuse (credential stuffing under any rate limit, expensive search, cart abuse) is the hardest class anywhere, and on OVHcloud it is entirely an application-code and reverse-proxy concern. The platform offers nothing here by design.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. DDoS testing is engaged both as an ongoing subscription and as a discrete project.
The models suit different cadences. An OVHcloud deployment that changes when a launch approaches, when an address is switched to permanent mitigation, or when a third-party L7 edge is added in front of a server, maps naturally onto project engagements: the test happens when the change happens. A continuously deploying estate may prefer a standing capability.
Neither is universally correct. Annual commitments can price out a team whose real need is a handful of well-scoped tests a year, a common shape for the cost-conscious teams OVHcloud serves well. Match the engagement model to the cadence the estate warrants, not the model a vendor leads with.
FAQ
What is OVHcloud DDoS testing?
Controlled, authorized generation of attack-shaped traffic against OVHcloud-hosted workloads, to verify how the stack behaves under pressure. It validates the specific deployment: the detection window before the anti-DDoS engages, whether legitimate traffic survives active mitigation, the Edge Network Firewall rules, the server or dedicated-machine ceiling, and any application-layer defenses you added, rather than testing whether OVHcloud's protection works in general.
Does OVHcloud protect against DDoS attacks?
At L3/L4, yes, and by default on every IP at no extra cost. The anti-DDoS absorbs volumetric and protocol floods once it detects them. It does not provide a managed WAF or application-layer DDoS protection for servers and instances, so HTTP floods, slow attacks, and application-logic abuse are defended only by what you add. Always-on protection is not the same as inline-at-every-layer protection.
What is the difference between auto and permanent mitigation?
Auto-mitigation lets traffic flow directly and diverts an address into scrubbing when it detects an attack, which keeps steady-state latency clean but leaves a detection window of direct exposure. Permanent mitigation routes an address through the scrubbing path continuously, closing that window at a constant path cost. Testing the detection window under auto-mitigation is how you decide which addresses warrant permanent mitigation.
Do you need OVHcloud's permission to run a DDoS test?
Treat it as required. OVHcloud's acceptable-use policy prohibits attack traffic, and its systems can act on traffic that resembles an attack, including a self-test that triggers the anti-DDoS. Read the current policy, coordinate a high-volume test with OVHcloud support, and obtain written authorization from the target owner regardless.
What is the first thing to validate on an OVHcloud deployment?
The detection window under auto-mitigation: how long the server absorbs an attack directly before scrubbing engages, and whether the service stays reachable throughout. Then, if a third-party edge provides your L7 layer, whether the origin is reachable on its raw IP around that edge, since the anti-DDoS will still answer at L3/L4 while the application-layer controls are bypassed.
Free is not the same as inline
The durable knowledge from an OVHcloud test separates cleanly from the perishable. Five years from now, OVHcloud will still give away a large L3/L4 scrubbing capability on every IP, it will still activate on detection unless you tell it otherwise, it will still filter at the network and transport layers and hand the application layer back to you, and a dedicated server will still have no cushion behind its ceiling. Those are stable.
What you have to keep re-verifying is everything built on the assumption that "protected by default" is the end of the sentence:
- the detection window on each critical address, and whether it still fits inside the outage a burst can cause
- whether an address that needed permanent mitigation is still set to it, or reverted in a rebuild
- whether legitimate traffic still survives active scrubbing, as your traffic shape drifts away from the heuristics
- whether the server behind the stateless edge still holds up to a connection flood the anti-DDoS never sees
- whether a leaked origin IP still lets an attacker reach the raw server around the third-party L7 edge
OVHcloud does not ship a weak platform. It ships an unusually generous one, and the generosity is precisely what makes the gaps easy to miss: when the strong control is free and automatic, the layers it does not cover are the ones nobody checks. A scrubbing network you did not have to configure is still a scrubbing network, with a moment it turns on, a heuristic that sometimes overreaches, and a ceiling at L4. You measure a service like that. You do not inherit it.
None of that shows up on a features page. It shows up the first time real attack-shaped traffic reaches a server during the window before mitigation engages, or lands on the one layer the free protection was never built to defend, which is exactly why you generate that traffic yourself, on a schedule you control, before someone else does it on theirs.