What is DDoS mitigation?

02Always-on vs. on-demand

On-demand mitigation only routes your traffic through the scrubbing network once an attack is detected, usually by a BGP announcement that redirects your prefix. It is cheaper, but there is a gap between the attack starting and the diversion taking effect, and most attacks are short: Cloudflare found that 90.60% of network-layer attacks in the first half of 2026 ended within ten minutes. A sharp attack can be over before mitigation engages, as the data in how long DDoS attacks last shows.

Always-on mitigation keeps traffic flowing through the filtering path at all times, so there is nothing to detect, divert or activate — an attack simply meets a system already inspecting every packet. The cost is that all traffic, not just attack traffic, takes that path, so the provider's latency and reliability become yours.

How traffic reaches the filter depends on what you protect: a DNS change to a reverse proxy for websites, a GRE tunnel or BGP announcement for everything else. The three are compared in remote DDoS protection explained.

03Mitigation techniques compared

Networks and providers combine a handful of techniques, and the type of attack decides which apply. They differ mainly in precision, and therefore in how much legitimate traffic they take down along with the attack.

04How attack traffic is identified

At the network layers, filtering is mostly statistical: packet rates, malformed or impossible header combinations, protocols that have no business reaching this service, and reflection signatures such as large DNS responses nobody asked for.

At the application layer it is much harder, because each request is individually well formed. Mitigation systems therefore judge behaviour across many requests and clients rather than one request at a time: whether a client behaves like the software it claims to be, whether its pace and navigation look human, and whether large numbers of unrelated addresses suddenly act alike.

The principle underneath is that real audiences are varied — many devices, browsers, networks and habits — while an attack is usually many copies of a few tools. Anything that makes the copies stand out from the crowd helps separate them.

05Challenges: proving you are a browser

When traffic is ambiguous, blocking risks turning away customers, so many services ask the client to show it is a real browser instead. A common form is a proof-of-work challenge: the page runs a short computation in the background and submits the result, with no puzzle for the visitor.

This changes the economics. A visitor pays a moment, while an attacker has to run a real browser engine at scale, which costs far more than sending raw requests. It is not proof of a human: headless browsers can complete the work, so a challenge raises the price of an attack rather than ending it, and works best alongside rate limits and behavioural checks.

Interactive challenges such as a CAPTCHA, which ask a person to click or solve something, cost every real visitor an interaction, so they are best kept for traffic that has already looked suspicious rather than shown to everyone.

06What you can do on your own server

No server setting survives a flood larger than its uplink, but a few basics blunt smaller protocol attacks and stop attackers going around your provider. Where that line falls is worked out in can a firewall stop a DDoS attack.

• Leave SYN cookies on. The Linux default, 1, sends them only when a socket's SYN queue overflows; the kernel documentation warns they are a flood defence, not a way to handle legitimate load
• Drop packets that connection tracking marks as invalid, and TCP packets that try to open a connection without a SYN
• Once a proxy is in front, accept web traffic only from the provider's ranges, as described in how to hide your origin IP
• Be careful with per-address connection limits: they stop one noisy client but also punish everyone behind a shared office or mobile address, so size them from your own traffic

# shell: 1 (the default) = send SYN cookies only when the SYN queue overflows
sysctl net.ipv4.tcp_syncookies

#!/usr/sbin/nft -f
# ddos-basics.nft: re-running the file replaces only this table
table inet ddos_basics
delete table inet ddos_basics
table inet ddos_basics {
    chain input {
        type filter hook input priority filter; policy accept;
        # packets that belong to no valid connection
        ct state invalid counter drop
        # new TCP connections that do not start with a bare SYN
        tcp flags & (fin | syn | rst | ack) != syn ct state new counter drop
    }
}

07Questions to ask a mitigation provider

Most of these come from the NCSC's guidance on upstream defences and testing. Ask them before you sign, and get the answers in writing.

• Is mitigation always on, or does it have to be activated — and if so, how long does that take?
• Does it apply automatically, and will you be told when it does?
• Does it cover both network and application layers, and every protocol you run?
• Is there a size or duration above which your bandwidth is throttled, your service terminated or your traffic black-holed?
• Can you see what is being blocked while it happens, through logs, alerts or monitoring feeds?
• Can you test it? The NCSC recommends testing against both network and application-layer attacks with legitimate testing providers

08How mitigation is priced, and why it matters

Pricing models vary more than the technology does, and the difference shows up at the worst possible moment.