What Is VLESS? Protocol, Xray-core and vless:// Links

VLESS in plain terms

VLESS is a stateless proxy protocol that carries traffic between a client app and a remote server. It was introduced in 2020 in the V2Ray project and has since been developed mainly in Xray-core, a V2Ray fork. Its job is deliberately narrow: authenticate the client and tell the server where to send the traffic.

Each connection opens with a short header: protocol version, user ID (a UUID), optional add-on data carrying the flow setting, a command (TCP, UDP or multiplexed), and the destination address and port. The server checks the UUID against its user list, connects to the destination and relays data both ways.

What VLESS leaves out matters just as much. For most of its history it had no encryption of its own: confidentiality came from the layer underneath, usually TLS or Reality. That keeps the protocol small and avoids encrypting the same bytes twice, which is why VLESS is usually named together with its security layer, as in "VLESS + Reality".

• Authentication: a UUID. Xray also accepts a short custom string and maps it to a UUID.
• No clock dependency: unlike VMess, VLESS has no time-based check, so a device clock that is a few minutes off doesn't break the handshake.
• Modular: transport and security are configured separately from the protocol itself.

Xray-core: the engine behind VLESS clients

VLESS is a specification; Xray-core is the most widely used program that implements it. Xray-core is open-source software written in Go, developed by Project X, and it supports other protocols too, including VMess, Trojan and Shadowsocks.

"Xray VLESS" and "V2Ray VLESS" are the same protocol on different cores. The basic wire format is shared, but newer features such as the Vision flow, Reality, XHTTP and VLESS Encryption came from Xray, and other cores may support only some of them. An Xray configuration has four main parts:

• Inbounds define where the core receives traffic from; in a client app, usually a local proxy port or a virtual network interface that the app manages.
• Outbounds define where traffic goes, such as a VLESS server with its address, port, UUID and flow.
• streamSettings, part of each inbound and outbound, set the transport (network) and the security layer: none, tls or reality.
• Routing rules decide which traffic uses which outbound. Many Xray-based apps build domain- and IP-based split tunneling on this mechanism.

Most graphical clients are front-ends for such a core: they parse your vless:// link, turn it into a configuration and start the core. That is also why two apps can handle the same link differently: they may ship different core versions.

VLESS transports: RAW (TCP), WebSocket, gRPC and XHTTP

The transport decides how VLESS data travels between client and server: the network setting in an Xray configuration, the type parameter in a vless:// link. These four are the most common.

RAW (TCP)

The default. VLESS data goes straight over a TCP connection, wrapped in TLS or Reality. Xray has renamed this transport from tcp to raw, but share links still use type=tcp. It adds the least framing overhead and is the transport most often paired with the xtls-rprx-vision flow.

WebSocket

The client sends an HTTP/1.1 request with an Upgrade header; once the server accepts it, both sides exchange WebSocket frames that carry the VLESS stream. The path and host parameters in the link apply to that first request, and the server accepts the session only on the expected path.

gRPC

Data travels as a gRPC stream over HTTP/2. The serviceName parameter names the gRPC service, and mode switches between the standard gun mode and the experimental multi mode.

XHTTP

XHTTP, previously called SplitHTTP, carries VLESS data in ordinary HTTP requests and responses over HTTP/1.1, HTTP/2 or HTTP/3. Its mode setting defines how upload and download are arranged:

• packet-up: upload is sent as a sequence of numbered POST requests; download arrives as one streaming response to a GET request.
• stream-up: upload goes in one long streaming POST; download still uses a streaming GET.
• stream-one: both directions share a single POST request and its response.
• auto: the default; the client chooses a mode based on the rest of the configuration.

So "VLESS XHTTP Reality" simply means VLESS over the XHTTP transport with Reality as the security layer. Less common transports such as HTTPUpgrade and mKCP also exist.

How VLESS connections are encrypted: TLS, Reality and VLESS Encryption

Because VLESS originally had no payload encryption, its encryption field must be set explicitly, and for years the only accepted value was none. A VLESS profile therefore relies on TLS or Reality for confidentiality unless VLESS Encryption is enabled.

TLS

