[New Protocol] VLESS BETA：性能至上、可扩展性空前，目标是全场景终极协议。

[RPRX]

官网文档：https://www.v2fly.org/config/protocols/vless.html

终极配置：VLESS over TCP with XTLS + 回落 & 分流 to WHATEVER

---

2020-07-31 更新：VLESS PREVIEW 1.1 已于两天前合并进 v2ray-core 公测，将出现在 v4.27.0 版本中。

2020-07-23 更新：加入了判断首包长度（原创）的协议回落模式，PREVIEW 版本将很快发布（在此之后，BETA 系列仍会继续）。

---

这份说明本来应该于一周前 VLESS BETA 发布时就写好的，但因为实在是很麻烦（每次写说明比写代码麻烦多了），所以就鸽到了今天。。。不过上次也差不多。与上一份说明 #2583 不同，这次更加注重 VLESS 本身的设计。

代码在 rprx/v2ray-vless，它是 v2fly/v2ray-core 的超集，只是多了 VLESS 协议，其它的完全一样。releases 已补充历版 VLESS Changes，有已编译好的 Windows & Linux x64 版本，交叉编译可参考 https://github.com/v2ray/discussion/issues/756 。

若你正在使用 TLS，简单地将 VMess 改为 VLESS 就可以获得性能提升：

1. 替换服务端和客户端的可执行文件。
2. 将两边的协议都改为 "vless"，具体参考 VLESS 配置文档，相较于 VMess 的只有少许改动。

这只是 VLESS 的短期意义，它的长期意义是：可扩展性空前，适合随意组合、全场景广泛使用，符合很多人的设想、几乎所有人的需求，足以成为 v2ray 的下一代主要协议，乃至整个 XX 界的终极协议。

那么，是时候更新一下对 VLESS 的认知了。

Request & Response

1 字节	16 字节	1 字节	M 字节	1 字节	2 字节	1 字节	S 字节	X 字节
协议版本	等价 UUID	附加信息长度 M	附加信息 ProtoBuf	指令	端口	地址类型	地址	请求数据

1 字节	1 字节	N 字节	Y 字节
协议版本，与请求的一致	附加信息长度 N	附加信息 ProtoBuf	响应数据

VLESS 早在第二个测试版 ALPHA 2 时就已经是上述结构了（BETA 是第五个测试版）：

“响应认证”被替换为“协议版本”并移至最前，使 VLESS 可以升级换代，同时消除了生成伪随机数的开销。混淆相关结构被替换为附加信息（ProtoBuf）并前移，赋予协议本身可扩展性，相关开销也极小（gogo/protobuf），若无附加信息则无相关开销。

我一直觉得“响应认证”不是必要的，ALPHA 时为了提升生成随机数的性能，还用 math/rand 替换 crypto/rand，而现在都不需要了。

“协议版本”不仅能起到“响应认证”的作用，还赋予了 VLESS 无痛升级协议结构的能力，带来无限的可能性。 “协议版本”在测试版本中均为 0，正式版本中为 1，以后若有不兼容的协议结构变更则应升级版本。

VLESS 服务端的设计是 switch version，即同时支持所有 VLESS 版本。若需要升级协议版本（可能到不了这一步），推荐的做法是服务端提前一个月支持，一个月后再改客户端。VMess 请求也有协议版本，但它的认证信息在外面，指令部分则高度耦合且有固定加密，导致里面的协议版本毫无意义，服务端也没有进行判断，响应则没有协议版本。Trojan 的协议结构中没有协议版本。

接下来是 UUID，我本来觉得 16 字节有点长，曾经考虑过缩短它，但后来看到 Trojan 用了 56 个可打印字符（56 字节），就彻底打消了这个念头。服务端每次都要验证 UUID，所以性能也很重要：VLESS 的 Validator 经历了多次重构/升级，相较于 VMess，它十分简洁且耗资源很少，可以同时支持非常多的用户，性能也十分强悍，验证速度极快（sync.Map）。API 动态增删用户则更高效顺滑。

引入 ProtoBuf 是一个创举，等下会详细讲解。“指令”到“地址”的结构目前与 VMess 完全相同，同样支持 Mux。

总体上，ALPHA 2 到 BETA 主要是：结构进化、清理整合、性能提升、更加完善。这些都是一点一滴的，详见 VLESS Changes。

ProtoBuf

似乎只有 VLESS 可选内嵌 ProtoBuf，它是一种数据交换格式，信息被紧密编码成二进制，TLV 结构（Tag Length Value）。

起因是我看到一篇文章称 SS 有一些缺点，如没有设计错误回报机制，客户端没办法根据不同的错误采取进一步的动作。 （但我并不认同所有错误都要回报，不然防不了主动探测。下一个测试版中，服务器可以返回一串自定义信息。） 于是想到一个可扩展的结构是很重要的，未来它也可以承载如动态端口指令。不止响应，请求也需要类似的结构。 本来打算自己设计 TLV，接着发觉 ProtoBuf 就是此结构、现成的轮子，完全适合用来做这件事，各语言支持等也不错。

