VMessAEAD / VLESS 分享链接标准提案

Question

VMessAEAD / VLESS 分享链接标准提案

DuckSoft opened this issue 5 years ago · 56 comments

DuckSoft commented 5 years ago

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://99c80931-f3f1-4f84-bffd-6eed6030f53d@qv2ray.net:31415?encryption=none#VMessTCPNaked
# VMess + TCP，自动选择加密。编程人员特别注意不是所有的 URL 都有问号，注意处理边缘情况。
vmess://f08a563a-674d-4ffb-9f02-89d28aec96c9@qv2ray.net:9265#VMessTCPAuto
# VMess + TCP，手动选择加密
vmess://5dc94f3a-ecf0-42d8-ae27-722a68a6456c@qv2ray.net:35897?encryption=aes-128-gcm#VMessTCPAES
# VMess + TCP + TLS，内层不加密
vmess://136ca332-f855-4b53-a7cc-d9b8bff1a8d7@qv2ray.net:9323?encryption=none&security=tls#VMessTCPTLSNaked
# VMess + TCP + TLS，内层也自动选择加密
vmess://be5459d9-2dc8-4f47-bf4d-8b479fc4069d@qv2ray.net:8462?security=tls#VMessTCPTLS
# VMess + TCP + TLS，内层不加密，手动指定 SNI
vmess://c7199cd9-964b-4321-9d33-842b6fcec068@qv2ray.net:64338?encryption=none&security=tls&sni=fastgit.org#VMessTCPTLSSNI
# VLESS + TCP + XTLS
vless://b0dd64e4-0fbd-4038-9139-d1f32a68a0dc@qv2ray.net:3279?security=xtls&flow=rprx-xtls-splice#VLESSTCPXTLSSplice
# VLESS + mKCP + Seed
vless://399ce595-894d-4d40-add1-7d87f1a3bd10@qv2ray.net:50288?type=kcp&seed=69f04be3-d64e-45a3-8550-af3172c63055#VLESSmKCPSeed
# VLESS + mKCP + Seed，伪装成 Wireguard
vless://399ce595-894d-4d40-add1-7d87f1a3bd10@qv2ray.net:41971?type=kcp&headerType=wireguard&seed=69f04be3-d64e-45a3-8550-af3172c63055#VLESSmKCPSeedWG
# VMess + WebSocket + TLS
vmess://44efe52b-e143-46b5-a9e7-aadbfd77eb9c@qv2ray.net:6939?type=ws&security=tls&host=qv2ray.net&path=%2Fsomewhere#VMessWebSocketTLS

6 补充

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

#91 (comment)

-udp443 系列属于客户端选项，不建议服务器下发，是否开启应由客户端决定。
splice 的使用场景比较苛刻，目前要求入站“纯粹”、且运行在 Linux / Android 操作系统上。若不满足相关要求，客户端使用 direct 模式即可。

@DuckSoft 的唠叨：

目前 splice 与否对服务器方面没有要求，服务器使用 direct 即可支持 splice 和 direct。建议服务器下发 direct，开启 splice 与否应由客户端自行决定。

必须充分认识到，XTLS 仍处于实验性阶段，当前阶段分享链接的主要目标是方便 XTLS 节点的交换与传播，并不适用于机场大规模下发。分享链接标准的更新会紧跟 XTLS 的任何变化，在稳定版之前出现破坏性变更是大概率事件，请知悉。

Answer 1 · 2020-12-21T04:20:29.000Z

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

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

Answer 2 · 2020-12-21T04:29:23.000Z

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

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

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

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

Answer 3 · 2020-12-21T10:30:38.000Z

对 VLESS flow XTLS 的补充说明：

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

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

Answer 4 · 2020-12-22T11:54:55.000Z

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

Answer 5 · 2021-01-04T08:24:00.000Z

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

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

Answer 6 · 2021-01-04T08:26:45.000Z

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

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

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

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

Answer 7 · 2021-01-04T08:31:36.000Z

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

Answer 8 · 2021-01-04T08:37:44.000Z

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

