Game Servers: High-Defense IP or High-Defense CDN? Split Modules by Protocol and Layer Your Access

Most games don't need to choose one over the other; just handle them separately by the protocol the traffic uses:

• TCP/UDP long connections for player battles, rooms, and lobbies (usually proprietary protocols) go through high-defense IP; for games with clients like mobile, PC, and card games, you can further consider a game shield.
• Official websites, event pages, mini-client and patch downloads, and HTTP-based login or payment interfaces go through high-defense CDN.

The situation for pure H5 web games is different and will be explained separately later.

If your server is currently under attack and the IP has been blackholed, you can jump directly to the access sequence in the last section.

First, split game services by protocol

High-defense CDN is essentially a distributed reverse proxy plus edge caching, natively handling HTTP/HTTPS layer 7 traffic. Game core battle synchronization and long-connection gateways mostly run on TCP or UDP proprietary protocols, and high-defense CDN usually cannot directly proxy such layer 4 raw data packets. High-defense IP does TCP/UDP port forwarding and can be configured for all ports or specific ports, with no requirements on proprietary protocols.

So the first step is to make a list, not compare products:

The same term "login" may be implemented differently across games. HTTP-based interfaces go on the CDN side; those where the client maintains a TCP long connection with the login server go on the high-defense IP side.

If you're not sure which category a module belongs to, you can first read Can High-Defense CDN Be Used for Non-Website Services?, which includes a method for determining by protocol.

For real-time battles, look at latency next

Strongly interactive games like FPS and MOBA are very sensitive to latency, packet loss, and jitter. High-defense CDN goes through multiple layers of edge scheduling and application-layer proxying, so using it for long connections can easily introduce jitter. BGP high-defense IP can connect directly over multiple lines and do layer 4 forwarding with less overhead, making it more suitable in front of battle links.

When selecting, it's recommended to test using the networks where players actually are, and look at average latency, jitter, and packet loss together. Testing only once near the data center won't reveal problems.

For games with clients, should you use a game shield?

Mobile, PC, and card games often encounter another type of attack: TCP empty connections, slow connections, and CC disguised as normal proprietary protocol requests. Such attack traffic isn't necessarily large, but it continuously occupies the high-defense IP's forwarding connection pool, and handling it solely by scrubbing large traffic can be difficult.

The game shield approach is to integrate an SDK into the client, establish an encrypted tunnel using a proprietary protocol between the client and protection nodes, and then dynamically schedule through distributed nodes. This way, neither the origin nor the protection nodes are directly exposed, and attack traffic is hard to concentrate on a single point. The cost is that the client must be modified and released with a version, so this step must be factored into scheduling.

You can judge as follows:

• If the main threat is large-traffic SYN Flood or UDP Flood, high-defense IP is usually sufficient.
• If connections are already saturated, frequent disconnections occur, yet traffic doesn't look large, or protection node IPs are repeatedly targeted, consider a game shield.

RockCloud's Game Shield supports TCP/UDP and proprietary protocol encapsulation, and can hide the origin. Acceleration and defense are completed on the same link with only one fee, and it supports free testing before deciding whether to migrate.

Pure H5 web games run in the browser, and communication is generally HTTPS or WebSocket. In this case, high-defense CDN may be able to carry the main traffic. However, whether WebSocket long connections are supported and how idle timeouts are set vary by product, so you need to confirm item by item and test in real matches.

Key points for combined deployment

1. Separate entry points. CNAME the Web domain to high-defense CDN; change the address the client uses to connect to the game server to high-defense IP, or let the game shield SDK schedule it.
2. Lock down the origin. Both the game server and Web origin should only allow back-to-origin IPs from protection nodes, and block all other public inbound traffic. If you only lock down one side, the other side becomes a bypass hole.
3. Don't let Web records expose the game server IP. If historical DNS records pointed directly to the game server IP, or the official website and game server share the same machine, attackers may find the real address.

For how to configure both products at the same time, see Can High-Defense IP and High-Defense CDN Be Used Together?; for whether to change DNS or ports during access, see Does High-Defense IP Require Changing DNS or Ports?. For cost calculations, see Which Is Cheaper, High-Defense IP or High-Defense CDN?.

Access sequence when under attack

1. First confirm which layer is being hit. Is it the official website, download site, or Web API that won't open, or is the game server dropping offline and the IP blackholed? The handling path is completely different.
2. Web and download parts: Switch the domain's CNAME to high-defense CDN; once DNS takes effect, traffic will go through protection nodes. How fast it takes effect depends on the TTL of the original record.

3. Game server blackholed: Do not connect layer 4 services to a CDN that only supports layer 7; that won't solve the problem. The correct approach is:

   • Configure TCP/UDP forwarding rules on the high-defense IP;
   • Change the client's connection target to the high-defense IP, usually by modifying the server list issued by the login server or the client configuration;
   • The origin only allows high-defense back-to-origin IPs.
4. Consider changing the origin IP. If the origin IP is already exposed, access controls on the server cannot stop large traffic directly hitting that IP, and upstream may still blackhole it. When conditions allow, switch to an IP that has never been public as the new origin, then lock it down.

If you are currently under attack and need help with access, you can contact RockCloud directly through the contact page.