How to Verify Alibaba Cloud CDN Is Working After Integration: Domain and Cache Check Steps

The domain in the Alibaba Cloud CDN console already shows “Running normally,” and the CNAME has been configured as instructed, but the website does not seem to change noticeably when opened.

At this point, two misjudgments are most likely: one is to assume the CDN is already in effect just because the website is accessible; the other is to see the first request returnMISSand conclude that the CDN is not working at all.

In fact, “the domain is connected,” “requests pass through the CDN,” and “the asset hits the cache” are three different things:

Therefore, to confirm whether Alibaba Cloud CDN is in effect, you cannot rely on a singlepingtest, nor can you just open the homepage in a browser. A more reliable approach is to choose a specific accelerated domain and a static file that should be cached, and check all the way from DNS to HTTP caching.

Before checking, choose the right test target

Suppose the website uses the following address to load an image:

https://static.example.com/assets/logo.png

When testing, replace it with your own real address. This file should ideally meet the following conditions:

• It can be accessed without logging in;

• Its content is stable and is not dynamically generated on every request;

• A cache rule is configured for it in Alibaba Cloud CDN;

• The URL does not contain constantly changing timestamps, tokens, or random parameters;

• It returns200normally, rather than a redirect page or error page.

Homepages, login endpoints, shopping carts, and user centers are usually not ideal cache test targets. Even if they pass through the CDN, they may still go to the origin on every request by design. Testing with dynamic pages can easily lead to the result of “the setup is normal and caching is working as configured, but it always looks like MISS.”

You should also confirm that the test domain is the accelerated domain added in the console. What is configured in the console isstatic.example.com, while web assets are still loaded fromwww.example.com. Even if the former is in effect, it will not automatically accelerate the latter.

Step 1: First check the domain status in the Alibaba Cloud CDN console

Go to “Domain Management” in the Alibaba Cloud CDN console, find the target accelerated domain, and first verify three things:

1. The accelerated domain exactly matches the hostname actually requested by the business;

2. The domain is in normal running status, rather than configuring, disabled, or in an abnormal review state;

3. Copy the CNAME value assigned to the domain in the console for later verification of DNS results.

Here, pay particular attention to the difference between “domain running status” and “CNAME status.”

The domain running normally means this accelerated domain can provide service on the Alibaba Cloud CDN side; only when the CNAME shows as configured has Alibaba Cloud detected the corresponding DNS pointing. If only the former is completed and public DNS is not switched to the CNAME, real users may still connect directly to the origin.

Alibaba Cloud’s officialConfigure CNAME documentationalso calls CNAME configuration the last step in activating CDN service: DNS first points the accelerated domain to the CNAME assigned by Alibaba Cloud, and then the CDN scheduling system returns the IP of a suitable edge node.

However, console status is suitable for quick verification and should not replace real resolution queries. Especially when ISP-specific DNS resolution is used, the console’s detection location may differ from the region where your users are located.

Alibaba Cloud documentation also notes that if CNAME is configured only for regions outside mainland China, the console may still show “To be configured,” but acceleration service in the corresponding regions is not necessarily affected.

Step 2: Use nslookup or dig to check whether the CNAME is in effect

Run the following in Windows Command Prompt:

nslookup -type=CNAME static.example.com

On macOS or Linux, you can run:

dig static.example.com CNAME +noall +answer

The returned CNAME target should match the value assigned in the Alibaba Cloud CDN console. An example result might look like:

static.example.com.  600  IN  CNAME  static.example.com.w.kunlunsl.com.

This is only a format example. The actual value is subject to your own console. Do not manually copy the domain in the example.

Then check the full resolution chain and the final IP:

dig static.example.com

When you need to troubleshoot authoritative DNS delegation, you can also run:

dig static.example.com +trace

+traceThis is suitable for troubleshooting whether authoritative DNS and records are correct, but it is not exactly the same as how ordinary users get results through recursive DNS. In actual troubleshooting, you can specify several recursive DNS servers for cross-checks:

dig @223.5.5.5 static.example.com CNAME +short
dig @1.1.1.1 static.example.com CNAME +short
dig @8.8.8.8 static.example.com CNAME +short

The goal here is not to require different DNS servers to return exactly the same edge node IP.

A CDN inherently schedules based on region, ISP, network conditions, and node load, so it is normal for different locations to resolve to different edge IPs. What really needs to be verified is whether the CNAME chain enters the expected Alibaba Cloud CDN scheduling system, rather than still returning origin records or old CDN records directly.

Why does the CNAME work for some people but not others right after it is changed?

DNS records are cached. After a record is changed, some recursive DNS servers and local devices may continue using the old result until the original TTL expires.

