Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Forward is in public beta on all Cloudflare Zero Trust plans; Worker usage is still billed under standard Workers pricing.
- A Worker runs only for HTTP traffic that matches a Forward policy and is not blocked by request policies. Deploy it in the same account first.
- HTTPS traffic requires TLS decryption. Do Not Inspect, WebSocket, HTTP CONNECT tunnels and protocol upgrades do not pass through the Worker.
- A body-inspection Block can interrupt a Worker, while a policy that still references a deleted Worker can return HTTP 500.
Who can use the public beta, and is Worker usage included?
On October 15, 2026, Cloudflare opened the Gateway and Workers integration as a public beta for all Zero Trust plans. Forward is an action in Gateway HTTP policies that sends matching, permitted traffic to a Worker in your account.
Beta availability does not make Worker execution free. Cloudflare says Workers usage is subject to standard Workers pricing. The announcement gives no specific rate and does not say that compute is included in a Zero Trust plan.
In what order does a request reach the Worker?
Gateway evaluates HTTP request policies first, then the Forward phase, followed by body policies and inspection. If several Forward policies match, the first matching policy in precedence order selects the Worker. An earlier Block prevents invocation; an Allow decision does not skip Forward, and Forward cannot override a Block.
Gateway handles the proxy connection, TLS decryption and upstream routing. The Worker receives the HTTP Request and, when available, Gateway context such as connection metadata, user identity and device posture. It can change the request or response, return a custom page, or start background work. Gateway inspects the final response before returning it.
Body inspection can interrupt a Worker that has already started. Seeing an invocation therefore does not prove that body inspection passed or that the request was ultimately allowed to reach its destination.
What must be in place before you create a policy?
Configure Workers and Gateway in the same Cloudflare account, deploy the Worker and enable the account's Workers subdomain. Cloudflare's documentation says the Worker does not need a public route.
Route a test device through Gateway HTTP filtering. For HTTPS traffic, enable TLS decryption and install a trusted root certificate on that device; encrypted traffic that is not decrypted cannot be handled as ordinary inspectable HTTPS by Forward.
Start with an HTTP policy limited to one test host and a test user or device group. You can match request metadata such as Host, URL and HTTP Method, with optional identity or device-posture conditions. Set the action to Forward and select the deployed Worker.
How can you confirm that a test request ran the Worker?
The Worker must implement the GatewayMiddleware entrypoint. Gateway calls GatewayMiddleware.handle, not a regular fetch handler. Have one test user request a host matched by the policy, then check for the x-gateway-worker: gateway-worker response header used in Cloudflare's example.
If the header is missing, check that the device uses Gateway HTTP filtering, HTTPS is decrypted, Do Not Inspect is not bypassing inspection, and an earlier Block or Forward policy did not handle the request. Cloudflare also recommends checking Workers Logs. If the script fails, disable the test policy while you inspect its entrypoint and response format.
Which traffic bypasses Forward?
Do Not Inspect traffic bypasses Forward. WebSocket connections go directly to the original upstream, so the selected Worker does not receive the upgrade request or messages. HTTP CONNECT tunnels, other protocol upgrades and trailers also bypass the Worker. This beta is not a general-purpose proxy path for every protocol.
A Block decision from Gateway body inspection can interrupt the Worker. For each traffic type you plan to handle, first confirm the protocol, inspection order and response with a narrowly scoped policy before widening its match conditions.
Why update the policy before deleting a Worker?
Gateway resolves the selected Worker when a Forward policy is saved. Deleting the Worker later does not remove or disable that policy. Matching requests can return HTTP 500 and will not reach the original upstream.
Before retiring a Worker, change every Forward policy that references it to another deployed Worker, or delete those policies. Then verify that requests no longer match the old policy; deleting the script alone is not a policy rollback.
Sources
Frequently Asked Questions
Do all Zero Trust plans include free Worker execution?
The Forward beta is available across Zero Trust plans, but Workers usage remains subject to standard Workers pricing. The announcement does not say compute is included or give a specific rate for this feature.
Does the Worker need a public workers.dev route?
No public route is required, but the Worker must be deployed in the same Cloudflare account as the Gateway policy and meet the documented Workers subdomain setup requirements.
Can Forward process WebSocket or CONNECT traffic?
No. WebSocket, HTTP CONNECT tunnels, protocol upgrades and trailers bypass the selected Worker. Do Not Inspect traffic bypasses Forward as well.
Will an existing Forward policy stop working automatically if I delete its Worker?
No. The policy remains, and matching requests can return HTTP 500 without reaching the upstream. Update or delete policies that reference the Worker before deleting it.