我觉得大概可以这样：

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

画风大概如此：
vmess://399ce595-894d-4d40-add1-7d87f1a3bd10@example.com: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

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

Answer 9 · 2021-01-04T08:40:27.000Z

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

我觉得大概可以这样：

headerType = "http"

request = $(压缩过后的对应JSON)

response = $(压缩过后的对应JSON)

画风大概如此：
vmess://399ce595-894d-4d40-add1-7d87f1a3bd10@example.com: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后看起来好看一点吧

Answer 10 · 2021-01-04T08:43:54.000Z

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

我觉得大概可以这样：

headerType = "http"

request = $(压缩过后的对应JSON)

response = $(压缩过后的对应JSON)

画风大概如此：
vmess://399ce595-894d-4d40-add1-7d87f1a3bd10@example.com: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://399ce595-894d-4d40-add1-7d87f1a3bd10@example.com:11451?headerType=http&request=eyJ2ZXJzaW9uIjoiMS4xIiwibWV0aG9kIjoiR0VUIiwicGF0aCI6WyIvIl0sImhlYWRlcnMiOnsiSG9zdCI6WyJ3d3cuYmFpZHUuY29tIiwid3d3LmJpbmcuY29tIl0sIlVzZXItQWdlbnQiOlsiTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV09XNjQpIEFwcGxlV2ViS2l0LzUzNy4zNiAoS0hUTUwsIGxpa2UgR2Vja28pIENocm9tZS81My4wLjI3ODUuMTQzIFNhZmFyaS81MzcuMzYiLCJNb3ppbGxhLzUuMCAoaVBob25lOyBDUFUgaVBob25lIE9TIDEwXzBfMiBsaWtlIE1hYyBPUyBYKSBBcHBsZVdlYktpdC82MDEuMSAoS0hUTUwsIGxpa2UgR2Vja28pIENyaU9TLzUzLjAuMjc4NS4xMDkgTW9iaWxlLzE0QTQ1NiBTYWZhcmkvNjAxLjEuNDYiXSwiQWNjZXB0LUVuY29kaW5nIjpbImd6aXAsIGRlZmxhdGUiXSwiQ29ubmVjdGlvbiI6WyJrZWVwLWFsaXZlIl0sIlByYWdtYSI6Im5vLWNhY2hlIn19&response=eyJ2ZXJzaW9uIjoiMS4xIiwic3RhdHVzIjoiMjAwIiwicmVhc29uIjoiT0siLCJoZWFkZXJzIjp7IkNvbnRlbnQtVHlwZSI6WyJhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0iLCJ2aWRlby9tcGVnIl0sIlRyYW5zZmVyLUVuY29kaW5nIjpbImNodW5rZWQiXSwiQ29ubmVjdGlvbiI6WyJrZWVwLWFsaXZlIl0sIlByYWdtYSI6Im5vLWNhY2hlIn19#CrazyVMessTCPHTTPBase64

如果先用 zlib 过一遍，大概会变成：
vmess://399ce595-894d-4d40-add1-7d87f1a3bd10@example.com:11451?headerType=http&request=eJxtkWGLgkAQhv_KsJ8KdNVSu6tPElHQeQUVHsQR2zrpku6KeglF__1Wu4ML7tu-s-_MPLxzIxcsK6EkGROHOsQgOdapirWcz7ZaFqxOyXhPLPJpkBRZrO1kfCMLVdVtvWkaemQi_qJc5drfaSGTTuqWXYWlGSQoO3eoriLLmOVRG3qRkLFqKnjfgmNTewLRKvLdPgRFkWGEx6WoLW84okMfesvFNnwzIBNnhDnys-rDNC1VjtpBbToYvXjUcYewYSdWip82jfO0UKxTJXEC0_UOHm9YbfTug30YPEaHjLelj2cI39bR_M9QitXmL4L9CqE6igwtxw1cz_8F6kZQ128jCTjHojZnkqtYJ9XmklxFYUCMp4zV2HqmSkrkdXeYPTkjFibLxKX7W5csyZm-kFQmZzxFcr9_A2IUiKg&response=eJwdjrEOgzAMRP_FMynQkbXq1KEd2BCDlbgQAU6UGKQK8e81jKd373Q7bJSyDwwN1LcaCsiCsmaN96rSmAjzRd8vTSOh0z40OzwCC7GY9hcJmg4wxtlbFN0qgxUSk0XlRa3NOwrlEmmAvoA2IecvJfNkG5zn4bTtuPJE7uQ6zGTl-tTBRBQNzn6jk30SDgvqGw7Goh0JjuMPXNJBHw

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

