Cloudflare: diagnose DNS, cache and origin separately

DNS does not configure the application

An A or CNAME record helps direct traffic, but the HTTP server still needs a route for the requested hostname. A CNAME to a working domain does not copy that domain’s reverse-proxy configuration. With Cloudflare proxying enabled, public DNS normally returns Cloudflare addresses rather than the origin address.

Inspect the response before purging

curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://example.com/assets/app.v2.js

Compare the HTTP status, Content-Type, Cache-Control and CF-Cache-Status. When present, Age helps assess how long a response has been cached. A cache MISS is not inherently an error: the resource may simply have been fetched from the origin.

Compare with the origin

An administrator can test the local server with the appropriate Host header. This checks origin HTTP routing, not public TLS correctness. Do not expose a private origin merely to perform the comparison.

curl -sS -I -H "Host: example.com" http://127.0.0.1/

If the origin works but the public address returns a 404 generated by another proxy, inspect that layer’s route. If both fail in the same way, inspect the application or files. Compare the same hostname and path throughout the test.

Version assets rather than content dates

Use a new filename or controlled version identifier for changed JavaScript and CSS. A new query parameter does not necessarily bypass caching when rules ignore query strings. An already open tab can continue running old code even while the server serves the update. A hard reload tests a fresh document, but it should not become a permanent substitute for a correct deployment.

• Purge the specific resource when that is sufficient.
• Avoid disabling caching globally to repair one file.
• Account, cart and private responses need their own caching policy.

Continue reading