Cache Rules
A cache rule decides how caching works for the addresses it covers. A domain can hold several cache rules with different settings — one for images, another for your API, another that switches caching off for your account pages.
Each rule is self-contained: whichever rule matches a request decides everything about how that request is cached.
Create a cache rule
Section titled “Create a cache rule”- Go to Rules → Add Rule → Cache Rule.
- Set which addresses it applies to (
/*for everything,/assets/*for one folder, and so on). - Choose what to cache and for how long.
- Save.
What gets cached: scope
Section titled “What gets cached: scope”| Scope | What it caches |
|---|---|
| Static files | Images, CSS, JavaScript, fonts, downloads — chosen by file extension. This is the safe default. |
| Everything | Every cacheable response, HTML pages included. |
There’s no “custom” scope: to cache less, narrow the rule’s paths instead.
How long: TTL and refresh
Section titled “How long: TTL and refresh”- Cache time (TTL) — how long a copy stays fresh before nsin fetches a new one.
- Background refresh — nsin re-fetches the copy on a schedule while still serving the current one, so visitors never wait for the refresh. Useful for a busy homepage that changes every few minutes.
The query string
Section titled “The query string”A page can be different for ?page=1 and ?page=2. Turn include the query
string on and each variation is cached separately; leave it off and they share
a single copy.
Turn it on for anything where the query changes the content. Leave it off to avoid caching a thousand copies of one page because of tracking parameters.
Safety checks
Section titled “Safety checks”These are on by default and exist so caching can’t leak private data. Each can be turned off individually — do that only when you’re certain the response is the same for everybody.
| Check | What it does |
|---|---|
Skip requests with an Authorization header | Doesn’t cache authenticated requests. |
| Skip responses that set a cookie | A response setting a session cookie is personal to that visitor. |
Honour no-store from the visitor | Respects a browser explicitly asking not to store. |
Honour your server’s Cache-Control | Lets your server’s caching headers decide. |
Use your server’s max-age | Takes the cache time from your server instead of the rule’s TTL. |
| Never cache WordPress admin/login | Leaves /wp-admin and /wp-login.php alone. |
Should I cache it or not?
Section titled “Should I cache it or not?”| If the page… | Do this |
|---|---|
| Looks the same to everyone (a blog post, an image) | Cache it |
| Differs per person (account, cart, dashboard) | Don’t cache it — or leave the safety checks on |
| Changes constantly (live scores, stock) | Short TTL, or background refresh |
Common questions
Section titled “Common questions”A private page got cached and showed the wrong data. Add a cache rule covering that path that doesn’t cache it, then purge once. Then check whether a broader rule has everything scope with the cookie check turned off — that combination is almost always the cause.
My changes aren’t showing. Purge that address, or turn on developer mode while you work.
Which rule applied to a request?
The Nsn-Cache-Status response header tells you how the request was handled —
see Proxy Headers.