Answer 11 · 2021-01-04T08:54:05.000Z

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

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

Answer 12 · 2021-01-04T09:13:44.000Z

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

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

我有一个建议：可以考虑在此基础上，仅提取必要且通用的字段出来，具体如下：

在 HTTPRequestObject 中，取出 method, host, path，其中 host 和 path 应支持逗号分隔多项，省略则使用各自对应的缺省行为；
在 HTTPResponseObject 中，取出 status, reason，省略则使用缺省行为；
将 method, host, path, status, reason 的值覆盖到 request 和 response 中，形成新的 request 和 response。若未指定 request 和 response，request 和 response 均应使用 {} 作为初始值。

这样一来操作很复杂，不过应该足够简化一些情况下的配置了，不知意下如何。

当然，如果我是开发者的话，我肯定就暴力 JSON 了，因为上面的过程的确太复杂了，为了这样一个冷门场景做优化不是很值得。
为了降低实际的开发压力，建议直接暴力两坨 JSON 带走。

Answer 13 · 2021-01-04T10:20:40.000Z

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

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

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

Answer 14 · 2021-01-05T11:43:34.000Z

约简单越好，就是翻个墙而已
不需要弄那么复杂

Answer 15 · 2021-01-05T12:20:51.000Z

约简单越好，就是翻个墙而已
不需要弄那么复杂

请你定义下简单和复杂

Answer 16 · 2021-01-06T17:10:29.000Z

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 头的内容。不推荐省略，不推荐设为空字符串。

省略时的行为没有说。

Answer 17 · 2021-01-06T17:15:51.000Z

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 省略的时候的效果应该同直接配置文件不写那一项相同，稍后修订，同样具体行为核心负责。

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

Answer 18 · 2021-01-06T17:20:28.000Z

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

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

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

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

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

Answer 19 · 2021-01-06T17:48:34.000Z

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

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

Answer 20 · 2021-01-22T01:52:34.000Z

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

Answer 21 · 2021-01-22T01:53:03.000Z

我觉得可以引入可选的分享加密（基于AES），自定义密钥，防止未授权的传播，之前的vmess就有很多泄露出去的，根本base64只是让人看不懂。而且实现AES也不会很复杂，更加保护分享的安全。适用于个人分享，以及保护订阅被盗时阻止非法访问。
具体可以这样：密文头部改为 Avless://或 Avmess:// 以提示需要自定义密钥解密。

Answer 22 · 2021-01-22T01:53:29.000Z

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

Answer 23 · 2021-01-22T01:55:02.000Z

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

Answer 24 · 2021-01-22T01:57:39.000Z

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

Answer 25 · 2021-01-22T02:04:01.000Z

我觉得可以引入可选的分享加密（基于AES），自定义密钥，防止未授权的传播，之前的vmess就有很多泄露出去的，根本base64只是让人看不懂。而且实现AES也不会很复杂，更加保护分享的安全。适用于个人分享，以及保护订阅被盗时阻止非法访问。
具体可以这样：密文头部改为 Avless://或 Avmess:// 以提示需要自定义密钥解密。

用处不大把,要分享的话仍然可以转换成普通链接

Answer 26 · 2021-01-22T11:59:21.000Z

