Cache and versioning policy configurator

The most insidious type of failure: the server continuously returns 200, yet the page consistently reports errors. Our backend scripts rely on nginx's expires 7d Cached by the browser for seven days; after script updates, the browser still runs the old version and crashes when rendering new data formats—while the code reports all exceptions as “server unreachable.” After hours of debugging the server (which was always healthy), this tool generates a conflict-free cache strategy by file type, plus a response header self-check script.

Free · No login required Locally generated · Content is not uploaded Corresponding incident · Long-cache version mismatch → false backend failure

1Site information

Domain (including protocol)

Version Stamp

Formatting suggestions YYYYMMDD + sequential letter(First version a today, then updated to b on the same day).

2Select the File Types You Have

HTML Page(Homepage / Content pages) Hashed build artifacts(e.g., main.a3f9c2.js) Handwritten JS/CSS without hash.(including backend scripts) Data API JSON(Data files read by backend) Images / Fonts SEO / GEO files（robots.txt、llms.txt、sitemap.xml）

Select all uncertain options; simply delete any extra fragments—missing types are where failures occur

3Policy selection

HTML Page Caching

Data API Caching

There’s often a CDN/cloud accelerator in front (which adds an extra caching layer). Frontend fetch includes ?t=timestamp Anti-Cache

ResultPolicy overview

Outputnginx cache snippets

0 lines

—

OutputResponse Header Self-Check Script

0 lines

—

After changing configuration, always run: What’s being read isResponse Headers— it’s not a configuration file. Configuration files may be correctly written but fail to take effect—a common occurrence.

Quick ReferencePhenomenon → Root cause → How to confirm

Phenomenon	Root Cause	How to verify
CSS/JS changes appear ineffective online.	Long cache + references without version numbers	`curl -I` Check max-age; republish with a new version number
Server logs show all 200s, but the page reports "data not readable"	Browser runs outdated scripts and crashes when rendering new data formats; caught exceptions falsely report network failures	Check the error line in the console; after changing the script to no-cache, press Ctrl+F5
Some pages are new, some are old	The same CSS is referenced by multiple pages, but only some of those pages had their version numbers updated.	Search site-wide for the resource name and batch-increment its version
Changes made in the backend take several days to take effect.	Backend pages are configured for long-term caching	Backend: always use no-store
Data Is Always the Oldest	Data APIs are cached by CDN or the browser	API endpoints: no-store; fetch requests must include a timestamp parameter.
Local curl works, but user browsers do not.	The CDN layer is still caching the old version	Use `-H 'Cache-Control: no-cache'` Compare, then purge from the CDN console

We’ve Fallen into This Pit Before

1 · Server returns 200, but the page throws an error.Background script is expires 7d Caching causes browsers to run outdated scripts after a release; when those old scripts parse new data formats, they crash—and because catch reports rendering exceptions as "server unreachable", the entire investigation path is completely misdirected.

2 · Fix: Apply no-cache separately to backend scripts.location = /assets/js/admin.js { add_header Cache-Control "no-cache"; }— Exact-match rules override regex-based long-cache rules for static assets.

3 · Error messages must be routed separately."Data arrived but rendering crashed" and "Network request failed" must be reported as two separate messages; otherwise, troubleshooting will head in the wrong direction for two days.

4 · One simple rule is enough:Long caching requires version numbers; assets without version numbers must never be long-cached.