According to Alibaba Cloud documentation, adding a new CNAME in Alibaba Cloud DNS takes effect in real time; when modifying a CNAME, the actual wait time depends on the TTL of the original DNS record, and with the default TTL, it may take about 10 minutes. If the domain does not use Alibaba Cloud DNS, the rules of the current authoritative DNS provider also apply.

At this point, do not repeatedly delete and recreate the same record. First query the authoritative DNS and multiple recursive DNS servers separately, and record “who is still returning the old value.”

If only the local machine’s result is stale, you can clear the operating system DNS cache or verify again with a different recursive DNS server. If the authoritative DNS itself still returns the old value, go back to the DNS provider and check whether the record was changed in the correct hosted zone, whether the host record was written correctly, and whether the NS delegation points to the DNS platform currently in use.

Step 3: Confirm that a real HTTP request passes through Alibaba Cloud CDN

A correct CNAME only proves that DNS configuration is basically in place. You also need to send a request for a real asset to see where it ultimately connects and what response is received.

First, use a regular GET request to keep the response headers and discard the body:

curl -sS -D - -o /dev/null \
  --connect-timeout 10 --max-time 30 \
  'https://static.example.com/assets/logo.png'

In Windows, you can use:

curl.exe -sS -D - -o NUL --connect-timeout 10 --max-time 30 "https://static.example.com/assets/logo.png"

Why not usecurl -Ias the only basis?

Because-Isends a HEAD request, and some origin servers, proxy rules, or caching logic handle HEAD and GET differently. Alibaba Cloud’sCache Troubleshooting Guidealso recommends using GET first to verify real cache behavior, with HEAD only as a supplement.

If you also want to record the resolved IP and the timing of each stage, you can run:

curl -sS -D /tmp/aliyun-cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://static.example.com/assets/logo.png'

Thisremote_ipis the IP that actually established the connection for this request. It should be considered together with the CNAME, IP network ownership, response headers, and CDN-side records; do not judge it as abnormal just because an IP differs from last time.

You can also put the accelerated domain intoCdnChart CDN Checkto view public clues such as the CNAME chain, response IP, IP/ASN, and HTTP response headers.

The check results are suitable for cross-validation: if the evidence is consistent, confidence in the judgment can increase; if it shows “suspected” or is not detected, continue checking DNS and the Alibaba Cloud console rather than treating a single automated detection as the final conclusion.

If the page opens, why doesn’t that prove the CDN is already in effect?

Because the origin can already serve the page. Even if DNS has not been switched successfully, users connecting directly to the origin may still see the website normally.

Conversely, if you only seeServer: nginxin the response headers does not immediately mean the request did not pass through the CDN. Origin response headers may be passed through, and CDN-side fields may also be hidden or modified according to configuration.

A more reliable judgment is to make the following evidence correspond with one another:

• The CNAME chain enters Alibaba Cloud CDN;

• This request connects to the expected edge network, rather than a known origin IP;

• Fields related to Alibaba Cloud CDN caching appear in the response;

• Alibaba Cloud CDN logs or monitoring can find the corresponding domain, time, and request;

• Origin access logs show that the request came from the origin fetch path, rather than from a direct client access.

Step 4: Request the same static file repeatedly and check X-Cache

After confirming that requests pass through the CDN, then determine whether caching is working.

Send two or three consecutive requests to the same full URL, without adding random parameters or changing request headers in between:

for i in 1 2 3; do
  echo "request=$i"
  curl -sS -D - -o /dev/null \
    'https://static.example.com/assets/logo.png' \
    | grep -Ei '^(HTTP/|x-cache:|age:|x-swift-cachetime:|cache-control:|expires:|vary:|set-cookie:)'
  sleep 2
done

You may see a change similar to the following:

X-Cache: MISS
Age: 0
X-Swift-CacheTime: 86400

It then becomes:

X-Cache: HIT
Age: 8
X-Swift-CacheTime: 86400

The above is only an illustration for easier understanding. Whether fields appear, their capitalization, and their specific values are subject to the actual response.

According to Alibaba Cloud’s official documentation:

• X-CacheisHIT, which indicates that this request hit the edge node cache;

• X-CacheisMISSor the field does not exist, it usually means this request did not hit the cache, and other information is needed to confirm whether it went to the origin;

• Ageindicates the number of seconds the resource has been cached at the edge node;

• X-Swift-CacheTimeindicates the total allowed cache duration;

• can be used toX-Swift-CacheTime - Ageestimate the remaining cache time for this copy.

First requestMISS, second requestHIT—this is a very common process: the current node does not have the asset the first time, so it fetches from the origin and caches it; only the next identical request is served from the node’s copy.

