A SYN proxy is a Layer 4 (transport) defensive control, one of the protections a thorough DDoS test is built to exercise. It is an inline device (a firewall, load balancer, or scrubbing appliance) that terminates the TCP three-way handshake on behalf of the origin. The proxy answers every inbound SYN itself and only establishes a connection to the protected server once a client proves it is real by completing the handshake, so a flood of half-open attempts is absorbed at the proxy and never reaches the origin's connection table.
How a SYN proxy works
When a SYN flood hits an unprotected server, each spoofed SYN consumes an entry in the SYN backlog while the kernel waits for an ACK that never comes. Enough half-open entries and the backlog fills, so legitimate SYNs are dropped. A SYN proxy moves that first handshake off the origin entirely. It replies to each SYN with a SYN-ACK of its own, commonly using a stateless SYN-cookie encoding so it holds no memory per attempt, and waits. A spoofed source never returns an ACK, so its attempt evaporates at the proxy at zero cost. A real client returns the ACK, at which point the proxy opens a matching connection to the origin and splices the two together.
The distinction from a bare SYN-cookie defense is placement and scope. SYN cookies are a technique the origin's own kernel applies to its own accept queue; a SYN proxy is a separate device in the path that shields the origin regardless of the origin's own tuning, and can protect hosts that cannot be tuned at all (embedded stacks, appliances, legacy servers). It also concentrates the defense at one enforcement point, which is easier to reason about under attack than per-host kernel parameters scattered across a fleet.
Where it helps and where it does not
A SYN proxy is decisive against classic spoofed SYN floods because it converts an attack on origin state into an attack on a purpose-built device engineered to shed it. Its limits matter just as much. It defends the handshake, not the application: once a real, or realistically emulated, client completes the handshake, its requests pass through, so a proxy does nothing against an L7 flood riding on fully established connections.
It can also become the bottleneck itself if the SYN rate exceeds its packet-processing budget, which relocates the layer of first failure from the origin to the proxy rather than removing it. A device rated for a peak the attacker exceeds simply fails one hop earlier, and the outage looks the same to the user.
What a DDoS test measures
Because a SYN proxy is a control that either engages or does not, testing it means generating a real spoofed-SYN flood and confirming three things: that the origin's connection table stays clean, that legitimate clients still complete connections through the proxy during the flood, and that the proxy itself holds at the offered packet rate rather than tipping over. A configuration can look correct in the console and still fail if the proxy is provisioned for a peak well below what a modern botnet delivers.
The finding that recurs is asymmetric coverage: a stack proxies SYNs cleanly and then folds to the first application-layer flood that arrives on established connections, because the two defenses were never tested together. Fitting a SYN proxy into a structured resilience exercise, alongside the L7 controls, is how those seams surface before an attacker finds them. See DDoS resilience testing for how individual controls are exercised as one system.