VMessAEAD / VLESS 分享链接标准提案

[DuckSoft]

VMess / VLESS 分享链接提案

0 致谢

• @DuckSoft (@Qv2ray): 作者
• @huyz: 提出了非常多的宝贵意见
• @RPRX: 审校

1 原则

• 必须是合法的 URL
• 对机器友好、对人类可读

2 约定

• URL 字段对出现顺序不敏感，但同一字段禁止重复出现
• 所有 URL 字段的 Value 都必须使用 encodeURIComponent 进行转义处理
• 所有参数名和常数字符串均区分大小写。

3 概览

protocol://
	$(uuid)
	@
	remote-host
	:
	remote-port
?
	<protocol-specific fields>
	<transport-specific fields>
	<tls-specific fields>
#$(descriptive-text)

特别说明：$() 代表此处需要 encodeURIComponent。

4 详述

4.1 基本信息段

4.1.1 协议名称 protocol

所使用的协议名称。取值必须为 vmess 或 vless。

不可省略，不能为空字符串。

4.1.2 uuid

UUID。对应配置文件该项出站中 settings.vnext[0].users[0].id 的值。

不可省略，不能为空字符串。

4.1.3 remote-host

服务器的域名或 IP 地址。

不可省略，不能为空字符串。

IPv6 地址必须括上方括号。

IDN 域名（如“百度.cn”）必须使用 xn--xxxxxx 格式。

4.1.4 remote-port

服务器的端口号。

不可省略，必须取 [1,65535] 中的整数。

4.1.5 descriptive-text

服务器的描述信息。

可省略，不推荐为空字符串。

必须使用 encodeURIComponent 转义。

4.2 协议相关段

4.2.1 传输方式 type

协议的传输方式。对应配置文件出站中 settings.vnext[0].streamSettings.network 的值。

当前的取值必须为 tcp、kcp、ws、http、quic 其中之一，分别对应 TCP、mKCP、WebSocket、HTTP/2、QUIC 传输方式。

修订：取值还可以是 grpc，代表 gRPC 传输方式。

4.2.2 (VMess/VLESS) encryption

当协议为 VMess 时，对应配置文件出站中 settings.security，可选值为 auto / aes-128-gcm / chacha20-poly1305 / none。

省略时默认为 auto，但不可以为空字符串。除非指定为 none，否则建议省略。

当协议为 VLESS 时，对应配置文件出站中 settings.encryption，当前可选值只有 none。

省略时默认为 none，但不可以为空字符串。

特殊说明：之所以不使用 security 而使用 encryption，是因为后面还有一个底层传输安全类型 security 与这个冲突。
由 @huyz 提议，将此字段重命名为 encryption，这样不仅能避免命名冲突，还与 VLESS 保持了一致。

4.2.3 (VMess) alterId、aid 等

没有这些字段。旧的 VMess 因协议设计出现致命问题，不再适合使用或分享。

此分享标准仅针对 VMess AEAD 和 VLESS。

4.3 传输层相关段

4.3.1 底层传输安全 security

设定底层传输所使用的 TLS 类型。当前可选值有 none，tls 和 xtls。

省略时默认为 none，但不可以为空字符串。

4.3.2 (HTTP/2) path

HTTP/2 的路径。省略时默认为 /，但不可以为空字符串。不推荐省略。

必须使用 encodeURIComponent 转义。

4.3.3 (HTTP/2) host

客户端进行 HTTP/2 通信时所发送的 Host 头部。

省略时复用 remote-host，但不可以为空字符串。

若有多个域名，可使用英文逗号隔开，但中间及前后不可有空格。

必须使用 encodeURIComponent 转义。

4.3.4 (WebSocket) path

WebSocket 的路径。省略时默认为 /，但不可以为空字符串。不推荐省略。

必须使用 encodeURIComponent 转义。

4.3.5 (WebSocket) host

WebSocket 请求时 Host 头的内容。不推荐省略，不推荐设为空字符串。

必须使用 encodeURIComponent 转义。

4.3.6 (mKCP) headerType

mKCP 的伪装头部类型。当前可选值有 none / srtp / utp / wechat-video / dtls / wireguard。

省略时默认值为 none，即不使用伪装头部，但不可以为空字符串。