我觉得可以引入可选的分享加密（基于AES），自定义密钥，防止未授权的传播，之前的vmess就有很多泄露出去的，根本base64只是让人看不懂。而且实现AES也不会很复杂，更加保护分享的安全。适用于个人分享，以及保护订阅被盗时阻止非法访问。
具体可以这样：密文头部改为 Avless://或 Avmess:// 以提示需要自定义密钥解密。

用处不大把,要分享的话仍然可以转换成普通链接

主要保护传输，防止被盗，对于订阅链接场景就很有用。

Answer 27 · 2021-01-22T12:05:33.000Z

@RainThings 你说的是服务端发送加密配置文件到客户端，客户端对用户保持加密，可以防止用户泄露配置信息？

但是这个应该由客户端与机场后端实现，不应该找Xray-core。

Answer 28 · 2021-01-30T01:30:30.000Z

其实前面uuid ip 端口号人类可读也就行了
其他都堆后面尽量压缩压缩变短，熵高，不用多整齐
选中那段链接，小手需要拖动多少距离，是我这种普通用户关心的。

Answer 29 · 2021-01-30T18:55:16.000Z

https://ew0KICAidbase64

此操作主要回避微信\QQ等AI侦测vless vmess关键字。base64改为高压缩率其他方案更好。过长也是特征。

Answer 30 · 2021-01-30T19:02:57.000Z

https://ew0KICAidiI6ICIyIiwNCiAgInBzIjogIuazleWbvSIsDQogICJhZGQiOiAidjIuZGV4My5tZSIsDQogICJwb3J0IjogIjQ5MzgyIiwNCiAgImlkIjogIjE1MzZhYzAwLWZjZDItNGY3ZS05ODcyLTAyZjdiY2ZlMTYxYyIsDQogICJhaWQiOiAiMjMzIiwNCiAgIm5ldCI6ICJ3cyIsDQogICJ0eXBlIjogIm5vbmUiLA0KICAiaG9zdCI6ICIiLA0KICAicGF0aCI6ICIiLA0KICAidGxzIjogIiINCn0=

此操作主要回避微信\QQ等AI侦测vless vmess关键字。base64改为高压缩率其他方案更好。过长也是特征。

脱了裤子放屁

Answer 31 · 2021-01-31T14:39:23.000Z

https://ew0KICAidiI6ICIyIiwNCiAgInBzIjogIuazleWbvSIsDQogICJhZGQiOiAidjIuZGV4My5tZSIsDQogICJwb3J0IjogIjQ5MzgyIiwNCiAgImlkIjogIjE1MzZhYzAwLWZjZDItNGY3ZS05ODcyLTAyZjdiY2ZlMTYxYyIsDQogICJhaWQiOiAiMjMzIiwNCiAgIm5ldCI6ICJ3cyIsDQogICJ0eXBlIjogIm5vbmUiLA0KICAiaG9zdCI6ICIiLA0KICAicGF0aCI6ICIiLA0KICAidGxzIjogIiINCn0=
此操作主要回避微信\QQ等AI侦测vless vmess关键字。base64改为高压缩率其他方案更好。过长也是特征。

脱了裤子放屁

所以你更好的建议是？

Answer 32 · 2021-01-31T14:43:30.000Z

https://ew0KICAidiI6ICIyIiwNCiAgInBzIjogIuazleWbvSIsDQogICJhZGQiOiAidjIuZGV4My5tZSIsDQogICJwb3J0IjogIjQ5MzgyIiwNCiAgImlkIjogIjE1MzZhYzAwLWZjZDItNGY3ZS05ODcyLTAyZjdiY2ZlMTYxYyIsDQogICJhaWQiOiAiMjMzIiwNCiAgIm5ldCI6ICJ3cyIsDQogICJ0eXBlIjogIm5vbmUiLA0KICAiaG9zdCI6ICIiLA0KICAicGF0aCI6ICIiLA0KICAidGxzIjogIiINCn0=
此操作主要回避微信\QQ等AI侦测vless vmess关键字。base64改为高压缩率其他方案更好。过长也是特征。

脱了裤子放屁

所以你更好的建议是？