目前“附加信息”只有 Scheduler 和 SchedulerV，它们是 MessName 和 MessSeed 的替代者，当你不需要它们时，“附加信息长度”为 0，也就不会有 ProtoBuf 序列化/反序列化的开销。其实我更愿意称这个过程为“拼接”，因为 pb 实际原理上也只是这么做而已，相关开销极小。拼接后的 bytes 十分紧凑，和 ALPHA 的方案相差无几，有兴趣的可以分别输出并对比。

为了指示对附加信息（Addons，也可以理解成插件，以后可以有很多个插件）的不同支持程度，下个测试版会在“附加信息长度”前新增“附加信息版本”。256 - 1 = 255 字节是够用且合理的（65535 就太多了，还可能有人恶意填充），现有的只用了十分之一，以后也不会同时有那么多附加信息，且大多数情况下是完全没有附加信息的。真不够用的话，可以升级 VLESS 版本。

为了减少逻辑判断等开销，暂定 Addons 不使用多级结构。一个月前出现过“可变协议格式”的想法，pb 是可以做到打乱顺序，但没必要，因为现代加密的设计不会让旁观者看出两次传输的头部相同。

下面介绍 Schedulers 和 Encryption 的构想，它们都是可选的，一个应对流量时序特征问题，一个应对密码学上的问题。

Schedulers Flow

中文名暂称：流量调度器（2020-09-03 更新：中文名确定为“流控”），指令由 ProtoBuf 承载，控制的是数据部分。

我之前发现，VMess 原有的 shake “元数据混淆”在 TLS 上完全不会带来有意义的改变，只会降低性能，所以 VLESS 弃用了它。并且，“混淆”这个表述容易被误解成伪装，也弃用了。顺便一提，我一直是不看好伪装的：做不到完全一样，那不就是强特征吗？做得到完全一样，那为什么不直接用伪装目标？我一开始用的是 SSR，后来发现它只是表面伪装骗运营商，就再也没用过了。

那么，“流量调度器”要解决什么问题？它影响的是宏观流量时序特征，而不是微观特征，后者是加密要解决的事情。流量时序特征可以是协议带来的，比如 Socks5 over TLS 时的 Socks5 握手 ，TLS 上不同的这种特征对于监测者来说就是不同的协议，此时无限 Schedulers 就相当于无限协议（重新分配每次发送的数据量大小等）。流量时序特征也可以是行为带来的，比如访问 Google 首页时加载了多少文件、顺序、每个文件的大小，多套一层加密并不能有效掩盖这些信息。

Schedulers 没必要像下面的 Encryption 一样整个套在外面，因为头部的一丁点数据相对于后面的数据量来说太微不足道了。

BETA 2 预计推出两个初级的 Scheduler：Zstd 压缩、数据量动态扩充。进阶操作才是从宏观层面来控制、分配，暂时咕咕。

Encryption

与 VMess 的高度耦合不同，VLESS 的服务端、客户端不久后可以提前约定好加密方式，仅在外面套一层加密。这有点类似于使用 TLS，不影响承载的任何数据，也可以理解成底层就是从 TLS 换成预设约定加密。相对于高度耦合，这种方式更合理且灵活：一种加密方式出了安全性问题，直接扔掉并换用其它的就行了，十分方便。VLESS 服务端还会允许不同的加密方式共存。

对比 VMess，VLESS 相当于把 security 换成 encryption，把 disableInsecureEncryption 换成 decryption，就解决了所有问题。目前 encryption 和 decryption 只接受 "none" 且不能留空（即使以后有连接安全性检查），详见 VLESS 配置文档。encryption 并不需要往外移一级，一是因为无法复用很多代码，二是因为会影响控制粒度，看未来的应用就明白了。

加密支持两类形式，一类是加密完全独立，需要额外密码，适合私用，另一类是结合已有的 UUID 来加密，适合公用。 （若用第一类加密形式，且密码是以某种形式公开的，比如多人共用，那么中间人攻击就不远了） 重新设计的动态端口可能会随加密同时推出，指令由 ProtoBuf 承载，具体实现和 VMess 的动态端口也会有很多不同。

套现成加密是件很简单的事情，也就多一层 writer & reader。BETA 3 预计支持 SS 的 aes-128-gcm 和 chacha20-ietf-poly1305： 客户端的 encryption 可以填 “auto: ss_aes-128-gcm_0_123456, ss_chacha20-ietf-poly1305_0_987654”，auto 会选择最适合当前机器的，0 代表测试版，最后的是密码。服务端的 decryption 也是类似填法，收到请求时会逐一尝试解密。

