If your website is hosted outside Mainland China but most users are in Mainland China, you need to consider performance and attack protection together. Should you rent a few servers and build your own CDN, or use a DDoS-protected CDN that accepts domains without an ICP filing?

Self-hosting gives you more control, but you must assemble and operate the network connectivity, protection, and infrastructure. With a managed DDoS-protected CDN, the provider operates the edge network and delivers security within the agreed scope.

Self-hosting can make sense if you have a technical team and reliable resources. If the site is already under sustained attack and no one is dedicated to network operations, an established managed service is usually easier to deploy.

These labels describe different things: “self-hosted” describes who builds and operates the CDN; “DDoS-protected” describes a security capability. A self-hosted CDN can also provide DDoS protection, but someone must supply and maintain the necessary resources.

What “no ICP filing,” “self-hosted,” and “DDoS-protected” mean

A “CDN without an ICP filing” usually refers to a service using edge locations outside Mainland China that accepts a domain without a Mainland China ICP filing. Service regions and onboarding requirements are what matter here. Delivering content to users in Mainland China does not mean the edge locations are in Mainland China.

For example, Alibaba Cloud's ESA documentation on service regions distinguishes regions with Mainland China edge locations from those without them, with different ICP filing requirements. Check the specific provider's rules for the service region and eligible domains.

A “self-hosted CDN,” as discussed here, means buying or renting servers for edge nodes, deploying reverse proxies, caching, traffic routing, and monitoring, and maintaining the system yourself.

Providers sometimes say they built their own platform or edge network. That does not mean the customer is building a CDN. The customer may still be buying a managed service, with the provider responsible for node failures, security policies, and platform upgrades.

A DDoS-protected CDN combines content delivery and proxying with mitigation for DDoS attacks and malicious HTTP requests. Which protocols it protects, the attacks it can handle, and what happens beyond the plan limits depend on the specific service.

Once those terms are separated, the differences between the two approaches are easier to assess.

The table is primarily about who owns each responsibility. It does not prove that a particular self-hosted setup is faster or that every product labeled “DDoS-protected” is reliable.

Why build your own CDN? Greater control over the details

Suppose a site mainly serves images and downloads, its users are concentrated in a few regions, and the team already has suitable servers outside Mainland China. Deploying caching edge nodes can reduce origin traffic by serving repeated requests at the edge, while giving the team more control over caching.

NGINX's reverse proxy and caching documentation covers request forwarding, cache keys, cache bypass, and origin fetch configuration. Those components can form the basis of a self-hosted delivery system, but coordinating nodes and routing around failures requires additional design.

More control also means more responsibility

You can decide which paths to cache, which query parameters affect cache keys, how long to retain particular files, and how to invalidate content after a release.

This control is valuable for teams with specialized release processes or integrations with internal systems. Existing servers, monitoring tools, and operations staff can also make incremental costs easier to manage.

Configuration flexibility brings responsibility, however.

Public images and customer invoices cannot follow the same caching rules. Pages behind a login, authenticated APIs, and payment status data need explicit cache boundaries. A faulty rule propagated across every node can compromise data correctness, not just page speed.

The question is not simply whether the team can install the software. It must also be able to review configurations, deploy changes, and roll them back promptly.

Forwarding requests is only one part of running edge nodes

Long-term operations bring recurring maintenance work:

• A certificate fails to renew on one edge node, causing errors for some users.
• After a site update, different edge nodes still serve different versions of assets.
• A node process is healthy, but the network path to it has severe packet loss.
• Growing logs fill the disk and disrupt caching or proxying.
• A node needs an upgrade, raising the question of how to handle existing long-lived connections.

None of these problems is necessarily difficult, but someone has to keep watching for them.

Failover is a particular concern. Detecting a fault, changing the entry point through the routing system, and getting users onto the new entry point are separate steps. A standby IP alone does not ensure existing connections move without interruption or every user switches immediately.

The value of a self-hosted CDN depends on the team's ability to maintain it over time. Looking only at server rental costs understates the work ahead.

What changes when the site is under attack?

At modest traffic levels, both a simple proxy node and a full protection platform may deliver pages successfully. Under attack, the question expands from whether the software can process requests to whether the network has enough capacity to carry legitimate traffic.

Request rate limiting and upstream traffic scrubbing address different problems

Access rules, rate limiting, and identity checks can reduce the impact of abnormal application-layer requests. For example, NGINX's request rate limiting module can limit the processing rate by a specified key and control how bursts are handled.

But a rate limit on a server takes effect only after traffic reaches that server. If the node's upstream bandwidth is saturated first, legitimate requests may not reach it reliably. Changing application rules cannot restore exhausted network capacity.