4.3.7 (mKCP) seed

mKCP 种子。省略时不使用种子，但不可以为空字符串。建议 mKCP 用户使用 seed。

必须使用 encodeURIComponent 转义。

4.3.8 (QUIC) quicSecurity

QUIC 的加密方式。当前可选值有 none / aes-128-gcm / chacha20-poly1305。

省略时默认值为 none。

4.3.9 (QUIC) key

当 QUIC 的加密方式不为 none 时的加密密钥。

当 QUIC 的加密方式为 none 时，此项不得出现；否则，此项必须出现，且不可为空字符串。

若出现此项，则必须使用 encodeURIComponent 转义。

4.3.10 (QUIC) headerType

QUIC 的伪装头部类型。其他同 mKCP headerType 字段定义。

4.3.11 (gRPC) serviceName

对应 gRPC 的 ServiceName。建议仅使用英文字母数字和英文句号、下划线组成。

不建议省略，不可为空字符串。

4.3.12 (gRPC) mode

对应 gRPC 的传输模式，目前有以下三种：

• gun: 即原始的 gun 传输模式，将单个 []byte 封在 Protobuf 里通过 gRPC 发送（参考资料）；
• multi: 即 Xray-Core 的 multiMode，将多组 []byte 封在一条 Protobuf 里通过 gRPC 发送；
• guna: 即通过使用自定义 Codec 的方式，直接将数据包封在 gRPC 里发送。（参考资料）

省略时默认为 gun，不可以为空字符串。

4.4 TLS 相关段

4.4.1 sni

TLS SNI，对应配置文件中的 serverName 项目。

省略时复用 remote-host，但不可以为空字符串。

4.4.2 alpn

TLS ALPN，对应配置文件中的 alpn 项目。

多个 ALPN 之间用英文逗号隔开，中间无空格。

省略时由内核决定具体行为，但不可以为空字符串。

必须使用 encodeURIComponent 转义。

4.4.3 allowInsecure

没有这个字段。不安全的节点，不适合分享。

4.4.4 (XTLS) flow

XTLS 的流控方式。可选值为 xtls-rprx-direct、xtls-rprx-splice 等。

若使用 XTLS，此项不可省略，否则无此项。此项不可为空字符串。

5 举例

# VMess + TCP，不加密（仅作示例，不安全）
vmess://[email protected]:31415?encryption=none#VMessTCPNaked
# VMess + TCP，自动选择加密。编程人员特别注意不是所有的 URL 都有问号，注意处理边缘情况。
vmess://[email protected]:9265#VMessTCPAuto
# VMess + TCP，手动选择加密
vmess://[email protected]:35897?encryption=aes-128-gcm#VMessTCPAES
# VMess + TCP + TLS，内层不加密
vmess://[email protected]:9323?encryption=none&security=tls#VMessTCPTLSNaked
# VMess + TCP + TLS，内层也自动选择加密
vmess://[email protected]:8462?security=tls#VMessTCPTLS
# VMess + TCP + TLS，内层不加密，手动指定 SNI
vmess://[email protected]:64338?encryption=none&security=tls&sni=fastgit.org#VMessTCPTLSSNI
# VLESS + TCP + XTLS
vless://[email protected]:3279?security=xtls&flow=rprx-xtls-splice#VLESSTCPXTLSSplice
# VLESS + mKCP + Seed
vless://[email protected]:50288?type=kcp&seed=69f04be3-d64e-45a3-8550-af3172c63055#VLESSmKCPSeed
# VLESS + mKCP + Seed，伪装成 Wireguard
vless://[email protected]:41971?type=kcp&headerType=wireguard&seed=69f04be3-d64e-45a3-8550-af3172c63055#VLESSmKCPSeedWG
# VMess + WebSocket + TLS
vmess://[email protected]:6939?type=ws&security=tls&host=qv2ray.net&path=%2Fsomewhere#VMessWebSocketTLS

6 补充

6.1 2020/12/21 @RPRX 关于 flow 选项的补充说明

#91 (comment)

1. -udp443 系列属于客户端选项，不建议服务器下发，是否开启应由客户端决定。