并不是所有组合都需逐一尝试：VMess 的加密分为三段，第一段是认证信息，结合了 UUID、alterId、时间因素，第二段是指令部分，以固定算法加密，指令中含有数据部分使用的加密算法，第三段才是重要的数据部分。可以看出，VMess 的加解密方式实际上是多对一（服务端适配），而不仅是结合 UUID。但仅是结合 UUID 来加密也是件相对麻烦的事情，短时间内不会出，鉴于我们现在有 VMessAEAD 可用，也并不着急。若 VLESS 推出了结合 UUID 的加密方式，相当于重构了整个 VMess。

UDP issues

由于 VLESS 是对 VMess 的精简且同样存在于 v2ray 中，目前 VLESS 的 UDP 能力与 VMess 完全相同，也就是：

1. 整个 v2ray 对 UDP 的处理广泛存在问题，这是影响 FullCone 实现的障碍之一，参考 https://github.com/v2ray/v2ray-core/issues/1429#issuecomment-549667805
2. VMess 没有为 UDP 建立持久的隧道，这是影响 FullCone 实现的障碍之二，参考 https://trojan-gfw.github.io/trojan/protocol
3. VMess 只支持 UDP over TCP，不支持直接 UDP（至于 mKCP、QUIC，它们不属于 VMess，且 UDP 实际上经历了两次转换）

对于第一个问题，要改 v2ray 很多地方的代码，希望 @xiaokangwang 大佬可以解决。

对于第二个问题，我先几句话讲清突破本地的层层 NAT 限制实现 FullCone 的原理：

简单来说就是把远端 VPS 的一些 UDP 端口“映射”到本机，使其效果完全等同于本机的端口（但本机的端口并不一定被实际占用）。因为 VPS 一般都是有公网 IP 的，NAT 环境最佳，核心原理就是利用 VPS 的公网 IP 来提升本机的 NAT 等级，或者某个游戏/应用的实际 NAT 等级。此时它们使用的实际上是远端 VPS 的端口，就绕过了本地的层层 NAT 限制。而要做到保持映射，至少连接要保持住。

VLESS BETA 系列后期，预计客户端可选：

"udp": {
    "nat": "origin" / "tunnel" / "tunnels",
    "tcp": true / false
}

Sharing link

为了避免 VMess 分享链接生态混乱的情况，VLESS 要求图形客户端等仅支持官方分享链接标准，即将出炉。

一开始，我只是简化了 VMess，并推出 VLESS 协议，追求性能极限，不断进行优化，同时注重可扩展性，为下一步铺路。

而现在，不同于前几个版本主要做减法，BETA 系列的目标是好好利用可扩展性，做可选的加法，成为终极协议。

我一直在强调，这些加法都是可选的，如果你不需要那就不用开启，并不影响性能极限，这也是最重要的、贯穿始终的。

到处可扩展、可组合、层层完美解耦不失性能，并不只是我一个人的设想，很多人都是这么想的，这个解决方案可以使所有人满意。

而 VLESS 将会成为有史以来可解耦性（性能）、可扩展性（功能）、安全性等都最强大、完美的终极协议，一个协议解决所有问题。

当然，这也离不开 v2ray 已有的模块，感谢大家的贡献。我相信对于 v2ray 来说，这也会是一个全新的开始。

若还有什么没考虑到的情况，欢迎提出改进建议，这个 issue 还会持续跟进 VLESS 的更新。

LESS IS MORE.

[RPRX]

@lxhao61

1. PROXY protocol 并不是必须的，若需要，则取决于 Caddy2 是否能接收它，我没用过 Caddy，不清楚。
2. 意思是网站只支持 h2 吗？改代码是可以去除限制（但我貌似没见过这种实践）。
3. mKCP 在底层且非广泛使用，难以隐藏。目前暂不考虑给其它地方写回落，UDP 上的貌似也无法实现。

[RPRX]

@lxhao61

如果你希望网站只支持 h2，可以试试 inbound TLS 的 alpn 只留 h2，应该相当于让 fallback 项失效。

[lxhao61]

@rprx 1与2项，明白了。 3项不是网站只支持H2。是想仅一个nginx，实现VLESS+TCP+nginx（web+回落）、VMess/VLESS+WebSocket+nginx（web+tls）、 VLESS+H2+nginx（web+回落）应用。

[1265578519]

nginx仅支持http1.1回源，不支持h2回源，任何一款web都是这样的，没有h2回源的功能。http协议规范中不存在h2回源一说法。

[lxhao61]

@lxhao61

如果你希望网站只支持 h2，可以试试 inbound TLS 的 alpn 只留 h2，应该相当于让 fallback 项失效。

不是。想v2ray除了TCP、WebSocket传输方式外，也同时用H2传输方式。