That is why DDoS protection also requires network resources. In its DDoS resilience architecture guidance , AWS treats edge network capacity, traffic distribution, and mitigation systems as parts of the same design rather than reducing protection to a server-side rule.

You can buy DDoS-protected edge capacity, scrubbing services, and redundant connectivity for a self-hosted CDN too. Those costs belong in the comparison. A standard server with a firewall and an edge node backed by upstream mitigation are not equivalent resources.

Protection capacity matters, but so does usability during an attack

A page loading during an attack is only the starting point.

An online store still needs logins, order lookups, and payments to work. A game needs players to join sessions, stay connected, and reconnect. An AI proxy API needs to authenticate requests, stream responses, and complete them within a reasonable time.

If every anomaly is handled by making verification stricter, you can create another failure: attack traffic falls, but legitimate users cannot complete their tasks either.

For example, several real users may share one public egress IP. An overly low per-IP rate limit can block them together. An interactive challenge that works in a browser may not work for an API client.

When evaluating a DDoS-protected CDN, describe how your application sends requests, its normal peak traffic, and its critical APIs so policies can reflect real usage. A self-hosted setup needs the same work, but your own team will largely own rule design, false-positive analysis, and ongoing adjustments.

Both approaches need to protect the origin

The origin is where the website's application, data, or services actually run. Placing a CDN in front of it does not automatically close its existing public entry point.

Old hostnames, historical DNS records, overlooked IPv6 addresses, or other services can still point to the origin and let attackers bypass the CDN. Restrict access to the origin according to the actual architecture, and verify that requests come from the intended proxy service.

Distinguish access control from bandwidth protection: a firewall rejecting requests does not mean attack traffic is no longer consuming the upstream link. If the origin is exposed and lacks network-layer protection, consider changing its public entry point or adding upstream mitigation.

Origin protection should be part of deployment whether you build the CDN or buy a service.

For users in Mainland China, assess performance across the entire path

When choosing a CDN for a site hosted outside Mainland China, it is tempting to start by asking how many Hong Kong edge locations it has.

Location matters, but a user's request also traverses carrier networks, cross-border links, the edge entry point, and the path from the edge to the origin. A geographically close location can still perform poorly if it is congested during evening peak hours.

With a self-hosted CDN, you must procure and combine these network routes yourself. With a managed service, find out which routes the provider offers and which resources your plan actually uses.

CDN07, for example, emphasizes Hong Kong edge locations and connectivity for users in Mainland China in its DDoS-protected CDN service , with options to configure its edge footprint, bandwidth, and security policies. For a site hosted outside Mainland China and serving users there, this lets you evaluate the delivery path alongside protection requirements.

Validate actual results with your own application. In particular, test two different kinds of requests.

For cacheable static assets, measure how well the edge serves content directly.

When images, scripts, and public downloads hit the cache, they reduce origin requests.

Dynamic requests that require real-time processing need end-to-end measurement. A faster homepage does not prove that logins, orders, user data, or model calls are faster. Their performance also depends on the path to the origin, application processing, and upstream services.

For a basic first check, send requests from a network your users actually use. The following command works on Linux, macOS, or WSL with curl installed. Replace the example URL with your own test page:

curl --silent --show-error \
  --output /dev/null \
  --connect-timeout 10 \
  --max-time 30 \
  --write-out 'HTTP=%{http_code}\nTTFB=%{time_starttransfer}s\nTOTAL=%{time_total}s\n' \
  'https://example.com/'

Here, `TTFB` is the elapsed time from the start of the request until the first byte arrives, and `TOTAL` is the total time for the operation, both in seconds. curl's documentation of its timing variables also makes clear that time to first byte includes connection setup and server processing. It is not simply the time spent by the origin application.

Check that the status code and content are as expected before comparing timings. If the URL redirects, continue testing with the final destination. If you get a 403 or 5xx response, investigate the cause first; a fast error page is not evidence of faster delivery.

This command requests one URL. It does not load all page images, run JavaScript, or capture the full experience of game reconnections or streaming AI responses. Use it for a basic comparison, then test critical user actions.

Tests for users in Mainland China should cover key provinces and carrier networks, including business hours and evening peaks. Records of slow requests, timeouts, and failures are more useful than a single best-case result.

Compare the full cost of infrastructure and operations

The most visible self-hosting costs are servers and bandwidth. For a managed DDoS-protected CDN, the monthly plan price is easiest to see. Comparing those figures alone leaves out much of the cost on either side.

For self-hosting, account for edge nodes, connectivity, upstream protection, spare capacity, monitoring and logging, software licenses, and staff time for maintenance and incidents.

