ddos-sim.com All simulations Configure a test
Home › DDoS simulation testing › TCP port stress test

Layer 4 · Transport · port_check

TCP port stress test

The port_check simulation opens a controlled number of TCP connections to a target port to confirm reachability and measure how the listener behaves as connections stack up. It is a bounded way to pressure the transport layer without spoofing a single packet.

Layer L4 Protocol TCP Command port_check Access After verification

On this page

  1. What a TCP connection flood does
  2. How ddos-sim.com simulates it safely
  3. What the test exercises
  4. How to run the test
  5. Availability & limits
  6. FAQ
  7. Related simulations

What a TCP connection flood does

A connection flood opens many complete TCP sessions to a service until its accept queue, connection-tracking table, or per-process descriptor limits are full, at which point new legitimate clients are refused. Unlike a SYN flood it uses real, fully established connections, so it stresses state further up the stack.

How ddos-sim.com simulates it safely

ddos-sim.com opens a bounded number of genuine TCP handshakes to the port you name on a single verified domain, pinned to a public address. The connection count and rate stay inside the limits for that domain, and no packets are forged.

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

  • Listener accept-queue and backlog limits
  • Connection-tracking (conntrack) capacity on firewalls and NAT
  • File-descriptor and per-process connection ceilings
  • Load-balancer connection distribution
  • Reachability and time-to-refuse under pressure

How to run a port check test

  1. Verify your domain. Prove ownership over DNS or HTTPS — it is self-service and takes minutes.
  2. Add the port_check command to a timeline in the portal and set the target path or port, 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, status codes, and worker timeline to find where your service starts to bend.

Configure a port check test in the portal →

Availability & limits

Port checks are available after self-service domain verification and run with prepaid credits.

Frequently asked questions

Does the port check spoof source addresses?

No. Every connection is a real, fully established TCP handshake from the worker's own address. Nothing is spoofed.

How is this different from a SYN flood?

A SYN flood pressures the half-open connection backlog, while the port check establishes full connections to stress accept queues and connection-tracking state further up the stack.

Related simulations

SYN flood test syn_flood_check Simulate a SYN flood against a domain you own to pressure the TCP connection table and backlog — with full, unspoofed handshakes. HTTPS resilience test https_check Run an authorized HTTPS resilience test against a domain you own. UDP flood test udp_flood Simulate a bounded UDP flood against infrastructure you own to probe UDP ingress filtering, bandwidth headroom, and rate limits.

Rehearse the port check against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Configure a test
← All DDoS simulations
© 2026 ddos-sim.com · Authorized testing only. Simulations · Terms · Acceptable use · Privacy