VMess, V2Ray's Original Protocol: UUID Logins, a 90-Second Clock and the Move to VLESS
Of 543 consumer VPNs in our data, 114 say they do not offer it. Below: the services that rank highest for it.
VMess is the encrypted proxy protocol that V2Ray (Project V) shipped with from day one. Authentication, destination address, cipher selection and the data itself all travel in the very first request, identified by a UUID; every header carries a timestamp, and the server rejects the client if the clocks on both ends differ by more than about 90 seconds. It is a proxy protocol for V2Ray-family cores and apps, not a standalone VPN.
How a VMess request is built and checked
The protocol is stateless: no handshake round trip precedes real traffic. The first packet already holds the proof of identity, the target address and port, a TCP or UDP command, the chosen cipher and the start of the payload, while the response uses a separate format. The UUID, a 16-byte random value, serves as the shared secret, and the header encryption keys are derived from it. One wrong character in that string and the server silently drops everything.
The payload cipher is set on the client. The default "auto" picks AES-128-GCM on 64-bit x86 and ARM, ChaCha20-Poly1305 elsewhere; "none" and "zero" disable payload encryption, though the header stays protected. Headers come in two generations. The legacy MD5 format, built on HMAC-MD5 of the UUID and time with an AES-128-CFB instruction section tied to alterId, was deprecated after 2020, when researchers published weaknesses that let active probing fingerprint it. The AEAD header, encrypted with AES-128-GCM, begins with an authentication ID that carries the timestamp, a random value and a CRC checksum; alterId 0 selects it on any current setup. The full details live in the official VMess protocol specification. The protocol can also mask packet lengths, add random padding and tell the client to move to a dynamic port for a set number of minutes.
Why the clocks must match within 90 seconds
Every request header carries a Unix timestamp, and the server rejects requests too far from its own clock. Only UTC matters, not the time zone. The typical symptom: the client "connects" but nothing loads, and the server log shows an invalid user or a header error. Enable automatic time (NTP) on both ends before blaming the config.
VMess over TCP, WebSocket and gRPC, with or without TLS
VMess itself only defines how messages look; the core decides how the bytes travel. Adding TLS gives the protocol a real certificate and an HTTPS appearance, but then the data is encrypted twice, and WebSocket adds an extra round trip on top.
| Transport | What an observer sees | Where it fits |
|---|---|---|
| Raw TCP, no TLS | Random-looking byte stream | Quick tests on unfiltered networks |
| WebSocket + TLS | A socket on a normal HTTPS site | Behind nginx or a CDN on port 443 |
| gRPC + TLS | HTTP/2 streams to a web service | CDNs that pass gRPC, parallel streams |
mKCP, HTTP/2 and QUIC are also available as transports, with or without TLS.
Why VLESS is pushing VMess out
Put VMess inside TLS and encryption happens twice, so the CPU cost lands on cheap routers and old phones. VLESS, developed further in Xray, has no cipher of its own and leaves protection to TLS or to VLESS with Reality, and it carries no timestamp check that clock drift could break. The bigger issue is detection: a 2023 USENIX Security study described how the Great Firewall flags fully encrypted streams, and plain VMess produces exactly that signature. Servers still on the MD5-era header were exposed to active probes. The XTLS Vision flow works only with VLESS, and Reality setups in Xray are built around VLESS.
Where VMess still turns up
It remains a standard inbound on older and simpler servers. Xray-core, the v2fly core and sing-box still support it, and the difference between the Xray and V2Ray projects is covered in a separate glossary entry. Client apps such as v2rayN, v2rayNG, Shadowrocket, Hiddify, NekoBox and the Clash family (mihomo) carry it alongside Trojan and Shadowsocks. Panels like 3X-UI and Marzban offer it among their inbound types, and free config lists are full of VMess over WebSocket because those profiles survive behind a CDN with almost no setup. Among VPN providers the share is modest: in the VPNRadarLab main ranking of 377 services, 17 say they support VMess, 96 say they do not, and 264 publish nothing about it (silence in a website's features list does not mean the protocol is absent). IVPN lists V2Ray VMess over QUIC or TCP as an obfuscation option, and TorGuard and StelsVPN name it next to VLESS, Trojan and Shadowsocks. The full list of services and apps sits on the VMess ranking page.
VMess FAQ
Is VMess a VPN?
No. It proxies traffic for apps pointed at the local port; routing a whole device requires the client's TUN mode.
Is VMess still safe to use?
With AEAD headers and TLS on top, the cryptography holds. What has aged is the plain variant's visibility to DPI.
Does VMess need a domain and a certificate?
Only if you add TLS, which any filtered network warrants anyway.
VMess in a few lines
VMess identifies itself with a UUID, handles header and payload encryption on its own, and needs both clocks to agree within about 90 seconds. Keep alterId at zero for the AEAD header, set the cipher to auto, turn on NTP, and use a TLS transport on filtered networks. For new deployments VLESS is lighter and harder to spot; VMess lives on in older servers, free configs, panels and a handful of provider features.