Has CDN Acceleration Taken Effect? How to Check After Integration

The backend shows “Normal,” and the DNS settings were changed according to the tutorial, but when the website is opened, it doesn’t seem to be much faster.

This uneasy feeling is common after setting up a CDN. You’ve spent the money and made the settings, so you naturally want to know whether requests actually go through the CDN and whether the cache is being used.

To determine whether CDN acceleration is working, you can follow a four-step check:Whether the domain is correctly integrated, whether requests go through the CDN, whether the cacheable resources hit the cache, and whether actual access performance has improved.

These four items need to be considered separately. If the website opens, it might still be connecting directly to the origin server; if an image shows a cache miss, it might simply be because the current edge node is fetching that file for the first time. Drawing conclusions from only one symptom can easily lead you to fix the wrong thing.

Start by finding a specific resource and tracing it through from start to finish. This is more likely to give you an answer than repeatedly refreshing the homepage.

Before checking, prepare a public static image.

Pick a normal image that the website is currently using. The requirements are simple: no login required, stable content, a moderate file size, and based on your configuration it should already be cached by the CDN.

Write down its full URL, for example:

https://static.example.com/images/cdn-check.jpg

This is a demo URL. Replace it with your own real image URL when you perform the check.

First, open it once in your browser to confirm that the expected image is displayed. Don’t test with a URL that doesn’t exist, otherwise what you see later may just be a 404 page or an error cache.

For now, don’t choose the shopping cart, user center, login APIs, or download links that change their signature each time. These requests have their own caching requirements, and using them to determine whether the CDN as a whole is working can lead you down a rabbit hole.

Next, check using the same domain and the same image. Don’t change the file name or add random query parameters during the process.

First, look at DNS resolution: does the domain that users visit resolve to the correct destination?

Return to the CDN console and verify that the CDN domain you added matches the domain actually used by the website.

For example, if the domain added in the console isstatic.example.com, but the images on the webpage are still requestingwww.example.com/images/. Even if the former is completely correct, the image will not automatically adopt the new domain.

This situation can look like “the CDN isn’t working,” but in reality you first need to check the page references or the resource domain configuration.

For products that use CNAME integration, you can query the alias record of the CDN domain. In Windows Command Prompt, run:

nslookup -type=CNAME static.example.com

On macOS or a Linux environment with dig installed, run:

dig static.example.com CNAME +noall +answer

Compare the query result with the CNAME target assigned by the CDN console. You should refer to the documentation for the product you are using; don’t just check whether the returned value contains “cdn.” Alibaba Cloud’sCDN CNAME configuration documentationprovides the corresponding integration and verification steps.

If you have just changed the DNS records and some networks still return the old result, first check whether the record on the authoritative DNS is correct, then consider the update time of recursive DNS and local caches. Repeatedly deleting and recreating records will make later comparisons more difficult.

Not all CDNs require you to see a CNAME in public queries. For products that use a proxy or CNAME flattening, you need to confirm according to the corresponding integration method.

Taking Cloudflare as an example, merely hosting DNS there does not prove that website requests already go through the Cloudflare proxy; you also need to check the proxy status of the target record. For the difference between orange-cloud proxy and DNS-only status, seeCloudflare’s official documentation.

After this step, you have confirmed the domain integration configuration. Next, you need to look at a real request.

Next, look at the request: does accessing this image go through the CDN?

OpenCdnChart’s CDN detection tool, enter the domain used by the image, not just the website’s main domain.

For example, if the image URL starts withstatic.example.com, run the check on that domain first. Use the vendor clues and evidence provided on the page to verify that it matches the service you have integrated.

Automatic detection is suitable as a cross-check. If the result is “suspected,” shows insufficient evidence, or is not recognized, preserve that uncertainty and then inspect the browser request and the vendor’s records.

In the browser, you can do this: open the “Network” panel of the developer tools, request this image again, click the corresponding entry, and check the full request URL, remote address, and response headers. Make sure it hasn’t redirected to another domain and isn’t returning an error page.Chrome network panel documentationexplains the location and meaning of these fields.

Some CDNs include request IDs, cache status, or node-related fields in responses. Looking at these clues together with the console and the official field descriptions is more useful than only watching whether the IP changes.

However, a singleServerfield or a genericX-Cacheheader, taken alone, is still not enough to confirm the vendor. It may come from another proxy layer, or it may have been rewritten. To learn how different pieces of evidence work together, seeCNAME, response headers, and network evidence in CDN provider detection.

If you have access to the CDN’s access logs, you can also check whether this request was logged based on request time, domain, and image path. Logs may be delayed, or full logging may not be enabled; just because you don’t see a log entry right away doesn’t mean the traffic didn’t go through the CDN.

At this point, if the integration configuration, actual request, and vendor-side records all correspond with one another, you have a basis for judging whether the request goes through the CDN.

Next, look at caching: request the same image a few more times.

After confirming that requests go through the CDN, check whether this image is cached as expected.

Use curl to send a normal GET request and inspect the response headers directly. The following command works on macOS and Linux:

curl -sS --connect-timeout 10 --max-time 20 \
  -D - -o /dev/null \
  'https://static.example.com/images/cdn-check.jpg'

