Proxy Protocol Comparison

Proxy protocols should be compared based on complete deployment combinations: how local traffic is intercepted, how the remote end expresses targets and authentication, how TCP/UDP is transported, and who verifies the security layer. You cannot directly map a protocol name to fixed levels like "high speed" or "always unrecognizable."

HTTP CONNECT and SOCKS5 are generic proxy interfaces; Shadowsocks, VMess, Trojan, VLESS, and Hysteria have their own authentication, packet, and transport designs. TUN is a local IP device interface, TLS is a transport security mechanism, WebSocket is message transport, and REALITY and Vision serve different responsibilities.

Narrow the Scope Using Five Dimensions

Local entry points and remote exits can be combined; for example, using a remote TCP proxy protocol after TUN interception. This does not automatically grant the remote protocol native UDP capabilities. Similarly, a SOCKS entry can connect to a QUIC remote transport; SOCKS is merely the local interface.

Core Mechanism Comparison

The table describes capability structures and does not guarantee that every client and combination implements all features. Protocol extensions, Mux, and UDP encapsulation must be verified against versions on both ends; do not treat optional modules of a specific implementation as mandatory protocol parts.

Shadowsocks: AEAD Protection and Wire Format Versions

Old AEAD TCP streams first send a salt, then use session sub-keys to protect length blocks and content blocks; the length also has an independent authentication tag. Each chunk undergoes two AEAD operations, with nonces evolving according to the specification. UDP is constructed per independent datagram, not by reusing the chunked state of a TCP stream. Shadowsocks AEAD

Taking the old AEAD format with AES-128-GCM as an example: salt (16 B), length (2 B) plus its tag (16 B), content (N B) plus its tag (16 B). Sending 1000 B of protocol payload as one chunk results in 16+2+16+1000+16=1050 B for the first direction; splitting into two chunks results in 1084 B. Here, the payload may still contain protocol data such as destination addresses, so it does not equal 1000 B of pure application content, nor does it account for TCP/IP headers.

def old_aead_tcp_size(payload_sizes, salt=16, tag=16):
    assert all(0 < size <= 0x3fff for size in payload_sizes)
    return salt + sum(2 + tag + size + tag for size in payload_sizes)

assert old_aead_tcp_size([1000]) == 1050
assert old_aead_tcp_size([500, 500]) == 1084
assert old_aead_tcp_size([500, 500]) - old_aead_tcp_size([1000]) == 34
print('One / Two chunks:', old_aead_tcp_size([1000]), old_aead_tcp_size([500, 500]))

AEAD-2022 updates key requirements, sessions, replay handling, and packet structures. You cannot simply replace the cipher name and continue using the old salt and chunk diagrams. Configuration migration requires checking protocol generations, key formats, and UDP support on both ends. SIP022

Authenticated encryption guarantees confidentiality and integrity under specified conditions; it does not promise that ciphertext length, packet splitting, or connection behavior will match standard HTTPS. If a specific deployment is identified, this does not imply that AEAD cryptography has failed.

How much extra overhead is added by splitting 1000 bytes into smaller chunks?

Changing the number of chunks from 1 to 2, while keeping the total content volume constant, only adds one instance of 34 B overhead; increasing to 20 chunks significantly raises the proportion of authentication and delimiting costs. This explains the budget for a clear wire format, without equating fewer bytes directly with faster real-world speed.

$$L=16+N+34k$$

VMess: Proxy Packets and Outer Transport Separated

VMess uses its own authentication request headers and data formats to express targets, options, and identity; the AEAD header format is a protocol version that needs distinction. Time-related verification means clock conditions affect the handshake; do not simplify it to "some random encrypted bytes inside TCP." V2Fly VMess Specification

Carrying VMess over WebSocket or other transports adds a layer of connection establishment, framing, or proxy behavior. Whether CDN is usable depends on the actual HTTP transport and forwarding configurations it supports; you cannot assume any CDN can relay just because a TCP stream is wrapped in TLS.

Multiplexing multiple logical sessions may reduce the number of connection establishments, but they might also share head-of-line blocking in a single outer TCP stream. Whether to choose multiplexing should depend on the number of short connections, interaction latency, and packet loss conditions, rather than assuming Mux is always faster.