This is standard TLS, the mechanism that protects HTTPS websites. The server presents a certificate for its domain, the client checks it against the name in the sni field, and session keys come from the TLS handshake. The operator therefore needs a domain and a valid certificate.

Reality

Reality is a security layer developed in Xray and built on TLS 1.3. The server doesn't need a domain or certificate of its own: the client verifies the server with its X25519 public key (pbk in the link) and presents a short ID (sid) that the server accepts. The connection looks like ordinary HTTPS traffic. Flex-VPN offers VLESS + Reality as an alternative profile over TCP/TLS alongside AmneziaWG; the AmneziaWG vs VLESS + Reality comparison explains when each one fits.

VLESS Encryption

In 2025 Xray-core added VLESS Encryption, an optional encryption layer inside the protocol itself. Its handshake, mlkem768x25519plus, combines the classic X25519 key exchange with ML-KEM-768, the post-quantum key-encapsulation mechanism NIST standardized in FIPS 203, so an attacker would have to break both to recover the session keys. The server holds a decryption string and the client a matching encryption string; Xray's own tools generate them as a pair.

In a share link, VLESS Encryption replaces encryption=none with a long generated string, and apps built on an older core can't read it. A link with encryption=none and security=reality is normal: the encryption comes from Reality.

Anatomy of a vless:// link, field by field

A vless:// link is a URL that packs a whole client profile into one line: vless://UUID@host:port?parameters#name. Here is a placeholder example for Reality over RAW with the Vision flow, the combination often called VLESS Reality Vision. None of the values point to a real server:

vless://00000000-0000-0000-0000-000000000000@vpn.example.com:443?type=tcp&security=reality&encryption=none&flow=xtls-rprx-vision&sni=www.example.com&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID#Example%20server

flow=xtls-rprx-vision selects Vision, which cuts overhead when the traffic inside the tunnel is already TLS-encrypted: rather than encrypting those bytes again, Xray can pass them through as they are. fp names a TLS client profile such as chrome or firefox; Reality profiles normally include one, and the right value is whatever the provider set.

Values are percent-encoded: a slash in a path becomes %2F and a space becomes %20. A link edited by hand with broken encoding may fail to import or quietly lose a field, so copy links exactly as issued.

Treat a vless:// link like a password: the UUID inside it is your credential, and anyone with the link can use your profile. Keep it out of shared chats and screenshots, and use a separate key for each device, as Flex-VPN recommends within your plan.

VLESS vs VMess vs Trojan

All three are proxy protocols implemented in Xray-core, and all three check a secret before relaying traffic. They differ in how much they do themselves.

VMess is the older V2Ray protocol. Its built-in encryption made sense on plain connections, but under TLS the same data is encrypted twice. VLESS dropped that duplication and the clock check, and newer Xray features target it, so VMess now appears mostly in older setups. Trojan was built around TLS from the start with a simple password check, but has no flow control.

Importing a vless:// link into Happ or v2RayTun

You rarely assemble these fields yourself. A provider gives you either a single vless:// link or a subscription link: an HTTPS address that returns one or more server profiles. With a subscription, Happ refreshes the server list on its own. VPN keys and subscriptions explains the difference.

Happ

1. Install Happ on your device; the download page lists compatible apps for each platform.
2. Copy the vless:// link or subscription link in full.
3. Open Happ and use its add or import option to paste from the clipboard, or scan a QR code where the app supports it.
4. Choose a server from the imported list and connect.
5. On the first connection, allow the app to add a VPN configuration if your system asks.

The Happ setup guide covers each platform in detail. v2RayTun follows the same import, select and connect pattern; see the v2RayTun setup guide. With Flex-VPN, you sign up in the official Telegram bot @vpn_flex_bot and receive a ready key or subscription link.

If the profile doesn't connect

• Copy the link again. A truncated link loses the fields at the end, often pbk or sid.
• Update the app. An older core may not recognize type=xhttp or a VLESS Encryption string.
• Close other VPN apps. Two VPN apps running at the same time can conflict, and phones allow only one active VPN connection.
• Don't edit server fields. Values such as sni, flow, pbk and sid have to match the server's settings.