What is a UDP flood?

02How big UDP floods get

UDP is the workhorse of volumetric attacks. Cloudflare's DDoS report for the third quarter of 2025 found UDP floods the most common network-layer vector, ahead of DNS, SYN and ICMP floods, and its records that quarter were a UDP attack peaking at 29.7 Tbps and a separate attack of 14.1 billion packets per second.

The 29.7 Tbps attack was carpet bombing: it spread across an average of 15,000 destination ports per second, so no single port stood out. It came from Aisuru, a botnet Cloudflare estimated at 1 to 4 million infected hosts. Floods at that scale are not something any single server, or most hosting networks, can absorb on their own.

03What actually breaks first

The packets do not need to be valid or even reach an open port. If the port is closed, the operating system answers with an ICMP port-unreachable message. Linux rate-limits those replies by default, but every packet still costs a lookup and a decision, and a stack without such a limit spends its own outbound bandwidth on replies.

If the port is open, the application has to look at every packet to decide it is garbage. For a game server that means the same thread handling player movement is being interrupted thousands of times a second to discard junk, which is why the symptom is stuttering and rubber-banding long before anything goes fully offline. The specifics for game hosts are covered in DDoS protection for game servers.

04Amplification makes it much larger

Because UDP has no handshake, an attacker can send a small request to a third-party server with the victim's address forged as the source. The server replies to the victim with something much larger. Public DNS resolvers, NTP servers, memcached instances and some game-server query protocols all have this property; amplification attacks covers the whole family.

The multipliers are large. CISA's alert on UDP-based amplification lists bandwidth amplification factors of 28 to 54 for DNS, 556.9 for NTP and 10,000 to 51,000 for memcached; the guides to NTP amplification and memcached amplification cover each in detail.

This turns a modest connection into a large attack, and it means the traffic arriving at the victim genuinely comes from legitimate servers, a further reason source-based blocking does more harm than good.

05The shortcut that looks like protection

Many providers respond to a UDP flood by null-routing the target address, or by dropping all UDP traffic for the duration. Both stop the flood from reaching them. Neither is protection, because from the player's point of view the server is exactly as unreachable as it would have been if the attack had succeeded. RFC 5635, which documents remotely triggered blackholing, says so plainly: it completes the attack, in that the target becomes unreachable.

For anything that depends on UDP, the useful question when comparing providers is not whether they can stop the flood but whether your legitimate UDP traffic keeps flowing while they do.

06How to confirm a UDP flood

A packet capture settles the question in seconds. Look at what dominates: source ports of well-known reflection services, IP fragments, or a spread of random ports from random sources. The table maps what you see to where it has to be fixed.

# replies from common reflection services (DNS, NTP, CLDAP, SSDP, WS-Discovery, memcached)
tcpdump -ni eth0 -c 200 'udp and (src port 53 or src port 123 or src port 389
  or src port 1900 or src port 3702 or src port 11211)'

# IPv4 fragments, common in amplified floods
tcpdump -ni eth0 -c 200 'ip[6:2] & 0x3fff != 0'

# your own IPv4 port-unreachable replies: a flood is hitting closed ports
tcpdump -ni eth0 -c 50 'icmp[icmptype] == icmp-unreach and icmp[icmpcode] == 3'

07What real filtering looks like

None of this can be done on the server itself: by the time packets arrive there, the bandwidth has already been consumed, which is the ceiling a host firewall runs into. UDP filtering only works upstream, which is why non-HTTP services are delivered protection through routing, typically over a GRE tunnel, rather than through a proxy.

Host rules still have a place behind that upstream filter: they keep junk away from the game process once the link is no longer the bottleneck. The example below drops reflection traffic aimed at a game port, drops IPv4 fragments and caps each source. The port and rates are placeholders to replace with your own game's measured traffic, and game-specific guides such as FiveM DDoS protection list the ports worth covering.

• Rate and shape per source and per destination port, upstream of your link
• Drop packets that cannot be valid for the protocol on that port
• Recognise the signatures of reflection sources and discard them early
• Keep the legitimate protocol flowing: filtering, not blanket blocking
• Hide the origin address so the attacker can only reach the filtered path

table inet udp_guard {
    set reflect_ports {
        type inet_service
        elements = { 19, 53, 123, 389, 1900, 3702, 11211 }
    }
    set game_src {
        type ipv4_addr
        flags dynamic
        timeout 1m
    }
    # before reassembly: drop IPv4 fragments (only if your game never fragments)
    chain pre_defrag {
        type filter hook prerouting priority -450; policy accept;
        ip frag-off & 0x3fff != 0 counter drop
    }
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 udp sport @reflect_ports counter drop
        udp dport 27015 update @game_src { ip saddr limit rate over 300/second burst 600 packets } counter drop
    }
}