Read cache status headers
HIT, MISS, BYPASS, EXPIRED — the diagnosis half of this workflow.
Open the topicCDN.com.tr Help
Cache keys and purge: why "I purged but it's still old" happens
Every cached object is stored under a key built from the request — scheme, host, path, and query string. A purge only clears an entry when it addresses that exact key. Understanding this one idea explains nearly every "purge did not work" case.
Cache, security, WAF, and purge
Cache keys and purge: why "I purged but it's still old" happens
Every cached object is stored under a key built from the request — scheme, host, path, and query string. A purge only clears an entry when it addresses that exact key. Understanding this one idea explains nearly every "purge did not work" case.
Panel path
- Management Panel
- CDN Accounts
- Purge Management
Prerequisites
- The path must belong to the selected account.
- Diagnose with the exact public URL (scheme + host + path + query), not a summary of it.
Use cases
You purged a path after a deploy, but a visitor still reports the old version. In almost every case the purge worked — it just cleared a different cache entry than the one the visitor is being served (a query-string variant, or their own browser cache).
Workflow
- Get the exact URL the visitor sees stale — including scheme (https), host (www or apex), and any query string. "The products page" is not enough; /products and /products?page=2 are different cache entries.
- Check what the CDN actually did:
curl -Ithat exact URL and readX-Proxy-Cache-MT. HIT means the CDN served a cached copy; MISS or BYPASS means the CDN is not what is serving the old content. - Purge with the scope that matches the problem in Purge Management: a single exact path for one URL, a folder purge for everything under a path, or a full-account purge when structure changed everywhere.
- Verify the same way you diagnosed: request the exact URL again and expect MISS (fresh from origin) then HIT. If your own browser still shows the old page, hard-refresh — the CDN cannot reach into browser caches.
Checks
- Query strings create separate entries: /banner.jpg and /banner.jpg?v=2 are cached independently. Purging one does not touch the other.
- Scheme and host are part of the key: http vs https and www vs apex are different entries. Purge the canonical form your visitors actually use.
- Mobile and desktop share one cache entry — a stale report only from phones is almost always the visitor's own browser cache.
- A purge clears the CDN, never a visitor's browser cache. What limits that last window is the browser TTL in your cache rules, not another purge.
Frequently asked questions
The purge said success, but the page is still old — did it fail?
Almost certainly not. Diagnose with curl -I against the exact URL: if you see MISS on the first request after the purge, the CDN entry was cleared and the stale copy is elsewhere — another variant of the URL, or the viewer's browser cache.
I purged /products but /products?page=2 and /products?utm_source=x are still old.
Each query-string combination is its own cache entry. Purge the folder/prefix so every entry under the path is cleared, or purge the busiest variants explicitly.
Do I need to purge after every deploy?
If your HTML is cached with a long TTL, yes — purge the changed paths as a deploy step. The purge API and cdnctl exist exactly for this; a deploy script that ends with a scoped purge never has this class of problem.
When should I use "purge all"?
When URL structure changed across the site (a migration, a redesign) and path-scoped purges would be a long guess-list. Use it deliberately: right after, every request is a MISS until the cache re-warms, so your origin briefly takes full traffic.