2. splice 的使用场景比较苛刻，目前要求入站“纯粹”、且运行在 Linux / Android 操作系统上。若不满足相关要求，客户端使用 direct 模式即可。

@DuckSoft 的唠叨：

1. 目前 splice 与否对服务器方面没有要求，服务器使用 direct 即可支持 splice 和 direct。建议服务器下发 direct，开启 splice 与否应由客户端自行决定。
2. 必须充分认识到，XTLS 仍处于实验性阶段，当前阶段分享链接的主要目标是方便 XTLS 节点的交换与传播，并不适用于机场大规模下发。分享链接标准的更新会紧跟 XTLS 的任何变化，在稳定版之前出现破坏性变更是大概率事件，请知悉。

[RPRX]

友情提醒：VLESS 的是基于 VLESS 0 的 提案，由于 VLESS 协议还在进化，分享标准也会随时修改，比如改定义、加字段、删字段。

如果客户端无法及时跟进 breaking change（要求不兼容旧行为，直接 breaking，避免行为混乱），请等完全确定后再实现。

[DuckSoft]

breaking 不是问题，列明变更、行为确定即可。

最怕的事情不是没有规范，而是后续的实现者要去翻看各个实现的代码，以某一实现所使用的语言/代码的特性作为规范。

Trojan-Go的分享链接规范即是我主导制定的，目前为止看来基本上达到了目的。

最后，希望这份花了4个小时反复推敲斟酌的文档能够帮后续的开发者缩减至少4个小时的开发时间，也希望VMess的悲剧不要再重演。

[RPRX]

对 VLESS flow XTLS 的补充说明：

1. 分享 Splice 出来代表希望被分享者优先使用 Splice，若系统不支持或入站不纯粹则应使用 Direct
2. 分享时应去掉 -udp443，因为这个配置仅对应本地特殊需求，不被推荐且不适合分享

计划中 XTLS 还会有些合并与优化，VLESS 则至少会有两类 UDP 增强：UDP over TCP 的 MUX 隧道、纯 UDP 多倍发包 + 长度填充

[ghost]

很好的提案
无论未来做加法还是做减法
这个提案的链接都能从容应对

[2dust]

4.2.1 传输方式 type = tcp时,进行 HTTP 伪装,这个时候如何分享这个type
是否可以这样 headerType = "http"?

https://www.v2fly.org/config/transport/tcp.html#httpheaderobject

[DuckSoft]

4.2.1 传输方式 type = tcp时,进行 HTTP 伪装,这个时候如何分享这个type
是否可以这样 headerType = "http"?

https://www.v2fly.org/config/transport/tcp.html#httpheaderobject

这个暂时没有想好，因为我记得两个客户端能进行通讯的要求是 Request 和 Response 部分都必须完全一致才可以，这是一个特别强的要求，除了把两坨 JSON 硬编码打进来我没有想到别的优雅的办法了。个人认为这样的节点可能不太适合分享。

如果选择支持 http 伪装，对应的设置的分享方式还需要仔细斟酌。
@2dust

[2dust]

那这样,我们这边暂时引用旧的做法, headerType = "http" , host="",两坨 JSON 硬编码直接内置了先.
后期确实可以把这个给抛弃

[DuckSoft]

那这样,我们这边暂时引用旧的做法, headerType = "http" , host="",两坨 JSON 硬编码直接内置了先.
后期确实可以把这个给抛弃

我觉得大概可以这样：

• headerType = "http"
• request = $(压缩过后的对应JSON)
• response = $(压缩过后的对应JSON)

