VLESS + XHTTP: clickone's censorship-resistant transport

clickone's data plane standardizes on the VLESS protocol running over XHTTP transport. This wasn't an arbitrary pick — it's the result of repeatedly weighing 'censorship resistance' against 'lightweight enough.'

Why VLESS, not VMess

• VLESS drops VMess's redundant encryption and timestamp checks — a simpler handshake and lower CPU overhead;
• Encryption is left to TLS at the transport layer, so the protocol doesn't reinvent the wheel;
• Fewer protocol signatures means it's harder to fingerprint.

What XHTTP solves

XHTTP wraps proxy traffic to look like ordinary HTTP requests/responses. In many restricted networks, plain long-lived TCP/WebSocket connections are easy to detect or throttle, whereas traffic that behaves like standard HTTP blends in more easily.

• In stream-up mode, upstream data is split across multiple requests, closer to real web browsing;
• It can sit behind a CDN, further hiding the real node address;
• The path is customizable, enabling flexible routing with a front Nginx / CDN.

Together, VLESS + XHTTP + TLS make your connection both lightweight and hard to distinguish from ordinary HTTPS on the wire — which is exactly why it stays more stable under censorship.