Tencent Cloud Third-party Top-up Tencent Cloud CDN Cache Purged but Old Content Persists? Cache Analysis

Tencent Cloud / 2026-08-03 18:08:10

If you already hit “purge” in Tencent Cloud CDN and users still see old pages, the problem is usually not the purge request itself. In real operations, this issue is more often caused by one of five things: the origin still serving old content, a second cache layer taking over, the purge scope being too narrow, browser-side caching, or account/billing restrictions interrupting CDN operations.

This article is written for the people who are actually trying to fix the issue today: site owners, engineers, procurement staff, and overseas teams handling Tencent Cloud account setup, KYC, payment, and renewals.

First: identify where the stale content is coming from

Before troubleshooting CDN, answer one question: who is still seeing old content?

Symptom Likely source What to check first
Only your browser shows old content Browser cache or service worker Open incognito mode, hard refresh, disable service worker
Some users in one region see updates, others do not CDN edge propagation / regional cache Check multiple POPs, wait for propagation, purge exact URL and directory
Images updated, HTML still old Different cache rules for HTML and assets Check cache TTL, headers, and whether HTML is cached at edge
Purged URL but old version still loads when query string changes Query-string cache key mismatch Review cache key settings and whether origin treats parameters differently
Purged CDN but app data is still old Origin/app/database cache Check application Redis/Memcached, reverse proxy, or object storage versioning
Purge request fails or is delayed Account, KYC, billing, or risk-control restriction Check account status, verification, balance, and API permissions

The most common reason: you purged the edge, but the origin still serves old content

This is the mistake I see most often. A team updates a file on the origin, then purges the CDN, but the file on the origin was never really replaced—or it was replaced in one location only.

Typical examples:

  • The deployment uploaded a new HTML file to one bucket or server, but the CDN origin points to another path.
  • An object storage file was overwritten, but the application still references an older signed URL.
  • The CMS updated the page content, but a reverse proxy in front of the CMS cached the older response.
  • The page is dynamically assembled from database content, and the database replica lags behind.

Practical check: request the origin directly, bypassing CDN, and compare the response headers and body with what the CDN returns. If origin is old, purging CDN will not fix it.

When purge “works” but users still see stale pages

In production, “purge all” sounds decisive, but there are four ways old content can survive anyway.

1) The browser still has the file

HTML, JS, CSS, images, and service-worker assets may be cached by the browser independently of CDN. This is especially common on SPA sites and PWA apps.

What to do:

  • Hard refresh and test in incognito mode.
  • Clear service-worker cache if the site uses one.
  • Check response headers like Cache-Control, ETag, and Last-Modified.

2) You purged the URL, but not the real file path

If your site serves content through multiple URLs pointing to the same asset, purging one path may not invalidate the others. Query parameters can also create separate cache keys depending on your CDN rules.

Example: you purge /news/latest.html, but users access /news/latest.html?v=2. If the cache key includes query strings, the old object can remain alive under a different key.

Operational fix: review whether the CDN cache key ignores or includes query strings, and purge all URL variants that users can reach.

3) The CDN edge updated, but another layer still sits above it

Some sites add a WAF, reverse proxy, load balancer, or regional gateway in front of CDN. In that setup, the purge only affects one layer. The other layer may still return the old response.

Check the full path:

  1. Tencent Cloud Third-party Top-up Browser cache
  2. ISP / mobile network cache
  3. Front-door proxy or WAF
  4. CDN edge
  5. Origin proxy
  6. Application cache
  7. Database / object storage

4) Propagation is not instant everywhere

Even after a successful purge API call, different edge nodes may refresh at different speeds. In normal operations, small changes propagate quickly, but during high traffic, regional load, or complex cache rules, some users can still see stale objects for a while.

Practical advice: if only a portion of users is affected, do not assume failure immediately. Verify across several regions and network operators before escalating.

How I would analyze it in production: a short workflow

  1. Check the origin directly. If the origin is old, fix deployment first.
  2. Tencent Cloud Third-party Top-up Compare CDN headers. Look for cache hits, remaining TTL, and edge status.
  3. Tencent Cloud Third-party Top-up Test multiple URLs. With and without query strings, HTTP and HTTPS, mobile and desktop.
  4. Test from different networks. Home broadband, mobile data, and a foreign VPN exit node if your audience is international.
  5. Check account status. If purge APIs or config changes are failing, billing/KYC/risk control may be blocking operations.
  6. Re-purge the exact asset set. Not just the page shell, but all CSS/JS/image dependencies.

Account purchase matters more than many teams expect

