DDoS Protection and Acceleration for Card and Competitive Games

Distributed scrubbing nodes absorb DDoS floods and CC attacks close to their source while your real server IP stays hidden. Full TCP/UDP forwarding keeps in-match latency around 30ms, so launches and tournaments stay online.

Get a game protection plan
  • 30msIn-match round-trip latency
  • 7T+DDoS mitigation capacity
  • 3,000+Edge and scrubbing nodes
Diagram: player clients reach the game server through distributed anti-DDoS nodes; attack traffic is absorbed at the nodes while the real origin stays locked away behind the protection layer.

Four risks every card and competitive title runs into

Downtime here rarely comes from underpowered servers. It comes from an exposed origin, broken long-lived sessions, and attacks timed for your most valuable hours.

  • The origin IP gets found — and flattened

    A fallback address hard-coded in the client, a latency-test endpoint, a third-party SDK callback or one stale DNS record is enough to give the real IP away. Once it is out, a few tens of Gbps take the whole fleet offline, and rotating the address only buys hours.

  • Players drop mid-match

    Card and competitive titles run on long-lived TCP/UDP sessions. One or two percent packet loss and a few tens of milliseconds of jitter are enough to force a reconnect — and a disconnect on the deciding turn becomes a refund ticket, not a latency chart.

  • Launches and tournaments are attacked on schedule

    Server openings, in-game events and streamed tournaments are your highest-traffic, highest-acquisition-cost hours — and exactly when DDoS and CC floods arrive. Attackers read your announcements; one successful hit writes off the whole campaign spend.

  • Fragmented experience across regions and carriers

    Players sit on different networks and in different countries. Cross-carrier detours leave one player at 40ms and another at 200ms on the same table, and the slower side is usually the one that stops coming back.

Six core capabilities

Mitigation, routing and acceleration run on one network. Clients only ever see a protected entry point, your origin disappears from the public internet, and your protocol stays untouched.

  • Origin IP shielding

    Players and attackers only reach a protected entry address. The real game server sits behind an allow-list that accepts connections from our fetch ranges alone.

  • Distributed terabit scrubbing

    7T+ of capacity spread across many sites absorbs SYN floods, UDP reflection and ACK storms near their source, so nothing converges on a single entry point.

  • CC defence for game protocols

    Behavioural models on login, matchmaking and room endpoints separate scripted connection floods and fake clients from real players, with device-fingerprint and rate-based blocking.

  • Full TCP/UDP forwarding

    Not just HTTP. Proprietary binary protocols, encrypted custom packets, WebSocket sessions and voice UDP streams are forwarded transparently by port — no server-side changes.

  • CN2 and multi-carrier ingress

    CN2 GIA routes interconnected with the three major Chinese carriers, plus multi-carrier entry points per region, remove cross-network detours and flatten peak-hour jitter.

  • Second-level failover

    When a node is targeted or a route degrades, players are rescheduled to a healthy entry point within seconds, with session affinity preserved so matches in progress keep running.

Four steps to go live, no game server changes

Everything happens at the network layer: the client connects to a protected entry point while your server logic and wire protocol stay exactly as they are.

  1. Map ports and protocols

    Register your TCP/UDP ports, session characteristics and expected concurrency so we know precisely what to protect.

  2. Configure forwarding and rules

    Create forwarding rules, protection tiers and CC policies from a card/competitive template, then tune against live traffic.

  3. Switch the connection address

    Point the client or dispatch service at the protected entry, rotate the origin IP and allow only our fetch ranges through the firewall.

  4. Load test and rehearse

    Run a load test with simulated attack traffic to validate loss, latency and failover, and keep the logs for post-incident review.

Typical results after onboarding

Ranges observed across card and competitive game customers; actual results depend on your protocol, packet rate and player distribution.

  • 60%Fewer mid-match disconnects
  • ≤0.1%Long-session packet loss
  • 99.99%Game server availability
  • SecondsFailover under attack

Card game protection FAQ

It is not — this is the most common way customers start. First, point the client at the protected entry. Second, rotate the origin IP at the same time: the old address is already in the attacker’s hands, so keeping it defeats the purpose. Third, allow only our fetch ranges through the origin firewall and drop everything else. Cutover usually completes within half an hour with no change to game logic. While the attack continues we hold the highest protection tier, then relax the policy as we learn the real traffic profile.

Four routes account for most leaks: fallback addresses hard-coded in the client, latency-test or announcement endpoints hitting the origin directly, mail and third-party callbacks exposing the egress IP, and historical DNS records. Onboarding addresses all four: every public address collapses onto the protected entry, origin egress moves to a separate NAT address, and rotating the IP invalidates the DNS history. After that the origin is effectively unreachable from the public internet — run any new endpoint through the same checklist.

It depends on whether that protection shape is enough. A protected server concentrates scrubbing in one facility, so capacity is capped there and a single public IP stays exposed — sustained pressure on that address often ends in a facility-level blackhole. Game Shield is distributed: traffic spreads across multiple protected nodes, the real origin IP is hidden, and an affected node can be swapped out in seconds. The two are not mutually exclusive; a common setup keeps the origin on the protected server as a last line of defence while Game Shield fronts player connections, giving you both facility-grade mitigation and distributed absorption with nearby routing.

Yes. Card and competitive titles are protected at layer 4: TCP/UDP traffic is forwarded transparently by port without inspecting your payload, so proprietary binary protocols, encrypted custom packets, WebSocket sessions and voice UDP streams all work unchanged — not one line of server code. All you supply is the port range to forward. If you also expose HTTP endpoints for login or top-ups, a layer 7 WAF and rate-limiting rules can be layered on top of those specifically.

Yes. Mitigation capacity is distributed, so attack traffic is absorbed across many sites instead of converging on one entry point — no capacity request needed in advance. Send us the schedule three to five days ahead and we will reserve scrubbing headroom, spread players across multiple entry points, and tune protection tiers and rate limits to your projected concurrency. We can staff the event window for minute-level response and provide an attack and mitigation report afterwards.

Normally no — most customers see latency fall. Players previously took a cross-network detour to a single origin; afterwards they connect to a nearby edge node and traffic reaches the origin over our private backbone and CN2 routes, cutting hops and congestion points. What does add latency is an entry point too far from your players, which is why we benchmark from your actual player regions before choosing the ingress mix instead of handing over one default address.

Multi-carrier ingress plus routing policy. Each region offers entry points on every major carrier and the client picks the best one from live probing; overseas players enter at a nearby node and reach the origin over the backbone. Players in the same room can also be pinned to a shared entry so their return paths match and the latency gap at one table narrows. The console breaks down latency, jitter and loss by region and carrier, so a complaint can be traced to the access leg or the origin leg quickly.

Still haven't found what you're looking for? Talk to our team.

Keep every match running to the final hand

Tell us your protocol type, port ranges, concurrency and player regions, and we will propose the forwarding, mitigation and routing setup to match — with a live match test before you commit.