What a UDP flood does
A UDP flood sends a torrent of connectionless packets toward a host or its ports, consuming bandwidth and forcing the target to process — and often reject — traffic for services that may not even exist. Because UDP is stateless,
volume alone can saturate links and exhaust ingress-processing capacity upstream of the application.
How ddos-simulation.com simulates it safely
ddos-simulation.com sends a small, fixed packet per operation to a single verified domain, pinned to a public address, with the packet rate held inside the limits granted for that domain. The most aggressive network-layer
methods like this one are reviewed and approved before they run.
Authorized targets onlyEvery run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly
authorized to test may be unlawful. See the Acceptable Use Policy.
What the test exercises
- UDP ingress filtering and access-control lists
- Bandwidth and link headroom to the origin
- Upstream scrubbing and rate-limiting behavior
- Stateless-service and resolver handling of unsolicited packets
- Collateral impact on shared network paths
When to run a UDP flood test
Run a UDP flood test when you need to see how UDP ingress filtering and rate limits hold up against a stream of small packets.
- You expose a UDP service (DNS, QUIC, game, VoIP, or custom) and want to measure how much packet noise it absorbs.
- Upstream rate limiting or ACLs are meant to drop unsolicited UDP and you need to confirm they engage.
- You want to understand bandwidth and packets-per-second headroom before an event.
How to run a udp flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
udp_flood command to a timeline in the portal and set the target path or port, rate, and duration. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.
Configure a udp flood test in the portal →
Reading the results
Resilient: Legitimate UDP traffic keeps flowing, rate limits shed the excess without collapsing the service, and CPU and interrupt load stay bounded.
Under strain: Packet loss climbs for real traffic, the NIC or kernel saturates on interrupts, or upstream filters fail to tell the flood from legitimate flows.
Availability & limits
UDP floods are reviewed and approved before they run — a manual review of your domain and intended use — and are priced per engagement — request a quote.
Frequently asked questions
Why does the UDP flood need review?
Volumetric UDP traffic can affect shared upstream links, so it is gated behind a manual review of your domain and intended use before it can run.
Are source addresses or packets spoofed?
No. Packets originate from the worker's real address and are directed only at your single verified, publicly-resolved domain.
Rehearse the udp flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan