CDN is broken for at least a couple of weeks

I did follow the in order to deploy the worker and it worked well. Without changing something at CF config or our backend the worker stoped to serve cf-cache-status headers… as a result, only local cache is working, but content isn’t stored at CF’s CDN… I rechecked the tutorials but it seems that nothing changed there… What can be the reason for such weird behaviour?

Looking into the code of the tutorial:

if (!response) {
    response = await fetch(`${BUCKET_URL}${url.pathname}`)
    const headers = { "cache-control": "public, max-age=14400" }
    response = new Response(response.body, { ...response, headers })
    event.waitUntil(cache.put(event.request, response.clone()))

Cache-control header is added first. It means if the response returns own cache-control it will override the one set in the code. Another preconditions you want to check are explained in the documentation.

1 Like

Thanks for reply. I do understand. My point is that I suddenly stoped to get cf-cache-status headers from cloudflare on the endpoint which are covered by worker. Though cache-control (which is added in worker) is exist in response.

It’s hard to tell without more context, could you provide an example request?

curl -i ""

gives no CF-related headers at all, but our worker configured to handle this url

you should provide file extension otherwise Cloudflare cache ignores it.

Mh… was there any update at cloudflare side recently? I am asking because our CDN setup (based on worker) was working for sure with the same URL I provided earlier

Moreover, I’d say the worker even isn’t triggered as cache-control current value is passed by our backend… According to worker’s logic the value must be max-age=60000 but it’s max-age=2592000 (which is defined at our backend)

I am just trying to understand which infrastructural changes might have caused the worker to break…

I suggest raising a support ticket so the team will help you with diagnosing the exact problem.

This URL is not enabled for cloudflare at all. The hostname is not orange-clouded.

You’ll need to orange-cloud it in your DNS settings to have HTTP requests flow via Cloudflare - at that point any page rules or workers should execute as per your configuration.


Hi @simon, there is indeed one record (* which isn’t proxied but marked as DNS only… But how exactly should I change it? I can’t see any property to change it

If you have a wildcard DNS record, that cannot be orange-clouded. You’d need to define a new A record for dev-api pointing to the same IP as the * record and orange-cloud that.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.