当然是不做任何处理，这样的做法并没有多大用处。如果要在被监视的情况下使用分享链接，应该学会使用 PGP 等工具。

Answer 33 · 2021-01-31T16:19:58.000Z

这句‘应该学会使用 PGP 等工具’或多或少缺乏移情力
vless开头真没任何不妥吗？

Answer 34 · 2021-01-31T16:26:36.000Z

这句‘应该学会使用 PGP 等工具’或多或少缺乏移情力
vless开头真没任何不妥吗？

没有，我们需要很容易地辨别出这是 VLESS 的分享链接。
顺带提一句，你给出的方案有点过分地小看腾讯开发人员的水平了。

Answer 35 · 2021-01-31T16:33:42.000Z

这句‘应该学会使用 PGP 等工具’或多或少缺乏移情力
vless开头真没任何不妥吗？

你即使用了https开头，最后还不是在本地，QQ一扫描你的文件夹全拿走了

Answer 36 · 2021-02-01T02:40:01.000Z

https://ew0KICAidiI6ICIyIiwNCiAgInBzIjogIuazleWbvSIsDQogICJhZGQiOiAidjIuZGV4My5tZSIsDQogICJwb3J0IjogIjQ5MzgyIiwNCiAgImlkIjogIjE1MzZhYzAwLWZjZDItNGY3ZS05ODcyLTAyZjdiY2ZlMTYxYyIsDQogICJhaWQiOiAiMjMzIiwNCiAgIm5ldCI6ICJ3cyIsDQogICJ0eXBlIjogIm5vbmUiLA0KICAiaG9zdCI6ICIiLA0KICAicGF0aCI6ICIiLA0KICAidGxzIjogIiINCn0=
此操作主要回避微信\QQ等AI侦测vless vmess关键字。base64改为高压缩率其他方案更好。过长也是特征。

脱了裤子放屁

http这个大概抄Telegram链接
另外，你这种人阴阳怪气的喷脏，真希望你先学会尊重自己

Answer 37 · 2021-02-01T03:23:26.000Z

我觉得没必要，目前没有发现QQ主动探测vless并上交国家和产生不良影响。可以作为可选功能添加

Answer 38 · 2021-02-01T04:33:08.000Z

我觉得没必要，目前没有发现QQ主动探测vless并上交国家和产生不良影响。可以作为可选功能添加

目前没发现，不等于腾讯没有做，以后也不保证腾讯不会做。预先采取更保险的措施乃理所应当

Answer 39 · 2021-02-01T04:53:14.000Z

我觉得没必要，目前没有发现QQ主动探测vless并上交国家和产生不良影响。可以作为可选功能添加

目前没发现，不等于腾讯没有做，以后也不保证腾讯不会做。预先采取更保险的措施乃理所应当

没有用处，分享链接最终也会转换成配置文件，如果QQ要识别也很快就被识别了。

Answer 40 · 2021-02-01T05:07:41.000Z

我觉得没必要，目前没有发现QQ主动探测vless并上交国家和产生不良影响。可以作为可选功能添加

目前没发现，不等于腾讯没有做，以后也不保证腾讯不会做。预先采取更保险的措施乃理所应当

没有用处，分享链接最终也会转换成配置文件，如果QQ要识别也很快就被识别了。

前提是QQ转换所有http链接，显然会极大提高其监控成本

Answer 41 · 2021-02-01T05:10:39.000Z

我觉得没必要，目前没有发现QQ主动探测vless并上交国家和产生不良影响。可以作为可选功能添加

我的意思是，文件在本地，所有其他软件都可以轻易获取你的配置文件

Answer 42 · 2021-02-12T18:25:45.000Z

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，与此处似乎不符

Answer 43 · 2021-02-12T18:57:48.000Z

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，与此处似乎不符

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

Answer 44 · 2021-02-18T09:00:34.000Z

复杂了对新手不友好，简单了缺少了高级玩法。个人认为可以参考下clash的config

Answer 45 · 2021-02-18T09:02:26.000Z

复杂了对新手不友好，简单了缺少了高级玩法。个人认为可以参考下clash的config

