ddos-sim.com All simulations Configure a test

Layer 4 · Transport · tcp_flag_flood

TCP flag flood test

The tcp_flag_flood simulation floods a target you own with crafted TCP control segments — SYN, ACK, RST, and FIN — to measure how stateful firewalls, connection-tracking tables, and the TCP stack behave when they must classify a burst of control-flag traffic. It runs from the worker's own address at a bounded rate, and is gated behind extended validation.

Layer L4 Protocol TCP Command tcp_flag_flood Access After extended validation

What a TCP flag flood does

A TCP flag flood sends a high rate of TCP segments carrying specific control flags — SYN, ACK, RST, FIN, or unusual combinations — that a target must inspect and classify. Stateful firewalls and connection-tracking tables spend work deciding whether each segment belongs to a known flow, and out-of-state control packets (a bare ACK or RST with no matching connection) can force extra lookups or table churn. At volume, that classification cost, rather than raw bandwidth, is what pressures the service.

How ddos-sim.com simulates it safely

ddos-sim.com emits TCP control segments toward a single verified domain, pinned to a public address, from the worker's own source address — the flags are crafted, but the source is never forged. The packet rate stays inside the limits set for that domain, health checks watch the target throughout, and the run aborts itself the moment a threshold you set is crossed.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over DNS or 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

  • Stateful firewall and connection-tracking (conntrack) classification cost
  • Handling of out-of-state control packets (bare ACK, RST, FIN)
  • TCP stack and CPU headroom under control-flag pressure
  • Rate limiting and anti-flood policy on network middleboxes
  • Time-to-degrade and recovery once the flood stops

How to run a TCP flag flood test

  1. Verify your domain. Prove ownership over DNS or HTTPS — it is self-service and takes minutes.
  2. Add the tcp_flag_flood command to a timeline in the portal and set the target port, flag mix, rate, and duration.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded latency, reachability, and worker timeline to find where your service starts to bend.

Configure a TCP flag flood test in the portal →

Availability & limits

The TCP flag flood is a higher-impact network-layer technique, so it is available after extended validation — beyond the self-service domain check — and runs with prepaid credits.

Frequently asked questions

Does the TCP flag flood spoof source addresses?

No. Every segment is emitted from the worker's own public address. The TCP control flags are crafted, but the source is never forged.

How is this different from a SYN flood?

A SYN flood pressures the half-open backlog with SYN segments alone. A TCP flag flood sends a mix of control flags — SYN, ACK, RST, and FIN — to exercise stateful firewalls and connection-tracking logic that treats each flag differently.

Rehearse a TCP flag flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Configure a test
← All DDoS simulations