GFW Technical Review 09 – V2Ray

Created on March 08, 2026

2026   ·   GFW

In the previous post, we looked at how Tor supports multiple obfuscation protocols in a modular fashion through pluggable transports. The core Tor software serves as the foundation for Tor network access, and obfuscation protocols can be selectively enabled on demand. Shadowsocks, on the contrary, is both a piece of software and an obfuscation protocol. This coupling means users and operators have to use different software if they want a different protocol.

V2Ray took Tor’s pluggable transport idea and ran with it. Rather than designing a single protocol with a fixed threat model, V2Ray’s creators built a framework: a modular proxy platform where the protocol, the transport, the routing logic, and the encryption layer are all interchangeable components. The result is a system that can adapt to new censorship techniques without being rewritten from scratch.

The VMess Protocol

Before looking into the V2Ray platform itself, let’s start with V2Ray’s own obfuscation protocol – VMess. VMess is an evolution of Shadowsocks. In principle, it is the same class of protocol – stateless and fully encrypted. It supports multiple encryption methods including stream ciphers and AEAD. It took some of the lessons learned from Shadowsocks and baked them into the protocol itself, resulting in a more feature-rich but more complicated design.

VMess has a few key differences from Shadowsocks:

  • UUID-based user identity: Shadowsocks can only have one password per instance with no concept of different users. VMess identifies users by UUID, enabling multi-user servers.

  • Asymmetric request and response format: the client-to-server and server-to-client frames have different structures, enabling features like mutual authentication and dynamic port instructions.

  • Built-in replay protection: achieved through timestamp validation and byte padding obfuscation.

Authentication

In order to identify which user is initiating the connection, the first field – the Encrypted Authentication UUID (EAuID) – contains an HMAC of the current UNIX timestamp keyed with the user’s UUID. The server needs to try every known UUID until it can successfully verify the hash. This field also provides replay protection: the encrypted timestamp ensures that each connection’s opening bytes look different, and the server can reject duplicates within the validity window. This is why the VMess client and server must stay time-synced within 120 seconds.

The Encrypted Header

The encrypted header section (AHeader) is feature-rich. Aside from the standard IV and key needed for AEAD encryption, the destination port and address needed for routing, and the Command field indicating TCP or UDP, it includes several additional capabilities:

  • Mutual authentication: the Response Auth V field is a challenge byte the server must echo back in its response to prove it successfully decrypted the request.

  • Decoupled header/body encryption: the header is always AEAD-encrypted, but the message body encryption method can be selected dynamically via the Encryption Sec field.

  • Header padding: the P-bytes Random field adds variable-length padding to protect against fingerprinting

Chunked Data and Padding

The data section is transmitted in chunks (an unchunked format existed but is now deprecated). If enabled – indicated in the header through the Options bitmask – each chunk gets 0–63 bytes of random noise appended. The padding length is deterministic, derived from a SHAKE stream that both sides agree on, so the receiver knows exactly how many bytes to strip. This per-chunk padding helps significantly with preventing payload fingerprinting.

Asymmetric Response

As previously mentioned, VMess requests and responses are asymmetric, enabling a few additional features:

  • The Response Auth V echoes the client’s challenge as an additional layer of replay protection – the server proves it read the request, not just that it accepted a connection.

  • The Command field may contain Dynamic Port Instructions, allowing the server to redirect the client for load balancing.

The response header and data are encrypted using encryption state shared with the client-to-server direction. This is different from Shadowsocks, where server-to-client communication has its own independent salt and key derivation.

Summary

VMess is an expansion and evolution of Shadowsocks. It adds multi-user support, mutual authentication, dynamic encryption selection, and per-chunk padding – many of which were later incorporated into Shadowsocks-2022. In return, it has a more complicated implementation and configuration, and – more importantly – a larger attack surface.

V2Ray Architecture

V2Ray is built as a central platform to run censorship circumvention protocols. It supports VMess as a “native” protocol, but its core capability is running multiple protocols flexibly through its Inbound → Router → Outbound abstraction.

The Inbound/Router/Outbound Pipeline

An inbound is a listener that accepts incoming connections and decodes them according to a configured protocol. A single V2Ray instance can run multiple inbounds simultaneously – for example, one speaking VMess on port 443, another accepting plain SOCKS5 on localhost:1080, a third handling Shadowsocks on port 8388. Each inbound unwraps the connection from its protocol-specific framing and hands a normalized connection request – destination address plus payload stream – to the next stage.

The router examines the connection metadata and decides which outbound should handle it.

An outbound takes the connection and forwards it toward its destination. Like inbounds, outbounds are protocol-agnostic: one outbound might re-wrap the traffic in VMess and send it to a remote server, another might forward via Shadowsocks to a different server, and a third – the special “freedom” outbound – sends traffic directly to the destination with no proxy at all. There is also a “blackhole” outbound that silently drops the connection, useful for blocking ads or known-malicious domains.

V2Ray Inbound/Router/Outbouding Architecture

The flexibility provided by this architecture makes V2Ray a Swiss army knife of network proxying. The software is fully decoupled from protocol details such that new protocol support can be added easily. A single instance can listen on multiple inbound ports and publish into multiple outbound channels, and the router allows rules to be configured dynamically.