？

clash是把配置文件放在服务器上，然后通过订阅链接下载到本地，这和这里讨论的分享链接有什么关系吗

Answer 46 · 2021-02-18T16:02:56.000Z

复杂了对新手不友好，简单了缺少了高级玩法。个人认为可以参考下clash的config

？

clash是把配置文件放在服务器上，然后通过订阅链接下载到本地，这和这里讨论的分享链接有什么关系吗

我走错片场了，才发现是分享链接的

Answer 47 · 2021-03-16T16:00:50.000Z

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

Answer 48 · 2021-03-16T16:14:38.000Z

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

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

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

Answer 49 · 2021-03-16T16:25:33.000Z

@DuckSoft

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

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

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

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

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

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

Answer 50 · 2021-03-16T16:33:59.000Z

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

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

Answer 51 · 2021-05-27T16:25:53.000Z

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

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

Answer 52 · 2021-05-31T23:20:21.000Z

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

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

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

@DuckSoft 建议修改一下例子

Answer 53 · 2021-05-31T23:28:46.000Z

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

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

Answer 54 · 2021-06-01T00:01:29.000Z

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 修改

Answer 55 · 2021-08-09T06:18:03.000Z

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

Answer 56 · 2021-09-11T04:18:58.000Z

为什么不直接用 json 呢？

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

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

VMess / VLESS 分享链接提案

0 致谢

1 原则

2 约定

3 概览

4 详述

4.1 基本信息段

4.1.1 协议名称 protocol

4.1.2 uuid

4.1.3 remote-host

4.1.4 remote-port

4.1.5 descriptive-text

4.2 协议相关段

4.2.1 传输方式 type

4.2.2 (VMess/VLESS) encryption

4.2.3 (VMess) alterId、aid 等

4.3 传输层相关段

4.3.1 底层传输安全 security

4.3.2 (HTTP/2) path

4.3.3 (HTTP/2) host

4.3.4 (WebSocket) path

4.3.5 (WebSocket) host

4.3.6 (mKCP) headerType

4.3.7 (mKCP) seed

4.3.8 (QUIC) quicSecurity

4.3.9 (QUIC) key

4.3.10 (QUIC) headerType

4.3.11 (gRPC) serviceName

4.3.12 (gRPC) mode

4.4 TLS 相关段

4.4.1 sni

4.4.2 alpn

4.4.3 allowInsecure

4.4.4 (XTLS) flow

5 举例

6 补充

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

4.3.3 (HTTP/2) host

4.4.1 sni

4.3.5 (WebSocket) host

4.3.3 (HTTP/2) host

4.4.1 sni

4.3.5 (WebSocket) host

4.4.2 alpn

4.4.2 alpn

4.1.1 协议名称 `protocol`

4.1.2 `uuid`

4.1.3 `remote-host`

4.1.4 `remote-port`

4.1.5 `descriptive-text`

4.2.1 传输方式 `type`

4.2.2 (VMess/VLESS) `encryption`

4.2.3 (VMess) `alterId`、`aid` 等

4.3.1 底层传输安全 `security`

4.3.2 (HTTP/2) `path`

4.3.3 (HTTP/2) `host`

4.3.4 (WebSocket) `path`

4.3.5 (WebSocket) `host`

4.3.6 (mKCP) `headerType`

4.3.7 (mKCP) `seed`

4.3.8 (QUIC) `quicSecurity`

4.3.9 (QUIC) `key`

4.3.10 (QUIC) `headerType`

4.3.11 (gRPC) `serviceName`

4.3.12 (gRPC) `mode`

4.4.1 `sni`

4.4.2 `alpn`

4.4.3 `allowInsecure`

4.4.4 (XTLS) `flow`

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

4.3.3 (HTTP/2) `host`

4.4.1 `sni`

4.3.5 (WebSocket) `host`

4.3.3 (HTTP/2) `host`

4.4.1 `sni`

4.3.5 (WebSocket) `host`

4.4.2 `alpn`

4.4.2 `alpn`