KovraShadowsocks and VLESS Reality solve the same problem — getting traffic past a censor — with opposite philosophies. Shadowsocks tries to look like nothing. Reality tries to look like something specific and boring. In 2026, that difference decides which one connects.
Shadowsocks: the traffic that looks like noise
Shadowsocks was written in 2012 by a Chinese developer who needed something the Great Firewall could not classify. The design is minimal: a lightweight SOCKS5-like protocol with authenticated encryption, no handshake preamble, no version fields, no distinguishing header. On the wire it is a stream of bytes with no structure a pattern matcher can latch onto.
That worked beautifully for years, and it still works on networks that block by keyword and IP. The weakness only appears against a censor that changed the question — from "does this match a known protocol" to "does this match anyknown protocol".
How modern DPI beats it
Entropy analysis. Real internet traffic is not uniformly random. HTTPS has a plaintext handshake before the encrypted part; video has telltale bursts; even compressed downloads carry framing. A connection that is high-entropy from the very first byte is unusual, and unusual is enough to flag.
Traffic shape. Packet size distributions, timing between bursts and the ratio of upstream to downstream all leave a classifiable signature, independent of content.
Active probing. The decisive one. Having flagged a candidate, the censor connects to that server and speaks to it — replaying captured bytes, sending garbage, opening TLS. A web server answers like a web server. A Shadowsocks server, which by design answers nothing to anyone without the correct key, answers like neither. That silence is itself the confession, and the IP goes on a blocklist.
Reality: the traffic that looks like a real website
Reality inverts the strategy. Instead of hiding structure, it borrows someone else's: during the handshake the server presents the certificate chain of a genuine, popular third-party site. A censor inspecting the connection sees a valid TLS 1.3 session, a real certificate for a real domain with years of history, and normal HTTPS traffic patterns.
Active probing fails too. A client without the correct key is transparently forwarded to the actual website whose certificate is being borrowed — so the probe gets a real page from a real server, exactly as it would if the address hosted a mirror. There is nothing anomalous to report. The full mechanism is in the VLESS Reality guide.
Side by side
| Shadowsocks | Shadowsocks + TLS plugin | VLESS + Reality | |
|---|---|---|---|
| Looks like | Random bytes | TLS to your own domain | TLS to a well-known site |
| Survives entropy analysis | No | Yes | Yes |
| Survives active probing | No | Partly | Yes |
| Needs your own domain | No | Yes | No |
| Certificate to maintain | None | Yes, renewals included | None |
| Handshake overhead | None | One TLS round trip | One TLS round trip |
| Client support | Very wide | Wide | Modern Xray-based clients |
| Post-quantum key exchange | No | Depends on TLS stack | Yes, ML-KEM hybrid available |
The domain problem with TLS plugins
Wrapping Shadowsocks in TLS closes the entropy gap, but introduces a different tell. Your certificate is for your domain: registered recently, hosting one service, receiving traffic from a handful of residential addresses that all pull large volumes. A censor correlating certificate age, traffic volume and client diversity has a workable heuristic, and blocking one unknown domain costs nothing politically. Reality sidesteps this because blocking the borrowed identity would mean blocking a site the country actually uses.
What to run, by situation
- Light filtering, self-hosted, minimal effort: Shadowsocks. It is a single binary and it still does the job.
- Moderate filtering, you own a domain: Shadowsocks with a TLS plugin, or plain VLESS over TLS.
- Serious DPI, active probing, national firewalls: VLESS with Reality. See what still works in China.
- Corporate or campus networks with TLS inspection: neither is a silver bullet on a managed device — the constraints are in unblocking sites at school or work.
Where WireGuard and OpenVPN sit
Below both, for this purpose. WireGuard's first packet has a fixed, documented layout that any DPI engine identifies in one packet; OpenVPN has an equally recognizable opcode structure. They are excellent protocols with the wrong threat model for censorship — the full comparison is in WireGuard versus OpenVPN versus VLESS.
The takeaway
Invisibility is no longer achievable — anything unclassifiable is classified as suspicious. The winning move is to be a plausible, uninteresting member of the largest crowd on the internet: ordinary HTTPS traffic to an ordinary website. That is what Reality does, and it is why the protocol keeps connecting where the alternatives get probed and dropped.