Serverless Relay Transport

A circumvention pattern where the user's "exit server" is not a VPS they rent but a serverless function deployed on a free tier of a major cloud provider. The client MITM-terminates its own HTTPS, repackages each request as an RPC to the function, and the function forwards it with fetch() (or equivalent). Response comes back the same way.

The canonical current examples are Google Apps Script (see masterhttprelayvpn, masterhttprelayvpn-rust) and Cloudflare Workers (same tools support it as an alternate backend). Historically AWS Lambda was used similarly, and Cloud Run still is for users who'll pay for the egress. The pattern generalizes to any provider that gives you a trivial HTTPS endpoint on their shared edge IPs with a free or near-free request allowance.

Why this is different from a VPN or a VLESS tunnel

A VPS-backed tunnel (xray-tutorial, WireGuard, OpenVPN) gives you an L3/L4 pipe. You route packets in, packets come out the other end. The server is yours, the IP is yours, the cert is yours, and the shape of what you send is under your control.

A serverless relay gives you an RPC endpoint, not a pipe:

The provider decides the hostname, the IP, the TLS cert, the allowed HTTP methods, and often the maximum body size and request duration.
You can't run arbitrary protocols. UDP is out. WebSocket is out (Apps Script doesn't support upgrade; Workers do but most free-tier relays don't wire it up). Server-sent events and long-lived HTTP/2 streams mostly don't work.
Every request pays the cost of: one TLS handshake (often reused), one HTTP/2 stream open, JSON-encoding the original request, the provider's fetch() call to the target, JSON-decoding the response, and returning. This adds hundreds of milliseconds of latency per request.
Streaming video is painful — the relay function usually has a per-invocation time cap (Apps Script: 6 minutes; Cloudflare Workers: 30 seconds on free tier, 15 minutes paid), after which the connection dies mid-stream.

The implication is that you cannot transparently tunnel the way WireGuard does. The client has to MITM local TLS, parse the HTTP request, repackage it, and translate the response. This is why every tool in this category ships a local root CA that it asks the user to install.

Why it works when CDN fronting usually doesn't

Classic domain-fronting is mostly dead because CDNs enforce SNI/Host consistency. Serverless relays survive because the front and the back are the same provider:

For Apps Script, outer SNI is www.google.com and inner Host is script.google.com. Both are Google. Google routes between them using the inner Host without calling it "fronting" — it's just their own HTTP/2 router.
For Cloudflare Workers, outer SNI is your Worker's hostname (or any Cloudflare hostname) and inner Host is your Worker's route. Both are Cloudflare. Same story.

A censor can't block the outer SNI because it's on a hostname the whole internet depends on. The censor also can't distinguish a request going to your relay from a request going to the provider's legitimate services — the IP, cert, and TLS fingerprint are the provider's, not yours. The fact that "domain fronting died in 2020" didn't kill this, because this isn't CDN domain fronting; it's "rent a subdomain on the provider's shared edge."

The catch is that the provider can still kill your relay whenever they want, by deleting your deployment, suspending your account, or adding server-side checks that distinguish UrlFetchApp.fetch() traffic from legitimate use. So far (April 2026) Google hasn't, for Apps Script. That could change tomorrow.

What you get, what you give up

Gains:

Zero infra. No VPS, no domain, no TLS cert, no SSH keys, no systemd unit, no ufw rules, no monitoring. A Google account and ~5 minutes of click-through.
Zero cost (at low usage). Free tier covers a single user browsing normally. Apps Script: 20,000 script-calls/day. Cloudflare Workers: 100,000 requests/day on free tier.
IP that's hard to block. Provider edge IPs serve so much legitimate traffic that blanket-blocking them is politically and technically expensive for the censor. This is the same argument as CDN fronting, but it still holds here because the traffic genuinely is the provider's traffic.
No server-state to burn. Unlike a VPS where a blocked IP takes hours to replace, a suspended Apps Script takes ~30 seconds to redeploy from a different account.

Losses:

No UDP, no WebSocket, no streaming. So no Hysteria2, no QUIC, no video calls without a protocol the relay can proxy as plain HTTPS requests.
Quota ceiling. A couple of YouTube sessions will eat Apps Script's daily quota unless the tool routes Google traffic directly (the hybrid-routing trick — see masterhttprelayvpn-rust).
Provider ToS risk. Apps Script's Terms prohibit "acting as a proxy or VPN." Enforcement is inconsistent, but Google can and does suspend scripts that look like proxies. The tools in this space carry fewer than the average number of stars among users who've had a relay suspended.
Latency tax. Every page load pays the relay's overhead. Noticeable compared to a direct VLESS tunnel; acceptable for text browsing, annoying for media-heavy sites.
Single-user viability. Sharing a relay across more than a few users burns the quota in minutes. This is genuinely a solo-user tool.

Where this sits in the circumvention landscape

The serverless relay is the "zero-budget solo user" end of the spectrum. Next rung up is a VLESS-over-CDN setup (paid Cloudflare domain + Worker + VLESS config), then classic VLESS on a VPS (xray-tutorial), then a cascaded multihop setup (russia-vpn-bypass-state-2026-04).

The audience matters a lot:

Iran. Serverless relays are widely used because Google IPs are effectively unblockable there and the local circumvention-tool market is huge. Apps Script is the current preferred backend. The Telegram channel for the upstream MasterHttpRelayVPN project is Persian.
Russia. Less common. TSPU's CIDR whitelist approach is different from Iran's SNI-list approach — Google edge IPs aren't automatically in the TSPU whitelist, and TSPU periodically throttles Google. Russian circumvention culture has also standardized on VLESS+Reality with VPS exits, and the serverless-relay niche is smaller.
China. Historically useful (Apps Script isn't actively blocked in the sense that Google's main services are), but the Great Firewall's handling of Google edge is different enough that most Chinese users go through Shadowsocks-family tools with local bridges.

Design pattern for building one

Every tool in this category converges on the same architecture:

Local HTTP-proxy + SOCKS5 listeners so the user can point their browser at 127.0.0.1.
A local root CA generated at first run. Installed into the OS trust store with platform-specific helpers.
A reshape layer: parse the browser's HTTPS request, pack it into JSON, send as a POST to the relay endpoint.
On the relay side: validate a shared secret, call the provider's HTTP client against the real target, stream the response body back.
A hybrid-routing optimization: requests to the provider's own properties (Google, Cloudflare) skip the relay and tunnel directly through the provider edge with SNI rewriting. This is where most of the free-tier quota savings come from.

The auth model is always a pre-shared secret (auth_key) between client and relay. There's no provider-level auth because anonymous deployments are the point. The relay endpoint is effectively public; if the secret leaks, anyone can burn your quota until you rotate it.

masterhttprelayvpn — the Python reference implementation (Apps Script, Cloud Run, Cloudflare Worker backends)
masterhttprelayvpn-rust — Rust port with desktop UI and Android support
domain-fronting — the TLS trick serverless relays use at the outer layer
xray-tutorial, vless-subscription-format — the VPS-backed alternative with a very different cost/performance profile
russia-vpn-bypass-state-2026-04 — why this pattern plays a smaller role in the Russian context