Clear or bypass an Nginx cache safely

First identify the cache serving the stale response. Nginx proxy_cache and fastcgi_cache use configured cache paths. Browser caches, CDN caches, and PHP OPcache are separate systems. Reloading Nginx alone does not invalidate a response cache.

Find the active cache and its scope

sudo nginx -T

Inspect proxy_cache_path, fastcgi_cache_path, the cache zone used by the affected location, and its cache key. Keep the configuration dump private. Confirm the directory is dedicated to this cache before considering file removal; a generic /var/cache/nginx assumption is insufficient.

Log or temporarily expose $upstream_cache_status and request the same resource repeatedly. Confirm whether Nginx actually serves a HIT, and compare the origin response. Purging the wrong layer changes nothing.

Invalidate all entries deliberately

For a planned full reset, one reversible approach is to configure a new cache directory and a new keys_zone name, point the relevant location at that zone, then test and reload. Preserve ownership and capacity. Keep the old directory until old workers have exited and no configuration uses it, then remove it through the normal maintenance process.

Changing a version component in proxy_cache_key is another way to stop selecting old entries. The old files remain until normal eviction or later cleanup.

Deleting files from a confirmed cache directory can invalidate entries, but it is not an atomic purge while workers are reading and writing. Cache managers do not make arbitrary recursive deletion free of races or operational cost. Plan for cold-cache traffic and avoid broad deletion commands against an unverified path.

Bypass is not purge

A bypass request fetches from the origin without reading an existing cached response. It does not necessarily delete the old entry, and bypass alone does not prevent storing the new response.

A tightly scoped operational configuration can recognize a request header:

# http context
map $http_cache_control $skip_cache {
    default 0;
    ~*no-cache 1;
}

# Inside the existing proxied location:
proxy_cache_bypass $skip_cache;
proxy_no_cache $skip_cache;

curl -H 'Cache-Control: no-cache' https://example.com/page

Both directives are shown so the diagnostic request neither reads nor writes this cache. Unrestricted client bypass can increase origin load; decide where this capability belongs. Merely sending the header without matching configuration does not guarantee bypass.

For targeted purging, use the interface supported by the installed NGINX Plus release or a reviewed third-party module. Their directive syntax differs. Restrict purge access and calculate the exact cache key, including host, query arguments, and any configured variation.

Check other caches

If no response-cache directives apply, do not assume Nginx has a page cache to clear. Other features such as open_file_cache have different semantics.

FAQ

Why is content still stale after invalidation?

Check the browser, CDN, another proxy instance, and the origin response. Verify that the test selects the intended host and location.

How can I bound disk use?

Set max_size and inactive on the cache path. Cleanup is performed by the cache manager; these are not a guarantee that instantaneous disk use can never exceed a threshold.

What should I watch after a purge?

Compare HIT/MISS rates, origin requests, response time, and application/database load. A successful content refresh can still overload the backend.

References: proxy cache directives, FastCGI cache directives.