Skip to content

Warn not to enable Workers Cache on the Protect worker #114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
forgetso merged 1 commit into from
Oct 20, 2026
Merged

Warn not to enable Workers Cache on the Protect worker #114

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions src/content/docs/en/protect-edge/cloudflare-worker.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -150,6 +150,10 @@ Then `wrangler deploy`. The worker now runs on every request to `www.<your-domai

**Deploy on a route, not `workers.dev`, before testing.** A `workers.dev` URL is not in front of anything, so there is no origin for `fetch(request)` to reach: an allowed request re-enters the worker and Cloudflare returns **Error 1042**. That is expected on `workers.dev` and not a fault in your config. Only a route has an origin behind it.

:::caution[Do not enable Workers Cache]
Leave the `[cache]` section out of `wrangler.toml`. With `[cache] enabled = true`, Cloudflare checks its cache before running the worker, so a cached response is served without Protect checking the request. By default one cached copy is served to every visitor, which means a page cached after one visitor was allowed is then served to bots too. See [Cloudflare's Workers Cache docs](https://developers.cloudflare.com/workers/cache/).
:::

Your account manager notifies you when a new `worker.js` is available. Replace the file and re-run `wrangler deploy`. Secrets persist.

### 1e. Verify the worker
Expand Down
8 changes: 8 additions & 0 deletions src/content/docs/en/protect-edge/troubleshooting.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -97,6 +97,14 @@ Common block sources:

Check the dashboard's traffic summary for your site to see request throughput broken down by verdict.

## Some requests skip Protect entirely

**Symptom:** Pages load for visitors who should be blocked or challenged, and those requests are missing from the dashboard's traffic summary.

**Cause:** Workers Cache is enabled in `wrangler.toml` (`[cache] enabled = true`). Cloudflare then serves cached responses before the worker runs, so Protect never sees those requests. See [Cloudflare's Workers Cache docs](https://developers.cloudflare.com/workers/cache/).

**Fix:** Remove the `[cache]` section from `wrangler.toml` and run `wrangler deploy`.

## Configuration drift

**Symptom:** Behaviour changed without anyone deploying. Verify commands that previously worked now fail (or vice versa).
Expand Down
Loading