WebSocket Long-Connection DDoS Attack Defense: Four-Gate Configuration

The WebSocket long-connection DDoS attack defense solution centers on four gates: handshake authentication, per-IP concurrent connection quotas, message rate and frame size limits, and idle heartbeat timeout reclamation. A separate solution is necessary because traditional request-by-request WAFs lose their inspection point after the HTTP 101 Upgrade. Typical symptoms: game room or market feed connections double within minutes, while bandwidth and QPS remain low, and memory and file descriptors (FD) keep climbing.

The comprehensive WebSocket adoption in real-time services is pushing a new type of connection-exhaustion attack to the forefront. OWASP's 2026 WebSocket security guidelines explicitly require handshake validation, per-IP concurrent connection quotas, and per-connection message rate limiting; Cloudflare's network configuration documentation also confirms edge nodes' native support for WebSocket long connections and idle timeout mechanisms. These standards and official statements collectively point to a four-gate defense framework.

First, triage: Connections surge but bandwidth and QPS are low—attack or your own problem?

Attack forms include three types: handshake flooding, where attackers complete handshakes repeatedly at low cost to fill the connection pool, with the connection curve only increasing but minimal business traffic per connection; high-frequency small-frame flooding within a single connection, where continuous small data frames push up memory and CPU usage; and Cross-Site WebSocket Hijacking (CSWSH), which exploits browser same-origin policy blind spots to redirect victim sessions to attacker-controlled endpoints. If connections remain active at low speed without disconnecting, the scenario resembles slow CC attack protection.

Conversely, many "attacks" are actually your own issues: leaked connections due to improper closure in code, or reconnection storms from weak networks. The key to differentiation is connection curve shape—attack-driven growth is typically stepwise or sudden and does not naturally decline; connection leaks often show a slow climb, while reconnection storms exhibit periodic fluctuations.

Why request-based WAFs stop after HTTP Upgrade: Where is the inspection break?

WebSocket handshake: the client sends a regular HTTP Upgrade request, the server responds with HTTP 101 Switching Protocols, and the connection switches to bidirectional persistent data transmission. The key point: after the 101 response, the data flowing over this TCP connection is no longer "request-response" pairs but continuous, unframed text or binary data frames. Request-based WAFs can only inspect per request and cannot perform continuous filtering on the persistent data frames within a long connection. This renders traditional CC protection nearly ineffective in WebSocket scenarios, allowing attackers a single handshake to occupy resources long-term. The essential difference between WebSocket and HTTP CC attacks is the unit of measurement: HTTP CC counts requests, WebSocket counts connections and messages; cost structures differ: handshake costs far less than a full request and consumes more memory and FD than bandwidth. This is why a separate WebSocket long-connection DDoS defense solution is necessary.

Gate 1: Origin and credential validation during handshake—reject before the connection is established

Once a connection is established, the cost of reclamation far exceeds the cost of rejection. OWASP emphasizes mandatory Origin and credential validation during handshake. Specific checks include: validating the Origin header, allowing only whitelisted sources to prevent CSWSH; verifying authentication tokens during handshake rather than waiting for the first frame—as malicious connections may consume resources before the first frame; and on rejection, directly return handshake failure rather than upgrade then disconnect.

Side effects and mis-injury risk: mobile native clients and server-to-server communication often lack the Origin header, so mandatory validation could reject legitimate connections. It is recommended to validate Origin for requests that carry it, and fall back to credential validation for those without, with the whitelist as a configurable item.

Gate 2: Per-IP or per-user concurrent connection quota—how to estimate the quota and avoid NAT mis-injury

Per-IP concurrent connection quota is the most misconfigured gate. Too low will kill real users behind NAT; too high fails to isolate attackers. A reasonable approach is to estimate a business baseline: count average connections per normal user, multiply by a safety factor as the starting quota. Implement per-IP limits at the edge or application layer, but it is better to add a per-user dimension. Nginx's limit_conn directive operates on the connection dimension and requires forwarding Upgrade and Connection headers. For Nginx-side rate limiting examples, refer to Nginx CC attack rate limiting best practices.

Side effects and mis-injury risk: enterprise egress and mobile networks commonly use NAT, so pure IP quotas risk mis-injury; the quota value must be calibrated through stress testing based on your traffic distribution.

Gate 3: Message rate and single-frame size limits—why count messages instead of requests

OWASP explicitly lists per-connection message rate limiting as a DoS defense requirement. The correct approach is to switch the measurement unit to message count, byte count, and frame size. Recommended multi-dimensional limits: max messages per second per connection, max bytes per frame, and max cumulative traffic per connection. Graduated enforcement: first drop frames to slow down, then close the connection and flag the IP. Legitimate business may have bursts, so an exemption channel is needed.

