Unlike TCP, UDP is connectionless. A server receiving a UDP packet on any port must process it — or at least decide to discard it — before knowing whether it's legitimate. Attackers send massive volumes of UDP packets to random ports, forcing the server to reply with ICMP 'destination unreachable' messages or simply collapse under the load.
Common UDP Flood Variants
- Pure UDP flood: random ports, random payload, raw volume.
- DNS flood: targeting UDP/53 specifically to exhaust your resolver.
- CHARGEN / QOTD reflection: using legacy UDP services as amplifiers.
- Fragmented UDP: sending fragments that can crash stateful inspection systems.
Detection and Mitigation
UDP floods are identifiable by their packet-per-second rate and traffic profile, but they are a network-layer problem: a stateless packet flood has to be dropped upstream, at your host or transit provider, before it saturates your link. A reverse proxy like Akarguard does not scrub UDP — it is a Layer 7 (HTTP/HTTPS) service. What it does do is hide your origin IP, so a UDP flood aimed at your server has no target; the volumetric traffic itself is stopped by the network in front of you, not by the proxy.
Key metric
A 10Gbps UDP flood contains roughly 7–14 million packets per second. Without hardware-level mitigation, a standard Linux server will drop connections well below this threshold.
If You Run a UDP-Based Application
Game servers, VoIP and public DNS run on UDP, and a reverse proxy cannot protect them — Akarguard is an HTTP/HTTPS service and does not scrub UDP. Those workloads need network-layer scrubbing from your host or transit provider, sized to absorb the packet flood before it reaches your link. What Akarguard protects is the web side of your infrastructure — the site, API and control panel that run over HTTP — with your origin IP hidden so it is not a direct target in the first place.