Orange Collar Media
Orange Collar Media
 DOCS
OCMLABS/MODULE-CLOUDFLARE · TROUBLESHOOTING

Troubleshooting Cloudflare caching - pages not cached, stale pages after a save, cached checkout, and connection errors

  • Magento
  • Adobe Commerce
  • Hyvä

Start with the Health tab or bin/magento ocmlabs:cloudflare:health. Most of the problems below have a check that names them.

cf-cache-status is DYNAMIC on every page

Cloudflare did not consider the page cacheable. In order of likelihood:

  1. Edge caching is off. It is off by default. Turn on Enable Edge Caching of HTML at website scope.
  2. No cache rule. Without the “Cache storefront HTML” rule Cloudflare never caches HTML, whatever the headers say. Apply the recommended rules.
  3. The module is disabled. Check Enable Cloudflare Integration at default scope.
  4. Varnish is in front of Magento with stock VCL. Stock VCL rewrites Cache-Control to no-cache. Load the exported VCL; see Varnish.
  5. A proxy strips the headers. Set Storefront Origin and read the “Origin sends edge cache headers” check.
  6. The page is not cacheable in Magento either. A block with cacheable="false" in the layout makes the whole page uncacheable, for Magento’s own full page cache as well as the edge. Search your theme and extensions for cacheable="false".

Check the origin response directly:

Terminal window
curl -sI -H "Host: www.example.com" https://<origin ip>/some-category.html -k | grep -iE "cache-control|cache-tag"

You should see Cache-Control: public, max-age=0, s-maxage=... and a Cache-Tag line.

cf-cache-status is BYPASS on a page that should be cached

A bypass rule matched. Compare the path with Bypass Paths, check whether the request carried the X-Magento-Vary cookie (any visit to a non-default store view, currency or a login sets it, and it persists), and whether the URL has a query string while Cache Query Strings is No.

Pages are stale after a product save

  1. The consumer is not running. Purges are queued by default and go nowhere until ocmlabsCloudflarePurge runs. The “Purge queue consumer” health check and the purge log (rows stuck at queued) both show it. See the Installation page for the two ways to run it.
  2. Rate limited. On a Free zone only five purge requests a minute go out. A large import can take minutes to drain; the purge log shows batches arriving. Nothing is lost.
  3. Cache-Tag never reached Cloudflare. Tag purges only work if Cloudflare stored the page with its tags. If something strips Cache-Tag before the edge, switch Purge Mode to By URL, or fix the proxy.
  4. The browser cached it. Check in a private window or with curl. If curl is fresh but the browser is stale, the zone’s Browser Cache TTL overrides the module’s max-age=0; set it to Respect Existing Headers.

Checkout, cart or account pages were cached

The module never marks these cacheable, so a cached private page means a rule overrode Magento’s headers. Look for a “Cache Everything” rule, a page rule, or an edge TTL override on the cache rule, and remove it. Then purge everything. The “Edge bypasses customer and checkout pages” probe fails when this happens.

If a payment or shipping extension adds its own paths (callbacks, notifications, address lookups), add them to Bypass Paths and purge everything.

Redirect loop on the storefront

The zone’s SSL mode is Flexible: Cloudflare talks HTTP to the origin, Magento redirects to HTTPS, Cloudflare asks again over HTTP. Set SSL/TLS to Full or Full (strict). The “SSL mode” check flags this and offers to fix it.

JavaScript is broken on the storefront

Rocket Loader, or Auto Minify on an older zone. Both rewrite the page and break RequireJS on Luma and Alpine.js on Hyva. Turn them off; the health checks name both.

Test Connection fails

  • Authentication error. The token is wrong, expired, or was pasted with whitespace. On 1.0.0, an account-owned token (cfat_ prefix) also failed Test Connection with “Invalid API Token” although purging and zone detection worked; 1.0.1 verifies account-owned tokens correctly.
  • Permission error on a specific action. The token is valid but missing a permission. The error says which call failed. Zone:Cache Rules:Edit is the one most often missing; without it everything works except applying rules.
  • The token works at default scope but not for one website. A website-scoped API Token override is set. Clear it or set it to the right token.

Detect Zone finds nothing

The token is scoped to zones that do not include the one serving the website’s base URL, or the base URL host is not in Cloudflare. Paste the Zone ID by hand from the Cloudflare overview page, and set Storefront Hosts if the public host differs from the base URL.

Orders show a Cloudflare IP

CF-Connecting-IP is being ignored because the peer is not Cloudflare, usually a load balancer in between. See Real Visitor IP for the nginx and Apache fixes. The “Real visitor IP” health check, run from an admin request that came through Cloudflare, reports which case applies.

The Analytics tab is empty or shows an error

  • The token lacks Analytics:Read.
  • Enable Analytics is off.
  • A single panel shows an error while the rest load: Cloudflare changed a GraphQL field. The panel names the error; the other panels are unaffected. Please report it.

Changes to the module are not taking effect

After installing, upgrading or removing the module, run bin/magento setup:di:compile (or clear generated/) and a full bin/magento cache:clean. Generated proxies and the merged admin RequireJS config stay stale otherwise, which can hide dashboard buttons or keep an old plugin alive.

The log file

With Debug Logging on, every Cloudflare API call, with the token redacted, is written to:

var/log/ocmlabs_cloudflare.log

When you open an issue, attach the relevant lines and the output of bin/magento ocmlabs:cloudflare:health --json.

See also

In this module