WebTunnel transport

WebTunnel VPN: VLESS That Looks Like a Website

WebTunnel carries VLESS over HTTPUpgrade inside TLS on port 443, to a real HTTPS name with its own Let's Encrypt certificate. To a network's filter it looks like a visit to an ordinary website.

WebTunnel VPNVLESS HTTPUpgradeHTTPS disguise VPNanti-DPI VPN
Network
TCP
Port
443
Certificate
Let's Encrypt
Needs UDP
No

01 /A visit to an ordinary HTTPS website

Your app opens a TLS connection on port 443 to a real name that has its own Let's Encrypt certificate, then runs VLESS over HTTPUpgrade inside it. The link looks like vless://…@address:443 with security=tls, a name in sni, type=httpupgrade, a secret path and the chrome fingerprint. Anyone who opens that name without the secret path gets a plain "not found" page.

02 /The name is on the wire, on purpose

As with any website, the name shows in the handshake. Names are random, 12 characters, and say nothing about the exit. Their certificates appear in the public Certificate Transparency logs, like every certificate. A block of that address or domain stops the line until a new name is served.

03 /Where it runs

On every exit the platform runs, a direct route carries it under the platform's own domain, on the exit's main address, port 443. A 2-hop route carries it when the entry's operator has switched WebTunnel on: it uses an extra address of the entry, behind that operator's own domain, and only where the entry and the exit have one owner. Other routes simply do not carry the line.

04 /Billed like Reality

The line is the route's own session at the route's price per GB, exactly like Reality. Nothing extra is added. A partner's subscribers get it only if that partner ticks WebTunnel among its transports; it is off until then.

// faq

Common questions

What is WebTunnel on ProofKit?

VLESS over HTTPUpgrade inside TLS on port 443, to a real HTTPS name with its own Let's Encrypt certificate. To a network's filter it looks like a visit to an ordinary website, and anyone who opens the name without the secret path gets a plain "not found" page.

When does WebTunnel help?

On networks that cut Reality, Hysteria2 or XHTTP but still let ordinary HTTPS websites through. When one disguise is cut, another is already in your list.

How do I get the WebTunnel line?

In the dashboard or the Telegram bot, set Transports in subscription to All or WebTunnel. The choice is offered only to an account that holds a route whose WebTunnel line is live. With All, the list carries it as its own entry after XHTTP, named "<route> · WebTunnel". A WebTunnel-only choice falls back to Reality on a route without it. The one-QR Auto bundle does not include it.

Which apps run WebTunnel?

Xray-core apps that run VLESS over HTTPUpgrade with TLS, such as Happ, V2RayNG and V2RayN, and the sing-box app Hiddify. Ghostlane, an open-source client, runs it from its own list.

What are its limits?

It needs TCP 443 to the address. The name is visible in the handshake, as with any website, and a block of that address or domain stops the line until a new name is served.

Is WebTunnel billed differently?

No. It is billed as the route's own session at the route's price per GB, exactly like Reality. Nothing extra is added.

// ready to try it

Try WebTunnel where Reality is cut

Connect straight to one of the platform's exits, set your subscription to All or WebTunnel, and compare it with Reality on the same network. Both stay in one list, so switching is a tap in your app.

~/proofkit — quick start
$ proofkit auth --wallet
→ signed in as UQAv4F…D9Q
$ proofkit connect --auto
→ session live · 0.0046 TON/GB
↳ proof sha256:c0a4e1ad…b7f9