How We Designed a DDoS-Resilient WebSocket Reverse Proxy for Game Servers

Running public-facing game services comes with a unique set of challenges, especially when long-lived WebSocket connections and frequent DDoS attempts are involved. This post outlines how we designed a reverse proxy architecture that prioritizes connection stability, predictable behavior under attack, and realistic operational costs.

The Problem With Traditional Protection Layers

Many game services rely on persistent WebSocket connections. While CDN-based protection works well for short-lived HTTP traffic, it often introduces instability for real-time services by rotating endpoints or terminating long-lived connections. In practice, this leads to unnecessary disconnects during mitigation events.

For game servers and real-time applications, preserving connection state is just as important as absorbing attack traffic.

Design Goals

The primary goals of our proxy layer were simple:

• Preserve active WebSocket connections during mitigation
• Absorb common network-layer and connection-based attacks
• Avoid protocol-specific interference at the application layer
• Keep latency predictable across regions
• Maintain clear separation between shared and dedicated customers

High-Level Architecture

Traffic is routed through a network-layer DDoS mitigation endpoint before reaching regional reverse proxy servers. The proxy layer handles TLS termination, WebSocket upgrades, and application-level routing, while origin game servers remain private and unreachable directly.

This layered approach allows upstream filtering to handle volumetric noise while the proxy focuses on connection stability and routing logic.

Handling WebSockets Correctly

WebSockets differ from standard HTTP traffic because they are long-lived by design. To handle this safely, the proxy layer enforces strict per-IP connection limits, enables TCP keepalive, and aggressively closes inactive or malformed sessions. Active connections remain untouched during mitigation events, ensuring players are not disconnected unnecessarily.

Application routing is handled after the WebSocket handshake, allowing multiple services to coexist behind the same hostname and port without exposing additional attack surface.

Shared vs Dedicated Proxy Separation

Shared proxy environments are designed with controlled density and conservative limits to reduce blast radius. Dedicated proxy deployments isolate customers entirely and allow for stricter guarantees around performance and availability.

This separation ensures that shared infrastructure remains stable while still allowing premium customers to scale independently.

Final Thoughts

There is no such thing as absolute DDoS immunity, especially on public infrastructure. However, by designing around realistic threat models and understanding how real-time traffic behaves, it is possible to build a proxy layer that remains stable, predictable, and transparent to users even under sustained attack.

Future posts will dive deeper into kernel tuning, connection limits, and operational lessons learned from running this architecture in production.