![\"Split](\"/images/journal-inline-cloudflare-set-cookie-bypass.webp\")
\n I fingerprint every Vite bundle and stylesheet with content hashes. Origin nginx serves them with Cache-Control: public, max-age=31536000, immutable. On paper that is the textbook setup for a CDN: long-lived assets, cache busting baked into filenames, HTML stays fresh with no-cache, must-revalidate. And yet Cloudflare kept answering every request to /assets/index-*.css with cf-cache-status: BYPASS. Repeat visitors paid full origin round trips on bytes that should have lived at the edge for a year.
That mismatch is worse than slow lab scores. Field Core Web Vitals aggregate real repeat loads. If your edge never caches JavaScript and CSS, every return visit re-downloads the main thread budget you already paid to optimize. I spent an afternoon chasing dashboard toggles before I read response headers like a crawler would.
\n\n\n Cloudflare’s caching model is conservative about personalization. If the origin attaches Set-Cookie on a response, the edge treats that response as potentially user-specific and refuses to store it in the shared cache — even when the URL is a hashed static file that will never vary per visitor. That is not a bug. It is the same rule that protects logged-in HTML pages from leaking session state to the next visitor on a shared cache node.
The trap is applying session machinery globally. Hosting panels, WAF modules, and legacy middleware often drop a session cookie on every response because it was easier to write one hook than to branch on file type. Your immutable asset headers become decorative. Cloudflare sees cookie plus long TTL, chooses cookie, and BYPASS wins.
\n\nHTML document routes should stay dynamic — cf-cache-status: DYNAMIC with short or revalidate directives is correct for prerender shells and SPA fallbacks. The failure mode is polluting static extensions with the same cookie HTML needs for WAF or admin tooling.
Stop guessing from the Cloudflare dashboard cache analytics. Pull headers twice on the same asset URL with GET — not HEAD. Some stacks set cookies on HEAD probes but behave differently on GET; browsers use GET. I run the same check through Cloudflare and directly to origin when debugging.
\n\n# First GET — note cf-cache-status and Set-Cookie\ncurl -sD - -o /dev/null \"https://briancrabtree.me/assets/index-*.css\" | \\\n rg -i '^(HTTP/|cf-cache-status|set-cookie|cache-control)'\n\n# Second GET — if fixed, cf-cache-status should be HIT and age should climbBefore the fix, every pass returned BYPASS and a server_name_session cookie on hashed CSS and JS. Origin already sent the right cache policy; the cookie was the disqualifier. Once I saw that pattern, the fix stopped being “purge harder” and became “stop sending cookies on static GETs.”
On this VPS, aaPanel’s BT WAF injected a session cookie from Lua on every response — including fingerprinted files under /assets/ and images under /images/. Nginx location blocks already set aggressive caching for those paths. The WAF hook ran afterward and undid the performance work silently.
That explains why PageSpeed lab runs could still look acceptable while field data lagged: Lighthouse often cold-loads once. Real users navigating between journal posts and the homepage hit the same JS chunks repeatedly. Without edge HITs, Time to First Byte on assets stays tied to origin latency even when filenames never change between deploys.
\n\nPurge workflows alone cannot fix BYPASS. See Cloudflare Cache and Stale Assets After Deploy for when targeted purges matter after you ship new hashes — but purging a URL that is permanently ineligible for cache just repeats the origin fetch.
\n\nI patched the WAF Lua entry so GET requests whose URI ends in a static extension — js, css, mjs, fonts, images, webp, and the rest — skip the session cookie entirely. Document routes, admin paths, and HTML shells still receive the cookie the WAF expects. No Cloudflare dashboard rule changes were required; this was origin behavior blocking edge cache eligibility.
After nginx reload, the first GET on a hashed asset may still show MISS or EXPIRED while the edge populates. The second GET on the same URL should flip to HIT with an increasing age: header and no Set-Cookie line. That single header pair is the proof — not a green gauge in a performance tool.
This change touched infrastructure only. The React app, prerender shells, robots policy, and homepage critical path stayed untouched. I ran npm run verify:edge to confirm PageSpeed still sees clean HTML without bot-fight scripts injected at the edge. AI crawl bots still get HTTP 200 on journal URLs with correct per-slug canonicals — unrelated to asset caching but non-negotiable on this site.
After verification I ran a prefix purge on /assets/ and /images/ so stale BYPASS responses did not linger at individual pops. New deploys still rely on filename hashes for busting; HTML stays on no-cache so journal shells update immediately after deploy.sh prod. The full stack — Vite hashes, nginx headers, Cloudflare orange cloud, WAF exceptions for PSI and answer bots — is documented in How This Site Is Built (Reference Stack).
If Cloudflare analytics show low cache hit ratio on /assets/* despite immutable filenames, curl your largest JS and CSS twice. Look for BYPASS plus Set-Cookie before you enable Rocket Loader or crank browser TTL in the dashboard. Fix origin response headers first. Edge cache eligibility is binary: cookie on a cacheable GET means BYPASS until you remove it.
Field Core Web Vitals will not jump overnight — CrUX needs traffic — but repeat-load performance and origin egress improve immediately when hashed assets start HITing. That is the kind of boring infrastructure win that compounds. If your stack has the same symptom and you want another pair of eyes on headers, send your asset URL and cf-cache-status output — not a Lighthouse screenshot, the raw headers.
","tags":["cloudflare","caching","core-web-vitals","nginx"],"views":11}