How the reverse proxy hop works

Test note · nested path, two segments deep

The customer's public domain resolves to Cloudflare. A Worker owns every request on it. For anything that isn't the Gushwork content hub, the Worker fetches the page from an upstream host and returns it unchanged.

Where the upstream lives

The upstream is a domain we control — vercel.gush.site — that has been added to the customer's Vercel project. Adding it is what makes Vercel issue a certificate for it, and Vercel's edge routes purely on SNI and Host. Without that step the TLS handshake fails outright.

visitor  →  gushwork.info/pricing
         →  Cloudflare Worker
         →  https://vercel.gush.site/pricing
         →  Vercel edge (matches SNI + Host)
         →  response returned unchanged

What actually does the routing

Not the resolveOverride hint in the tenant config. Cloudflare ignores that whenever the URL host and the override host sit outside the Worker's own zone, which is the case here. The DNS record on gush.site is what carries the request to Vercel. The config field still has to be set, because an empty value makes the Worker fall through to a 404 — but it isn't steering anything.

Three things most likely to break it

Domain redirects. A Vercel project designates a primary domain and can 301 the others to it. If the upstream host redirects to the public domain, the Worker fetches it, gets a redirect back to the domain it is already serving, and loops.

Absolute URLs. Canonical tags, og:url and hardcoded links are where an upstream hostname escapes into the HTML. Every canonical on this site points at the public domain deliberately, so a leak would be visible immediately.

Upstream security rules. Once the whole domain is proxied, every request reaches the origin from Cloudflare addresses rather than from real visitors. Bot protection upstream will see one source making all the requests.