A VLESS server is described by a user ID (a UUID), its security (none, TLS or REALITY) and a transport that carries the connection, such as WebSocket or gRPC. It can also use the Vision flow, which hides the "TLS inside TLS" pattern of proxied HTTPS traffic, and VLESS Encryption, Xray's post-quantum encryption layer. Potatso connects to a server when it supports all of these settings. Use the tables below to check your server's settings, as shown by your provider or in its vless:// link.
You can add a VLESS server by hand, with a vless:// link, or by importing:
- a Clash or Mihomo subscription,
- an Xray or V2Ray configuration.
Potatso doesn't import VLESS servers from a sing-box configuration yet. Use the server's vless:// link instead.
Every supported setting below is tested against real Xray and sing-box servers.
User ID
The user ID is normally a UUID, such as 3971e1b2-18a3-4f83-8fa6-bf9b142ee258. Xray servers also accept any other text of up to 30 characters as an ID, and turn it into a UUID the same way every client does. Potatso does too, so use the ID exactly as your provider gives it.
Transports
| Transport | Link type |
Supported | Tested with |
|---|---|---|---|
| No transport (raw TCP) | tcp, raw, or none |
✅ | Xray, sing-box |
| WebSocket | ws |
✅ With or without early data | Xray, sing-box |
| gRPC | grpc |
✅ | Xray, sing-box |
| HTTP Upgrade | httpupgrade |
✅ | Xray, sing-box |
| XHTTP | xhttp, splithttp |
✅ In stream-one and auto mode |
Xray |
| HTTP/2 | http or h2 |
✅ | sing-box |
| mKCP | kcp |
❌ | |
| QUIC | quic |
❌ | |
| TCP with HTTP header obfuscation | tcp with headerType=http |
❌ |
Every transport works with and without TLS, and with UDP. Potatso doesn't import a server whose transport it doesn't support.
Xray no longer offers HTTP/2 or QUIC: Xray servers that used them now use XHTTP.
XHTTP
XHTTP (formerly SplitHTTP) has several modes. Potatso sends the whole connection as one HTTP request (stream-one). An Xray server accepts that in its default auto mode and in stream-one and stream-up mode, so a link with mode=auto, or no mode, works.
Potatso doesn't support the packet-up and stream-up client modes, and doesn't import a link that asks for them. The extra parameter of an XHTTP link isn't supported: Potatso ignores it. Potatso edits XHTTP servers with TLS or REALITY; an imported XHTTP server without TLS still works.
Security
| Security | Link security |
Supported |
|---|---|---|
| None | none, or none |
✅ Your traffic isn't encrypted unless the server uses VLESS Encryption. |
| TLS | tls |
✅ |
| REALITY | reality |
✅ With no transport, gRPC or XHTTP |
TLS settings
| Setting | Clash key | Link parameter | Supported |
|---|---|---|---|
| Server name (SNI) | servername |
sni |
✅ Without one, Potatso uses the server's address. |
| ALPN | alpn |
alpn |
✅ Without one, Potatso sends http/1.1 for WebSocket, h2 for gRPC, HTTP/2 and XHTTP, and nothing for the others. |
| Skip certificate verification | skip-cert-verify |
allowInsecure, insecure |
✅ |
| Certificate pinning (SHA-256) | fingerprint |
pcs |
✅ One certificate |
| Verify the certificate for another name | vcn |
❌ Potatso checks the certificate against the server name. | |
| Browser fingerprint | client-fingerprint |
fp |
✅ chrome, firefox, safari, ios, android, edge and random. Other names connect with a default handshake. |
| Encrypted Client Hello (ECH) | ech-opts |
ech |
✅ With the ECH configuration in the link or subscription |
| Custom CA certificate | ❌ | ||
| TLS client certificate | certificate, private-key |
❌ |
Turning off certificate verification lets anyone between you and the server read your traffic. Pin the server's certificate instead if it uses a self-signed one: set the SHA-256 of its certificate as the certificate pin. Potatso pins one certificate; it doesn't import a link that lists several in pcs.
A browser fingerprint makes the connection's TLS handshake look like that browser's. It doesn't change what the server must support.
REALITY
A REALITY server borrows another website's TLS certificate, so it doesn't need one of its own. Set the server's public key and short ID as your provider gives them, and the server name to the website the server borrows from. The link's spx (spider path) isn't needed to connect, and Potatso ignores it.
REALITY needs a browser fingerprint: when your link or settings don't have one, Potatso uses chrome. With REALITY, android and names Potatso doesn't know also connect as chrome.
REALITY works with no transport, gRPC and XHTTP.
Vision flow
| Flow | Link flow |
Supported |
|---|---|---|
| None | none | ✅ |
| Vision | xtls-rprx-vision |
✅ |
| Vision, UDP 443 allowed | xtls-rprx-vision-udp443 |
✅ |
xtls-rprx-direct, xtls-rprx-splice and other old XTLS flows |
❌ Xray removed them |
Vision works only with no transport and TLS or REALITY: Potatso doesn't save or import a Vision server with another transport or without TLS. It also works with VLESS Encryption on top of TLS.
With Vision, UDP is carried the way Xray carries it, over Mux.Cool, which both Xray and sing-box servers accept. Xray's own client refuses UDP to port 443 (QUIC) with xtls-rprx-vision, so that browsers fall back to TCP; Potatso carries it with both flows.
VLESS Encryption
VLESS Encryption (mlkem768x25519plus) is Xray's post-quantum encryption layer: an ML-KEM-768 and X25519 key exchange under the VLESS connection. The server's decryption setting has a matching encryption value for clients, which looks like this:
mlkem768x25519plus.native.0rtt.<key>| Setting | Supported |
|---|---|
Modes native, xorpub and random |
✅ |
1rtt and 0rtt (resumed connections) |
✅ |
| Server authenticated with an X25519 or an ML-KEM-768 key | ✅ |
| With no transport and no TLS | ✅ |
| On top of TLS | ✅ Also with Vision |
| Vision without TLS | ❌ |
Potatso keeps the encryption value of a link, Clash subscription or Xray configuration. You can't type one in the server's settings yet.
Multiplexing
Potatso can run several connections over one VLESS connection, set with smux in a Clash subscription:
| Protocol | Clash smux.protocol |
Servers | Supported |
|---|---|---|---|
| Mux.Cool (Xray) | muxcool |
Xray, sing-box | ✅ TCP and UDP |
| sing-box multiplexing | smux, yamux, h2mux |
sing-box, with multiplexing turned on | ✅ TCP and UDP, with or without padding |
With Vision, Mux.Cool carries only UDP and each TCP connection keeps its own connection, as in Xray. sing-box multiplexing doesn't work with Vision, and Potatso doesn't import a Vision server that asks for it.
Xray's mux settings in an Xray configuration aren't imported.
UDP
VLESS carries UDP over the same connection as TCP. UDP is off by default, as in Clash. Turn on UDP Relay in the server's settings if your server relays UDP: Xray and sing-box both do. A Clash subscription turns it on with udp: true.
Each UDP flow gets its own connection to the server, and each destination its own flow. Potatso doesn't support XUDP or packetaddr (packetEncoding in a link, packet-encoding or xudp in a subscription): servers accept Potatso's UDP without them, and Potatso ignores the setting.
Feature support
| Feature | Supported |
|---|---|
| VLESS protocol version 0: TCP and UDP commands | ✅ |
| UUID and text user IDs | ✅ |
| Several users on one server | ✅ Each with their own ID |
Vision flow (xtls-rprx-vision, -udp443) |
✅ See Vision |
VLESS Encryption (mlkem768x25519plus) |
✅ See VLESS Encryption |
| TLS, REALITY, ECH, certificate pinning, browser fingerprints | ✅ See Security |
| WebSocket, gRPC, HTTP Upgrade, HTTP/2 transports | ✅ See Transports |
| XHTTP | stream-one and auto mode |
| mKCP, QUIC, TCP HTTP header obfuscation | ❌ |
| Mux.Cool | ✅ |
| XUDP, packetaddr | ❌ UDP uses the plain UDP command |
| sing-box multiplexing (smux, yamux, h2mux) | ✅ |
Reverse proxy (VLESS reverse) |
❌ It's a server feature |
vless:// links (Xray share link standard) |
✅ |
vless:// links
A vless:// link holds a whole server in one line:
vless://id@host:port?type=…&security=…&…#name| Part | Description |
|---|---|
id |
The user ID. |
host |
Server address. Put an IPv6 address in square brackets, such as [2001:db8::1]. |
port |
Server port. |
encryption |
none, or a VLESS Encryption value. |
flow |
Optional. xtls-rprx-vision or xtls-rprx-vision-udp443. |
type |
The transport. |
security |
none, tls or reality. |
sni, alpn, fp, pcs, ech, allowInsecure |
TLS settings. |
pbk, sid |
The REALITY public key and short ID. |
host, path |
The Host header and path of WebSocket, HTTP Upgrade, HTTP/2 and XHTTP. A WebSocket path can carry early data as ?ed=2048. |
serviceName |
The gRPC service name. |
mode |
The XHTTP mode. |
name |
Optional. The server's name in Potatso. |
When Potatso shares a VLESS server, it writes a link in this form.
Examples
Each example shows the link to import. The user ID is 3971e1b2-18a3-4f83-8fa6-bf9b142ee258.
TLS with no transport:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=tls&sni=vless.example.com&type=tcp#TLSREALITY with Vision, borrowing www.example.com:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=reality&sni=www.example.com&fp=chrome&pbk=Z84J2IelR9ch3k8VtlVhhs5ycBUlXA7wHBWcBrjqnAw&sid=0123abcd&type=tcp&flow=xtls-rprx-vision#REALITY-VisionWebSocket over TLS through a CDN, with 2048 bytes of early data:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=tls&type=ws&host=cdn.example.com&path=%2Fws%3Fed%3D2048#WebSocketgRPC over TLS:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=tls&type=grpc&serviceName=gun#gRPCHTTP Upgrade over TLS:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=tls&type=httpupgrade&host=cdn.example.com&path=%2Fup#HTTPUpgradeXHTTP over TLS:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=tls&type=xhttp&host=cdn.example.com&path=%2Fxh&mode=auto#XHTTPHTTP/2 over TLS:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:443?security=tls&type=http&host=cdn.example.com&path=%2Fh2#HTTP2VLESS Encryption with no TLS:
vless://3971e1b2-18a3-4f83-8fa6-bf9b142ee258@vless.example.com:8443?security=none&encryption=mlkem768x25519plus.native.0rtt.u7dtLE6KgE4mjeBK3oYdNMw6MJB47Ijr_9AG2avwSmY&type=tcp#Encryption