[lxhao61]

nginx仅支持http1.1回源，不支持h2回源，任何一款web都是这样的，没有h2回源的功能。http协议规范中不存在h2回源一说法。 @1265578519

哦，这样呀。

[lxhao61]

想VLES支持如下： v2ray client <--- H2 ---> v2ray server<--- 回落 ---> nginx

[1265578519]

@lxhao61 根据网络协议规范，仅能支持v2ray客户端h2→nginx http1.1→v2ray ws服务端 当然有个方法，直接在v2ray服务器内部集成nginx，用户不可见那种，然后v2ray可以直接输出h2，此时v2ray客户端可以通过h2直接连接服务端 或者说，在同一台服务器中安装nginx，通过127.0.0.1的方式反代到v2ray服务端，也可以在v2ray客户端使用h2连接到nginx h2上，然后nginx负责127本地网络反代到v2ray服务端，此时不经过公网ip，网络无法出现干扰劫持

[lxhao61]

@1265578519 v2ray客户端h2→nginx http1.1→v2ray ws服务端 是v2ray client <---WebSocket+tls---> nginx <--- WebSocket ---> v2ray server吧。

[lxhao61]

@lxhao61 根据网络协议规范，仅能支持v2ray客户端h2→nginx http1.1→v2ray ws服务端 当然有个方法，直接在v2ray服务器内部集成nginx，用户不可见那种，然后v2ray可以直接输出h2，此时v2ray客户端可以通过h2直接连接服务端 或者说，在同一台服务器中安装nginx，通过127.0.0.1的方式反代到v2ray服务端，也可以在v2ray客户端使用h2连接到nginx h2上，然后nginx负责127本地网络反代到v2ray服务端，此时不经过公网ip，网络无法出现干扰劫持

@rprx @1265578519

主要是caddy2已经实现如下： v2ray client <--- H2 ---> caddy2 <--- H2C ---> v2ray server 而nginx无法实现如上（替换caddy2），故想通过VLES实现如下： v2ray client <--- H2 ---> v2ray server<--- 回落 ---> nginx

[RPRX]

@rprx 1与2项，明白了。 不是网站只支持H2。是想仅一个nginx，实现VLESS+TCP+nginx（web+回落）、VMess/VLESS+WebSocket+nginx（web+tls）、 VLESS+H2+nginx（web+回落）应用。

https://github.com/v2ray/v2ray-core/issues/2677#issuecomment-673988159

这个功能完成后，可以比较方便地实现 443 端口 TCP WS H2 共存（但暂时没有内部直接传输）

[lxhao61]

@rprx 1与2项，明白了。 不是网站只支持H2。是想仅一个nginx，实现VLESS+TCP+nginx（web+回落）、VMess/VLESS+WebSocket+nginx（web+tls）、 VLESS+H2+nginx（web+回落）应用。

#2677 (comment)

这个功能完成后，可以比较方便地实现 443 端口 TCP WS H2 共存（但暂时没有内部直接传输）

@rprx 基本就是这个需求。只是我对是否支持WS回落不持立场。毕竟已有v2ray client <---WebSocket+tls---> nginx <--- WebSocket ---> v2ray server了。我主要想VLESS有H2传输方式回落即可。

[1265578519]

H2C和H2协议不是同一个东西吧。。。 h2 指的是建立在 LTS 之上的 HTTP/2 协议，即 HTTP/2 Over LTS。 h2c 指的是建立在 TCP 之上的 HTTP/2 协议, 即 HTTP/2 Over TCP。

参考：https://blog.csdn.net/hanziyuan08/article/details/104050303

[cn4]

未来能否把vless协议独立成一个lib(不要依赖太多v2ray的组件)，方便其他客户端直接调用，以便更快普及？

[lxhao61]

H2C和H2协议不是同一个东西吧。。。 h2 指的是建立在 LTS 之上的 HTTP/2 协议，即 HTTP/2 Over LTS。 h2c 指的是建立在 TCP 之上的 HTTP/2 协议, 即 HTTP/2 Over TCP。

参考：https://blog.csdn.net/hanziyuan08/article/details/104050303 @1265578519

当然不是一个东西。H2C+TLS=H2

[zhaoyadong00]

各位大神 udp 问题什么时候解决

[cjwddtc]

我一直有个想法，可惜一直996没机会实现，就是所有的翻墙工具都是传输层的，为什么不能直接利用tun，实现一个完整的链路层级别的翻墙工具，直接绕过udp，tcp和ipv4、ipv6等顶层的问题，单纯的对点到点的流量进行加密和伪装，底层使用udp进行数据传输。

[gxind]

关于mux的问题，大佬说mux.cool有坑，那么是不是应该把第三方成熟的mux尽早考虑进来。考虑到一个问题，我们一般是fallback指向一个网页伪装，而我们代理肯定不止一个网页，那么会不会在tcp连接数上会成为一个特征呢