But do not interpret “two consecutive requests” as meaning that MISS must turn into HIT in every scenario. If the asset is set not to cache, the response contains no-cache directives, URL parameters keep changing, the cache key is affected by request headers, or the two requests actually land on different nodes, the result may continue to be MISS.

To understand these fields more systematically, you can continue reading“How to Read CDN Cache Hits: Understanding HIT, MISS, and Age”.

If It Is Always MISS, Check These Areas First

The tested asset should not be cached in the first place

Dynamic APIs, login pages, order data, and personalized content usually need to go to the origin or be isolated per user. Their always being MISS is not necessarily a fault.

Do not force-cache the entire site just to make test results become HIT. Otherwise, it may cause login state confusion, shopping cart mix-ups, or even let one user see another user’s data.

The origin returned no-cache directives

Check these fields in the response:

Cache-Control: no-store
Cache-Control: no-cache
Cache-Control: max-age=0
Pragma: no-cache

Their meanings are not exactly the same.no-storeusually means not to store the response;no-cacheallows storage but requires revalidation before use. When troubleshooting, do not simply interpret both as “no caching at all.”

If it is a public static asset, fix the response headers and business logic at the origin first. Although Alibaba Cloud CDN provides configurations such as ignoring origin no-cache headers, before overriding them you must confirm that the content does not contain user-related data.

The origin returns Set-Cookie for static files

Alibaba Cloud’s cache troubleshooting documentation notes that when the origin response containsSet-Cookie, the CDN may not cache that response by default.

The safest approach is to stop the origin from setting session cookies for public static assets such as images, CSS, JavaScript, and fonts.

It is not recommended to remove it directly across the entire siteSet-Cookie. Login state, authentication, and shopping carts often depend on it. If it can only be handled on the CDN side, you should also limit it to explicit static asset paths and verify the business impact before going live.

URL Parameters Turn the Same File into Multiple Cache Objects

For example:

/assets/logo.png?t=1720000001
/assets/logo.png?t=1720000002

If parameters are part of the cache key, two requests will be treated as different objects. During testing, first keep the URL exactly the same; in production configuration, distinguish whether parameters truly affect the content.

Analytics parameters may be ignored, but image processing parameters, version numbers, and authentication parameters often must be retained. Globally ignoring all parameters may increase the hit rate, but it may also return incorrect content.

The cache rule does not match the target path

Check which cache rule the target file actually matches, including rule type, directory or extension, priority, cache duration, and conditional rules.

A more specific path rule may override a general rule, and a high-priority “cache for 0 seconds” rule may cause all requests to keep going to the origin.

The configuration has been changed, but edge nodes still have old cached content

Rule deployment and old cache purging are two different things.

Alibaba Cloud documentation states that deploying configuration to all edge nodes usually takes a few minutes; assets already cached under the old policy will not disappear automatically just because the rule was changed.

If you need to verify the new rule immediately, you can perform a URL refresh or directory refresh within the actual scope. Before doing so, assess the origin fetch pressure; in particular, do not refresh the entire site just to test one file. Specific limits and usage should follow Alibaba Cloud’sRefresh and Preload Resources documentationas the authoritative reference.

The two requests landed on different edge nodes

Local network switching, DNS re-resolution, IPv4 and IPv6 differences, and CDN scheduling changes can all cause consecutive requests to reach different edge nodes.

The first node having cached content does not mean the second node necessarily has the same copy.remote_ipand response headers. If the IP changes, do not compare only HIT and MISS; also factor node changes into the judgment.

Step 5: Check Whether Different Regions and ISPs Have All Been Switched

A single request from your own computer only represents the current network, current DNS, and current moment.

If the website serves users nationwide, you should also check resolution and access results for China Telecom, China Unicom, China Mobile, and major provinces.

You can useCdnChart Website Speed Testto perform multi-region tests on the actual accelerated domain or a specific static file, focusing on:

• The response IP resolved in different regions;

• Whether China Telecom, China Unicom, and China Mobile can all access it normally;

• Whether some nodes still connect to old IPs or another CDN;

• Whether there are regional anomalies in status codes, DNS time, connection time, and total time;

• Whether IPv4 and IPv6 show inconsistent access paths.

Different regions returning different IPs is itself normal CDN scheduling behavior.

What truly warrants attention is: some regions still clearly resolve to the origin, an old provider, or an incorrect address; or only one ISP shows concentrated 403s, 5xx errors, certificate errors, and timeouts.

If the switch was just completed, it is advisable to test again after one TTL period and record the time, region, ISP, response IP, and status code. This can distinguish between DNS cache not yet expired and a persistent resolution configuration error.

Step 6: Return to the Alibaba Cloud Console to Check Monitoring and Logs