画风大概如此：
vmess://[email protected]:11451?headerType=http&request=%7B%22version%22%3A%221.1%22%2C%22method%22%3A%22GET%22%2C%22path%22%3A%5B%22%2F%22%5D%2C%22headers%22%3A%7B%22Host%22%3A%5B%22www.baidu.com%22%2C%22www.bing.com%22%5D%2C%22User-Agent%22%3A%5B%22Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20WOW64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F53.0.2785.143%20Safari%2F537.36%22%2C%22Mozilla%2F5.0%20(iPhone%3B%20CPU%20iPhone%20OS%2010_0_2%20like%20Mac%20OS%20X)%20AppleWebKit%2F601.1%20(KHTML%2C%20like%20Gecko)%20CriOS%2F53.0.2785.109%20Mobile%2F14A456%20Safari%2F601.1.46%22%5D%2C%22Accept-Encoding%22%3A%5B%22gzip%2C%20deflate%22%5D%2C%22Connection%22%3A%5B%22keep-alive%22%5D%2C%22Pragma%22%3A%22no-cache%22%7D%7D&response=%7B%22version%22%3A%221.1%22%2C%22status%22%3A%22200%22%2C%22reason%22%3A%22OK%22%2C%22headers%22%3A%7B%22Content-Type%22%3A%5B%22application%2Foctet-stream%22%2C%22video%2Fmpeg%22%5D%2C%22Transfer-Encoding%22%3A%5B%22chunked%22%5D%2C%22Connection%22%3A%5B%22keep-alive%22%5D%2C%22Pragma%22%3A%22no-cache%22%7D%7D#CrazyVMessTCPHTTP

因为实在是太丑了，在写标准的时候就没有考虑要写这个，也觉得这种东西确实不太适合分享

[ghost]

那这样,我们这边暂时引用旧的做法, headerType = "http" , host="",两坨 JSON 硬编码直接内置了先.
后期确实可以把这个给抛弃

我觉得大概可以这样：

• headerType = "http"
• request = $(压缩过后的对应JSON)
• response = $(压缩过后的对应JSON)

画风大概如此：
vmess://[email protected]:11451?headerType=http&request=%7B%22version%22%3A%221.1%22%2C%22method%22%3A%22GET%22%2C%22path%22%3A%5B%22%2F%22%5D%2C%22headers%22%3A%7B%22Host%22%3A%5B%22www.baidu.com%22%2C%22www.bing.com%22%5D%2C%22User-Agent%22%3A%5B%22Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20WOW64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F53.0.2785.143%20Safari%2F537.36%22%2C%22Mozilla%2F5.0%20(iPhone%3B%20CPU%20iPhone%20OS%2010_0_2%20like%20Mac%20OS%20X)%20AppleWebKit%2F601.1%20(KHTML%2C%20like%20Gecko)%20CriOS%2F53.0.2785.109%20Mobile%2F14A456%20Safari%2F601.1.46%22%5D%2C%22Accept-Encoding%22%3A%5B%22gzip%2C%20deflate%22%5D%2C%22Connection%22%3A%5B%22keep-alive%22%5D%2C%22Pragma%22%3A%22no-cache%22%7D%7D&response=%7B%22version%22%3A%221.1%22%2C%22status%22%3A%22200%22%2C%22reason%22%3A%22OK%22%2C%22headers%22%3A%7B%22Content-Type%22%3A%5B%22application%2Foctet-stream%22%2C%22video%2Fmpeg%22%5D%2C%22Transfer-Encoding%22%3A%5B%22chunked%22%5D%2C%22Connection%22%3A%5B%22keep-alive%22%5D%2C%22Pragma%22%3A%22no-cache%22%7D%7D#CrazyVMessTCPHTTP

因为实在是太丑了，在写标准的时候就没有考虑要写这个，也觉得这种东西确实不太适合分享

把request/response base64后看起来好看一点吧

[DuckSoft]

那这样,我们这边暂时引用旧的做法, headerType = "http" , host="",两坨 JSON 硬编码直接内置了先.
后期确实可以把这个给抛弃

我觉得大概可以这样：

• headerType = "http"
• request = $(压缩过后的对应JSON)
• response = $(压缩过后的对应JSON)

