Replies: 61 comments 9 replies
-
|
友情提醒：VLESS 的是基于 VLESS 0 的 提案，由于 VLESS 协议还在进化，分享标准也会随时修改，比如改定义、加字段、删字段。 如果客户端无法及时跟进 breaking change（要求不兼容旧行为，直接 breaking，避免行为混乱），请等完全确定后再实现。 |
Beta Was this translation helpful? Give feedback.
-
|
breaking 不是问题，列明变更、行为确定即可。 最怕的事情不是没有规范，而是后续的实现者要去翻看各个实现的代码，以某一实现所使用的语言/代码的特性作为规范。 Trojan-Go的分享链接规范即是我主导制定的，目前为止看来基本上达到了目的。 最后，希望这份花了4个小时反复推敲斟酌的文档能够帮后续的开发者缩减至少4个小时的开发时间，也希望VMess的悲剧不要再重演。 |
Beta Was this translation helpful? Give feedback.
-
|
对 VLESS
计划中 XTLS 还会有些合并与优化，VLESS 则至少会有两类 UDP 增强：UDP over TCP 的 MUX 隧道、纯 UDP 多倍发包 + 长度填充 |
Beta Was this translation helpful? Give feedback.
-
|
很好的提案 |
Beta Was this translation helpful? Give feedback.
-
|
4.2.1 传输方式 type = tcp时,进行 HTTP 伪装,这个时候如何分享这个type https://www.v2fly.org/config/transport/tcp.html#httpheaderobject |
Beta Was this translation helpful? Give feedback.
-
这个暂时没有想好，因为我记得两个客户端能进行通讯的要求是 Request 和 Response 部分都必须完全一致才可以，这是一个特别强的要求，除了把两坨 JSON 硬编码打进来我没有想到别的优雅的办法了。个人认为这样的节点可能不太适合分享。 如果选择支持 http 伪装，对应的设置的分享方式还需要仔细斟酌。 |
Beta Was this translation helpful? Give feedback.
-
|
那这样,我们这边暂时引用旧的做法, headerType = "http" , host="",两坨 JSON 硬编码直接内置了先. |
Beta Was this translation helpful? Give feedback.
-
我觉得大概可以这样：
画风大概如此：
|
Beta Was this translation helpful? Give feedback.
-
把request/response base64后看起来好看一点吧 |
Beta Was this translation helpful? Give feedback.
-
那大概会变成： 如果先用 zlib 过一遍，大概会变成： 最后吐槽一次，实在是实在是实在是太丑了…… |
Beta Was this translation helpful? Give feedback.
-
|
v2rayN现在的做法,分享 如果要分享整个requestHost,那的确不合适 |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
大佬预计啥时候释出支持此方案的N或NG？ |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
This comment has been hidden.
This comment has been hidden.
-
|
@kirin10000 我的倾向是布尔值有且仅有三种取值，要么未指定，要么是0，要么是1，不能为空。 至于multiMode这种，我认为未来可能还会出来更多种类的互不兼容的模式，出于这样的考虑我不想把他作为布尔型。 |
Beta Was this translation helpful? Give feedback.
-
|
XTLS 的流控方式。可选值为 xtls-rprx-direct、xtls-rprx-splice 等。 但是例子里面又变成了“rprx-xtls-splice”，rprx和xtls的顺序反过来了。规范还是严谨一些好。 |
Beta Was this translation helpful? Give feedback.
-
可能是当时就是写成 @DuckSoft 建议修改一下例子 |
Beta Was this translation helpful? Give feedback.
-
the name |
Beta Was this translation helpful? Give feedback.
-
他指的应该是 |
Beta Was this translation helpful? Give feedback.
-
|
@DuckSoft |
Beta Was this translation helpful? Give feedback.
-
|
为什么不直接用 json 呢？ vless://base64encode({"host":"11.11.11.11", "port": 443, "uuid": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}) 客户端只需要 json.Unmarshal 一下，就可以了 |
Beta Was this translation helpful? Give feedback.
-
|
原则写了，需要人类可读。 |
Beta Was this translation helpful? Give feedback.
-
|
没有必要人类可读吧，分享链接客户端一般情况下都支持导入，而且，就算不支持，手动填写，只需要base64解码一下，json阅读起来更方便吧。这种形式，后台解析的时候还需要一项一项的填参数到协议配置文件。解析的时候还没办法通过&来分割，因为存在? 和#，针对这个还要做一些处理，虽然不麻烦，但是我还是认为vmess/vless://base64(json)更好。 |
Beta Was this translation helpful? Give feedback.
-
|
请问多个alpn是先用逗号分隔再转义还是先转义再用逗号分隔？ |
Beta Was this translation helpful? Give feedback.
-
|
可不可以把链接的解析放到核心功能里，用类似
|
Beta Was this translation helpful? Give feedback.
-
|
VLESS 分享链接标准提案 能不能增加一下"fingerprint": "chrome" |
Beta Was this translation helpful? Give feedback.
-
|
已添加于 2023-02-01 |
Beta Was this translation helpful? Give feedback.
-
|
请给出 REALITY 的标准！ |
Beta Was this translation helpful? Give feedback.
-
|
已添加于 2023-03-19 |
Beta Was this translation helpful? Give feedback.
-
|
Now that FoXray on apple devices has added the support for fragment I think it would be good for share link to also support the fragment for better sharing. My proposal: It could also support strings: P.S I have been wondering if it would be useful to have a configurable packet padding like |
Beta Was this translation helpful? Give feedback.
-
|
先不出分享吧，出了分享就会导致更大规模的传播与使用，伊朗 GFW 就会封了这类方法，因为它们特征太明显了，封起来太简单。 这个问题是，我们是想让这类方法传得广一些，还是活得久一些？我觉得后者更重要，至少一小部分人还能用。 就像 REALITY 有任意 SNI、无 SNI 的隐藏玩法，我也没想让它们传播开，因为经不起查，大规模用就是滥用，很快就会被封。 |
Beta Was this translation helpful? Give feedback.
-
VLESS 会添加更多的 Flow，还会启用 Seed 机制。 |
Beta Was this translation helpful? Give feedback.
-
|
是否有计划将sockopt也添加进分享链接提案中呢？ |
Beta Was this translation helpful? Give feedback.
-
|
感觉它好像不太适合分享？ |
Beta Was this translation helpful? Give feedback.
-
|
是否有计划将 mKCP header 的 dns 伪装域名添加进分享链接提案中呢？ |
Beta Was this translation helpful? Give feedback.
-
|
目前使用 host 字段 |
Beta Was this translation helpful? Give feedback.
-
|
增加公钥的新别名后，传输参数中的&pbk=格式是否会改变？还是保持不变？ |
Beta Was this translation helpful? Give feedback.
-
|
保持不变，分享链接很难改，就像 tcp 一时半会儿改不成 raw |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
VMess / VLESS 分享链接提案
0 致谢
1 原则
2 约定
encodeURIComponent进行转义处理3 概览
特别说明：
$()代表此处需要encodeURIComponent。4 详述
4.1 基本信息段
4.1.1 协议名称
protocol所使用的协议名称。取值必须为
vmess或vless。不可省略，不能为空字符串。
4.1.2
uuidUUID。对应配置文件该项出站中
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（@RPRX 修改于 2024-03-05，2024-06-18，2024-11-11）协议的传输方式。对应配置文件出站中
settings.vnext[0].streamSettings.network的值。当前的取值必须为
tcp、kcp、ws、http、grpc、httpupgrade、xhttp其中之一，分别对应 RAW、mKCP、WebSocket、HTTP/2/3、gRPC、HTTPUpgrade、XHTTP 传输方式。
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（@RPRX 修改于 2023-03-19）设定底层传输所使用的 TLS 类型。当前可选值有
none，tls和reality。省略时默认为
none，但不可以为空字符串。4.3.2 (HTTP/2/3)
path（@RPRX 修改于 2024-11-11）HTTP/2/3 的路径。省略时默认为
/，但不可以为空字符串。不推荐省略。必须使用
encodeURIComponent转义。4.3.3 (HTTP/2/3)
host（@RPRX 修改于 2024-11-11）客户端进行 HTTP/2/3 通信时所发送的
Host头部。省略时复用
remote-host，但不可以为空字符串。若有多个域名，可使用英文逗号隔开，但中间及前后不可有空格。
必须使用
encodeURIComponent转义。4.3.4 (WebSocket)
pathWebSocket 的路径。省略时默认为
/，但不可以为空字符串。不推荐省略。必须使用
encodeURIComponent转义。4.3.5 (WebSocket)
hostWebSocket 请求时
Host头的内容。不推荐省略，不推荐设为空字符串。必须使用
encodeURIComponent转义。4.3.6 (mKCP)
headerTypemKCP 的伪装头部类型。当前可选值有
none/srtp/utp/wechat-video/dtls/wireguard。省略时默认值为
none，即不使用伪装头部，但不可以为空字符串。4.3.7 (mKCP)
seedmKCP 种子。省略时不使用种子，但不可以为空字符串。建议 mKCP 用户使用
seed。必须使用
encodeURIComponent转义。4.3.11 (gRPC)
serviceName（@RPRX 修改于 2024-03-05）对应 gRPC 的 ServiceName。
建议仅使用英文字母数字和英文句号、下划线组成。不建议省略，不可为空字符串。
修订：必须使用
encodeURIComponent转义。#18154.3.12 (gRPC)
mode对应 gRPC 的传输模式，目前有以下三种：
gun: 即原始的 gun 传输模式，将单个 []byte 封在 Protobuf 里通过 gRPC 发送（参考资料）；multi: 即 Xray-Core 的 multiMode，将多组 []byte 封在一条 Protobuf 里通过 gRPC 发送；guna: 即通过使用自定义 Codec 的方式，直接将数据包封在 gRPC 里发送。（参考资料）省略时默认为
gun，不可以为空字符串。4.3.13 (gRPC)
authority（@RPRX 添加于 2024-03-05）对应 gRPC 的 Authority。#3076
此项可能为空字符串。
必须使用
encodeURIComponent转义。4.3.14 (HTTPUpgrade)
path（@RPRX 添加于 2024-03-05）HTTPUpgrade 的路径。省略时默认为
/，但不可以为空字符串。不推荐省略。必须使用
encodeURIComponent转义。4.3.15 (HTTPUpgrade)
host（@RPRX 添加于 2024-03-05）HTTPUpgrade 请求时
Host头的内容。不推荐省略，不推荐设为空字符串。必须使用
encodeURIComponent转义。4.3.16 (XHTTP)
path（@RPRX 添加于 2024-06-18，修改于 2024-11-11）XHTTP 的路径。省略时默认为
/，但不可以为空字符串。不推荐省略。必须使用
encodeURIComponent转义。4.3.17 (XHTTP)
host（@RPRX 添加于 2024-06-18，修改于 2024-11-11）XHTTP 请求时
Host头的内容。不推荐省略，不推荐设为空字符串。必须使用
encodeURIComponent转义。4.3.18 (XHTTP)
mode（@RPRX 添加于 2024-11-11）XHTTP 的
mode：#39944.3.19 (XHTTP)
extra（@RPRX 添加于 2024-11-11）XHTTP 的
extra：#4000必须使用
encodeURIComponent转义。4.4 TLS 相关段
4.4.0
fp（@RPRX 添加于 2023-02-01，修改于 2023-03-19）TLS Client Hello 指纹，对应配置文件中的
fingerprint项目。省略时默认为
chrome，不可以为空字符串。若使用 REALITY，此项不可省略。
4.4.1
sniTLS SNI，对应配置文件中的
serverName项目。省略时复用
remote-host，但不可以为空字符串。4.4.2
alpnTLS ALPN，对应配置文件中的
alpn项目。多个 ALPN 之间用英文逗号隔开，中间无空格。
省略时由内核决定具体行为，但不可以为空字符串。
必须使用
encodeURIComponent转义。4.4.3
ech（@RPRX 添加于 2025-07-26）TLS Encrypted Client Hello，对应配置文件中的
echConfigList项目。必须使用
encodeURIComponent转义。此项可能为空字符串。（没有
allowInsecure，不安全的节点不适合分享）4.4.4 (XTLS)
flow（@RPRX 修改于 2024-11-11）XTLS 的流控方式。可选值为
xtls-rprx-vision等。若使用 XTLS，此项不可省略，否则无此项。此项不可为空字符串。
4.4.5 (REALITY)
pbk（@RPRX 添加于 2023-03-19，修改于 2025-07-22）REALITY 的密码，对应配置文件中的
password项目。若使用 REALITY，此项不可省略，否则无此项。此项不可为空字符串。
4.4.6 (REALITY)
sid（@RPRX 添加于 2023-03-19）REALITY 的 ID，对应配置文件中的
shortId项目。无需特殊处理。此项可能为空字符串。
4.4.7 (REALITY)
pqv（@RPRX 添加于 2025-07-22）REALITY 的 ML-DSA-65 公钥，对应配置文件中的
mldsa65Verify项目。无需特殊处理。此项可能为空字符串。
4.4.8 (REALITY)
spx（@RPRX 添加于 2023-03-19）REALITY 的爬虫，对应配置文件中的
spiderX项目。必须使用
encodeURIComponent转义。此项可能为空字符串。5 举例
6 补充
6.1 2020/12/21 @RPRX 关于
flow选项的补充说明-udp443系列属于客户端选项，不建议服务器下发，是否开启应由客户端决定。splice的使用场景比较苛刻，目前要求入站“纯粹”、且运行在 Linux / Android 操作系统上。若不满足相关要求，客户端使用direct模式即可。Beta Was this translation helpful? Give feedback.
All reactions