Can Non-Website Services Use Anti-DDoS CDN? Identify the Protocol First, Then Choose Anti-DDoS CDN, Layer 4 Proxy, or Game Shield

Yes, it can, but it depends on what protocol your service uses.

The core working method of an anti-DDoS CDN is a Layer 7 reverse proxy: clients access via domain names, CDN nodes parse HTTP/HTTPS requests, match the corresponding site by Host header, and then perform scrubbing, caching, and origin fetch. As long as your non-website service runs on HTTP/HTTPS at the underlying layer (including most app APIs), it can connect to an anti-DDoS CDN. If it uses raw TCP/UDP or a game private protocol, traditional anti-DDoS CDNs cannot parse the protocol headers and therefore cannot forward back to the origin. In that case, you need to switch to a Layer 4 proxy, anti-DDoS IP, or game shield solution.

Below, we explain in the order of "identify the protocol first, then check the client and ports, and finally decide on the solution."

Step 1: Confirm the protocol your service actually uses

"Non-website" only means there is no web page, not that it does not use HTTP. First capture packets or ask the developer to confirm what is actually transmitted between the client and server:

• HTTP/HTTPS APIs: App backend APIs, mini-program backends, APIs called by H5, HLS or HTTP-FLV live streaming pulled over HTTP. These are no different from websites at the protocol level and can connect directly to an anti-DDoS CDN.
• WebSocket: The handshake phase is an HTTP upgrade request, and whether it can go through an anti-DDoS CDN depends on whether the provider supports WebSocket forwarding. Confirm this clearly before integration, and also check the idle timeout for long connections to avoid disconnections caused by heartbeat intervals longer than the timeout.
• Raw TCP/UDP or private protocols: Game battles, custom protocols for instant messaging, RTMP streaming, IoT device reporting, and various port services. This type of traffic has no HTTP headers, so traditional anti-DDoS CDNs cannot handle it.

A single service often has both. For example, a game's login, payment, and announcements use HTTPS, while battles use UDP. In this case, handle them separately rather than choosing only one solution.

Step 2: Choose a solution based on protocol and client form

HTTP/HTTPS: use an anti-DDoS CDN directly

The integration method is the same as for a website: assign a domain name to the API, point the CNAME to the anti-DDoS CDN, and write the domain name in the client instead of the IP. There are a few points that differ from websites and need separate attention:

• APIs return dynamic content, so cache rules should be set to no-cache, and only truly static resources should be cached. Otherwise, one user's data might be returned to another user.
• If the app uses certificate pinning, the certificate deployed on the CDN must match what the client verifies. Before changing certificates, confirm that online client versions are compatible.
• For this type of service, besides DDoS, API abuse and credential stuffing are more common. WAF and CC rules can set thresholds by path and parameters, which Layer 4 solutions cannot do.

Raw TCP/UDP, fixed and few ports: Layer 4 proxy or anti-DDoS IP

Two paths:

• Edge Layer 4 proxy: Some edge acceleration networks provide TCP/UDP port forwarding, such as Cloudflare Spectrum and Alibaba Cloud ESA's Layer 4 acceleration. The advantage is nearby access and simultaneous traffic scrubbing; the limitation is that many products have upper limits on configurable ports and forwarding rules, and you cannot use Layer 7 caching or WAF semantic detection. Refer to each provider's documentation for specific limits.
• Anti-DDoS IP: Use an anti-DDoS IP to handle traffic, configure forwarding rules by port, scrub transport-layer attacks such as SYN Flood and UDP Flood, and then forward to the origin. Suitable for services connected directly by IP with fixed ports.

Both methods require the client to connect to the protection entry address, and the origin's real IP is no longer exposed externally.

Own client, private protocol, many ports, or origin frequently discovered: game shield solutions

If you can control the client (games, your own app) and encounter any of the following, a game shield is suitable to consider:

• Many ports, or dynamically allocated port ranges, making it unrealistic to configure forwarding rules one by one;
• Attackers capture packets and reverse-engineer the client to find the origin IP, so hiding only at the DNS resolution layer is insufficient;
• You need to dynamically schedule nodes by user, so that when a node is attacked, the client can switch to another node.

A game shield usually requires integrating an SDK or access component into the client, encapsulating the private protocol and routing it through the protection link, so the origin address no longer appears in the client. The cost is that development must modify the client and release a new version, and older client versions need a transition period.

Four criteria for quick matching

Among the four items, if they fall into different columns, protocol comes first: if the protocol is not HTTP, anti-DDoS CDN is not a candidate; among the remaining options, choose between Layer 4 solutions and game shield based on port form and origin hiding requirements.

Three things to confirm before integration

1. Whether the server can obtain the user's real IP. After passing through a proxy, the origin sees the node IP. HTTP services generally read request headers such as X-Forwarded-For; TCP/UDP services must rely on Proxy Protocol, TOA kernel modules, or SDK pass-through, and different methods have different requirements for server programs and system kernels. If your service uses real IP for risk control, rate limiting, or banning, ask the provider to explain which method is used and what the server needs to change.
2. Whether the origin IP has already been exposed. For IPs that previously served externally, attackers may still bypass protection and attack the origin directly after integration. After integration, change the origin IP and only allow the protection node's back-to-origin addresses in the firewall.
3. How to split hybrid services. It is common practice for the HTTP part to use an anti-DDoS CDN and the TCP/UDP part to use a Layer 4 solution. For combination methods and configuration points, see Can Anti-DDoS IP and Anti-DDoS CDN Be Used at the Same Time?; for the cost structure differences between the two solutions, see Which Is Cheaper, Anti-DDoS IP or Anti-DDoS CDN?.

Take action based on the result

• All services use HTTP/HTTPS: connect to an anti-DDoS CDN in the same way as a website, and focus on setting API cache rules and CC thresholds.
• Games or apps with private protocols or TCP/UDP long connections: RockCloud's game shield supports TCP/UDP and private protocol encapsulation, hides the origin, and completes acceleration and defense in the same link. It is recommended to first apply for a free trial, switch part of real traffic over, and focus on verifying latency, reconnection after disconnection, and real IP acquisition. After confirming there are no issues, switch over completely.