How to Test Whether CDN Acceleration Is Working: Methods for Checking CDN Caching, Nodes, and Access Speed

In day-to-day operations and website performance optimization, you often run into this situation: you've just configured the domain in your CDN provider's console and updated the DNS records, the site seems to load, but you're still wondering: Is the CDN actually working? Is it distributing traffic to edge nodes around the world, or is it still passing requests straight through to your origin server? Is the site faster? Are cache hits happening?

Many site owners and developers who are new to website troubleshooting tend to confuse "DNS resolution is live" with "acceleration is live." This article breaks down CDN status detection, cache hit verification, and performance optimization from the ground up, covering both the underlying network logic and practical troubleshooting methods.

1. What's the difference between a successful CDN setup and CDN acceleration actually taking effect?

Many operations newcomers assume that once the DNS record is updated and the console shows "configured," the CDN is done. But these are two fundamentally different things:

• Successful CDN setup (configuration and resolution layer): This only means you've successfully pointed a CNAME record at the alias address provided by your CDN vendor (through your domain registrar such as Yewsafe, Cloudflare, Alibaba Cloud DNS, DNSPod, etc.), or completed an NS record switch. At this point, the domain resolution path is clear and user requests can be correctly routed to the CDN's scheduling system.

• CDN acceleration taking effect (business and transport layer): This means the HTTP/HTTPS requests users initiate actually land on the nearest CDN edge node, and that node can correctly serve static assets according to your configuration (cache hits), block abnormal traffic, and use the CDN vendor's optimized backbone routes to pull dynamic content — significantly reducing the TTFB (Time to First Byte) and overall page load latency users experience.

Put simply, a successful setup just "paves the road," while acceleration taking effect means "the car is actually driving on the highway and has pre-warmed cache data ready."

2. Five key steps to test whether CDN acceleration is working

To accurately determine whether your CDN is working, you can't rely on "it feels faster." You need to verify it using the following five standard technical steps.

1. Check DNS / CNAME and response IP

First, confirm whether domain resolution has been handed over to the CDN vendor.

Run nslookup or dig in your local terminal:

# Check the CNAME record dig www.yourdomain.com CNAME +short # Or view the full resolution process nslookup www.yourdomain.com

If the response shows that the domain resolves to a CDN vendor-specific subdomain (such as *.kunlun*.com, *.cloudflare.net, etc.), or if pinging the domain returns an IP that is no longer your origin server's real IP, then the DNS layer is successfully in effect.

2. Check HTTP response headers and cache hit status

This is the most direct way to identify the CDN vendor and its operating status. Open your browser's developer tools (F12), switch to the Network tab, refresh the page, and click on the main document or a static asset (such as .js, .css, or an image):

Look for characteristic fields in the Response Headers:

• Yewsafe Anti-DDoS CDN: server: yewsafe, x-yewsafe-cache: HIT/MISS, x-yewsafe-pop: xxx

• Cloudflare: server: cloudflare, cf-ray: xxx, cf-cache-status: HIT/MISS

• Alibaba Cloud CDN: via: xxx, x-swift-savetime: xxx, x-cache: HIT/MISS

• AWS CloudFront: via: xxx.cloudfront.net, x-amz-cf-pop: xxx, x-cache: Hit from cloudfront

As long as you see a CDN provider-specific identifier in the response headers, the request has gone through a CDN node. If the response header shows HIT and the Age field is greater than 0, the resource was served directly from the node's cache without going back to the origin.

3. Multi-region node and network scheduling tests

Testing from just your own computer isn't objective, because the core value of a CDN lies in cross-region, cross-carrier coverage. Users in different provinces and on different carriers (China Telecom, China Unicom, China Mobile) accessing the same CDN domain should resolve to completely different nodes.

The most direct and effective approach is to use Chahu's multi-node website speed test:

Enter your website domain in Chahu, and it instantly calls on dozens of monitoring nodes across every province in China and overseas to run access diagnostics simultaneously:

• Verify node scheduling: Check whether nodes in different regions resolve to different IPs (which confirms smart DNS routing is working).

• Identify localized issues: Check whether a specific carrier (such as China Mobile or China Unicom) has unusually high latency or severe packet loss.

• Pinpoint network blocks: One-click troubleshooting for DNS pollution, TCP handshake timeouts, or edge route packet loss (MTR diagnostics), helping operations teams quickly uncover regional CDN connectivity problems.

4. Analyze network performance metrics (TTFB and connection time)

In your browser's F12 Network -> Timing, focus on two metrics:

• TCP Connection / TLS Handshake: Since CDN nodes are close to users, the TCP three-way handshake and SSL/TLS handshake should be significantly shorter (typically between 10ms and 50ms).

