A Hetzner DDoS test has to answer a question the platform gives you no console to answer: the protection is on, it is automatic, and it has no settings, so how do you know what it actually does to your traffic?
Hetzner includes DDoS protection free on every Cloud server and every dedicated server, active by default, at every data center. It is a real capability and it absorbs the volumetric floods that would flatten a single machine. It is also, from the customer side, a closed box. There is no mode to pick, no threshold to raise, no tier to buy, no rule to inspect.
On most platforms a DDoS finding is a control set the wrong way: a WAF rule left in count mode, a mitigation tier nobody enrolled. Hetzner removes that entire category of finding, because there is nothing to set. What it puts in its place is a different problem. You cannot misconfigure a control you cannot configure, but you also cannot tune it, cannot whitelist around it, and cannot read its rules to predict its behavior. The only way to know how it treats your traffic is to measure it.
This is the Hetzner instance of structured DDoS testing. The methodology is the same one that governs any environment. The contour is Hetzner's: a free, automatic, opaque L3/L4 filter you do not operate, a firewall layer that is stateful on Cloud and something else on dedicated, and a compute layer, much of it single-tenant hardware, with no managed defense above L4.
Where Hetzner's protection is a black box, not a control panel
The platforms with tunable DDoS controls invite a configuration audit. You read the WAF policy, confirm the rule is in block mode, check the rate-limit key. The test verifies that the settings match the intent.
Hetzner offers no such surface. Its automatic mitigation watches traffic at the network edge, recognizes attack patterns, and filters them, and it does all of that without exposing a dial. You do not choose its sensitivity, you do not see where its trigger sits, and you do not get told when it engaged or what it dropped.
So the test changes character. It is not an audit of a configuration, because there is no configuration to audit. It is an empirical characterization of a black box: send known traffic, observe what arrives and what is served, and infer the box's behavior from the outside. That inference is the whole job, and it is a genuinely different job from testing a platform whose controls you can read.
At a glance: what a Hetzner DDoS test validates
| Hetzner control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Automatic DDoS protection | Free, always-active L3/L4 filtering on every IP, no configuration | When it engages against your traffic, what it lets through under its trigger, and whether the service stays reachable |
| No tuning surface | (there is none by design) | What the opaque filter does to legitimate traffic you cannot exempt, since there is no whitelist to set |
| Cloud Firewall (Cloud) | Stateful packet filtering on Cloud servers | Whether its connection state table is the layer of first failure on the Cloud product |
| Dedicated-server firewall | A separate, limited packet filter on dedicated servers | Whether it holds state at all, and where the stateful ceiling sits once it does not |
| The L7 layer | (not provided by the platform) | Whether anything rate-limits, scores, or filters application requests |
| Compute (Cloud instance, dedicated server) | Serve the application | The single-node ceiling, and for a dedicated machine, that nothing scales out behind it |
The recurring theme: on Hetzner the L3/L4 floor is present and free, so the test moves past "is it on" to the questions a closed box cannot answer for you. When does it fire, what does it drop of yours, and what happens at the layers 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 Hetzner that precision has to be built from observation, because the platform documents the protection as present without documenting the parameters you would need to predict it.
Automatic DDoS protection: free, always-on, and opaque
This is the control that makes a Hetzner test different. The DDoS protection is included on every Cloud server and every dedicated server at no extra cost, active by default, with nothing to enable and nowhere it is absent. It filters at the network and transport layers, absorbing the volumetric and protocol floods, a SYN flood, a UDP reflection flood, carpet-bombing across an address range, that a lone server could not survive.
The property that matters for testing is not that it exists but that it is closed. A comparable free floor on OVHcloud at least exposes a mode choice per address. Hetzner exposes nothing: no auto-versus-permanent switch, no sensitivity setting, no visible threshold, no per-service policy. The filter decides, and you find out what it decided by watching your traffic.
Treat the specifics of the mitigation, its capacity, its detection behavior, the point at which a large attack escalates, as published-doc material to confirm at test time, and expect some of it to be undocumented for customers on purpose. The durable test step is not a number the platform will not give you anyway. It is measuring what the box does on your own traffic.
The cost of no dials: what "not configurable" means for a test
Configurability is usually treated as a convenience feature. Under attack it is also a remediation path, and its absence is the single most consequential fact about testing on Hetzner.
When a tunable filter drops legitimate traffic, you respond by adjusting it: raise a threshold, add an exemption, move a rule to a less aggressive mode. When Hetzner's automatic filter drops legitimate traffic, there is no such lever. You cannot tell it that a particular high-rate source is a real client, cannot loosen it for a launch, cannot exempt a protocol it treats as suspect. The behavior you measure is, for practical purposes, the behavior you are stuck with.
That inverts the usual purpose of a test. Elsewhere the test finds a misconfiguration so you can fix the configuration. On Hetzner the test finds a behavior so you can design around it, because fixing it in place is not an option the platform offers. Remediation moves from the control to your architecture: absorb or clean traffic before it reaches the automatic filter, or accept the behavior as a fixed constraint. Knowing which, and knowing early, is the point of running the test at all.
The firewall layer: stateful on Cloud, something else on dedicated
Hetzner is really two product lines under one roof, and their firewalls behave differently under a connection flood, which is exactly the kind of asymmetry a test has to know about in advance.
Hetzner Cloud provides a free, stateful Cloud Firewall applied to Cloud servers. Stateful means it tracks connections, which makes its state table a candidate layer of first failure: a flood of half-open or churned connections can fill the table at a packet rate that looks unremarkable on a bandwidth graph, the same shape a stateful Cloud Firewall exhibits on DigitalOcean.
The dedicated-server side offers a separate firewall that is a more limited packet filter, historically ingress-only with a small rule budget and without the same stateful connection tracking. Confirm the current behavior for your product before you test, because it determines where the stateful ceiling actually sits. If the edge filter holds no meaningful state, the state ceiling moves back to the server's own kernel, exactly as it does behind a stateless edge on other platforms. The test has to know which product it is exercising, because the same connection flood lands in a different place on each.
The missing L7 layer
Like the budget and bare-metal hosts, Hetzner ships no managed web application firewall and no application-layer DDoS service in front of your compute. The automatic protection 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 Hetzner is the same: if an application-layer flood reaches the server, the only thing in its way is what you put there. The automatic protection will not see it, because from L3/L4 a valid request to a valid port looks like traffic, not an attack.
Many teams front a Hetzner origin with a third-party edge or CDN to supply the L7 layer. That is a sound pattern, and it changes what origin exposure means here, covered below.
Cloud instances and dedicated servers
Hetzner's catalog spans Cloud instances and single-tenant dedicated servers, and the distinction matters under attack.
A 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 with 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 automatic protection defends the pipe to that machine; it does nothing about a connection flood or an L7 flood the machine itself must absorb. The fixed-ceiling, no-scale-out shape is a topic in its own right for pure bare-metal deployments; here it is enough to test a dedicated server as a constraint to measure, not a surprise to discover.
What Hetzner DDoS testing actually surfaces
A useful test is organized around the gaps that recur on Hetzner estates. They follow from the shape above: a free but closed L3/L4 filter, a firewall layer that differs by product, and a fixed compute ceiling with no managed layer above L4.
The trigger you cannot see is the headline finding
On a platform with tunable mitigation, you can read where the trigger sits. On Hetzner you cannot, so the test's first job is to locate it by observation: at what offered rate, and against what pattern, does the automatic filter visibly engage.
That matters in two directions. Above the trigger, a volumetric flood is absorbed, which is the reassuring half. Below it, a connection flood or a low-and-slow attack that never rises to volumetric intensity never trips the filter and lands on the server directly, and you have no way to lower the line to catch it. The dangerous traffic is precisely the traffic that stays under an invisible threshold you did not set.
The test characterizes both halves: confirm the filter engages for a volumetric profile and that the service survives when it does, then establish how much hostile traffic can arrive under the trigger without the platform reacting at all. That lower band is where the real exposure lives, and no dashboard will draw the line for you.
False positives you cannot tune away
An automatic L3/L4 filter separates attack from legitimate traffic with heuristics, and heuristics are imperfect. When they misjudge, legitimate traffic that resembles an attack is filtered, and on Hetzner that is not a setting you can correct.
This is the false-positive cost of automated mitigation, sharpened by the missing tuning surface. High packet-rate legitimate workloads are the ones most at risk: a busy real-time service, a game server, a VoIP or streaming backend whose normal traffic shape overlaps with a flood signature. On a tunable platform you would add an exemption. Here the exemption does not exist, so a false positive is an outage you architect around rather than configure away.
The measurement is goodput for legitimate clients while the automatic filter is active, not just whether the attack was absorbed. A test that confirms "the flood was filtered" and stops has answered the platform's question, not the user's. On Hetzner specifically, if that measurement shows collateral damage, the finding is not "adjust the filter"; it is "this workload needs an absorbing layer in front of a filter it cannot instruct."
Origin exposure changes shape here
Origin exposure works differently on a platform whose L3/L4 protection rides every IP. On most CDN-fronted setups, leaking your origin address strips your protection. On Hetzner the automatic filter is attached to the address itself, so leaking it does not remove the L3/L4 floor.
What a leak removes is whatever you added above L4. If you front a Hetzner origin with a third-party WAF or CDN for the application-layer protection the platform does not provide, and the origin's real address leaks, an attacker who connects directly still meets Hetzner's automatic filter, but walks around your L7 controls entirely. The flood that gets through is precisely the application-layer flood Hetzner 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 Hetzner gives you: a Cloud 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 depends on which product you run
Because the firewall layer differs by product, the stateful layer of first failure is not in a fixed place across Hetzner. On the Cloud product the stateful Cloud Firewall's connection table can be the thing that fills first. On a dedicated server behind a limited, largely stateless filter, the state ceiling drops back to the server's own kernel.
Either way, a connection flood, a slow-read attack, or a burst of half-open connections is the class most likely to slip between the platform's controls. It is too low-rate to trip the automatic volumetric filter, it may or may not exhaust a firewall table depending on the product, 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 a Hetzner test produces, and which layer gives way first is the second. Neither is on any datasheet.
Hetzner authorization: the acceptable-use gate
Hetzner'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 and opaque. A convincing simulated flood against a Hetzner target will trigger the automatic mitigation exactly as a real attack would, which is part of what you are measuring, but the same event can read to the platform's abuse systems as hostile traffic and draw automated action against the account. Because the mitigation gives you no visibility, you also cannot watch a console to see how close you are to that line as you ramp.
The durable instruction is procedural, because specific policies and contact processes change. Before any Hetzner DDoS test, read the current acceptable-use and testing guidance, and coordinate the test window with Hetzner'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 a Hetzner test informative and safe is the one that governs any production-adjacent test, with a Hetzner contour.
Environment selection
The strongest first target is a staging environment built from the same provisioning as production: the same product line (Cloud or dedicated), the same server types, the same Cloud Firewall rules, and the same third-party edge in front if production uses one. Because the automatic protection is identical across the fleet and cannot be configured, one thing you do not have to replicate is its settings. What you do have to match is the product line, since the firewall and the compute ceiling differ between Cloud and dedicated.
Where a finding can only be confirmed in production, the reachability of a leaked origin, for instance, or the true behavior of the automatic filter 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 their public IPs, whether each is a Cloud instance or a dedicated machine, the Cloud Firewall rules in force, and any third-party edge. It sets the vectors and maximum rates, the test windows, the kill switch, and the escalation path.
On Hetzner specifically, the scope should record the product line per target, because that determines where the stateful ceiling sits and how the test reads a connection flood, and it should state up front that the automatic filter is a fixed variable to be characterized, not a control to be reconfigured mid-test.
Measurement per control
Each control gets a measured outcome. Automatic protection: the offered rate and pattern at which it visibly engages, how much hostile traffic can arrive under that trigger, and whether the target stays reachable when it fires. Filter behavior: goodput for legitimate clients while mitigation is active, to catch false-positive collateral you cannot correct. Firewall: whether its state table, on the Cloud product, is the first thing to fill. Compute: the offered rate at which goodput collapses 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, at what apparent 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 Hetzner 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 automatic filter's domain, absorbed once it detects the pattern. The test confirms it engages for this profile, locates the apparent trigger, and checks that legitimate traffic survives the filtering rather than being caught as collateral.
- Connection-state floods (TCP connection flood, slow-read, half-open) stay under the volumetric trigger and land on the firewall or the kernel depending on the product. This class reveals the connection ceiling and the state-table limit, which sit well below the bandwidth ceiling and below whatever level trips the automatic filter.
- 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 Hetzner 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. A Hetzner deployment that changes when a launch approaches, when a service moves from Cloud to dedicated, or when a third-party L7 edge is added in front of an origin, 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 Hetzner serves well. Match the engagement model to the cadence the estate warrants, not the model a vendor leads with.
FAQ
What is Hetzner DDoS testing?
Controlled, authorized generation of attack-shaped traffic against Hetzner-hosted workloads, to verify how the stack behaves under pressure. It validates the specific deployment: where the automatic filter's trigger appears to sit, how much hostile traffic arrives under it, whether legitimate traffic survives active filtering, the Cloud Firewall or dedicated-server ceiling, and any application-layer defenses you added, rather than testing whether Hetzner's protection works in general.
Does Hetzner protect against DDoS attacks?
At L3/L4, yes, and for free by default on every Cloud and dedicated server. The automatic protection absorbs volumetric and protocol floods once it detects them. It does not provide a managed WAF or application-layer DDoS protection, so HTTP floods, slow attacks, and application-logic abuse are defended only by what you add. It is also not configurable, so its behavior is something to characterize, not something to tune.
Can you configure Hetzner's DDoS protection?
Not from the customer side. There is no mode to select, no threshold to set, and no whitelist to add, which is why testing it is an empirical exercise rather than a configuration review. If the automatic filter causes false positives for a legitimate high-rate workload, the remediation is architectural, absorb or clean the traffic before it reaches the filter, rather than a setting you change.
Do you need Hetzner's permission to run a DDoS test?
Treat it as required. Hetzner'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 automatic protection. Read the current policy, coordinate a high-volume test with Hetzner support, and obtain written authorization from the target owner regardless.
What is the first thing to validate on a Hetzner deployment?
How much hostile traffic can reach your server under the automatic filter's trigger. Because the trigger is fixed and invisible, a connection or application flood that stays below it is never filtered and lands on the machine directly. Establish that lower band first, then, if a third-party edge provides your L7 layer, whether the origin is reachable on its raw IP around that edge.
A control you measure, not one you operate
The durable knowledge from a Hetzner test separates cleanly from the perishable. Five years from now, Hetzner will still give away automatic L3/L4 protection on every server, it will still expose no settings for it, it will still stop at L4 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 that depends on the closed box behaving the way it did last time:
- how much hostile traffic still arrives under the invisible trigger before the filter reacts
- whether your legitimate high-rate traffic still survives active filtering, as its shape drifts toward or away from an attack signature you cannot see
- whether the connection flood still lands on the firewall table or the kernel, after a move between Cloud and dedicated
- whether a leaked origin IP still lets an attacker reach the raw server around your third-party L7 edge
Most platforms hand you a control and ask you to configure it correctly. Hetzner hands you a control and asks you to trust it, which is a harder thing to verify, because trust is not a setting you can read back. A filter with no dials is not a weaker filter; it is an unaccountable one, and the only accountability you get is the accountability you generate by testing it. You do not operate a protection like this. You interrogate it, and you design for the answers.
None of that shows up on a features page. It shows up the first time real attack-shaped traffic slips under the trigger you were never shown, or a legitimate spike gets filtered with an attack you cannot tell the box to spare, which is exactly why you generate that traffic yourself, on a schedule you control, before someone else does it on theirs.