For Tencent Cloud CDN, troubleshooting is not only technical. In cross-border projects, I often see delays caused by account onboarding, identity verification, or payment failure—especially when the team buys the account through an overseas subsidiary or a local contractor.

If the account is not fully activated, the CDN may still look “available” in the console, but real operational tasks such as API purge, configuration updates, or domain addition can be limited or delayed.

Which account setup is safer for real operations?

Scenario Best account type Main advantage Main risk
Small overseas team testing CDN before launch Individual or small-business account, if allowed in your region Fastest activation Lower quota, more scrutiny on unusual usage
Company operating a commercial website Enterprise-verified business account Better for billing, renewals, and compliance More documents required, longer approval time
Agency managing multiple client domains Business account under the real legal entity Cleaner ownership and invoice flow Need clear authorization for each domain/project
Short-term campaign site Prepaid / funded account where available Easy to control spend Renewal lapses can break CDN operations suddenly

Identity verification (KYC): the failure modes that slow CDN work

Most KYC issues are not “document missing”; they are mismatch issues. Tencent Cloud risk control commonly looks for consistency across identity, payment method, company information, and usage behavior.

Common reasons verification or approval gets stuck:

  • Name mismatch between account holder and cardholder/company documents.
  • Business registration documents do not match the domain ownership or website content.
  • Repeated registration attempts from the same device, IP, or payment instrument.
  • Use of a proxy/VPN during registration that does not fit the claimed business region.
  • Unclear website content, especially for finance, gaming, adult, or cross-border commerce.
  • Incomplete authorization letter when a third party manages the account.

Operational tip: if you know you will need production CDN changes quickly, finish KYC and billing setup before you migrate traffic. Do not wait until a cache emergency to discover that the account cannot pass review.

Payment methods and why they affect cache troubleshooting

It sounds unrelated, but payment method often decides whether your CDN remains usable during a critical deploy. An unpaid or suspended account can block configuration updates or limit purge operations, which leads teams to misdiagnose a “cache problem” that is actually a billing problem.

Payment method Best for Pros Common problems
Credit / debit card Fast setup and small-to-medium usage Quick activation, simple renewals Declines due to bank fraud filters, overseas transaction blocks, or cardholder mismatch
Corporate bank transfer / wire Companies with procurement controls Cleaner audit trail, easier for finance teams Slower funding, manual reconciliation, possible temporary service risk while waiting
Prepaid balance / wallet Teams that want strict cost control Easy budget cap, predictable spend If balance runs out, services may stop or config changes may fail until topped up
Local payment options Region-specific accounts Lower payment friction in supported markets Availability varies by entity type and country

My recommendation for overseas teams: if you expect frequent CDN purges, release cycles, or traffic spikes, set up a payment method that does not require manual approval every time. The cheapest payment route is not always the safest operational choice.

Tencent Cloud Third-party Top-up Renewals: the hidden cause of “cache issues”

When CDN service is near expiration, teams often notice inconsistent behavior: some assets still load, others do not, and purges start failing. This is usually because billing status, quota, or service entitlements are changing in the background.

Things that happen in real projects:

  • The card on file expires, renewal fails, and the team discovers it only after a deployment.
  • Prepaid balance is exhausted during a holiday or weekend.
  • Finance delays invoice settlement, causing service restrictions right when content must be refreshed.

Practical rule: keep enough balance or a valid payment method to cover at least one full deployment cycle plus a buffer. If your site depends on rapid invalidation, do not let billing become the bottleneck.

Risk control and compliance reviews: how to avoid false alarms

Tencent Cloud may flag unusual account behavior, especially for new accounts or cross-border usage. This does not always mean the account is blocked permanently. Often it is a manual review or a temporary restriction triggered by behavior that looks inconsistent.

Behaviors that often trigger review

  • Registering from one country but funding with a card from another country.
  • Tencent Cloud Third-party Top-up Creating multiple accounts with similar company names or domains.
  • Tencent Cloud Third-party Top-up Making large one-time top-ups immediately after registration.
  • Pushing many purge requests in a short period on a fresh account.
  • Serving content in regulated industries without complete supporting documents.

How to reduce the chance of being delayed

  • Use real, consistent entity data across registration, KYC, payment, and domain ownership.
  • Keep the website content aligned with the declared business type.
  • Tencent Cloud Third-party Top-up If a third party manages the account, prepare authorization documents in advance.
  • Do not rotate cards, emails, or IPs during onboarding unless there is a real operational reason.

In practice, the fastest way through review is not to “argue” with risk control. It is to make your account look like a normal business account with a normal operating pattern.

What to do if purge keeps failing on a working account

