[Improvement] Add Cloudflare Worker as an exit_node option (like Deno/val.town)

[TKZ700]

Hi,

Wouldn't it be better to have a Cloudflare Worker relay as an exit_node, similar to the existing Deno and val.town relays?

Benefits of this approach:

1. Less fragmentation – reduces the variety of Code.gs versions currently in use
2. Standard single format – one consistent implementation across all users
3. Client-side enable/disable - can be toggled from the client, unlike Code.gs (e.g., when Telegram doesn't work through CF relay, you can simply disable it)
4. Fixes existing issues – this would also resolve the problems reported in Need EXCLUDE_SNI_REWRITE_SUBDOMAINS_LIST for app_script mode #719 and Google AI Studio gets SNI‑rewritten → connects directly with Iran IP and gets sanctioned #701 , since pass-through hosts are already implemented for exit_nodes

Any thoughts on implementing this?

Thanks.

[therealaleph]

Already replied earlier in #722 / #382 thread: Cloudflare Workers' outbound IP space is in CF's own range — CF anti-bot still flags Workers as worker-internal traffic and serves the same Turnstile loop. Verified by users (and the CF-anti-bot block list publicly tracks Workers' egress range).

For sites NOT behind CF anti-bot, Workers does technically work, but the use case for exit-node is specifically CF anti-bot bypass — so adding Workers as a documented option would mislead users into thinking it solves the bypass case.

The one CF-related option that DOES work is Cloudflare Pages Functions — different egress range from Workers, some users report it bypasses CF's bot list. Worth experimenting with but not officially supported in our docs (we don't want to recommend a path that might quietly stop working).

می‌بندم — Workers stays out of the recommendation; Pages Functions can be tried at user's discretion.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}