This flexibility also allows the same V2Ray binary to serve in both the client and server roles. A V2Ray client can be configured with a SOCKS5 inbound and a VMess outbound to proxy traffic with VMess. A V2Ray server needs a VMess inbound to decode the VMess traffic and a “freedom” outbound to access the internet.

The Routing Engine

The router is where V2Ray’s modularity pays off most visibly. Shadowsocks was essentially all-or-nothing: once you configured your browser to use a Shadowsocks proxy, all traffic went through the remote server. This is wasteful and slow for domestic traffic that doesn’t need to bypass censorship, and it draws unnecessary attention by routing local requests through a foreign IP.

V2Ray’s routing engine lets you define rules that match connections by destination domain, destination IP, source IP, port, user identity, inbound tag, or protocol type – and route each connection to a different outbound. The practical power of this becomes clear in a typical Chinese user’s configuration. You might define two routing tiers: traffic destined for Chinese domestic IPs or domains – identified via a bundled GeoIP database and a community-maintained “geosite” domain list – goes to the “freedom” outbound for direct access. Everything else goes to the proxy outbound, tunneled through VMess to an overseas server.

This split-routing pattern – often called “bypass mainland China” in user-facing clients – is a significant UX improvement. Pages load faster because domestic CDN traffic doesn’t take a round trip through a foreign server, bandwidth on the proxy server is conserved, and the user’s traffic profile looks more normal from the GFW’s perspective.

Routing also enables more advanced topologies. You can chain multiple proxies – with the first outbound connecting to the second inbound – creating multi-hop proxy chains for additional anonymity or to traverse multiple censorship boundaries. You can serve different users over the same or different inbounds, identified by their UUID, and route them to different outbounds depending on configuration – effectively running a multi-tenant proxy service from a single V2Ray instance.

The Transport Layer

V2Ray separates the proxy layer from the transport layer. VMess, Shadowsocks, and other protocols define the framing and encryption of the proxied data; the transport layer defines the delivery mechanism. Any proxy protocol can be paired with any transport, providing additional flexibility.

Aside from the typical TCP transport, V2Ray also supports WebSocket, QUIC, and gRPC. Note that V2Ray requires reliability from its transport layer, so classic UDP is not supported. Instead, V2Ray supports mKCP – a UDP-based protocol with reliable delivery guarantees, designed for high-throughput, low-latency scenarios on lossy networks.

Each transport has different characteristics from a censorship-resistance standpoint. WebSocket and gRPC are notable because they are compatible with CDN services like Cloudflare – meaning the censor sees a connection to a Cloudflare IP rather than to your proxy server. QUIC has TLS 1.3 built in, but the GFW has demonstrated the ability to identify and block QUIC-based proxy connections. mKCP works over UDP, which is useful when TCP connections are being throttled, but sustained high-bandwidth UDP streams to a foreign IP are unusual and attract attention.

We will explore the interactions between transport, TLS, and censorship resistance in greater detail in the next post on TLS-based protocols.

V2Ray Layers of Abstractions

Multiplexing (Mux)

V2Ray includes a built-in multiplexing layer called Mux.Cool that lets multiple logical connections share a single transport connection. When you browse a webpage, your browser might open dozens of connections – one for the HTML, others for CSS, JavaScript, images, API calls. Without muxing, each of those connections triggers a separate proxy session, each with its own TLS handshake, protocol negotiation, and connection setup overhead. Mux.Cool bundles them into a single underlying connection, assigning each logical stream an ID and interleaving their frames.

The performance benefit is straightforward: fewer TLS handshakes, lower connection-setup latency, reduced load on the server. On high-latency links – common when your proxy is on a different continent – this can noticeably improve page load times.

The censorship-resistance trade-off is less straightforward. A real browser visiting a website opens multiple parallel TCP connections – that’s a recognizable and expected traffic pattern. A muxed proxy client opens one connection and sends all its traffic through it. To a traffic analyzer, this looks different: one long-lived, high-throughput connection where you’d expect to see many short-lived ones. The statistical fingerprint – connection duration, packet timing, bidirectional data ratios – diverges from what “normal” browsing looks like.

V2Ray Muxing

V2Ray Ecosystem

V2Ray serves as the foundation of censorship circumvention technology and has been widely adopted. After the original authors went silent, the v2fly community forked the original V2Ray into v2ray-core and continued development. More recently, another fork – Xray/Project X – introduced XTLS (covered in later posts) and has become the most actively developed branch.

Outside the core V2Ray engine, a wide range of client applications have popularized V2Ray. These are what most users install and interact with – most notably V2RayN on Windows, V2RayNG on Android, and Shadowrocket on iOS. V2Ray’s configuration is notoriously complicated due to its rich feature set, and these clients wrap the configuration process through mechanisms like URL-based subscriptions, significantly lowering the barrier to entry.

Closing Thoughts

V2Ray is the foundational software of the censorship circumvention ecosystem. Its modular design and rich feature set make it capable of handling virtually any use case, and the configuration complexity is often abstracted away by client software. In the next post, we’ll move back to the protocol side and discover an entirely new class of censorship resistance protocols – ones that lean on TLS itself as their primary defence.

References



Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • GFW Technical Review 08 – Tor
  • GFW Technical Review 07 – Active Probing
  • GFW Technical Review 06 – HTTPS and Domain Fronting
  • GFW Technical Review 05 – Shadowsocks
  • GFW Technical Review 04 – The West Chamber Project