The Proxy Protocol Landscape: From Shadowsocks to VLESS

Internet censorship is fundamentally an arms race: detection systems evolve to identify proxy traffic, and proxy protocols evolve to evade detection. Understanding this history isn't academic — it directly informs which tools you should deploy today and why certain architectures have emerged as dominant.

This chapter traces the lineage of major proxy protocols, from the original Shadowsocks through to modern VLESS and Trojan, explaining what each got right, what killed it, and where the field is heading.

---

How Censorship Systems Identify Proxy Traffic

Before discussing protocols, you need to understand the adversary. The GFW (Great Firewall) and similar systems employ several detection strategies:

A good proxy protocol must look "normal" across every single one of these dimensions. That constraint drives the entire evolution we're about to discuss.

---

Shadowsocks: The Pioneer

Shadowsocks (SS) appeared in 2012, created by @clowwindy. It was the first widely adopted lightweight proxy protocol and represented a fundamental departure from traditional VPNs.

How It Works

SS applies symmetric encryption (typically AES-256-GCM) to the traffic stream. The server decrypts and forwards to the destination. There's no handshake negotiation — once connected, raw encrypted data flows immediately.

Why It Became Obsolete

SS has a fatal flaw: its traffic is trivially identifiable.

• No disguise: Encrypted data has entropy approaching 1.0 (near-perfect randomness), while legitimate HTTPS has a structured TLS handshake envelope
• Fixed ports: Typically runs on non-standard ports (e.g., 8388), unlike normal web services on 443
• Replay vulnerability: Early versions lacked replay protection — the GFW could record packets and replay them to probe server behavior

---

ShadowsocksR: The Obfuscation Attempt

SSR forked from Shadowsocks with one major addition: protocol obfuscation plugins that attempted to make traffic resemble legitimate HTTP or TLS.

Common obfuscation modes:

• http_simple: Disguises traffic as HTTP requests
• tls1.2_ticket_auth: Mimics a TLS handshake

Why It Failed

Mimicking a protocol is not the same as being that protocol. The GFW defeats these obfuscation layers through:

1. Deep Packet Inspection (DPI): The fake TLS handshake diverges from real TLS in subtle details — certificate chains, extension fields, cipher suite ordering
2. Active probing: Send a legitimate HTTP/HTTPS request to the server; if the response is abnormal, flag it as a proxy
3. Traffic timing analysis: Fake HTTP traffic exhibits timing patterns inconsistent with real browser behavior

---

VMess: The V2Ray Era

VMess, the core protocol of the V2Ray project, introduced several meaningful improvements over Shadowsocks:

• Dynamic ports: Support for multi-port rotation
• UUID authentication: Time-stamped UUID-based auth with replay protection
• Pluggable transports: TCP, WebSocket, HTTP/2, gRPC — the transport layer became configurable

Architecture

The combination of VMess + WebSocket + TLS was the first truly mature "looks like HTTPS" solution. To an external observer, the traffic appears as an ordinary wss:// WebSocket connection.

Limitations of VMess

• Redundant encryption: VMess encrypts at the protocol layer, then TLS encrypts again at the transport layer — double encryption with no security benefit and real performance cost
• Time sensitivity: Authentication fails if the client-server clock skew exceeds 90 seconds
• Implementation complexity: The protocol is complex enough that it has historically been a source of security vulnerabilities

---

VLESS: The Minimalist Victory

VLESS is the successor to VMess, introduced by the Xray project. Its core design philosophy: the protocol itself performs no encryption — security is entirely delegated to the transport layer (TLS or Reality).

Why Removing Encryption Makes It Stronger

VLESS traffic on the wire looks like standard TLS-encrypted data — because that's exactly what it is. There's no additional protocol structure to fingerprint. You can't detect what isn't there.

---

Trojan: A Parallel Approach

Trojan emerged around the same time as VLESS with a similar philosophy — use TLS itself for encryption, with the protocol layer handling only authentication and routing.

Key characteristics of Trojan:

• Built-in fallback: Invalid connections are forwarded to a real web server (e.g., Nginx), so active probers see a legitimate website
• Password authentication: Uses SHA256(password) for client verification
• No independent encryption: Like VLESS, relies entirely on TLS

---

Protocol Evolution Summary

The trajectory is unmistakable: protocols are becoming simpler, delegating security and disguise to standard TLS implementations. This is the correct direction — TLS is the most common encryption protocol on the internet, used by billions of devices. Your proxy traffic blending into that ocean is the best possible camouflage.

---

Transport Layer Choices

Beyond the protocol itself, the transport layer selection is equally consequential:

The combination of transport layer and security layer determines your final architecture. The next chapter dives deep into the strongest current security option — how TLS certificates, CDN routing, and VLESS + Reality work together to create a nearly undetectable proxy.

---

In the next chapter, we'll examine VLESS + Reality in detail — how it achieves best-in-class probe resistance without requiring a domain name or TLS certificate, and the role of CDN architecture in protecting your origin server.