[1265578519]

mux我在服务器上抓包看了，还是会有多条连接持续通讯，不是只有一条，应该是客户端把多条连接合并成一条后发送，如果超过多条则合并成第二条。

[gxind]

mux我在服务器上抓包看了，还是会有多条连接持续通讯，不是只有一条，应该是客户端把多条连接合并成一条后发送，如果超过多条则合并成第二条。

v2现在的mux是这样的呀 concurrency项设置每几条连接合并成一条

[sisyphsu]

我一直有个想法，可惜一直996没机会实现，就是所有的翻墙工具都是传输层的，为什么不能直接利用tun，实现一个完整的链路层级别的翻墙工具，直接绕过udp，tcp和ipv4、ipv6等顶层的问题，单纯的对点到点的流量进行加密和伪装，底层使用udp进行数据传输。

可以通过tun直接代理IP层报文

[kulongwangzhi85]

弱弱的问下，什么协议回落模式。有什么好处。歇息。

[daiaji]

VLESS现在用在生产环境了吗？ 换VLESS能减少大量延迟？

[t66y100]

VLESS现在用在生产环境了吗？ 换VLESS能减少大量延迟？ 汗水发源于头上 速度取决于线路 名字是个代号 幸福全靠裆恩赐 啊啊啊啊啊啊啊啊啊

[sztuxp]

大神，再多的文字不如图方便，能否针对各种场景用图来表示一下各协议的层次关系，如果能对比一下VMESS，更有利于迁移。感谢！

[cjwddtc]

层级和vless没啥区别，我自己也是个程序员，大多数时候所谓的"性能提升"都是自己意淫出来的，其实没啥区别，翻墙工具性能瓶颈从来都是在加解密上面，而且事实上真实的瓶颈几乎都是线路，同级别的软路由和服务器性能一般都是有富裕的，三百多的软路由配置就能轻而易举的跑满200m的翻墙线路。 提升翻墙速度的优先级是加钱升级线路>加钱升级设备>更换加密算法>更换翻墙工具。 就算是更换翻墙工具中shadowsocks-libev对v2ray也是降维打击，人家是c语言的。。。。 vless我觉得牛逼的是那个混淆的方案，不过牛逼才吹出来，能不能做出来就不知道了，要是能做出来就真的流批了。

[ghost]

层级和vless没啥区别，我自己也是个程序员，大多数时候所谓的"性能提升"都是自己意淫出来的，其实没啥区别，翻墙工具性能瓶颈从来都是在加解密上面，而且事实上真实的瓶颈几乎都是线路，同级别的软路由和服务器性能一般都是有富裕的，三百多的软路由配置就能轻而易举的跑满200m的翻墙线路。 提升翻墙速度的优先级是加钱升级线路>加钱升级设备>更换加密算法>更换翻墙工具。 就算是更换翻墙工具中shadowsocks-libev对v2ray也是降维打击，人家是c语言的。。。。 vless我觉得牛逼的是那个混淆的方案，不过牛逼才吹出来，能不能做出来就不知道了，要是能做出来就真的流批了。

https://github.com/badO1a5A90/v2ray-doc/blob/master/v2ray%20speed%20test%20v4.27.2.md

[cjwddtc]

这是拿两台服务器测试的。真是翻墙需求中，能跑到500mbps的线路要多少钱一个月？这种级别的线路会配一个志强双核的vps吗？至于客户端，电子垃圾中新一点的都能轻松跑满千兆。我并不是说没有性能提升，我也喜欢没事优化一下，但是这种优化的层级，即使我不去看测试结果我也知道只会在某些比较不常见的情况下提升较为有限的性能，因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。（我就是搞性能分析工具开发的）。

• 真实的使用场景下通常速度瓶颈大部分都是在带宽，所以大部分人换了协议速度根本不会提升。

• 软件处理数据包的延迟通常不会超过1ms即使超过了也远远不能和在网络中传输时数十毫秒甚至上百毫秒的延迟相比。所以换了协议几乎不会提升延迟

• 即使你真的有一个能翻墙跑满千兆的线路，升级下vps的配置到4核心就跑满千兆了，相比于折腾带来的大得多。

我没有否定这项工作意义的意思，我说过我也是程序员，也喜欢干这种事，一个开发了这么久的项目能一波操作提升10%以上的性能真的很牛逼。我只是告诉使用程序的普通人，你换了没用的，别折腾了，还可能有bug。

[cjwddtc]

另外问那个生产环境那个，你不要想太多，生产环境可以参考v2ray开发了多久才开始有机场支持vmess。好几年前了，我也不记得了。反正至少要等标题中那个大大的beta没了之后才有可能。

[cjwddtc]

