Replies: 66 comments 9 replies
|
友情提醒：VLESS 的是基于 VLESS 0 的 提案，由于 VLESS 协议还在进化，分享标准也会随时修改，比如改定义、加字段、删字段。 如果客户端无法及时跟进 breaking change（要求不兼容旧行为，直接 breaking，避免行为混乱），请等完全确定后再实现。 |
|
breaking 不是问题，列明变更、行为确定即可。 最怕的事情不是没有规范，而是后续的实现者要去翻看各个实现的代码，以某一实现所使用的语言/代码的特性作为规范。 Trojan-Go的分享链接规范即是我主导制定的，目前为止看来基本上达到了目的。 最后，希望这份花了4个小时反复推敲斟酌的文档能够帮后续的开发者缩减至少4个小时的开发时间，也希望VMess的悲剧不要再重演。 |
|
对 VLESS
计划中 XTLS 还会有些合并与优化，VLESS 则至少会有两类 UDP 增强：UDP over TCP 的 MUX 隧道、纯 UDP 多倍发包 + 长度填充 |
|
很好的提案 |
|
4.2.1 传输方式 type = tcp时,进行 HTTP 伪装,这个时候如何分享这个type https://www.v2fly.org/config/transport/tcp.html#httpheaderobject |
这个暂时没有想好，因为我记得两个客户端能进行通讯的要求是 Request 和 Response 部分都必须完全一致才可以，这是一个特别强的要求，除了把两坨 JSON 硬编码打进来我没有想到别的优雅的办法了。个人认为这样的节点可能不太适合分享。 如果选择支持 http 伪装，对应的设置的分享方式还需要仔细斟酌。 |
|
那这样,我们这边暂时引用旧的做法, headerType = "http" , host="",两坨 JSON 硬编码直接内置了先. |
我觉得大概可以这样：
画风大概如此：
|
把request/response base64后看起来好看一点吧 |
那大概会变成： 如果先用 zlib 过一遍，大概会变成： 最后吐槽一次，实在是实在是实在是太丑了…… |
|
v2rayN现在的做法,分享 如果要分享整个requestHost,那的确不合适 |
This comment has been hidden.
This comment has been hidden.
大佬预计啥时候释出支持此方案的N或NG？ |
This comment was marked as spam.
This comment was marked as spam.
This comment has been hidden.
This comment has been hidden.
|
为什么不直接用 json 呢？ vless://base64encode({"host":"11.11.11.11", "port": 443, "uuid": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}) 客户端只需要 json.Unmarshal 一下，就可以了 |
|
原则写了，需要人类可读。 |
|
没有必要人类可读吧，分享链接客户端一般情况下都支持导入，而且，就算不支持，手动填写，只需要base64解码一下，json阅读起来更方便吧。这种形式，后台解析的时候还需要一项一项的填参数到协议配置文件。解析的时候还没办法通过&来分割，因为存在? 和#，针对这个还要做一些处理，虽然不麻烦，但是我还是认为vmess/vless://base64(json)更好。 |
|
请问多个alpn是先用逗号分隔再转义还是先转义再用逗号分隔？ |
|
可不可以把链接的解析放到核心功能里，用类似
|
|
VLESS 分享链接标准提案 能不能增加一下"fingerprint": "chrome" |
|
已添加于 2023-02-01 |
|
请给出 REALITY 的标准！ |
|
已添加于 2023-03-19 |
|
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 |
|
先不出分享吧，出了分享就会导致更大规模的传播与使用，伊朗 GFW 就会封了这类方法，因为它们特征太明显了，封起来太简单。 这个问题是，我们是想让这类方法传得广一些，还是活得久一些？我觉得后者更重要，至少一小部分人还能用。 就像 REALITY 有任意 SNI、无 SNI 的隐藏玩法，我也没想让它们传播开，因为经不起查，大规模用就是滥用，很快就会被封。 |
VLESS 会添加更多的 Flow，还会启用 Seed 机制。 |
|
是否有计划将sockopt也添加进分享链接提案中呢？ |
|
感觉它好像不太适合分享？ |
|
是否有计划将 mKCP header 的 dns 伪装域名添加进分享链接提案中呢？ |
|
目前使用 host 字段 |
|
增加公钥的新别名后，传输参数中的&pbk=格式是否会改变？还是保持不变？ |
|
保持不变，分享链接很难改，就像 tcp 一时半会儿改不成 raw |
|
Feature Request. It'd be good to support proxy chains (use second proxy as dialerProxy for the first). In Russia now sometimes it's possible to find/buy a proxy with whitelist IP, but of course you can't trust links found on the web. Of course, xray core supports dialerProxy and you can use whitelist proxy as a proxy to your own VPS, but this is such a common situation that I think it's worth supporting this in the link format. Suggested format "link1 -> link2 -> link3" meaning route link 3 traffic through link2 and all of this route through link1. |
|
Feature request: can we add |
|
#6218 2dust/v2rayN#9543 Feature request: 在订阅文件中推送DNS设置，避免进一步DPI。可以推送以下的设置。 其他例子： 机场一般推送三个设置即可： 目的：在解析节点域名和更新订阅时，使用机场的DOH服务器解析节点域名和订阅URL域名。 |
|
please add |
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（@RPRX 修改于 2026-1-18）当协议为 VMess 时，对应配置文件出站中
settings.security，可选值为auto/aes-128-gcm/chacha20-poly1305/none。省略时默认为
auto，但不可以为空字符串。除非指定为none，否则建议省略。当协议为 VLESS 时，对应配置文件出站中
settings.encryption，当前可选值只有none和mlkem768x25519...。省略时默认为
none，但不可以为空字符串。特殊说明：之所以不使用
security而使用encryption，是因为后面还有一个底层传输安全类型security与这个冲突。由 @huyz 提议，将此字段重命名为
encryption，这样不仅能避免命名冲突，还与 VLESS 保持了一致。4.2.3 (VMess)
alterId、aid等没有这些字段。旧的 VMess 因协议设计出现致命问题，不再适合使用或分享。
此分享标准仅针对 VMess AEAD 和 VLESS。
4.2.3 (VLESS)
flow（@RPRX 添加于 2026-1-18）VLESS 的流量整形方式。可选值为
xtls-rprx-vision等。无需特殊处理。此项可能为空字符串。
4.3 传输层相关段
4.3.1 底层传输安全
security（@RPRX 修改于 2023-03-19）设定底层传输所使用的 TLS 类型。当前可选值有
none，tls和reality。省略时默认为
none，但不可以为空字符串。4.3.4 (WebSocket)
pathWebSocket 的路径。省略时默认为
/，但不可以为空字符串。不推荐省略。必须使用
encodeURIComponent转义。4.3.5 (WebSocket)
hostWebSocket 请求时
Host头的内容。不推荐省略，不推荐设为空字符串。必须使用
encodeURIComponent转义。4.3.6 (mKCP)
mtu（@RPRX 添加于 2026-03-27）mKCP 的 Maximum Transmission Unit。
可省略，最终的默认值取决于 Xray-core。
4.3.7 (mKCP)
tti（@RPRX 添加于 2026-03-27）mKCP 的 Transmission Time Interval。
可省略，最终的默认值取决于 Xray-core。
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.3.20 (Finalmask)
fm（@RPRX 添加于 2026-01-31）可能包含 XICMP、XDNS、header-*、mkcp-*、Salamander 等，对应配置文件中的
finalmask项目。由于结构较为复杂且支持自定义多层嵌套，目前类似于 XHTTP
extra直接分享整个 JSON 段。必须使用
encodeURIComponent转义。4.4 TLS 相关段
4.4.0
fp（@RPRX 添加于 2023-02-01，修改于 2023-03-19）TLS Client Hello 指纹，对应配置文件中的
fingerprint项目。省略时默认为
chrome，不可以为空字符串。若使用 REALITY，此项不可省略。
4.4.1
sni（@RPRX 修改于 2026-1-18）TLS/REALITY 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转义。此项可能为空字符串。4.4.4
pcs&vcn（@RPRX 添加于 2026-1-18，修改于 2026-2-2）TLS CA/leaf 证书 SHA-256 指纹，对应配置文件中的
pinnedPeerCertSha256项目。TLS 用于验证 leaf 证书的 name，对应配置文件中的
verifyPeerCertByName项目。必须使用
encodeURIComponent转义。这两项可能为空字符串。GUI 设计上留两个 string 空位并直接传入 Xray-core 即可，其中包含的
,会被自动分割。（没有过
allowInsecure，且 Xray-core 已移除该配置项，请使用以上两项代替）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模式即可。All reactions