I have a handful of Bypass Cache page rules that I recently turned off because I’m building a Worker that is going to do the bypassing for me. I turned off these rules a while ago (probably at least 30 minutes by now) and have done a complete cache purge twice since then. But when I load those pages I’m still seeing a CF-Cache-Status: BYPASS header in the responses.
I’m seeing this both in Chrome’s inspector with the box checked to disable local cache, and when I pull those URLs with curl at the command line.
So I guess my first question is: Should I expect it to take 30+ minutes for a page-rule change to take effect? And if not, can anyone give me some ideas about where to start troubleshooting? It feels very much like I must be missing something obvious here…
Sorry forgot to mention that I have a Cache Everything rule in place for the entire site. These Bypass rules were intended to override that for a handful of URLs. That was working fine (and still is unfortunately!). Other HTML pages have CF-Cache-Status: HIT in the response.
So I’ve disabled all of my page rules except for the Cache Everything rule, and I’ve deleted my Worker routes just to make sure the worker I’m building wasn’t causing this problem somehow. (this is all on a staging site right now)… still getting BYPASS for those URLs. I think I figured out what’s going on here, but it raises an interesting question.
For the URLs in question, the origin server does an IP geolocation lookup on the backend and then either sends a 303 to redirect the user to a location-specific page, or sends back a generic page with a dropdown where the user can manually select a location.
I’m guessing now that the first time CF pulls the page after a config-change/purge, the origin server is sending back a 303 and so CF then flags that URL to bypass the cache for future requests. Does that sound right?