我一直有个想法，可惜一直996没机会实现，就是所有的翻墙工具都是传输层的，为什么不能直接利用tun，实现一个完整的链路层级别的翻墙工具，直接绕过udp，tcp和ipv4、ipv6等顶层的问题，单纯的对点到点的流量进行加密和伪装，底层使用udp进行数据传输。

可以通过tun直接代理IP层报文

我知道tun，但是协议本身是传输层的，或者说协议本身只能接受传输层报文的输入，实际区别就是不能ping，因为ping是icmp协议的。在我看来这样做会提高复杂度，必须要多不同的传输层协议报文做处理，而且我目前没有发现明显的优势，所以我一直很费解为什么所有的翻墙工具都处理的是传输层的报文，而不是直接处理网络层的报文，把nat的问题交给操作系统。

[ghost]

这是拿两台服务器测试的。真是翻墙需求中，能跑到500mbps的线路要多少钱一个月？这种级别的线路会配一个志强双核的vps吗？至于客户端，电子垃圾中新一点的都能轻松跑满千兆。我并不是说没有性能提升，我也喜欢没事优化一下，但是这种优化的层级，即使我不去看测试结果我也知道只会在某些比较不常见的情况下提升较为有限的性能，因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。（我就是搞性能分析工具开发的）。

• 真实的使用场景下通常速度瓶颈大部分都是在带宽，所以大部分人换了协议速度根本不会提升。
• 软件处理数据包的延迟通常不会超过1ms即使超过了也远远不能和在网络中传输时数十毫秒甚至上百毫秒的延迟相比。所以换了协议几乎不会提升延迟
• 即使你真的有一个能翻墙跑满千兆的线路，升级下vps的配置到4核心就跑满千兆了，相比于折腾带来的大得多。

我没有否定这项工作意义的意思，我说过我也是程序员，也喜欢干这种事，一个开发了这么久的项目能一波操作提升10%以上的性能真的很牛逼。我只是告诉使用程序的普通人，你换了没用的，别折腾了，还可能有bug。

1.真是翻墙需求中，能跑到500mbps的线路要多少钱一个月？这种级别的线路会配一个志强双核的vps吗？ ·········还真有，现在有钱人挺多，高于100mbps的线路在性能上就能体现出差别了。而使用100mbps以上的线路的人并不少。 ·········就算是小带宽的服务器，对于很多路由器用户来说，性能提升巨大。https://github.com/v2ray/discussion/issues/513#issuecomment-581247798 2.软件处理数据包的延迟通常不会超过1ms即使超过了也远远不能和在网络中传输时数十毫秒甚至上百毫秒的延迟相比。所以换了协议几乎不会提升延迟 ·······看视频当然没区别，打游戏你就能体会到区别了。虽然VLESS的游戏体验还是一般，因为走的是tcp，这个没办法

[RPRX]

瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 CPU 占用率间歇性 100%。消耗资源少对性能本身就差些的硬件和移动设备等更是利好（此时还有个耗电问题），从目前得到的真实反馈来看，VLESS 的延迟的确更低一些，响应速度更快，体感提升明显（即使 WS）。

VLESS 相较于 VMess，除了最大限度精简外（甚至比 Socks5 更简），使用方式上又去掉了一层 WS（1-RTT）和 Nginx。 https://github.com/v2fly/v2ray-examples/tree/master/VLESS-TCP-TLS-WS%20(recommended) 发这个是为了说明，评价 VLESS 也不只是性能这一个标准，要从多角度看待问题，比如 v2ray 有了不输 trojan 的协议。

这两天会完成“新型协议回落模式解析”

顺便一提，实际使用基本都是 TLS 二次加密，VLESS 即将推出一个具有划时代意义的试验版本 VLESS xTLS 来解决这个问题。

[ghost]

顺便一提，实际使用基本都是 TLS 二次加密，VLESS 即将推出一个具有划时代意义的试验版本 VLESS xTLS 来解决这个问题。

VLESS+TCP+TLS 和 VLESS+WS+nginx分流+TLS 都是 TLS 二次加密吗？

[cjwddtc]

瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 CPU 占用率间歇性 100%。消耗资源少对性能本身就差些的硬件和移动设备等更是利好（此时还有个耗电问题），从目前得到的真实反馈来看，VLESS 的延迟的确更低一些，响应速度更快，体感提升明显（即使 WS）。

VLESS 相较于 VMess，除了最大限度精简外（甚至比 Socks5 更简），使用方式上又去掉了一层 WS（1-RTT）和 Nginx。 https://github.com/v2fly/v2ray-examples/tree/master/VLESS-TCP-TLS-WS%20(recommended) 发这个是为了说明，评价 VLESS 也不只是性能这一个标准，要从多角度看待问题，比如 v2ray 有了不输 trojan 的协议。