For a managed service, check how much legitimate traffic or bandwidth the plan includes, whether it limits requests, concurrent connections, or hostnames, and what happens when attacks exceed the agreed protection scope.

Ask separately about attack mitigation capacity and bandwidth for legitimate traffic.

The first describes the scope of attacks the service can address under specified conditions. The second affects how much capacity remains available to users on an ongoing basis. A large mitigation figure cannot substitute for a clear explanation of application capacity.

The team's current stage also matters.

Existing infrastructure and operations staff make self-hosting worth evaluating

If you already have reliable connectivity, users are concentrated in a few regions, most content can be cached, and staff can maintain the edge nodes, self-hosting may offer useful configuration flexibility.

Such teams can use existing resources and tune caching and delivery to the application. They can also add professional DDoS protection incrementally; self-hosting and specialist mitigation can work together.

Plan ahead for traffic growth, sustained attacks, and edge failures. Can your current team and budget keep up?

Under attack and short on operations staff? Managed service may fit better

Other sites have a different reality: developers are focused on application features, site owners handle operations and customers, and only after an attack does someone scramble to contact a data center, change rules, or move the entry point.

In that situation, recovery depends in part on whether the provider helps diagnose problems, adjust protection, and clearly explain charges and responsibilities.

CDN07's DDoS-protected CDN service for domains without an ICP filing includes DDoS and HTTP flood protection and lists WebSocket support. Its published onboarding options also include registration without identity verification and USDT payments, which may be relevant to projects hosted outside Mainland China with those account and payment requirements.

For these teams, the question is whether one service can cover connectivity, protection, and day-to-day support, reducing the need to coordinate separate providers. Test the service with real application traffic before buying long term. Check normal access, long-lived connections, false positives, and the billing scope.

You still need to maintain your own authentication, database, application capacity, and backups after adopting the service. Clear ownership on both sides makes ongoing operations easier.

A hybrid setup can also work

Having an existing self-hosted cache or gateway does not mean you must remove it all to add DDoS protection.

You could retain useful application-specific configurations, put a protected entry point in front, or move only some hostnames to the managed service. With two proxy layers, recheck cache rules, forwarding of the real client IP, certificate validation, and timeouts to avoid conflicts.

Keep each layer only if it has a clear purpose. An architecture that avoids duplicate work and makes faults easier to isolate will be easier to maintain over time.

Frequently Asked Questions

If I build a CDN without an ICP filing, do I still need DDoS protection?

It depends. Self-hosting determines who builds the edge and proxy system. Protection still depends on the upstream network, edge resources, and security policies. Teams with existing mitigation infrastructure can integrate it themselves; ordinary edge servers need a separate assessment of their ability to withstand attacks.

Is a managed DDoS-protected CDN always faster than a self-hosted CDN?

No. Performance depends on the actual network routes, where users are located, cache behavior, and the path to the origin. A well-designed self-hosted setup can also be fast. Compare the same application over the same networks at similar times.

Are a few servers in different regions enough to make a CDN?

They can form the basis of a multi-location proxy or delivery system. Long-term operation also requires routing, health checks, cache management, certificate maintenance, monitoring, and incident response. Node count is only one factor.

Can games and AI APIs use the same protection settings as a standard website?

They should not use identical settings by default. Website assets, APIs, and long-lived connections behave differently, so design verification and rate limits separately. If a game uses its own TCP or UDP protocols, confirm that the service supports them. WebSocket support in an HTTP CDN does not imply coverage for every game protocol.

Do I still need to protect the origin IP after buying a DDoS-protected CDN?

Yes. Reduce origin exposure and restrict bypass access. The CDN protects traffic that passes through its mitigation path; the origin's remaining public entry points, old DNS records, and other services need separate checks.

Before choosing, decide who will keep the site available

Each approach fits different circumstances. Keep four points in mind:

• Self-hosting provides more control and full responsibility for maintenance.
• DDoS protection requires both network resources and security policies. Installing proxy software is only one part.
• For users in Mainland China, test the delivery path, origin connectivity, and evening peak performance together.
• Compare costs on the same basis: capacity for legitimate traffic, attack mitigation, and staff time.

If you have the team and resources, start by validating a small self-hosted deployment. If the site is already being attacked and you want to reduce the work of maintaining connectivity and protection, include managed options such as CDN07's DDoS-protected CDN for domains without an ICP filing in your evaluation.

Share where your users are, where your origin is hosted, which protocols you use, normal peak traffic, and any attack history. That will lead to a more useful long-term choice than asking only, “How much does it cost, and how many gigabits can it mitigate?”