Trojan Proxy Protocol: How a Password Inside TLS Hides Traffic Behind a Real Website

In the VPN and proxy world, Trojan is an open-source protocol for bypassing censorship, not a virus and not a VPN brand. The name comes from the Greek wooden horse: the traffic disguises itself as ordinary HTTPS. Your client opens real TLS on port 443, proves itself with a hashed password in its first message, and anyone without the right password sees an ordinary website.

Inside the first packet after the handshake

When TLS is established, the client packs several things into a single message: the SHA-224 hash of the password written as 56 hexadecimal characters, a line break (CRLF), a SOCKS5-like request (CONNECT or UDP ASSOCIATE, with the destination address and port), another CRLF, and the first chunk of data. Attaching data to the login matters: there is no short tell-tale "auth" packet for a censor to notice. The protocol description fits on one page.

What a wrong password or a scanner gets back

A failed TLS handshake is dropped like any web server would drop it. When the handshake succeeds but the hash is wrong or the request is malformed, the server hands the stream to a preset fallback endpoint, by default a local web server on port 80. Put a real site behind it: a blank page draws suspicion, while a live blog leaves a prober nothing to flag. Passive observation reads the whole thing as HTTPS browsing, and the protocol claims it can also dodge ISP throttling (QoS) aimed at proxies.

Trojan-GFW, Trojan-Go and Trojan-R

The original C++ project (trojan-gfw on GitHub) was built to get past China's Great Firewall; the Arch Linux wiki notes its development has stalled and that the code has never been properly security-audited. Trojan-Go reimplements the protocol in Go, config-compatible with the original, and adds smux multiplexing to cut latency, WebSocket transport for relaying through a CDN, an optional Shadowsocks AEAD encryption layer, TLS fingerprint imitation, and a routing module. Trojan-R is a Rust build focused on speed and low memory use.

Where you meet Trojan: Xray, V2Ray, sing-box and Clash

Most users never install a Trojan binary. Cores like Xray-core, V2Ray, sing-box (with optional multiplexing and uTLS) and the Clash family running mihomo implement Trojan; apps such as v2rayN, v2rayNG, Hiddify, Shadowrocket and NekoBox import its profiles, and the old Android client Igniter speaks original Trojan. The core opens a local SOCKS5-style port; pulling the whole device in is the app's TUN mode job. Xray's documentation allows plain mode only on a trusted private network: everywhere else TLS is mandatory, and on public networks Mux must be switched on as well to kill the TLS-inside-TLS pattern.

Strong points and weak spots

Trojan, VLESS Reality and NaiveProxy

Reality comes from the Xray project and skips the domain and certificate chore: the server borrows the TLS handshake of a real third-party website, and probes without the key are passed to that site; the VLESS Reality and Xray/V2Ray glossary entries cover that family. NaiveProxy runs Chromium's own network code behind a Caddy server, so its traffic is Chrome's (glossary entry); Trojan's disguise is only as good as the client's browser imitation. Shadowsocks, briefly, aims to look like random noise rather than HTTPS.

Trojan support among VPN services

Of 377 services in the VPNRadarLab main ranking, 11 claim Trojan support, 98 say they lack it, and 268 say nothing about it. The Trojan ranking lists the providers, apps, cores and panels that run it.

Trojan FAQ

Does Trojan need its own domain?

A self-signed certificate works only if every client pins that certificate; otherwise you need a real domain with a valid certificate.

Can a Trojan server sit behind a CDN?

Original Trojan cannot. Trojan-Go relays through a CDN over WebSocket, and Xray supports the same over WebSocket or gRPC.

Is Trojan-Go compatible with original Trojan clients?

Only while its extensions stay off.

Trojan in a few lines

Trojan wraps proxy traffic in genuine TLS on port 443, checks a SHA-224 password hash inside the first message, and serves a fallback website to everyone without the right hash. Its weak points are the client TLS fingerprint, TLS-in-TLS patterns without Mux, and IP blocks. Reality removes the need for your own domain and certificate, and NaiveProxy copies Chrome's fingerprint more closely; IP blocking hits all three.