画风大概如此：
vmess://[email protected]:11451?headerType=http&request=%7B%22version%22%3A%221.1%22%2C%22method%22%3A%22GET%22%2C%22path%22%3A%5B%22%2F%22%5D%2C%22headers%22%3A%7B%22Host%22%3A%5B%22www.baidu.com%22%2C%22www.bing.com%22%5D%2C%22User-Agent%22%3A%5B%22Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20WOW64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F53.0.2785.143%20Safari%2F537.36%22%2C%22Mozilla%2F5.0%20(iPhone%3B%20CPU%20iPhone%20OS%2010_0_2%20like%20Mac%20OS%20X)%20AppleWebKit%2F601.1%20(KHTML%2C%20like%20Gecko)%20CriOS%2F53.0.2785.109%20Mobile%2F14A456%20Safari%2F601.1.46%22%5D%2C%22Accept-Encoding%22%3A%5B%22gzip%2C%20deflate%22%5D%2C%22Connection%22%3A%5B%22keep-alive%22%5D%2C%22Pragma%22%3A%22no-cache%22%7D%7D&response=%7B%22version%22%3A%221.1%22%2C%22status%22%3A%22200%22%2C%22reason%22%3A%22OK%22%2C%22headers%22%3A%7B%22Content-Type%22%3A%5B%22application%2Foctet-stream%22%2C%22video%2Fmpeg%22%5D%2C%22Transfer-Encoding%22%3A%5B%22chunked%22%5D%2C%22Connection%22%3A%5B%22keep-alive%22%5D%2C%22Pragma%22%3A%22no-cache%22%7D%7D#CrazyVMessTCPHTTP
因为实在是太丑了，在写标准的时候就没有考虑要写这个，也觉得这种东西确实不太适合分享

把request/response base64后看起来好看一点吧

那大概会变成：
vmess://[email protected]:11451?headerType=http&request=eyJ2ZXJzaW9uIjoiMS4xIiwibWV0aG9kIjoiR0VUIiwicGF0aCI6WyIvIl0sImhlYWRlcnMiOnsiSG9zdCI6WyJ3d3cuYmFpZHUuY29tIiwid3d3LmJpbmcuY29tIl0sIlVzZXItQWdlbnQiOlsiTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV09XNjQpIEFwcGxlV2ViS2l0LzUzNy4zNiAoS0hUTUwsIGxpa2UgR2Vja28pIENocm9tZS81My4wLjI3ODUuMTQzIFNhZmFyaS81MzcuMzYiLCJNb3ppbGxhLzUuMCAoaVBob25lOyBDUFUgaVBob25lIE9TIDEwXzBfMiBsaWtlIE1hYyBPUyBYKSBBcHBsZVdlYktpdC82MDEuMSAoS0hUTUwsIGxpa2UgR2Vja28pIENyaU9TLzUzLjAuMjc4NS4xMDkgTW9iaWxlLzE0QTQ1NiBTYWZhcmkvNjAxLjEuNDYiXSwiQWNjZXB0LUVuY29kaW5nIjpbImd6aXAsIGRlZmxhdGUiXSwiQ29ubmVjdGlvbiI6WyJrZWVwLWFsaXZlIl0sIlByYWdtYSI6Im5vLWNhY2hlIn19&response=eyJ2ZXJzaW9uIjoiMS4xIiwic3RhdHVzIjoiMjAwIiwicmVhc29uIjoiT0siLCJoZWFkZXJzIjp7IkNvbnRlbnQtVHlwZSI6WyJhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0iLCJ2aWRlby9tcGVnIl0sIlRyYW5zZmVyLUVuY29kaW5nIjpbImNodW5rZWQiXSwiQ29ubmVjdGlvbiI6WyJrZWVwLWFsaXZlIl0sIlByYWdtYSI6Im5vLWNhY2hlIn19#CrazyVMessTCPHTTPBase64

如果先用 zlib 过一遍，大概会变成：
vmess://[email protected]:11451?headerType=http&request=eJxtkWGLgkAQhv_KsJ8KdNVSu6tPElHQeQUVHsQR2zrpku6KeglF__1Wu4ML7tu-s-_MPLxzIxcsK6EkGROHOsQgOdapirWcz7ZaFqxOyXhPLPJpkBRZrO1kfCMLVdVtvWkaemQi_qJc5drfaSGTTuqWXYWlGSQoO3eoriLLmOVRG3qRkLFqKnjfgmNTewLRKvLdPgRFkWGEx6WoLW84okMfesvFNnwzIBNnhDnys-rDNC1VjtpBbToYvXjUcYewYSdWip82jfO0UKxTJXEC0_UOHm9YbfTug30YPEaHjLelj2cI39bR_M9QitXmL4L9CqE6igwtxw1cz_8F6kZQ128jCTjHojZnkqtYJ9XmklxFYUCMp4zV2HqmSkrkdXeYPTkjFibLxKX7W5csyZm-kFQmZzxFcr9_A2IUiKg&response=eJwdjrEOgzAMRP_FMynQkbXq1KEd2BCDlbgQAU6UGKQK8e81jKd373Q7bJSyDwwN1LcaCsiCsmaN96rSmAjzRd8vTSOh0z40OzwCC7GY9hcJmg4wxtlbFN0qgxUSk0XlRa3NOwrlEmmAvoA2IecvJfNkG5zn4bTtuPJE7uQ6zGTl-tTBRBQNzn6jk30SDgvqGw7Goh0JjuMPXNJBHw