这两天会完成“新型协议回落模式解析”

顺便一提，实际使用基本都是 TLS 二次加密，VLESS 即将推出一个具有划时代意义的试验版本 VLESS xTLS 来解决这个问题。

100mbps的话按照那个测试，即使单核志强也能跑出300mbps的速度，100mbps确实很多，超过200mbps就比较少了，有钱人干嘛一顿折腾提上14%的性能，直接增加核心就完事了，从测试结果看4核心已经能够跑满千兆了。 另外我问一句tls二次加密是什么意思？你不会是指tls经过http服务器转发给v2ray再做一次tls吧？我其实不用v2ray的tls，我都是直接用http服务器的tls反向代理tcp的vmess，这样做会有什么问题吗？

[daiaji]

另外我问一句tls二次加密是什么意思？

多半是CDN的加密吧

[cjwddtc]

瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 CPU 占用率间歇性 100%。消耗资源少对性能本身就差些的硬件和移动设备等更是利好（此时还有个耗电问题），从目前得到的真实反馈来看，VLESS 的延迟的确更低一些，响应速度更快，体感提升明显（即使 WS）。

VLESS 相较于 VMess，除了最大限度精简外（甚至比 Socks5 更简），使用方式上又去掉了一层 WS（1-RTT）和 Nginx。 https://github.com/v2fly/v2ray-examples/tree/master/VLESS-TCP-TLS-WS%20(recommended) 发这个是为了说明，评价 VLESS 也不只是性能这一个标准，要从多角度看待问题，比如 v2ray 有了不输 trojan 的协议。

这两天会完成“新型协议回落模式解析”

顺便一提，实际使用基本都是 TLS 二次加密，VLESS 即将推出一个具有划时代意义的试验版本 VLESS xTLS 来解决这个问题。

延迟这个事情说真的，打游戏不算，我是真的感觉不出来，wireguard（这个跑udp的我理解中应该是延迟天花板了）和v2ray+ws走apachewss反向代理，我感觉不出来任何区别。延迟这个事情总感觉这是个心理作用（我真的掐表数过，虽然人工计时不准）。

[ghost]

瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 CPU 占用率间歇性 100%。消耗资源少对性能本身就差些的硬件和移动设备等更是利好（此时还有个耗电问题），从目前得到的真实反馈来看，VLESS 的延迟的确更低一些，响应速度更快，体感提升明显（即使 WS）。 VLESS 相较于 VMess，除了最大限度精简外（甚至比 Socks5 更简），使用方式上又去掉了一层 WS（1-RTT）和 Nginx。 https://github.com/v2fly/v2ray-examples/tree/master/VLESS-TCP-TLS-WS%20(recommended) 发这个是为了说明，评价 VLESS 也不只是性能这一个标准，要从多角度看待问题，比如 v2ray 有了不输 trojan 的协议。

这两天会完成“新型协议回落模式解析”

顺便一提，实际使用基本都是 TLS 二次加密，VLESS 即将推出一个具有划时代意义的试验版本 VLESS xTLS 来解决这个问题。

延迟这个事情说真的，打游戏不算，我是真的感觉不出来，wireguard（这个跑udp的我理解中应该是延迟天花板了）和v2ray+ws走apachewss反向代理，我感觉不出来任何区别。延迟这个事情总感觉这是个心理作用（我真的掐表数过，虽然人工计时不准）。

打游戏我是用过vmess+nginx(ws分流)+tls、vless+tcp+tls、wireguard+udpspeeder+udp2raw三种。vmess+nginx(ws分流)+tls和wireguard+udpspeeder+udp2raw简直是一个天上一个地下，vless+tcp+tls勉强能玩。

[RPRX]

@kirin10000 @cjwddtc @daiaji

TLS 二次加密指的是大多数传输的内容本身就是 TLS（网站、APP 等），此时再用基于 TLS 的代理工具，就出现了 TLS 嵌套。

我正在写一个魔改版 TLS：xTLS，它可以与 VLESS 完美配合，遇到 TLS data record 时稍作修改即可传输，接收方也可以识别。

因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。

优化掉了。

[cjwddtc]

@kirin10000 @cjwddtc @daiaji

TLS 二次加密指的是大多数传输的内容本身就是 TLS（网站、APP 等），此时再用基于 TLS 的代理工具，就出现了 TLS 嵌套。

我正在写一个魔改版 TLS：xTLS，它可以与 VLESS 完美配合，遇到 TLS data record 时稍作修改即可传输，接收方也可以识别。

因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。

优化掉了。

这么流批的功能，加到文档里啊。

[daiaji]

@rprx 流行的搞法不是cdn也加密一次吗？ 就直接把ws裸出去让cdn加个密就完事了？

[RPRX]

这么流批的功能，加到文档里啊。