Trojan: TLS Appearance and Application Authentication Are Not the Same Guarantee

Trojan sends proxy authentication and request information inside a TLS connection; its protocol includes TCP CONNECT and UDP ASSOCIATE-like commands. TLS is used to protect the channel and verify the server, while proxy credentials determine whether relaying is allowed; neither can compensate for the absence of the other.

UDP data in this protocol has record formats for target, length, and content, carried over TLS streams. It preserves datagram boundaries, but when the outer reliable stream has gaps, subsequent data still waits for recovery; reliability characteristics suitable for TCP may not suit real-time UDP applications. Trojan Protocol

Normal TLS handshakes and fallback sites help change observed behavior, but handshake parameters, traffic size, timing, and deployment responses may still differ. A valid public certificate only proves the corresponding service identity; it does not guarantee "indistinguishability from normal web browsing."

What Do VLESS, Vision, and REALITY Each Handle?

VLESS retains user IDs and proxy request semantics; it has not removed UUID-like identity fields. The traditional encryption: none combination relies on outer TLS/REALITY etc. for protection; as of September 2026, Project X documentation still defines the VLESS Encryption option, so "VLESS never has protocol encryption" cannot be written as an immutable fact.

Vision is a specific stream processing mode related to inner TLS identification, padding, and applicable path optimization; it is not a new TLS suite and cannot be equated with XUDP or Mux. Mode selection may also change UDP443 handling policies; specific flows should be checked rather than just looking at the "VLESS" label. Project X VLESS Configuration

REALITY uses dedicated authentication and handshake processing, and designs fallback behavior for connections that fail authentication. The server has its own configuration key, and the client holds corresponding verification materials; this is not obtaining a third-party website's private key, nor is it completing legitimate proxy client authentication by "obtaining the actual certificate of a filed website." REALITY Project

Current Xray client code includes dedicated certificate verification paths based on materials like AuthKey, while distinguishing normal certificate verification from whether the expected REALITY authentication state is reached. Asserting "no identity verification at all" based on reading one InsecureSkipVerify flag is also wrong, because it configures custom verification. Xray REALITY Client Implementation

Copying a public certificate does not allow any server to prove possession of that certificate's private key; fallback forwarding and dedicated client authentication are two separate paths. The mechanism can reduce certain observation differences, but you cannot directly deduce from project goals that all active probes are ineffective, or that there is an indistinguishability guarantee for all observers.

Hysteria 2: QUIC Multi-Stream and Optional Outer Obfuscation

Hysteria 2 uses QUIC/TLS and establishes proxy eligibility through HTTP/3 authentication exchange. After authentication, each TCP connection uses corresponding bidirectional streams, and UDP capabilities are indicated by the server and encapsulated according to the protocol. It does not treat all proxy content as standard web HTTP responses.

QUIC allows independent recovery between streams, but connection congestion control is still shared. Hysteria's congestion and bandwidth configurations affect sending strategies; filling in larger bandwidth values does not increase actual link capacity; bottleneck queuing may even harm small interaction latency. Hysteria 2 Protocol

Salamander is an optional outer obfuscation that adds salt and processes QUIC packet bytes; it does not eliminate packet length, direction, and timing, nor does it guarantee failure of all detection. Current documentation also lists other obfuscation options; do not write one option as the protocol's unique permanent form. QUIC includes TLS handshakes, and Initial protection materials can be derived from public information, so "QUIC has no TLS fingerprint" is inherently incorrect.

In networks with UDP restrictions, QUIC-like transports may be unavailable or unstable; when available, first packet, tail latency, throughput, and CPU should be measured, rather than judging performance solely by "based on UDP." Client settings must match the server and the version used. Hysteria Client Configuration

How to Make Meaningful Comparisons

Comparisons should fix server location, path, load, and client version, and record configuration combinations; a single failure may come from DNS, certificates, UDP paths, or version mismatches. Protocol security goals, implementation correctness, deployment reachability, and identification risks should be evidenced separately.

Continue Reading

• Forward Proxy: CONNECT, SOCKS5, and DNS location.
• Transparent Proxy and TUN: Local interception and outbound bypass.
• TLS 1.3: Authentication, keys, and handshake visibility.
• UDP and QUIC: Reliable streams, DATAGRAM, and congestion boundaries.