最后吐槽一次，实在是实在是实在是太丑了……

[2dust]

v2rayN现在的做法,分享
headerType = "http"
host = "a.com,b.com"
然后
requestHost = 内置JSON 拼接上上面的host
所有不需要分享整个requestHost

如果要分享整个requestHost,那的确不合适

[ghost]

v2rayN现在的做法,分享
headerType = "http"
host = "a.com,b.com"
然后
requestHost = 内置JSON 拼接上上面的host
所有不需要分享整个requestHost

如果要分享整个requestHost,那的确不合适

大佬预计啥时候释出支持此方案的N或NG？

[ghost]

4.3.3 (HTTP/2) host

客户端进行 HTTP/2 通信时所发送的 Host 头部。

省略时复用 remote-host，但不可以为空字符串。

4.4.1 sni

TLS SNI，对应配置文件中的 serverName 项目。

省略时复用 remote-host，但不可以为空字符串。

省略时复用 remote-host是否合理，我觉得省略时应该设置为空。
这俩设置如果为空，会自动使用"address"中的域名进行连接。

4.3.5 (WebSocket) host

WebSocket 请求时 Host 头的内容。不推荐省略，不推荐设为空字符串。

省略时的行为没有说。

[DuckSoft]

4.3.3 (HTTP/2) host

客户端进行 HTTP/2 通信时所发送的 Host 头部。
省略时复用 remote-host，但不可以为空字符串。

4.4.1 sni

TLS SNI，对应配置文件中的 serverName 项目。
省略时复用 remote-host，但不可以为空字符串。

省略时复用 remote-host是否合理，我觉得省略时应该设置为空。
这俩设置如果为空，会自动使用"address"中的域名进行连接。

4.3.5 (WebSocket) host

WebSocket 请求时 Host 头的内容。不推荐省略，不推荐设为空字符串。

省略时的行为没有说。

4.3.5 省略时的就是没有那个 Host Header，具体行为由核心负责。

4.3.3 和 4.4.1 省略的时候的效果应该同直接配置文件不写那一项相同，稍后修订，同样具体行为核心负责。

另外，置空和省略是不同的。

[ghost]

4.3.5 省略时的就是没有那个 Host Header，具体行为由核心负责。

4.3.3 和 4.4.1 省略的时候的效果应该同直接配置文件不写那一项相同，稍后修订，同样具体行为核心负责。

另外，置空和省略是不同的。

即：
省略：json中没有这一项
置空：json中设置为 ""？

如sni：
省略：对应json中没有serverName这一项
置空：对应json "serverName": ""

[ghost]

另外，置空和省略是不同的。

抱歉是我疏忽了，json文件中websocket host 置空和省略行为确实不同

[Butterflyflower]

我自定义id "#7544@" 无法用分享链接导入v2rayng。

[Butterflyflower]

vless://#7544@@udhdhjv.xyz:443?security=xtls&encryption=none&headerType=none&type=tcp&flow=xtls-rprx-splice#%F0%9F%87%B8%F0%9F%87%AC%E6%96%B0%E5%8A%A0%E5%9D%A1

[Butterflyflower]

@Butterflyflower 这个链接我导入不到v2rayng中，是不是要去v2rayng反馈。

[RPRX]

@Butterflyflower 分享链接只有 uuid，自定义 id 不直接分享

[dyhkwong]

4.4.2 alpn

TLS ALPN，对应配置文件中的 alpn 项目。

多个 ALPN 之间用英文逗号隔开，中间无空格。

省略时默认为 h2,http/1.1，但不可以为空字符串。

必须使用 encodeURIComponent 转义。