External requests can already provide a great deal of evidence, but if the site is yours, you can also cross-check with data from Alibaba Cloud.

In resource monitoring, check the target accelerated domain’s access traffic, request count, origin traffic, hit rate, and HTTP status codes.

Alibaba Cloud’sCDN Resource Monitoring documentationdistinguishes byte hit rate from request hit rate: the former focuses on the proportion of bytes served directly by edge nodes, while the latter focuses on the proportion of requests that hit; the two do not necessarily change in sync.

For example, if a site has many small images hitting the cache but a few large files continuously going to the origin, the request hit rate may look decent while the byte hit rate is low. Looking at only one percentage can easily lead to misjudging origin pressure and actual acceleration performance.

Monitoring data usually has a statistical delay, so it is not suitable for confirming a single request from just one second ago. For one-off troubleshooting, first checkcurlresponse and real-time logs, and then look at monitoring curves for trend analysis.

If onboarding succeeds but the website does not get noticeably faster, the problem may not be “whether it is in effect”

Even when the CNAME, request path, and cache hits are all normal, the website may still feel slow. Reasons include:

• The main HTML document still needs to go to the origin, and TTFB is affected by the origin application and database;

• The page contains many third-party scripts, and these assets are not controlled by your CDN configuration;

• Images are too large, JavaScript execution takes a long time, or first-screen rendering is blocked;

• The HTTPS certificate chain, redirects, and connection reuse configuration are not ideal;

• The main users do not match the origin, edge node coverage, or acceleration region;

• The cache hits, but the file size itself has not been optimized.

At this point, you should verify “whether the CDN is connected” and “whether user experience has improved” separately.

For the former, look at DNS, request path, and caching; for the latter, look at DNS, TCP, TLS, TTFB, download, and the entire browser rendering process.

If you need a complete general checking framework, see “Is CDN Acceleration Working? Check It This Way After Onboarding.” If onboarding is confirmed to be normal but TTFB is still high, continue with “What Causes High TTFB? Should You Check the CDN or the Origin First?”

A Table to Determine What to Check Next

Frequently Asked Questions

If the Alibaba Cloud CDN console shows “Configured,” does that necessarily mean it is in effect?

It means Alibaba Cloud has detected the CNAME configuration, which is important evidence, but it is still recommended to usenslookupordigto query the real DNS result, and then send an HTTP request to an actual URL.

ISP-specific DNS resolution, recursive DNS caching, and the business using another domain can all make some users’ access paths differ from the console status.

After the CNAME takes effect, why does ping still return an IP?

Applications ultimately must connect to an IP, so after DNS continues resolving along the CNAME chain, it still gets an A or AAAA record.

pingIt is normal for it to show the final IP. It measures ICMP reachability and round-trip time; it cannot prove whether HTTP caching hits, nor does it fully represent page load speed.

If X-Cache is MISS the first time, does that mean Alibaba Cloud CDN is not in effect?

Not necessarily.

When the current node requests the asset for the first time, it has no copy and may need to fetch it from the origin, so MISS appears. Keep the URL and request conditions consistent and request it a few more times; if HIT appears later, the node has established the cache.

If it remains MISS, then check the cache rule, origin no-cache response headers,Set-Cookie, URL parameters, and whether the node has changed.

Why does testing from another computer turn it back to MISS?

Another computer may use a different ISP, a different recursive DNS, or be scheduled to another edge node. The cache state of different nodes may differ.

Record the resolution results, actual connection IPs, and response headers on both sides to determine whether it is a normal node difference or a configuration anomaly.

After modifying a cache rule, do I need to refresh immediately?

Not necessarily. New rules usually only affect caches formed afterward; old copies can be left to expire naturally.

If the business must see the new content immediately, or you need to verify the new cache key and response policy right away, then perform a precise URL refresh. The broader the scope, the greater the origin fetch pressure; refreshing the entire site is not recommended as a routine testing action.

To check whether Alibaba Cloud CDN is in effect, what is the minimum information to save?

At minimum, save the test time, full URL, region and ISP, CNAME chain, actual connection IP, HTTP status code,X-Cache,Age,X-Swift-CacheTime,Cache-Controland the results of two or three consecutive requests.

If you need to submit a support ticket, also provide the accelerated domain under the Alibaba Cloud account, the affected regions, reproduction time, and relevant logs.

When these records can be connected, “whether the CDN is actually in effect” is no longer a matter of guesswork: DNS hands requests to Alibaba Cloud CDN, real HTTP requests reach the edge network, static assets that should be cached show HIT, and users in multiple regions no longer access the old path—this is a complete, verifiable chain of evidence that it is in effect.