Most DDoS protection failures are not failures of the protection. The scrubbing works, the rules are right, the dashboard is green. The traffic simply never arrives there.
A managed edge defends the requests that pass through it. That is the whole contract. Anything that reaches your origin by another route is outside the contract, and no amount of capacity at the edge changes that.
So the question worth asking before any of the tuning questions is the plainest one available. Is the protection you provisioned actually in the path?
It is also the first thing DDoS testing establishes, because every later measurement assumes the traffic under test reaches the defense you are measuring.
The failure has a shape
It usually looks like this. The www hostname points at the edge, because that is the one everybody remembers to migrate. The apex still resolves to the origin address it had before the edge existed, because changing it was awkward at the time and nothing broke.
Both names serve the same site. One of them is defended.
An attacker does not have to discover anything clever to exploit that. They resolve the name, see an address that is not the edge, and aim there. The protection you are paying for records nothing, because from its point of view no attack happened.
We checked a well-known open-source project's site while testing this and found exactly that split: the apex behind a major CDN, and the www hostname resolving straight to university hosting running a bare web server. We do not know the history, and it may well be deliberate. What matters is that from the outside the two names do not agree, and only one of them is behind the edge.
That is the point worth sitting with. Run by capable people, and still worth checking, because the disagreement is only visible from outside. Nobody inside the platform is shown it.
The apex is the one that drifts, and there is a reason
This keeps happening for a specific technical reason, and it is worth understanding rather than treating as carelessness.
Putting a hostname behind an edge normally means pointing a CNAME at the provider's name. But DNS does not permit a CNAME at a zone apex. The apex has to carry the zone's SOA and NS records, and a CNAME cannot coexist with other records at the same name. So www.example.com gets a one-line CNAME and example.com cannot have one.
Providers each solved this in their own way. Some offer ALIAS or ANAME records that behave like a CNAME but resolve to addresses at query time. Some flatten the CNAME internally. Some hand you an anycast address to put in a plain A record. All of these work, and every one of them is provider-specific.
That is the asymmetry that creates the drift. Two hostnames that ought to be equivalent are configured by two different mechanisms, and only one of them is a single obvious line. During a migration, under time pressure, the easy one gets done and the awkward one gets deferred.
The same logic explains why the problem multiplies with subdomains. Every api, staging, and mail name is another record that may or may not have made the trip, and none of them are as visible as the front page.
Fixing a mixed path
The fix is not complicated, but it is deliberate. Decide which hostnames are public, and route every one of them through the same edge.
For the apex, use whatever your DNS provider calls its CNAME substitute rather than leaving a legacy A record pointing at the origin. If you must keep an A record, it should hold an address belonging to the edge, never the origin.
Then close the back door. Moving the DNS record stops traffic arriving at the origin by name, but the origin address remains reachable by anyone who knows it. Restrict the origin so it only accepts connections from the edge, whether by firewall rule, security group, or the provider's authenticated pull mechanism. Otherwise you have changed where the signpost points while leaving the road open.
Why the dashboard cannot tell you
The provider console reports on traffic it receives. A hostname that bypasses the edge produces no traffic there, so the console shows a healthy service with nothing wrong.
Traffic graphs, mitigation logs, and health checks all agree that things are fine, because each of them describes traffic that arrived. There is one place it can surface from the inside: if your DNS is hosted by the same provider as your edge, the record list will show which names are proxied and which are not. That only helps when the two live together, which is often not the case.
Otherwise the gap is visible only in DNS, from outside, by asking what each public name actually resolves to.
What "in the path" means precisely
Three separate things get confused with each other, and the difference matters under attack.
Provisioned means you are paying for it and it exists in your account.
In the path means traffic for a given hostname actually transits it.
Effective means it holds when a real attack arrives.
Provisioned is easy to verify and tells you the least. Effective is the one that matters and cannot be established by looking, which is what DDoS testing exists to determine. In the path sits between them, and it is the one most often assumed rather than checked.
You can be provisioned and not in the path. That is the drift above. You can be in the path and not effective, which is the harder problem and the reason testing exists at all.
Check it on your own domain
We wrote a small tool that answers the middle question. It is read-only, it is open source, and it sends no attack traffic: just one ordinary HTTPS GET per hostname, the same request your browser makes.
cargo run --release -- example.com
It reads public DNS over DNS-over-HTTPS, maps the addresses to their network operator, and looks at ordinary HTTPS response headers, the same information any browser receives. Then it compares your apex and www and tells you whether they agree.
It prints its evidence rather than a verdict you have to trust:
[*] example.com
networks: EXAMPLE-EDGE - Example Edge, Inc., US
edge: Example Edge (evidence: address is on EXAMPLE-EDGE)
[*] www.example.com
edge: no recognised edge
server: Apache
[FAIL] MIXED PATH. Some hostnames are fronted, others reach the origin directly.
Three outcomes. In path, where every hostname checked transits a recognised edge. Mixed path, where some do and some do not, which is the finding worth acting on. And inconclusive, which deserves its own explanation.
Inconclusive is not the same as unprotected
If the tool recognises no edge, it says so and stops. It does not tell you that you are undefended.
A first-party edge produces this result. Large platforms that serve their own traffic match none of the public signatures, and reporting them as exposed would be wrong. So would reporting any provider that simply is not in the tool's table yet.
Absence of recognition is not evidence of absence. The tool prints the server banner so you can identify what is actually in front of you, and leaves the judgment to you. We would rather ship something that admits its limits than something that produces a confident number.
What this does not tell you
Now the honest part, because a tool that overstates itself is worse than no tool.
Knowing your protection is in the path tells you the traffic arrives. It says nothing about what happens next.
It does not tell you whether the edge detects a flood as an attack or serves it as legitimate demand. It does not tell you the threshold where rate limiting engages, or whether that threshold is above or below the point your origin starts shedding requests. It does not tell you how many seconds pass between the first malicious packet and active mitigation, and those seconds are usually where the outage lives.
It also sees one resolver's view of the world. Geo-steered or split-horizon DNS can answer differently somewhere else, so a clean result from one vantage point is not a guarantee for every region.
And it says nothing at all about the question that decides real incidents: what happens when the attack changes shape.
A static test replays a fixed script. A real attacker watches what you do and adapts, shifting vector, rate, and source distribution in response to your defenses. You cannot validate whether a defense adapts by attacking it with something that does not.
That is the gap between a configuration check and a resilience test. Our Patent-Pending Adaptive DDoS Testing applies simultaneous multi-vector load and adapts in real time to how your defenses respond, so you learn where resilience actually ends rather than where the documentation says it should.
Checking the path is free and takes a minute. Knowing whether it holds is a conversation.
Where to point it
The build story, including the two detection bugs that had to be fixed before it could be trusted, is on dev.to: Your DDoS protection is provisioned. I checked whether it was actually in the path. The code is on GitHub at github.com/BlackNeuron-ai/ddos-protection-path-check.
Each run checks the domain you pass plus its www. Origins hide behind api, dev, staging, and mail far more often than behind www, because those are the names nobody thought of as public, so pass each of those as its own argument rather than assuming the default pair covers you.
Run it against domains you own or are authorized to test. It reads only public data, but that is the right habit regardless.
It sits alongside the other free DDoS resilience tools, each of which answers one checkable question about your own estate.
The path question is one of several that a structured DDoS test answers properly. Two neighbours are worth checking at the same time: whether your origin is reachable directly past the edge, which is the same bypass seen from the other end, and whether the edge is actually absorbing traffic rather than forwarding it, which decides how much of a flood reaches you even when the path is correct.
Re-run it after any DNS change, any migration, and any new environment. A correct path stays correct only until something moves, and something always moves.
Common questions
Why can't I just put a CNAME on my apex? DNS does not allow it, for the reason described above. Your provider will offer its own substitute, and the fact that every provider names it differently is precisely why the apex drifts.
Does an unrecognised edge mean I am unprotected? No. It means nothing matched a known signature. A first-party edge, or any provider not yet in the tool's table, produces the same result. Read the server banner it prints and compare it against what you believe you are running.
Is checking the path the same as testing my protection? No, and the difference is the whole point. The path tells you traffic arrives. Whether the defense holds, at what threshold, and how it behaves when the attack adapts are separate questions that only a test answers.