alpn 项省略/为空时， tcp 和 http 的 ALPN 为 h2,http/1.1，ws 的 ALPN 为 http/1.1，与此处似乎不符

[DuckSoft]

4.4.2 alpn

TLS ALPN，对应配置文件中的 alpn 项目。
多个 ALPN 之间用英文逗号隔开，中间无空格。
省略时默认为 h2,http/1.1，但不可以为空字符串。
必须使用 encodeURIComponent 转义。

alpn 项省略/为空时， tcp 和 http 的 ALPN 为 h2,http/1.1，ws 的 ALPN 为 http/1.1，与此处似乎不符

的确，此处应该遵循内核的空值行为

[ghost]

请问multiMode这个属性怎么表示，是用multiMode=0|1来代表真假，还是true,false？

[DuckSoft]

请问multiMode这个属性怎么表示，是用multiMode=0|1来代表真假，还是true,false？

按道理来说，MultiMode 与传统的 gun 完全不兼容，应该作为一种新的传输类型（比如叫 multigun），以防止客户端软件误认为带有 multiMode=1 的分享链接是支持的格式。

暂时能确定的应该只有 serviceName 这样一个新的属性，至于 multi 与否，需要进一步的讨论和协商。

[ghost]

@DuckSoft

我想说一下我个人的想法，这个想法之前就有想过了，与MultiMode无关。

这个想法是，把分享链接是json文件outbound部分一种映射，即在指定分享链接标准的时候，只需要考虑这个分享链接对应的json文件应该是什么样子的，而不需要考虑上游的行为。

简单点说就是：给出一个分享链接，根据分享链接能且仅能写出一个outbound。

我也不知道我的想法好不好，轻喷

当然有的部分变通也是好的，比如allowInsecure不能写，且对应json文件一定是false。这个我就觉得很好。

所以我想问的是，当json中有键值对的数据是布尔类型时，在分享链接上应该如何表示。不一定是multiMode，以后可能有别的属性是布尔类型的。

[DuckSoft]

@kirin10000 我的倾向是布尔值有且仅有三种取值，要么未指定，要么是0，要么是1，不能为空。
有效的例子：根本没这项 / something=0 / something=1
无效的例子：something=yes / something=no / something=True / something=true / something=on / something= / ...

至于multiMode这种，我认为未来可能还会出来更多种类的互不兼容的模式，出于这样的考虑我不想把他作为布尔型。
我们可以这样写：mode=gun / mode=multi，仅供参考。

[xumng123]

XTLS 的流控方式。可选值为 xtls-rprx-direct、xtls-rprx-splice 等。

但是例子里面又变成了“rprx-xtls-splice”，rprx和xtls的顺序反过来了。规范还是严谨一些好。

[wc7086]

XTLS 的流控方式。可选值为 xtls-rprx-direct、xtls-rprx-splice 等。

但是例子里面又变成了“rprx-xtls-splice”，rprx和xtls的顺序反过来了。规范还是严谨一些好。

可能是当时就是写成rprx-xtls-splice rprx-xtls-direct

@DuckSoft 建议修改一下例子

[rurirei]

XTLS 的流控方式。可选值为 xtls-rprx-direct、xtls-rprx-splice 等。
但是例子里面又变成了“rprx-xtls-splice”，rprx和xtls的顺序反过来了。规范还是严谨一些好。

the name rprx- is not on a standard in fact.

[wc7086]

XTLS 的流控方式。可选值为 xtls-rprx-direct、xtls-rprx-splice 等。
但是例子里面又变成了“rprx-xtls-splice”，rprx和xtls的顺序反过来了。规范还是严谨一些好。

the name rprx- is not on a standard in fact.

他指的应该是 5 举例 中的错误
不知道是 @DuckSoft 写错了还是当时就是以 rprx- 开头，现在需要等 @DuckSoft 修改

[zeromake]

@DuckSoft
我有个问题啊像 AnXray 这种客户端在 tls 模式下可以把自己的自签证书放进去，这算是安全还是不安全呢？如果算安全是不是应当导出这个证书呢。

[recall704]

为什么不直接用 json 呢？

vless://base64encode({"host":"11.11.11.11", "port": 443, "uuid": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"})

客户端只需要 json.Unmarshal 一下，就可以了