• TTFB (Time to First Byte): If a static asset hits the CDN cache, TTFB should typically complete within tens of milliseconds. If TTFB stretches to hundreds of milliseconds or even seconds, the request is very likely passing through to the origin.

5. Why can't you judge CDN performance with Ping alone?

Many people habitually run ping yourdomain.com to check latency, thinking that if the Ping value drops from 100ms to 20ms, everything is fine.

In reality, Ping uses the ICMP protocol and only reflects basic IP connectivity. Website traffic uses HTTP/HTTPS, which involves complex TCP handshakes, TLS certificate negotiation, header parsing, and data transfer — and ICMP packets cannot reflect CDN node cache hit status at all. Therefore, Ping can only verify smart DNS resolution and node connectivity; it should never be the sole standard for evaluating a website's real load speed.

3. What proper operation looks like and how to locate faults

When your CDN is truly working well and accelerating your site, your overall website performance will show these characteristics: testing with Chahu's multi-node speed test tool, Ping latency in the vast majority of regions nationwide stays under 30ms with virtually no packet loss; origin server CPU and bandwidth consumption drop noticeably; and static assets load instantly.

If your site still isn't faster after enabling the CDN, or you're getting 502/504 errors, it's usually caused by the following issues. We recommend using the Hosts direct-connection method to pinpoint responsibility:

Modify Hosts to bypass the CDN and connect directly to the origin

Edit the hosts file on your local computer to force the domain to bind to your origin server's real IP:

1.2.3.4  www.yourdomain.com

Save, then refresh your browser or verify with curl:

curl -I -H "Host: www.yourdomain.com" http://1.2.3.4/

Use the direct-connection results to quickly determine where the problem lies:

To determine whether CDN acceleration is working, the key is to "check resolution, inspect headers, verify caching, and test across the network." When troubleshooting, never rely solely on a simple Ping value — combine the HIT/MISS status in HTTP response headers and use Chahu's multi-node speed test tool to see the actual origin fetch behavior. Only when traffic is precisely distributed to edge nodes, static assets achieve a high cache hit ratio, and origin server pressure is genuinely relieved can CDN acceleration be considered truly in effect.

Related Q&A

1. The origin logs are full of user IPs—does that mean the CDN isn't being used?
   Not necessarily. When a layer-7 CDN fetches from the origin, the origin usually sees the CDN's back-to-origin node IP, while the real user IP is typically placed in headers like X-Forwarded-For. If Nginx isn't configured with the real_ip module, the logs will show the CDN node IP instead. If you're seeing home broadband IPs from all over the country and no CDN back-to-origin ranges, that's when you should suspect traffic is bypassing the CDN.

2. CNAME on the root domain always fails—is that a CDN problem?
   Most likely not. Root domains usually can't coexist with other records, and CNAME conflicts with MX and TXT are common. Many CDNs have root domains use NS delegation or A/AAAA aliases. Using CNAME on a subdomain is much easier. Before making changes, list your existing DNS records—don't just overwrite them.

3. If dynamic APIs aren't cached, does that mean you can't test CDN performance?
   No. Dynamic requests don't hit the cache, but the CDN can still do nearby TLS termination, long connection reuse, and back-to-origin route optimization. The response headers may not show HIT, but connection establishment time and time to first byte will feel different. Look at APIs and static assets separately—don't use cache hit rate as the only metric.

4. After purging the cache, how do you confirm the update has propagated everywhere?
   Purges aren't instantly synchronized worldwide; each node invalidates gradually. First add a nonexistent parameter to see if it goes back to origin, then request the original URL from multiple regions and watch whether the cache timestamp and hit status change. Preloading works the opposite way—let nodes pull proactively first. URL purge and directory purge have different scopes, so don't mix them up.

5. The same file sometimes HITs and sometimes MISSes—is that normal?
   Yes. Different POP caches are independent, and the cache key may also include query parameters, cookies, Vary headers, and device type. Node eviction, back-to-origin request coalescing, and purge operations all affect it. When testing, keep request headers fixed, avoid random numbers, and test multiple times. If it MISSes long-term, check the cache key and whether the origin response headers allow caching.

6. Once the CDN is live, should the origin only allow CDN back-to-origin traffic?
   Yes. If someone finds your origin IP, they can bypass the CDN and hit it directly, making your caching and protection useless. Configure the origin firewall to allow only CDN back-to-origin IP ranges, use an auth key or custom header for back-to-origin requests, and pair it with a WAF. Vendor back-to-origin ranges get updated, so remember to sync them regularly.