How to stop a DDoS attack

02While it is happening

The order matters. Getting protection in place is useless if the attacker can still reach the address behind it.

• Get behind a network with capacity — for HTTP, point DNS at a reverse proxy; for anything else, arrange routed or tunnelled transit
• Check the TTL on the records you are about to change: resolvers keep the old answer for up to that long, and lowering it now only helps once the old value has expired
• Firewall the origin to accept web traffic only from your provider's published ranges, or the attack simply continues around your new protection; hiding your origin IP covers the other leaks to close
• Turn on the strictest protection mode you have while you stabilise, then relax it
• Cache aggressively — anything served from cache never touches your origin
• Tell your host: they see the traffic before you do and may already be null-routing you

#!/usr/sbin/nft -f
# Replace the example ranges with the list your provider publishes.
# Re-running the file replaces this table and leaves other rules alone.
table inet origin_lock
delete table inet origin_lock

table inet origin_lock {
    set proxy4 {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.0/24, 198.51.100.0/24 }
    }
    set proxy6 {
        type ipv6_addr
        flags interval
        elements = { 2001:db8::/32 }
    }

    chain input {
        type filter hook input priority filter; policy accept;
        iif "lo" accept
        ct state established,related accept
        tcp dport { 80, 443 } ip saddr @proxy4 accept
        tcp dport { 80, 443 } ip6 saddr @proxy6 accept
        tcp dport { 80, 443 } counter drop
    }
}

03Pick the route back online by what is under attack

The fix depends less on the attack than on what it is aimed at. A website can be moved behind protection with a DNS change; most other services cannot, and knowing that before you start saves an hour of trying the wrong thing.

04What not to do

These are the reactions people reach for first, and each one costs time without helping.

05Afterwards, before the next one

Attacks recur, frequently against the same target and often shortly after. The window right after one ends is the only time you will have both the motivation and the calm to prepare properly.

• Keep protection always-on rather than switching it on when something breaks: Cloudflare's report for the first half of 2026 found that 90.6% of network-layer attacks were over within ten minutes, faster than anyone can react by hand; how long DDoS attacks last has the wider data
• Audit every DNS record for anything still pointing at the origin, including subdomains you forgot; a DNS lookup of each name shows what the rest of the world sees
• Check certificate transparency logs for certificates issued to hostnames that resolve to your origin — the logs are public and append-only, so anything there stays findable
• Move mail off the web server, or its headers publish the address you just hid
• Write down what the traffic looked like: source spread, request pattern, which endpoints were targeted
• Report serious or repeated attacks: DDoS attacks are a criminal offence in most jurisdictions, and timestamps plus logs make a report usable
• Set alerts on your own baseline, not on fixed thresholds

06Match the defence to the layer

A single answer does not cover every attack type, and buying the wrong one is a common and expensive mistake.