Even though you've switched nodes, refreshed the cache, and replaced files in the CDN console, you still see old content when accessing the site, as if the CDN hasn't taken effect. In this situation, many people's first reaction is that the DNS cache hasn't been refreshed, so they run various cleanup commands, refresh the browser cache, and modify the DNS server, but still can't see the updated content immediately. To understand the root cause of this confusion, you need to understand the working principle of CDN, the DNS resolution mechanism, browser caching strategies, and the synchronization speed of nodes in different regions.

　　While seeing old content after switching CDN nodes can indeed be related to DNS caching, in many cases it's not a DNS problem, but rather due to reasons such as unsynchronized caches at different layers of the CDN, outdated origin pull strategies, residual local browser cache, and node switching delays. To completely solve this problem, you need to check the CDN caching chain layer by layer and understand which links might cause old content to be retained. To determine if it's caused by DNS caching, you can first understand the role of DNS in the CDN. Most CDN platforms use CNAME to point your domain name to the CDN's access point, for example:

www.example.com   CNAME   xxx.cdnprovider.net

　　When a user visits a website, DNS resolves to the CDN's dispatch address, which is the IP address of the nearest node. However, the node assignments within the CDN are usually handled automatically by the CDN platform through intelligent scheduling, not by changing the node assignments via DNS. Therefore, even if you switch nodes on the CDN platform, DNS still returns only the CDN's entry point, not the specific node itself. In other words, DNS is responsible for "bringing users into the CDN network," but which node the CDN assigns the user to is determined by the CDN's load balancing system, not by DNS records. Therefore, when you see old content after switching CDN nodes, it's usually not due to a DNS cache not being refreshed, because DNS doesn't control the details of node switching.

　　To understand the real reason why the CDN displays old content, you should first understand the CDN's caching layers. CDNs generally have four caching sources: browser cache, local node cache, regional center node cache, and the CDN's origin server caching strategy. On the browser side, caching strategies are influenced by headers such as Cache-Control, ETag, and Last-Modified. Even if the CDN node cache has been updated, if the browser is still using strong caching or conditional caching, it may continue to display old content. Many sites, due to incorrect response header settings, allow browsers to retain old versions for extended periods, leading to inconsistent user experiences.

　　At the CDN node level, even if you "switch nodes," cache synchronization between nodes in different regions is not real-time. Most CDNs handle cache updates independently by region. When a node in one region has cleared its cache, another region may still retain the old cache, especially in more remote network areas. If a user accesses the site through a ISP, browser, DoH (Domain-Oriented Hierarchy), proxy, or enterprise gateway, they may be routed to different nodes, and the cache status of these nodes may not be consistent.

　　Another common reason is that cache refresh in CDN platforms does not take effect immediately. Even if the platform indicates "refresh successful," it can still take several minutes to over ten minutes to fully extend to all nodes. This is especially true when the cached objects are large, the number of nodes is vast, or cross-regional caching policies are not synchronized, resulting in significant delays in cleanup speed. For some low-frequency nodes, the cleanup time may be even longer. If you still see old content after switching nodes, it's very likely that the CDN refresh hasn't completed on all nodes.

　　The origin cache policy can also cause old content to persist. If "origin cache" is enabled in the CDN settings, or the CDN origin cache policy is set to "do not expire based on origin content," then even if the node cache is cleaned up, the CDN may still re-cache the old content based on the cache headers set by the origin server. Many sites have similar headers set in their origin server Nginx:

add_header Cache-Control "public, max-age=86400";

　　This causes the CDN to continue caching the content for 24 hours after re-fetching, meaning you won't see the new content immediately even if you switch nodes.

　　Sometimes, the CDN's intelligent scheduling mechanism might keep you on an old node due to network preferences, ISP traffic distribution, TCP session reuse, and historical access records. For example, if you just visited an old node, that node might still have your active TCP or TLS session, and the browser might continue to reuse that connection. Therefore, even if you "switch nodes," you'll still be accessing the old node's content. To avoid session reuse, try accessing the site in incognito mode, on different devices, and under different network conditions to see if the old content still appears.

　　Another easily overlooked reason is that the CDN determines cache hits based on the headers or query parameters carried in the user's request. For example, one of your visits might have carried cookies, login status, or parameters. This content might cause the CDN to determine the request as "uncacheable," bypassing the node cache and directly accessing the origin server to obtain the old version of the data. Or, due to inconsistent cache key settings on some nodes, different variations of the same resource might be cached, ultimately presenting old content.

　　In summary, accessing old content after a CDN node switch is not necessarily a DNS caching issue. This is because DNS only guides users into the CDN network; it doesn't control which nodes the CDN uses or determine what content those nodes cache. The real factors causing access to old content primarily lie in the CDN's own caching system, browser caching, origin server pull strategy, node synchronization time, and connection reuse mechanisms. To determine if it's a DNS issue, you can execute the following commands, which will help you check if DNS is still returning the old entry address:

　　Windows system：

ipconfig /flushdns
nslookup www.example.com

　　macOS system:

sudo killall -HUP mDNSResponder
dig www.example.com

　　If the DNS resolution result matches the CNAME provided by the CDN and does not point to the old server IP, then the problem is not DNS caching. For example:

www.example.com.  CNAME  xxx.cdnprovider.net

　　This result proves that the DNS is functioning correctly; accessing older content must originate from the CDN or browser caching layer, not the DNS itself.

　　To ensure new content displays immediately after a CDN node switch, the following methods can be used: Perform a "force refresh cache" in the CDN backend instead of a regular refresh; disable browser caching or use incognito mode; configure critical resources to not be cached or have a short cache; ensure the origin server's response headers do not allow the CDN to cache older content; use curl to force bypass the cache and access the origin server to verify if the content has been updated; test synchronization between nodes in different regions by changing network environments; force a direct connection to the origin server using curl with a specified host to confirm if the origin server provides the new version. For example:

curl -H "Host: www.example.com" http://Origin IP

　　If the origin server's content is still the old version, then it's normal for the CDN to display old content, because the CDN is simply caching the content provided by the origin server.

　　Many times, developers mistakenly believe that the CDN content hasn't refreshed, but in reality, the content on the origin server hasn't been updated successfully either. Only when the origin server returns the correct content, the caching strategy is reasonable, and node synchronization is normal, can the CDN stably display the latest content.

　　Throughout the troubleshooting process, an important principle is not to rely on testing a single device. Testing on different networks, in different regions, with different browsers, using command-line tools (curl/wget), and switching DNS servers can all help determine which layer the problem is at. By checking the CDN caching links one by one, you can accurately pinpoint whether it's a DNS issue or a problem with the CDN node's own cache not being updated.