If the account is active and verified but the content still remains stale, use this order:

  1. Confirm the origin changed. View the file or page directly at origin.
  2. Use the correct purge type. Purge the exact URL for a single file, or purge the directory if many files share the same path.
  3. Invalidate dependent files. If HTML changed, also purge linked CSS and JS assets.
  4. Tencent Cloud Third-party Top-up Check cache key rules. Query strings, cookies, and headers may create separate variants.
  5. Look at headers. Age, X-Cache, and Cache-Control tell you whether the response is still coming from cache.
  6. Test from another region. Sometimes your local network is the only stale path.

If you are dealing with a high-traffic website, it is often safer to version static assets instead of relying on frequent full purges. For example, use file names like app.2025-01-15.js rather than overwriting a single filename repeatedly. That reduces the chance that users keep seeing an old JS bundle from browser or edge cache.

Cost comparison: purge-heavy CDN operation vs versioned deployment

Teams often underestimate the operational cost of frequent cache invalidations. It is not just the CDN request count. It is also the time lost debugging propagation, the risk of hitting quota limits, and the chance of triggering account review if the behavior looks abnormal.

Approach Direct cost Operational risk Best use case
Frequent full-site purge Usually low per request, but can accumulate in large environments Higher chance of stale-edge complaints and quota pressure Emergency fixes, small sites, rare updates
Targeted URL/directory purge Efficient Requires accurate path mapping Normal release cycle
Asset versioning + long cache TTL Lower operational overhead Needs disciplined deployment process Production sites with frequent JS/CSS changes
Short TTL with no versioning More origin traffic Less stable and often more expensive at scale Temporary testing, not ideal for production

From a real operations perspective, versioned assets usually cost less in human time than repeated purge debugging. For teams with international users, that difference matters more than a small difference in CDN request fees.

Case: e-commerce site updated prices, but old prices kept showing

A client changed product prices at noon and purged the CDN, but some users still saw the old prices for nearly half an hour. The root cause was not the CDN itself:

  • The homepage HTML was cached at the edge.
  • The price widget loaded a JS file that was overwritten without versioning.
  • Mobile users on one carrier stayed on an older browser cache longer than expected.
  • The origin server behind CDN had a reverse proxy with a 10-minute cache TTL.

The fix was a combination of targeted purges, versioned JS filenames, and a reduction in reverse-proxy caching for price-sensitive sections. The important lesson: if the page contains time-sensitive content, purge alone is a fragile strategy.

FAQ

Why does “purge all” still not remove the old page?

Because the stale content may come from browser cache, another proxy layer, a second CDN, or the origin itself. “Purge all” only clears the CDN layer you targeted.

How long should I wait after a purge?

For a small site, changes are often visible quickly. For multi-region traffic or complex cache rules, allow time for propagation and test from multiple locations before concluding it failed.

Is URL purge better than directory purge?

URL purge is more precise and safer for one file. Directory purge is better when a whole path tree changes, such as a release folder or image directory. Use the smallest scope that matches the change.

Can browser cache alone make it look like CDN purge failed?

Yes. This is common on sites using aggressive front-end caching, service workers, or static asset reuse. Always test in incognito mode and on a different device.

What if my Tencent Cloud account is new and purge requests are limited?

That usually points to account maturity, verification status, or risk-control checks. Complete KYC, confirm billing, and avoid unusual burst behavior during the first days of usage.

Does payment failure affect CDN cache updates?

It can. If billing is overdue or the prepaid balance is empty, some configuration changes or purge-related operations may stop working. That is why billing status should be part of cache troubleshooting.

What payment method is safest for a business account?

The safest method is the one that matches your legal entity and stays stable over time. For many companies, that means a corporate card or bank transfer setup with clear ownership and renewal responsibility.

What documents usually help if compliance review is triggered?

Business registration documents, domain ownership proof, a clear company website, and authorization letters for third-party operators are the most useful. Keep the account name, payment name, and business documents consistent.

What I would do if I had to fix this today

  1. Check the origin directly and confirm the new file is really there.
  2. Open the page in incognito mode from another network.
  3. Purge the exact URL plus all dependent JS/CSS assets.
  4. Review cache headers and query-string behavior.
  5. Confirm the Tencent Cloud account is verified, funded, and not under review.
  6. Switch high-change assets to versioned filenames so the same problem does not return next week.

If your CDN purge looks successful but old content remains, the fix is usually not “purge again.” The real answer is to locate the cache layer that still owns the response, then remove dependency on that layer for future releases.

TelegramContact Us
CS ID
@cloudcup
TelegramSupport
CS ID
@yanhuacloud