指正文吗？因为 xTLS 最开始只是想法，这两天才着手验证了可行性，所以哪都没写。

[ghost]

@kirin10000 @cjwddtc @daiaji

TLS 二次加密指的是大多数传输的内容本身就是 TLS（网站、APP 等），此时再用基于 TLS 的代理工具，就出现了 TLS 嵌套。

我正在写一个魔改版 TLS：xTLS，它可以与 VLESS 完美配合，遇到 TLS data record 时稍作修改即可传输，接收方也可以识别。

因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。

优化掉了。

明白了。这个东西我之前就有想过，但是觉得不太现实，或者可能带来安全隐患，就没提过，没想到真的可以实现，太惊喜了。 我以前就有想过，访问youtube，抓包，只能知道你在访问youtube，不能知道你的完整url，所以只要对youtube这个域名加密就好了。

[daiaji]

xTLS，它可以与 VLESS 完美配合，遇到 TLS data record 时稍作修改即可传输，接收方也可以识别。

这起看来特征拉满啊

[RPRX]

这起看来特征拉满啊

从外面看都是完整的 TLS data record，和普通 TLS 连接没有任何区别。

[cjwddtc]

@kirin10000 终于抓到一个用翻墙工具加速游戏的，我问下为什么不用专门的网游加速器呢，我觉得网游加速器效果应该更好啊。我一直有这个问题，但是没有碰到这么干的人。

[ghost]

@kirin10000 终于抓到一个用翻墙工具加速游戏的，我问下为什么不用专门的网游加速器呢，我觉得网游加速器效果应该更好啊。我一直有这个问题，但是没有碰到这么干的人。

1.我喜欢折腾。 2.要翻墙看youtube，同时也要打游戏，你用个游戏加速器去看youtube啊？？ 3.udpspeeder+udp2raw就是为自建服务器打游戏而生的，你自己去查一下，那个地方有很多用服务器打游戏的人 用服务器打游戏的人：https://github.com/wangyu-/UDPspeeder/blob/branch_libev/doc/README.zh-cn.md

[t66y100]

@kirin10000 终于抓到一个用翻墙工具加速游戏的，我问下为什么不用专门的网游加速器呢，我觉得网游加速器效果应该更好啊。我一直有这个问题，但是没有碰到这么干的人。

有钱人都是这么干的

[daiaji]

@rprx 把SNI之类的东西挑出来加个密混个淆？

[RPRX]

@rprx 把SNI之类的东西挑出来加个密混个淆？

不是这个思路，这样做不安全。

[badO1a5A90]

100mbps的话按照那个测试，即使单核志强也能跑出300mbps的速度，100mbps确实很多，超过200mbps就比较少了，有钱人干嘛一顿折腾提上14%的性能，直接增加核心就完事了，从测试结果看4核心已经能够跑满千兆了。 另外我问一句tls二次加密是什么意思？你不会是指tls经过http服务器转发给v2ray再做一次tls吧？我其实不用v2ray的tls，我都是直接用http服务器的tls反向代理tcp的vmess，这样做会有什么问题吗？

测试是我做的，的确如你所说，自建翻墙需求的体验和速度瓶颈大部分都是在基础网络上。我文中结论也说了网络条件不好的用什么都能跑满带宽的。 对于自建翻墙来说，首先考虑安全和伪装，然后稳定，然后延迟和带宽。所以不仅仅是带宽，体感明显的是延迟，更尤其是稳定性（高峰期大爆炸的vps没有什么协议可以救）。

但这并不能否认VLESS的性能提升，更不能说性能提升没有意义，可能很多人无论用什么都拉满了自己的带宽，但也有很多人可能从性能提升中受益.

而且VLESS的意义也并不是仅仅为了提高速度上限，并且这个测试想体现的是： 0.最想告知大家的是，VLESS的使用方式和v2ray原先的方式不一样，所以我首先写的是推荐组合方案，因为太多的测试和使用还停留在VLESS简单去替换vmess然后作比较，这不能完全发挥VLESS的性能和伪装性。（作者做了很有意义的工作，我希望能有更多的人能了解。） 1.在不一样的方式下提升的性能不是14%而是50%+，这是有明显差距的，比如江浙沪一带200-300mbps家用宽带并不少见，XX家1-2.5G口的三网GIA线路vps也不能说特别贵吧，某些环境下还是能跑出差距的。 2.VLESS的回落和不一样的使用方式带来的是更好的伪装性。 3.VLESS over TCP比大多数常见方案少1RTT延迟也是明显优势，比如看网页的体感差距。（比如对于美西vps来说真实使用延迟少150ms+）。 4.性能提升也意味着同样的速率需要更少的资源，VLESS可以降低功耗，节约手机电量等等。

ps：4核心VLESS over TCP裸奔跑出的不是千兆而是近7Gbps（10Gbps口）