What a Slow POST (RUDY) attack does
RUDY sends an HTTP POST advertising a large Content-Length, then trickles the body one byte at a time. Each connection ties up a server thread or goroutine waiting for a body that never finishes, so a handful of connections can exhaust the request-reader pool with almost no bandwidth. It is the request-body counterpart to Slowloris, which drips the request headers instead.
How ddos-simulation.com simulates it safely
ddos-simulation.com completes a real TLS handshake to a single verified domain pinned to a public address, sends a fixed POST preamble, and drips a fixed filler byte within the rate and concurrency limits for that domain. Nothing you supply is sent — the request is not configurable — so it cannot become a request-smuggling or arbitrary-payload primitive.
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
- Request-body read timeouts and idle-connection handling
- Per-connection request-reader pool limits
- Whether a reverse proxy buffers the full body before the origin sees it
- Concurrency caps that specifically target slow clients
- How quickly capacity recovers once the connections are dropped
When to run a Slow POST test
Run a Slow POST (RUDY) test when request bodies — not headers — are where a slow client could tie up the server.
- Your endpoints accept POST or PUT bodies (uploads, forms, APIs) and you want to confirm read timeouts apply to the body, not just the headers.
- You want to validate that a proxy or WAF fully buffers request bodies before forwarding to the origin.
- You're checking per-connection limits against long-lived, byte-at-a-time uploads.
How to run a slow POST test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
slow_post command to a timeline in the portal and set the rate, duration, and any concurrency limit. - 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 slow POST test in the portal →
Reading the results
Resilient: Request read timeouts abort drip-fed bodies, buffering upstream shields the origin, and the connection pool stays healthy.
Under strain: Request handlers block waiting on bodies that never complete, connection or thread pools fill, and legitimate POSTs are starved.
Availability & limits
Slow POST is priced per engagement — request a quote. Verify your domain before it runs.
Frequently asked questions
How is this different from Slowloris?
Slowloris drips the request headers and never finishes them; Slow POST (RUDY) completes the headers and then drips the body, exercising the body-read path and any request buffering instead.
Does it send my data?
No. The body is fixed filler bytes and the request line is not configurable, so nothing you provide is transmitted.
Rehearse a slow POST test against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan