To clear Nginx’s file-backed cache, first identify the active cache directory from the loaded configuration, then delete everything inside that directory while preserving the directory itself, its owner, and its permissions. You normally do not need to restart Nginx when only cached files change. If you change cache configuration, validate it with nginx -t and apply it with a graceful reload.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What Nginx cache are you clearing?
Nginx can cache responses on disk for several proxying features. The cache type and location come from directives such as proxy_cache_path, fastcgi_cache_path, uwsgi_cache_path, and scgi_cache_path. These directives define a cache zone and the filesystem path where Nginx stores cached responses. Nginx documents that cache data are stored in files, with filenames derived from the cache key and distributed through configured directory levels.
As an Amazon Associate I earn from qualifying purchases.
That means /var/cache/nginx is only a possible location, not a safe assumption. A distribution package, a custom build, a container image, or an included virtual-host file may use another directory. Clearing the wrong path leaves stale objects in place; deleting an unrelated directory can damage the server.
How the path, zone, and key fit together
The first argument of a cache-path directive is the directory on disk. Other arguments define details such as the cache zone and directory levels. A cache zone can be referenced later by a server or location block, so the path declaration and the block serving your request may be in different included files. The name of the zone therefore matters when several paths are configured.
Nginx derives cache filenames from the configured cache key rather than from a simple, human-readable URL filename. The key can contain variables such as the scheme, host, URI, or query string, depending on the configuration. Consequently, manually looking for a file whose name resembles a URL is unreliable. For a complete-zone purge, remove the files below the configured path; for a URL-level purge, use a mechanism that evaluates the same cache key.
Before deleting anything
- Confirm which Nginx instance serves the traffic you are testing. A host can have more than one installation or configuration tree.
- Identify every relevant
*_cache_pathdirective and decide whether you are clearing one zone or all zones. - Check that you have root privileges, normally through
sudo. - Record the cache directory’s owner, group, and mode before changing it.
- Plan the timing. Deleting cache files causes subsequent requests to fetch and store fresh responses, so the first requests can be slower and can increase load on the upstream application.
- Do not remove the cache directory itself unless you are deliberately recreating it with the same ownership and permissions.
If the cache is shared by production traffic, coordinate the purge with whoever operates the upstream application. A full purge can make many requests miss the cache at once. Clearing only the affected zone, or using URL-level invalidation where supported, limits that effect.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Step 1: Find the active cache path
Inspect the complete loaded configuration
The most reliable method is to ask the running Nginx binary to print its complete configuration, including files pulled in with include directives:
sudo nginx -T 2>/dev/null | lessSearch the output for proxy_cache_path, fastcgi_cache_path, uwsgi_cache_path, and scgi_cache_path. The first path argument in the matching directive is the directory containing that cache’s files. Also note the cache-zone name, because several directives can define separate zones with different directories.
Review the surrounding server and location blocks as well. A path can be valid but unrelated to the host or URL you are troubleshooting. If the same cache type appears more than once, map each zone to the locations that use it instead of assuming the first match is the active one.
nginx -T reads the configuration Nginx would use and prints it. If it reports an error, do not proceed with a guessed path; resolve the configuration problem or inspect the files directly.
Fallback for older or custom builds
If the installed binary does not support -T, find the configuration file compiled into the binary:
nginx -V 2>&1 | tr ' ' 'n' | grep -- '--conf-path='The result shows the compiled --conf-path. Common package and source-build locations include /etc/nginx/nginx.conf and /usr/local/nginx/conf/nginx.conf, but the output from your own binary takes precedence. Open that file and follow its include statements until you find the applicable cache-path directive.
In a custom installation, also make sure the nginx command in your shell is the same binary used by the service. Comparing the binary’s reported configuration path with the service definition helps avoid cleaning a directory belonging to another installation.
Check the directory before cleaning it
After substituting the path you found, inspect its metadata:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo ls -ld /path/to/cache
sudo stat /path/to/cacheMake sure the path is the intended cache zone, not a parent directory containing unrelated data. If multiple cache zones share a parent, target only the zone that should be invalidated. Record the owner, group, and mode in the command output so they can be restored if the directory is accidentally removed.
Step 2: Purge an entire cache zone
Once the path is confirmed, remove the contents below it while leaving the cache directory in place:
sudo find /path/to/cache -mindepth 1 -delete-mindepth 1 prevents find from deleting /path/to/cache itself. The command removes cached files and the subdirectories Nginx created beneath the configured path. Replace the example path exactly; do not type it literally.
Run this command separately for each zone you intentionally selected. The command is deliberately scoped to one known directory; do not broaden it to a parent path merely because the parent appears in a configuration file.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Why preserving the directory matters
Nginx expects the configured cache path to exist and to be writable by the account used by its worker processes. Removing the directory can leave Nginx unable to create new cache files, especially when the parent directory has restrictive permissions or when the service runs under a dedicated user. Keeping the directory preserves its existing owner, group, and mode.
If you already removed it, recreate it with the ownership and permissions recorded before deletion, then start or reload Nginx only after confirming that the worker account can write there. The exact user and mode are installation-specific, so copy the values from the original directory rather than guessing.
Cleaning one of several zones
Repeat the find command only for the cache directory you intend to invalidate. A server might use one zone for reverse-proxy responses and another for FastCGI, uWSGI, or SCGI responses. Clearing one does not clear the others, and clearing all of them can create an unnecessary upstream load spike.
Do you need to restart or reload Nginx?
No restart is required merely because cached files were deleted. Cache contents are runtime data; removing them does not alter the Nginx configuration. Existing workers can continue serving requests, and new responses will populate the now-empty cache according to the current settings.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsA reload is required when you change a cache directive, add a cache zone, change an include file, or alter any other configuration. A restart is a more disruptive operation and is not the normal response to a file-only purge.
Do not reload just to make a file deletion take effect. If the only operation was removing cache contents, leave the running configuration alone and verify the next request instead. Reloading becomes part of the procedure only when configuration has changed.
When configuration changed: test, then reload
Validate before applying
Run the configuration test first:
sudo nginx -tThe -t option checks syntax and attempts to open files referenced by the configuration. Treat any error as a stop condition. Do not reload until the command reports a successful test.
Gracefully reload the validated configuration
After a successful test, use Nginx’s reload signal:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →sudo nginx -s reloadA reload starts workers with the new configuration and gracefully retires old workers. If validation fails, the old configuration remains in service rather than being replaced by the invalid one.
Using a service manager
On a systemd-managed installation, the equivalent wrapper is commonly:
sudo systemctl reload nginxUse the command supported by the installation. The underlying Nginx behavior is a reload signal; service-manager command names can vary on other init systems and custom deployments.
Selective invalidation with Nginx Plus
Deleting a whole directory is broader than necessary when only one URL is stale. Nginx Plus documents URL-level invalidation through proxy_cache_purge. A typical configuration maps a restricted request method to a purge flag:
map $request_method $purge_method {
PURGE 1;
default 0;
}
location / {
proxy_pass http://backend;
proxy_cache mycache;
proxy_cache_purge $purge_method;
}After placing the directives in the appropriate configuration context, test and reload the configuration. Then send a purge request for the URL:
curl -X PURGE -D - 'https://example.com/path'The cache key used for the purge must correspond to the key used when the response was stored. If the configuration includes host, scheme, query-string, cookies, or other variables in the key, purging a visually identical URL may not match the stored object unless the same key inputs are present.
A successful response from the purge request should be interpreted in the context of that key. If a later normal request still receives the old representation, inspect the cache-key inputs and confirm that the request reached the location containing proxy_cache_purge, rather than assuming the filesystem purge failed.
Protect the PURGE endpoint
A purge method is an administrative operation. Restrict it with the same care as any other cache-management interface: allow only trusted addresses or an authenticated control path, and do not expose an unrestricted PURGE method to the public internet. The mapping shown above demonstrates method handling; it does not provide access control by itself.
Wildcard purge behavior
A wildcard key can match a set of cached entries, but matching files may remain on disk temporarily. Nginx Plus documentation notes that they can be removed later through inactivity, a cache purger process, or subsequent access. Therefore, a successful wildcard purge is not the same as an immediate filesystem wipe. If your requirement is that every cache file disappear now, perform a controlled full-directory cleanup instead.
Open-source Nginx and purge options
The proxy_cache_purge directive and the persistent cache purger are documented Nginx Plus features. Open-source deployments commonly handle broad invalidation by deleting files under the configured cache path, or use a separately installed purge module where that module is available for the exact Nginx build. Module availability, syntax, and maintenance are installation-specific; verify them before adding directives.
Do not paste an Nginx Plus-only directive into an open-source build and assume it will work. Run nginx -t after any change; an unknown directive will be reported before a reload.
Compare the available approaches
| Approach | Scope | Availability impact | Requirements | Main safety concern |
|---|---|---|---|---|
| Delete contents of one configured cache directory | Every cached object in that zone | Usually no restart or reload; cache refills on demand | Correct path, root privileges, preserved directory metadata | Deleting the wrong path or causing an upstream load spike |
| Delete contents of several configured directories | All selected cache zones | Usually no restart or reload | Separate confirmation for every zone | Accidentally removing unrelated data or purging more traffic than intended |
Nginx Plus PURGE |
One URL/key or a wildcard set | No restart for the request itself | proxy_cache_purge, matching cache key, access controls |
Unauthorized purge requests; wildcard files can linger on disk |
| Configuration change followed by reload | Whatever the new cache settings define | Graceful worker transition | Successful nginx -t and a supported reload command |
Reloading untested syntax or referenced files |
Troubleshooting common failures
The cache still serves an old response
Recheck the loaded configuration with nginx -T. You may have cleared a default directory while the active server block uses another proxy_cache_path, or the response may belong to a different cache type such as FastCGI. Confirm the request reaches the Nginx instance and location whose cache zone you inspected.
Recommended Free Tools
Also check whether more than one cache zone contributes to the response path. Clearing a proxy zone cannot remove an object stored by a FastCGI, uWSGI, or SCGI cache. The relevant *_cache_path directive and the location’s cache directive must agree with the traffic you are testing.
find reports permission denied
Run the command with sudo and verify that the path is correct. Do not solve a permissions error by making the cache world-writable. The goal is to retain the existing owner, group, and mode so Nginx workers can write safely.
Nginx will not reload after an edit
Run sudo nginx -t and read the reported file and line number. Typical causes include a misspelled directive, an include file that cannot be opened, an invalid cache path, or a directive unsupported by the installed edition. Correct the error, run the test again, and only then reload.
The directory was deleted accidentally
Stop making further configuration changes, recreate the exact configured path, and restore the original owner, group, and mode from your records or the surrounding deployment’s documented permissions. Test the configuration, then reload or start Nginx as appropriate. If you cannot establish the original permissions, investigate them before allowing production traffic to depend on the cache.
Free tools Windows power users keep installed
One-click scans. No signup required.
The cache refills immediately
That is expected after a full purge. The next eligible response can be written as a new cache file. A purge removes existing objects; it does not disable caching. To stop refilling, change the relevant cache directives, test the configuration, and perform a graceful reload.
nginx -T shows a path you did not expect
Use the path printed by the loaded configuration rather than a distribution default. Follow the included files and identify which server or location references the associated zone. If the service uses a custom binary, compare its compiled configuration path with the result of the shell command you are running.
A repeatable operational checklist
- Run
sudo nginx -T 2>/dev/null | less, or locate the compiled configuration withnginx -Vif-Tis unavailable. - Record each applicable
*_cache_path, its cache-zone name, and the directory owner, group, and mode. - Choose the smallest scope that solves the problem: one zone, several zones, or a single key through a protected Nginx Plus purge.
- For a full zone purge, run
sudo find /path/to/cache -mindepth 1 -delete; leave the configured directory itself intact. - If you changed configuration, run
sudo nginx -tand stop if it fails. - Apply a validated change with
sudo nginx -s reloador the installation’s supported service-manager equivalent. - Make a controlled request and verify that the expected fresh response is generated and that new cache files are appearing in the configured zone.
Frequently Asked Questions
Where is the Nginx cache folder on Linux?
There is no universal folder. Find the active proxy_cache_path, fastcgi_cache_path, uwsgi_cache_path, or scgi_cache_path with sudo nginx -T. The first path in the matching directive is the cache directory.
Can I clear one URL without deleting the whole cache?
Nginx Plus supports URL-level invalidation with proxy_cache_purge and a protected PURGE request. The purge request must use the same cache-key inputs as the stored response. Open-source Nginx commonly requires filesystem cleanup or a separately installed purge module.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do I need to restart Nginx after deleting cache files?
No. Deleting cache contents does not change configuration, so existing workers can continue serving traffic and refill the cache. Reload only after changing configuration, and validate first with nginx -t.
Is deleting /var/cache/nginx safe?
Only if the loaded configuration confirms that it is the intended cache path. Never assume that default location is active, and remove its contents rather than the directory itself so ownership and permissions remain intact.
Why do wildcard PURGE files remain on disk?
A wildcard purge can mark matching entries for removal without immediately deleting every file. Nginx Plus may remove them later through inactivity, a cache purger process, or subsequent access. Use controlled filesystem cleanup when immediate disappearance is required.
What happens to traffic after a full cache purge?
The next eligible requests miss the empty cache and fetch fresh responses from the upstream application before new cache files are created. Those initial requests can be slower and can temporarily increase upstream load.
The Bottom Line
Find the path from the active *_cache_path directive, delete only its contents, preserve the directory and permissions, and reload Nginx only when configuration changed. Use a protected Nginx Plus PURGE workflow when you need URL-level invalidation instead of a full-zone purge.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
