clash
clash copied to clipboard
Dreamacro
Add VLESS support
希望早点添加支持。
update: 随着v2ray支持trojan和vless添加trojan回落，其实clash添加vless的支持已经不那么急切了。
@sandianyue 从代码可维护性角度出发，XTLS 和 uTLS 一样并不是一个很好的形式（fork 自 go 的 TLS 并魔改，而 go 会随着迭代更新修改一部分功能，最终可能因为缺乏维护导致脱节）。因为它只在特定场景下会有一些提升，我个人的看法是除非真的有必要，否则不太建议加入它
uTLS
好吧 感谢您的回复 其实我不是希望clash主分支合并进来.. 只是希望可以在下游分支中体验到 我个人觉得这是VLESS主打的特性之二 相信 @rprx 以及v2fly项目组应该会持续维护的 也许等VLESS 经历数个preview迭代为成熟正式版protocol后 您会再次考虑可行性和回报价值😀
@sandianyue 从代码可维护性角度出发，XTLS 和 uTLS 一样并不是一个很好的形式（fork 自 go 的 TLS 并魔改，而 go 会随着迭代更新修改一部分功能，最终可能因为缺乏维护导致脱节）。因为它只在特定场景下会有一些提升，我个人的看法是除非真的有必要，否则不太建议加入它
是的，个人觉得VLESS作者越跑越偏了
忍不住说几句。
fork 自 go 的 TLS 并魔改，而 go 会随着迭代更新修改一部分功能，最终可能因为缺乏维护导致脱节
答案是不会。
因为它只在特定场景下会有一些提升
VLESS & XTLS 从原理的角度出发，做的事情就是一个增强版的 ECH：只加密握手等前几个包，并且支持代理中转，也支持普通流量。这是一个全新且最终的代理形式，目前测试在有 AES 硬解的设备上能提升 50% 左右，在没有 AES 硬解的设备上能提升 100% 左右，这还只是初步结果，因为 XTLS 后续还有更多优化，预计可带来更多成倍的性能提升，以前的代理可能会成为历史。
是的，个人觉得VLESS作者越跑越偏了
是否存在些偏见？
拿 SS 和 trojan 作为代表来举例子，以及直连和中转（可能是 IPLC）这两个场景。
首先，SS 没有 TLS 代理的隐蔽性（指作为未知 TCP 流量有时会被限流，某些时期还会被彻底阻断），它相对于 TLS 的好处就是省些资源、延迟、UDP，但最终还是有二次加解密。如果使用 XTLS，则不会丢掉隐蔽性，且绝大多数流量不需要二次加密了，相信会更省资源。延迟上，如果有需要，可以引入 0-RTT 支持。UDP 走 UDP 还是 TCP，这个因地区而异，无法下定论。
至于中转，很多人在用 SSR，因为它能欺骗运营商、防止被限流，而且开销比 TLS 低一些（SS）。如果使用 XTLS，也不会被限流，然后再比开销，上面已经说过了。
最后是 trojan，大体上差不多，只是换用 XTLS 有性能提升，还可能是成倍的。
PS：是因为我发现这里的讨论对 XTLS 存在较大误解（以及我的计划与 VLESS 发展方向？），所以忍不住说几句。
没觉得现在的方向是跑偏，请把 VLESS & XTLS 当成一种新形式的代理去看待。这里魔改个 TLS 也只是因为需要而已，并不是重点。
@rprx
答案是不会。
就 clash 这个项目而言，我会尽可能在第一时间就把 golang 新的 release、新的特性用上，比如 1.15 就对 tls 包做了一些 API 层面的修改（https://golang.org/doc/go1.15#crypto/tls）。当我去使用一个「类官方库（fork 魔改）」的时候，我希望它的 API 和 code 能和最新的 go 版本一致。这期间能有 gap 但我不希望这个 gap 时间太长，像 uTLS 这个项目目前看起来已经和 go 官方脱节了。XTLS 会不会也有这个情况暂不清楚，所以现在还在观望。
因为它只在特定场景下会有一些提升
我觉得这个我并没有说错，就目前而言，它确实只在一些低配置设备上具有一些提升
BTW, 给点小小的建议，在描述一个技术问题的时候，不要尝试用「最终」、「空前」等字眼。简单的把现在的痛点，改进方案以及改进后的 benchmark 丢出来就行了。用这些词语容易造成不必要的反感。
uTLS 的确是已经脱节了的，比如目前 XTLS fork 的是 Go 1.15 的 TLS，只有 1.15 才能编译（我也比较追新）。目前 XTLS 和 TLS 没有深度耦合，更像是一个 patch，XTLS Project 有多名成员，如果我不小心消失了，相信其他成员也能完成更新。
我觉得这个我并没有说错，就目前而言，它确实只在一些低配置设备上具有一些提升
如果从瓶颈的角度来讲，的确只有性能跟不上带宽时才能明显感受到吞吐量的提升，但另一个因素是移动设备耗电，这一点也不能忽视。不过从设计的角度来讲，并不是性能充足就可以不关注提升，因为省资源始终是有必要的优化方向，这是大家一直在做和追求的事情，否则也不会有很多人吹 trojan 了（相对于 VMess WSS）。
BTW, 给点小小的建议，在描述一个技术问题的时候，不要尝试用「最终」、「空前」等字眼。简单的把现在的痛点，改进方案以及改进后的 benchmark 丢出来就行了。用这些词语容易造成不必要的反感。
是的，我发现了。甚至在第一个描述 VLESS 的 issue 中，有一些人误以为我不做实事。这些词语是综合我的认知（或与测试）得出的结论，但在它们成为现实之前，的确会带来不必要的麻烦。
另外需要说明：v4.29.0 的 release note 之前，对 XTLS 使用了不当的测试方法，所以导致 release note 比较谦虚。新一轮 测试 的性能提升我刚才已经说明了（50% 左右和 100% 左右），如果网速是瓶颈，则会转化为减少本地资源占用。
https://github.com/v2fly/v2ray-core/pull/239
具体改变：每个 UDP 载荷前加两字节长度的 length，最大值为 2048-2=2046。若不使用 Mux，服务端与客户端均需升级至 v4.30.0+。这是 VLESS 公测版（0）协议结构本身唯一一次 breaking change，正式版（1）的服务端预计会长期同时支持该版本，第三方客户端的实现应当尽快跟进。
公测版的协议结构就这样了，正式版的服务端预计会长期同时支持它（我大概过年有空再实现 XUDP，也即 VLESS 正式版）。
@Dreamacro
正式版才可能会解决，时间未定，至少半年。
在 clash 只是 vmess 协议的问题，但在 v2ray 是整个 core 的问题，需要大改软件架构，还需要解决与路由的冲突，所以要求仅新协议 VLESS 必须处理这个全局问题并不合理。
@Dreamacro
目前来说 VLESS 的服务端只有 v2ray-core，所以这么做的意义不大，因为组合不出一个没问题的服务。
而当 VLESS 解决了此问题，即 XUDP，协议版本会变成 1，与现在的 0 有所区分。
@Dreamacro
这里与定位无关，而是解决了 UDP 问题后 VLESS 的协议版本就直接改成 1 出正式版了，现在的这个版本 0 是什么格式就没有意义了。
具体改变：每个 UDP 载荷前加两字节长度的 length，最大值为 2048-2=2046。若不使用 Mux，服务端与客户端均需升级至 v4.30.0+。这是 VLESS 公测版（0）协议结构本身唯一一次 breaking change，正式版（1）的服务端预计会长期同时支持该版本，第三方客户端的实现应当尽快跟进。
公测版的协议结构就这样了，正式版的服务端预计会长期同时支持它（我大概过年有空再实现 XUDP，也即 VLESS 正式版）。
对了，这一条是为了提醒这个 PR 的 UDP 格式需要跟上 VLESS 的新格式，不是催促合并，至少需要先修改，否则会出现问题
@Dreamacro
目前来说 VLESS 的服务端只有 v2ray-core，所以这么做的意义不大，因为组合不出一个没问题的服务。
而当 VLESS 解决了此问题，即 XUDP，协议版本会变成 1，与现在的 0 有所区分。
能不能放弃v2ray-core，单独给vless协议写一个支持udp/xtls的轻量级别的服务端？
另外问一下说vless有详细的spec么？
@Ehco1996
有开新架构的计划，暂定 Xray-next
VLESS 协议结构请搜索“VLESS BETA”
VLESS 正式版计划扔掉 pb，五个指令：tun、xudp、tcp、xtls、smux（或者 xudp 也靠 smux）
@Ehco1996
有开新架构的计划，暂定 Xray-next
VLESS 协议结构请搜索“VLESS BETA”
VLESS 正式版计划扔掉 pb，五个指令：tun、xudp、tcp、xtls、smux（或者 xudp 也靠 smux）
期待，请问有大致的时间规划么，正式版大概会在多久后发布
@Ehco1996
有开新架构的计划，暂定 Xray-next
VLESS 协议结构请搜索“VLESS BETA”
VLESS 正式版计划扔掉 pb，五个指令：tun、xudp、tcp、xtls、smux（或者 xudp 也靠 smux） 大佬现在这个版本能支持xray了吗 谢谢
拿 SS 和 trojan 作为代表来举例子，以及直连和中转（可能是 IPLC）这两个场景。
首先，SS 没有 TLS 代理的隐蔽性（指作为未知 TCP 流量有时会被限流，某些时期还会被彻底阻断），它相对于 TLS 的好处就是省些资源、延迟、UDP，但最终还是有二次加解密。如果使用 XTLS，则不会丢掉隐蔽性，且绝大多数流量不需要二次加密了，相信会更省资源。延迟上，如果有需要，可以引入 0-RTT 支持。UDP 走 UDP 还是 TCP，这个因地区而异，无法下定论。
至于中转，很多人在用 SSR，因为它能欺骗运营商、防止被限流，而且开销比 TLS 低一些（SS）。如果使用 XTLS，也不会被限流，然后再比开销，上面已经说过了。
最后是 trojan，大体上差不多，只是换用 XTLS 有性能提升，还可能是成倍的。
@rprx 我只有一个问题，TLS 的设计不是为了隐蔽性，也不是为了隐私，只是为了机密性。这玩意你就算再怎么 ECH，也无法提供隐蔽和 anti-censorship 的功能... 个人表示不看好任何携带有唯一标识字段的特征（包括但不限于 TLS 证书）的代理。
@Dreamacro 目前来说 VLESS 的服务端只有 v2ray-core，所以这么做的意义不大，因为组合不出一个没问题的服务。 而当 VLESS 解决了此问题，即 XUDP，协议版本会变成 1，与现在的 0 有所区分。
能不能放弃v2ray-core，单独给vless协议写一个支持udp/xtls的轻量级别的服务端？
另外问一下说vless有详细的spec么？
更同意有个通用且详细的 spec 来解决这个问题，而不是二进制和纯 code review 层面解决。
那这个还是等到1版本解决了在统一支持吧
同意
如果进行版本分发,请在分发时停止对上游的同步
需要修改 clash 的 license
出于个人偏好和对开源授权的了解，个人还是维持 GPL。
费了这么多的口舌，不如all in one，让用户选择。fork并合并maskedeken的代码后编译：https://github.com/xumng123/clash/releases/tag/v1.5.7
费了这么多的口舌，不如all in one，让用户选择。fork并合并maskedeken的代码后编译：https://github.com/xumng123/clash/releases/tag/v1.5.7
cool！请问这个支持vless+tls 对应的格式是什么
费了这么多的口舌，不如all in one，让用户选择。fork并合并maskedeken的代码后编译：https://github.com/xumng123/clash/releases/tag/v1.5.7
cool！请问这个支持vless+tls 对应的格式是什么
proxies:
- { name: net_vmess_tcp, server: xxx.dynv6.net, port: 443, type: vless, uuid: 2dc6e29f-4b92-49a2-977e-cf25b96a97de, alterId: 1, cipher: auto, network: http, tls: true, flow: xtls-rprx-direct, skip-cert-verify: true }
费了这么多的口舌，不如all in one，让用户选择。fork并合并maskedeken的代码后编译：https://github.com/xumng123/clash/releases/tag/v1.5.7
cool！请问这个支持vless+tls 对应的格式是什么
proxies:
- { name: net_vmess_tcp, server: xxx.dynv6.net, port: 443, type: vless, uuid: 2dc6e29f-4b92-49a2-977e-cf25b96a97de, alterId: 1, cipher: auto, network: http, tls: true, flow: xtls-rprx-direct, skip-cert-verify: true }
你好，能大致说一下如下配置在clash中的格式么
Xray 配置信息 地址（address）: xxx 端口（port）： 443 用户 ID（UUID）： yyyy 流控（flow）： xtls-rprx-direct 加密方式（security）： none 传输协议（network）： tcp 伪装类型（type）： none 底层传输安全： xtls 或 tls
我目前是这么写的好像不行：
- name: "test" type: vless server: xxx port: 443 uuid: yyyy alterId: 1 cipher: auto skip-cert-verify: true network: tcp flow: xtls-rprx-direct
费了这么多的口舌，不如all in one，让用户选择。fork并合并maskedeken的代码后编译：https://github.com/xumng123/clash/releases/tag/v1.5.7
upx压缩clash文件后版本，节省router空间，upx不支持64位架构。
https://github.com/xumng123/clash/releases/tag/v1.5.8