In Windows Command Prompt, you can use:

curl.exe -sS --connect-timeout 10 --max-time 20 -D - -o NUL "https://static.example.com/images/cdn-check.jpg"

The command requests the resource, outputs the response headers, and discards the downloaded body.-D -is responsible for showing the response headers,--max-time 20limits this request to a maximum of 20 seconds. For the meaning of the parameters, seethe official curl documentation.

If a 301 or 302 is returned, first checkLocationwhere it points, then continue testing with the final image URL. If a 403, 404, or 5xx is returned, resolve that access problem first; don’t treat an error response as the cache result for the image.

On the same network, repeat the request two or three times a few seconds apart and record each response. Don’t keep adding timestamps to the URL for the sake of a “refresh”; that can change the cache key and make it a different object.

Taking Cloudflare as an example, below are possiblesample response headers, not the actual measured data from this test.

One request might show:

HTTP/2 200
content-type: image/jpeg
cf-cache-status: MISS

Subsequent requests might show:

HTTP/2 200
content-type: image/jpeg
cf-cache-status: HIT
age: 12

According to Cloudflare’s field definitions,MISSmeans it did not find the object in its cache this time and had to fetch it from the origin;HITmeans the resource was found in its cache. A single MISS does not mean your integration has failed, and later requests are not guaranteed to become HIT; the outcome is still affected by cache rules and request conditions.

Agecan be used as a supporting clue, but its source may involve other cache layers, so it alone cannot confirm whose CDN was hit. For the exact status, refer toCloudflare’s cache response documentationfor other vendors, check their respective documentation.

The most valuable thing to save in this round is the sequence of responses for the same resource under comparable conditions. A single successful test only describes that request; it cannot represent that all regions and all resources have already met expectations.

If you never see a cache hit, find the cause first. Don’t rush to set the entire site to be cached.

If the selected image still has no cache hit after repeated requests, check in the following order:

• Whether the full URL stays the same and whether the query parameters have changed.

• Whether the path matches the expected cache rule and is not excluded by a more specific rule.

• Whether the response containsCache-Control: private,no-storeor other directives.

• Whether the request carries login cookies or authentication information, and whether the response sets cookies.

• Whether the cache has just been purged, whether the resource is beyond product limits, or whether the test traffic reached a different cache node.
  

These factors must be evaluated in light of the specific product and rule priorities; a single response header cannot replace a full configuration check.

If you’re testing the homepage or an API, first confirm whether those should be cached at all. For example, Cloudflare does not cache HTML or JSON by default, so a cache miss on these requests doesn’t mean the request didn’t go through its network.See Cloudflare’s default cache behavior.

In addition,no-cachecannot be simply understood as “never stored.” It usually involves revalidation before the cache is used, and its meaning is different fromno-store.MDN’s HTTP caching guideprovides detailed explanations.

At this point, you might think: why not just force caching on all pages? Then it should be fast, right?

Hold off on that. User center, shopping cart, orders, and personalization APIs must show each user the correct content. Sacrificing business correctness just to turn the detection result into a HIT is not worth it.

The goal of acceptance is to cache the public resources that should be cached, and to keep the data correct that needs real-time responses or isolation.

Finally, ask again: has the website actually become faster?

Only after confirming CDN integration and caching behavior should you evaluate the acceleration effect.

OpenCdnChart website speed test, run a test on your actual business domain, and look at the response performance for the regions and ISPs of your main users. Be sure to use the data from the actual test run; the simulated preview on the page cannot serve as a conclusion for your website.

If your visitors are mainly domestic, focus on the networks that domestic real users cover; for an overseas business, look at the relevant regions. A monitoring point very close to the origin performing well does not mean all other visitors will have the same experience.

When comparing results before and after integration, keep the test location, target content, protocol, and cache conditions comparable. Record the test times and keep failed requests. Run several rounds and check whether the changes are persistent, don’t just pick the fastest single result.

Changes on the same page between tests—such as images, compression methods, or scripts—can also affect the results. You should note these changes so that you don’t attribute every improvement to the CDN or blame it for every other problem. For sampling and data interpretation, refer toCdnChart testing methodology.

There is also a scope that needs to be separated: the website speed test provides observations for the corresponding HTTP requests; when a browser opens a full page, it still needs to load images, execute scripts, and complete rendering. How much that particular image has improved needs to be assessed with its own request records; whether the first screen users see is faster also depends on the browser’s full loading process.

If you don’t have speed test results from before the integration, you don’t need to guess at an “improvement percentage.” First confirm the current integration and caching behavior, create a comparable record, and then evaluate the changes brought by subsequent optimizations.

Draw conclusions only for the steps you have actually completed.

After connecting a CDN, there’s no need to describe everything with just two words: “working” or “not working.”

A more useful record is: this domain has been integrated as required, requests for this image go through the CDN, repeated requests show a cache hit, and the connection time for one region still needs further investigation.

In this way, you have a direction for the next step—whether to adjust the DNS records, adjust the cache, or check the access link.

If you are now stuck at the “the backend looks fine but I’m still not sure” stage, start with a public image from the website. Trace its domain, requests, and responses, and keep several records that line up with each other. That will give you more confidence than refreshing the homepage ten more times.