Side effects and mis-injury risk: too-tight thresholds block real business traffic; first analyze normal message distribution, then set thresholds with dynamic adjustment interfaces.

Gate 4: Idle timeout and heartbeat reclamation—how short a timeout disconnects real clients?

Idle timeout is the fallback gate to prevent connection leaks and zombie connection accumulation. Cloudflare's WebSocket documentation mentions a default 100-second inactivity cutoff at edge network—this value serves as a common default reference, not an industry standard, and certainly not your business standard. The key is to set the application heartbeat interval shorter than the shortest idle timeout in the chain. A connection from client to origin may pass through CDN, load balancer, NAT gateway, each with its own idle disconnect mechanism; the shortest window determines the real keepalive duration. It is recommended to set heartbeat interval to less than half the shortest link timeout, e.g., starting at 30 seconds (this value is an empirical starting point, not a universal recommendation; calibrate based on your link segments' actual idle timeouts and disconnection rates via stress tests), with client support for exponential backoff reconnection.

Four-gate comparison table and disqualification signal quick reference

Below is a summary of the four-gate WebSocket long-connection DDoS defense solution:

Use this table to self-check; missing any gate may leave you vulnerable. Disqualification signal quick reference: connection count only rises, never falls; memory and FD approach limits simultaneously; disconnection rate is zero for a long time; per-IP connection proportion is abnormally high.

Why connection termination and rate limiting should move to the edge: RockCloud's approach

Modern CDN and edge reverse proxies natively support WebSocket passthrough and connection aggregation, finishing protocol termination and connection cleaning at Anycast nodes, significantly reducing origin connection count and serving as a natural barrier against connection-exhaustion attacks. Moving connection termination and rate limiting to the edge means attacker handshake requests are handled before reaching the origin, leaving only timeout reclamation and business validation fallback at the origin. RockCloud high-protection CDN and game shield carry long connections at the handshake layer, distribute per-IP concurrent connection quotas and message rate policies, combined with origin whitelist and return-path consolidation to prevent attackers from bypassing the edge to directly connect to WebSocket ports. Edge protection is not a panacea; it cannot fully block long-connection abuse from real clients nor achieve zero mis-injury. If concerned about origin IP exposure, refer to how to prevent origin real IP exposure for consolidation solutions.

Pre- and post-launch verification checklist: stress test methods and three key metrics

After configuring the WebSocket long-connection DDoS defense solution, three types of stress tests are mandatory: handshake flooding, single-connection frame flooding, and semi-zombie connections. Each test verifies whether the corresponding gate rejects as expected. During gray release, start with alert-only, observe mis-disconnection rates, then gradually tighten. Three metrics to watch: ① ratio of concurrent connections to origin connections—when edge is effective, origin count should be much less than client count; ② process FD and memory usage curves should remain stable; ③ real user abnormal disconnection rate and reconnection success rate—if too high, configuration is too tight and needs adjustment.

FAQ

WebSocket connections exhausted—what to do?

First check the connection curve: only increasing and low bandwidth suggests an attack; immediately enable quotas and timeout reclamation. If slow climbing, it may be connection leaks; check code for proper closure.

What is the difference between WebSocket and HTTP CC attacks?

The core difference is the unit of measurement: HTTP CC counts requests, WebSocket counts connections and messages. Handshake cost is far lower than a full request, and it primarily consumes memory and FD rather than bandwidth.

Should WebSocket handshake validate Origin?

Yes. OWASP explicitly requires Origin validation to prevent CSWSH. Mobile and server-to-server may lack Origin; fall back to credential validation. Reject directly with handshake failure.

What is an appropriate WebSocket heartbeat timeout?

There is no standard value; it depends on the shortest idle timeout in the link. With Cloudflare's default 100 seconds as a reference, set heartbeat interval to less than half the shortest link timeout, e.g., starting at 30 seconds (empirical starting point; calibrate based on actual link segment idle timeouts and disconnection rates via stress tests, not a universal recommendation).

Do premium CDNs support WebSocket?

Yes. Modern premium CDNs natively support WebSocket passthrough and connection aggregation, terminating connections at the edge, cleaning attacks, and consolidating origin connections. Specific concurrency limits and timeout parameters should be consulted with the provider.

How to configure nginx per-IP concurrent connection limit for WebSocket?

Use the limit_conn directive to limit per-IP connections, requiring forwarding of Upgrade and Connection headers. The quota should be based on business baseline to avoid mis-injury to NAT users.

Is memory surge in a long-connection service an attack?

Not necessarily; it could also be connection leaks or reconnection storms. Observe whether connection count only increases and FD climbs in sync. If connections are stable but memory grows, it may be frame flooding; combine with the four gates to troubleshoot.