[New Protocol] VLESS BETA：性能至上、可扩展性空前，目标是全场景终极协议。
RPRX opened this issue · comments
官网文档：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 版本，交叉编译可参考 v2ray/discussion#756 。
若你正在使用 TLS，简单地将 VMess 改为 VLESS 就可以获得性能提升：
- 替换服务端和客户端的可执行文件。
- 将两边的协议都改为 "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 完全相同，也就是：
- 整个 v2ray 对 UDP 的处理广泛存在问题，这是影响 FullCone 实现的障碍之一，参考 #1429 (comment)
- VMess 没有为 UDP 建立持久的隧道，这是影响 FullCone 实现的障碍之二，参考 https://trojan-gfw.github.io/trojan/protocol
- 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 希望releases能增加“linux arm64”、“linux arm”。因为VLESS受益最大的应该是手机端（我绝不承认自己编译不出执行文件）。
VLESS 即将发布一个 PREVIEW 版本，先合并进 v2ray-core 公测。以及，v2ray-vless 新版本会编译 linux-arm64-v8a 和 macos-64。
尽快合并到主项吧，这样才有支持VLESS的OpenWrt路由器端、手机端、图形界面客户端应用。因为基本无人用v2ray原版的无图形界面的客户端。
好着急啊，不知道大佬们什么时候能融入正式版，这样我的垃圾软路由就能减轻负担了
希望能解决UDP的痛点，那就真的是完美了
@RPRX
v2ray下的socks+websocket+tls、shadowsocks+v2ray-plugin及shadowsocks+websocket+tls配置应用有UDP问题不？非Vmess协议。
I think one may enable FullCone NAT with v2ray's bridge and portals over VLESS, where mux will be automatically enabled, and the heart beat will be sent to keep the connection.
@RPRX
Also the Port and Address in VLESS can be omitted when Mux.Cool is enabled. Maybe they can go into the ProtoBuf extesion?
I like the Mux.Cool because of its flexibility and the potential to allow multiplexing an customizable dummy UDP into TCP connections to modulate the traffic pattern, for future obfuscation needs.
v2ray 的 Mux 是在 VLESS 之前就接管了请求，把 VLESS 当成了它的底层传输方式，提供身份认证功能。
所以开启 Mux 后，Port 和 Address 已经不是 VLESS 的事情了，无需放入 ProtoBuf。
目前 Mux 是可以在一定程度上保持连接，但 v2ray 的一些组件有问题，仍然无法实现 FullCone。
Mux.Cool 本身也可能有一些坑，VLESS 协议以后可以单独选择第三方成熟的 Mux 方案。
mark nb
赞 期待
我觉得可行。
VMess/VLess可考慮擴展加入ICMP通道，這是為手機/電腦的V2Ray VPN模式而設計（目前PC的V2Ray Core只提供SOCKS/HTTP代理）。而VPN方案有TAP-Windows，用route或netsh設定路由表。
如果解决不了NAT的问题的话，，，感觉新协议没什么意义啊，看起来对比现有的貌似也没什么区别。
除了性能提升外？还有什么亮点吗，没看出来
v2ray-core 的第一个 VLESS 预览版，我觉得亮点是简洁而强大、安全的协议回落，接下来就是解决 UDP 问题和继续提升性能了。
有了这样的协议回落后，可以使 TCP + TLS 成为常态，比 WSS 更好。协议回落今天也刚刚升级，预计很快发布，主要是：
允许根据 TLS ALPN 的协商结果来单独转发 h2；支持 PROXY protocol 1 & 2，这样后端就能拿到请求的真实来源 IP 和端口了。
我覺得transport security的TLS可以分為server mode和client mode，server mode可以指定Cipher suite、ECDH Curve、Rekey timeout、Prefer server cipher，client/server可指定TLS Engine（Go/OpenSSL，也可考慮LibreSSL，Windows 10內建OpenSSH用的是LibreSSL）。未來可將DTLS和SSH（預設偽裝無Shell的SSH，畢竟Psiphon用的就是改版SSH）加入到transport security裡面。雖然目前TLS足夠穩定而且速度快。另外OpenSSL TLS 1.0-1.2使用OpenSSL風格的Cipher suite name，如ECDHE-ECDSA-AES128-GCM-SHA256（TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256）、ECDHE-ECDSA-AES128-SHA256（TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256），程式在指定Cipher suite時要自動轉換。
還要考慮一些電腦遊戲、程式是不支援代理的，必須VPN模式。我們遇到一個現象是繁體中文/日文Windows在中國下載更新（Windows Update/Windows Store）很慢，簡體中文Windows下載更新很快。
請支援NAT設定。
另外WS+TLS是用TLS包裝WS，H2+TLS是用TLS包裝H2；不清楚KCP+TLS是用TLS包裝KCP，還是用KCP包裝被TLS加密的數據。
@RPRX
大神出一个VLESS支持 PROXY protocol 1 & 2回落的具体配置模板（VLESS与Nginx配合），特别是Nginx安装与配置。否则大部分不知道怎么具体配置，当然包括我。
@RPRX
大神出一个VLESS支持 PROXY protocol 1 & 2回落的具体配置模板（VLESS与Nginx配合），特别是Nginx配置模板。否则大部分不知道怎么具体配置，当然包括我。
VLess是底層協定（SOCKS也可作為V2Ray底層協定），TLS、TLS+WS、TLS+HTTP2是進一步Transport層包裝。Nginx可以偽裝成wss://localhost:443，瀏覽器或curl打開https://localhost:443 後是一個網頁。Trojan-GFW支援plain_http_response選項，就是直接以HTTPS協定訪問端口時會返回的網頁。
VLESS 有基于首包长度分流（VLESS 原创）的新型协议回落模式，相对于其它协议回落方案，更简洁、高效、安全，功能也更强大。
https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md
设置 proxy_protocol 和 set_real_ip_from 即可（当然，之后也会出例子
https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/
v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vless/outbound: failed to find an available destination > v2ray.com/core/common/retry: [dial tcp xx.xx.xx.xx:443: operation was canceled dial tcp: operation was canceled] > v2ray.com/core/common/retry: all retry attempts failed
这个警告是因为服务器太渣，产生丢包，然后Warming吗？
帶加密協定。VMore？VMess V2（不向下相容VMess V1）？我的想法是VMess V2，可選加密，可選混淆，可選被transport security（TLS、DTLS、SSH）包裝。中國移動限制UDP厲害，中國電信也限制UDP。TLS只有AES-CBC、AES-GCM（TLS實作是SHA2和GHASH兩層MAC）、CHACHA20-POLY1305（TLS實作是SHA2和POLY1305兩層MAC）加密可選。SSH有AES-CBC（SSH的AES-CBC有漏洞，AES-CBC已被新版OpenSSH禁止）、AES-CTR、AES-GCM（SSH實作是使用內置GHASH，不使用SHA等額外MAC）、CHACHA20-POLY1305（SSH實作是使用內置POLY1305，不使用額外MAC）加密可選，還有EdDSA、ZLib壓縮等功能。
It seems that VLESS does not support Dynamic Port; is not it?
VLESS 有基于首包长度分流（VLESS 原创）的新型协议回落模式，相对于其它协议回落方案，更简洁、高效、安全，功能也更强大。
https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md设置 proxy_protocol 和 set_real_ip_from 即可（当然，之后也会出例子
https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/
@RPRX
唉，能力不行，搞不了。虽然折腾编译出了定制模块的nginx，但参考资料弄不成功，不知道那里配置出问题了。不折腾了，等正式及有配置模板再弄vless+tcp+tls+web（nginx）了。
另外想知道：因为vless支持协议回落模式。
1、如与定制模块的nginx配合，除了可实现vless+tcp+tls+web（nginx）外，是否可以实现vless+h2c+tls+web（nginx）？
2、caddy2（最新测试版）支持H2C了，已成功。不知道是否可以实现vless+tcp+tls+web（caddy2）?
Nginx 默认版就有 proxy_protocol 等，其实不需要自己编译
h2c 是支持的，Nginx 也不需要定制模块，起个 http2 服务，然后 VLESS 设置 fallback_h2 项即可（参考 VLESS 文档，很简单
Nginx 默认版就有 proxy_protocol 等，其实不需要自己编译
h2c 是支持的，Nginx 也不需要定制模块，起个 http2 服务，然后 VLESS 设置 fallback_h2 项即可（参考 VLESS 文档，很简单
我看介绍，Nginx 默认不带 proxy_protocol呀。晕。
@RPRX
我用Debian 9，版本过低。看using-proxy-protocol资料及其它资料介绍要自己定制编译。
大神，你弄个参考模板吧。参考：https://github.com/veekxt/v2ray-template
添加vless+tcp+tls+web（nginx）与vless+h2c+tls+web（nginx）两个。
希望能解决UDP的痛点，那就真的是完美了
redsocks redsocks2和ipt2socks一直都可以FullCone。
期待出个vless的具体配置模板，小白还是不太会自己配
是的。主要nginx配置。
/dev/random RNG會明顯影響加密軟件（TLS、SSH）的效能。Google很多文章都沒提到這個問題。
用dd if=/dev/random of=/dev/null命令可以測試/dev/random亂數生成器的速度。
在Debian/Ubuntu下可以使用haveged加快亂數生成速度。CentOS 8預設安裝rng-tools，CentOS 8使用的rngd是被Red Hat修改的rngd 6.x，比Debian/Ubuntu的rng-tools5效能更好。
Linux kernel 5.6已經大幅改善/dev/random效能，不需安裝haveged或rng-tools。
這就是為什麼明明用iperf3測試server->client速度很快，但使用TLS、SSH速度緩慢的原因。
如果使用Linux kernel 4.8以上，也可以執行ln -sf /dev/urandom /dev/random，並執行systemctl stop rngd haveged && systemctl disable rngd haveged。但每次重啟後都要執行ln -sf /dev/urandom /dev/random。這樣比rng-tools和haveged快。
https://wiki.archlinux.org/index.php/Random_number_generation
https://en.wikipedia.org/wiki//dev/random
另外希望統一解決V2RayNG等Android/iOS Client在連接VPN後無法使用Miracast投影的問題。現在很多VPN App的「Bypass LAN IP」其實只跳過IPv4 LAN IP，沒有跳過IPv6 LAN IP。希望Bypass LAN IP和GeoIP統一更新IPv6位址。
mark
Update: 反馈的地方有误，和 VLess 关系不大，这应该是 transport 层该处理的问题。
GFW 可能会阻断带有 ESNI 扩展的 TLS 连接，如果 VLess 会提供 TLS 1.3 支持时需要考虑到这一点。
消息来源于 GFW Report，维基百科的 服务器名称指示 条目也在 ESNI 的部分补充了这条消息。
Update: 反馈的地方有误，和 VLess 关系不大，这应该是 transport 层该处理的问题。
GFW 可能会阻断带有 ESNI 扩展的 TLS 连接，如果 VLess 会提供 TLS 1.3 支持时需要考虑到这一点。
消息来源于 GFW Report，维基百科的 服务器名称指示 条目也在 ESNI 的部分补充了这条消息。
對ESNI下手，原理是降級攻擊，還不能做到解密。目前ESNI還很少用，主流的OpenSSL不支援ESNI。當你執行gnutls-cli www.yahoo.com:443時順便抓包，你會發現抓到www.yahoo.com，這就是SNI，SNI未被加密，ESNI就是把SNI加密了。當DNS over TLS和ESNI都普及後…… 而目前IP-only憑證並不便宜。
GFW 可能会阻断带有 ESNI 扩展的 TLS 连接，如果 VLess 会提供 TLS 1.3 支持时需要考虑到这一点。
ESNI（最近改名為ECH）只是TLS 1.3的一個擴展，並非所有TLS 1.3連接都開啓了此擴展。相反，ESNI目前是非常小眾的東西，客户端僅僅只有firefox提供支持，而且起用方式十分麻煩。服務器端僅僅只有cloudflare支持，你用的服務器無論nginx，caddy，haproxy，都是不支持的。
至於GFW阻斷ESNI，部分原因也是因為目前最主流瀏覽器（firefox不算），服務器都未實現，所以直接一刀切封掉完全不存在連帶損害。倘若ECH將來成為包括國內大廠在內的市場主流，也不是沒有解封的可能。
至於GFW阻斷ESNI，部分原因也是因為目前最主流瀏覽器（firefox不算），服務器都未實現，所以直接一刀切封掉完全不存在連帶損害。倘若ECH將來成為包括國內大廠在內的市場主流，也不是沒有解封的可能。
我起初误解了扩展的定义，之前的话语稍有些危言耸听。如此看在，GFW 阻断 ESNI 至少在很长一段时间内无关痛痒，感谢 @okudayukiko @darhwa 两位赐教。
@RPRX
1、VLESS回落是否可以由caddy2来配合？知道caddy1有http.proxyprotocol插件。caddy2还没查到相关资料。
2、目前VLESS回落，发现不能独立启用fallback_h2。想实现VLESS+H2+nginx回落。
3、nginx的PROXY Protocol支持stream，是否可以实现mKCP回落，配置媒体网站隐藏mKCP？
产生1的原因：主要是caddy无法反向代理v2ray TCP。
产生2的原因：主要是nginx无法反向代理v2ray H2/H2C。
产生3的原因：主要是想mKCP也实现“隐藏”。
- PROXY protocol 并不是必须的，若需要，则取决于 Caddy2 是否能接收它，我没用过 Caddy，不清楚。
- 意思是网站只支持 h2 吗？改代码是可以去除限制（但我貌似没见过这种实践）。
- mKCP 在底层且非广泛使用，难以隐藏。目前暂不考虑给其它地方写回落，UDP 上的貌似也无法实现。
@RPRX
1与2项，明白了。
3项不是网站只支持H2。是想仅一个nginx，实现VLESS+TCP+nginx（web+回落）、VMess/VLESS+WebSocket+nginx（web+tls）、
VLESS+H2+nginx（web+回落）应用。
nginx仅支持http1.1回源，不支持h2回源，任何一款web都是这样的，没有h2回源的功能。http协议规范中不存在h2回源一说法。
如果你希望网站只支持 h2，可以试试 inbound TLS 的 alpn 只留 h2，应该相当于让 fallback 项失效。
不是。想v2ray除了TCP、WebSocket传输方式外，也同时用H2传输方式。
nginx仅支持http1.1回源，不支持h2回源，任何一款web都是这样的，没有h2回源的功能。http协议规范中不存在h2回源一说法。
@1265578519
哦，这样呀。
想VLES支持如下：
v2ray client <--- H2 ---> v2ray server<--- 回落 ---> nginx
@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，网络无法出现干扰劫持
@1265578519
v2ray客户端h2→nginx http1.1→v2ray ws服务端
是v2ray client <---WebSocket+tls---> nginx <--- WebSocket ---> v2ray server吧。
@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，网络无法出现干扰劫持
主要是caddy2已经实现如下：
v2ray client <--- H2 ---> caddy2 <--- H2C ---> v2ray server
而nginx无法实现如上（替换caddy2），故想通过VLES实现如下：
v2ray client <--- H2 ---> v2ray server<--- 回落 ---> nginx
@RPRX
1与2项，明白了。
不是网站只支持H2。是想仅一个nginx，实现VLESS+TCP+nginx（web+回落）、VMess/VLESS+WebSocket+nginx（web+tls）、
VLESS+H2+nginx（web+回落）应用。
这个功能完成后，可以比较方便地实现 443 端口 TCP WS H2 共存（但暂时没有内部直接传输）
@RPRX
1与2项，明白了。
不是网站只支持H2。是想仅一个nginx，实现VLESS+TCP+nginx（web+回落）、VMess/VLESS+WebSocket+nginx（web+tls）、
VLESS+H2+nginx（web+回落）应用。这个功能完成后，可以比较方便地实现 443 端口 TCP WS H2 共存（但暂时没有内部直接传输）
@RPRX
基本就是这个需求。只是我对是否支持WS回落不持立场。毕竟已有v2ray client <---WebSocket+tls---> nginx <--- WebSocket ---> v2ray server了。我主要想VLESS有H2传输方式回落即可。
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
未来能否把vless协议独立成一个lib(不要依赖太多v2ray的组件)，方便其他客户端直接调用，以便更快普及？
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
各位大神 udp 问题什么时候解决
我一直有个想法，可惜一直996没机会实现，就是所有的翻墙工具都是传输层的，为什么不能直接利用tun，实现一个完整的链路层级别的翻墙工具，直接绕过udp，tcp和ipv4、ipv6等顶层的问题，单纯的对点到点的流量进行加密和伪装，底层使用udp进行数据传输。
关于mux的问题，大佬说mux.cool有坑，那么是不是应该把第三方成熟的mux尽早考虑进来。考虑到一个问题，我们一般是fallback指向一个网页伪装，而我们代理肯定不止一个网页，那么会不会在tcp连接数上会成为一个特征呢
mux我在服务器上抓包看了，还是会有多条连接持续通讯，不是只有一条，应该是客户端把多条连接合并成一条后发送，如果超过多条则合并成第二条。
mux我在服务器上抓包看了，还是会有多条连接持续通讯，不是只有一条，应该是客户端把多条连接合并成一条后发送，如果超过多条则合并成第二条。
v2现在的mux是这样的呀 concurrency项设置每几条连接合并成一条
我一直有个想法，可惜一直996没机会实现，就是所有的翻墙工具都是传输层的，为什么不能直接利用tun，实现一个完整的链路层级别的翻墙工具，直接绕过udp，tcp和ipv4、ipv6等顶层的问题，单纯的对点到点的流量进行加密和伪装，底层使用udp进行数据传输。
可以通过tun直接代理IP层报文
弱弱的问下，什么协议回落模式。有什么好处。歇息。
VLESS现在用在生产环境了吗？
换VLESS能减少大量延迟？
VLESS现在用在生产环境了吗？
换VLESS能减少大量延迟？
汗水发源于头上
速度取决于线路
名字是个代号
幸福全靠裆恩赐
啊啊啊啊啊啊啊啊啊
大神，再多的文字不如图方便，能否针对各种场景用图来表示一下各协议的层次关系，如果能对比一下VMESS，更有利于迁移。感谢！
层级和vless没啥区别，我自己也是个程序员，大多数时候所谓的"性能提升"都是自己意淫出来的，其实没啥区别，翻墙工具性能瓶颈从来都是在加解密上面，而且事实上真实的瓶颈几乎都是线路，同级别的软路由和服务器性能一般都是有富裕的，三百多的软路由配置就能轻而易举的跑满200m的翻墙线路。
提升翻墙速度的优先级是加钱升级线路>加钱升级设备>更换加密算法>更换翻墙工具。
就算是更换翻墙工具中shadowsocks-libev对v2ray也是降维打击，人家是c语言的。。。。
vless我觉得牛逼的是那个混淆的方案，不过牛逼才吹出来，能不能做出来就不知道了，要是能做出来就真的流批了。
层级和vless没啥区别，我自己也是个程序员，大多数时候所谓的"性能提升"都是自己意淫出来的，其实没啥区别，翻墙工具性能瓶颈从来都是在加解密上面，而且事实上真实的瓶颈几乎都是线路，同级别的软路由和服务器性能一般都是有富裕的，三百多的软路由配置就能轻而易举的跑满200m的翻墙线路。
提升翻墙速度的优先级是加钱升级线路>加钱升级设备>更换加密算法>更换翻墙工具。
就算是更换翻墙工具中shadowsocks-libev对v2ray也是降维打击，人家是c语言的。。。。
vless我觉得牛逼的是那个混淆的方案，不过牛逼才吹出来，能不能做出来就不知道了，要是能做出来就真的流批了。
https://github.com/badO1a5A90/v2ray-doc/blob/master/v2ray%20speed%20test%20v4.27.2.md
这是拿两台服务器测试的。真是翻墙需求中，能跑到500mbps的线路要多少钱一个月？这种级别的线路会配一个志强双核的vps吗？至于客户端，电子垃圾中新一点的都能轻松跑满千兆。我并不是说没有性能提升，我也喜欢没事优化一下，但是这种优化的层级，即使我不去看测试结果我也知道只会在某些比较不常见的情况下提升较为有限的性能，因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。（我就是搞性能分析工具开发的）。
-
真实的使用场景下通常速度瓶颈大部分都是在带宽，所以大部分人换了协议速度根本不会提升。
-
软件处理数据包的延迟通常不会超过1ms即使超过了也远远不能和在网络中传输时数十毫秒甚至上百毫秒的延迟相比。所以换了协议几乎不会提升延迟
-
即使你真的有一个能翻墙跑满千兆的线路，升级下vps的配置到4核心就跑满千兆了，相比于折腾带来的大得多。
我没有否定这项工作意义的意思，我说过我也是程序员，也喜欢干这种事，一个开发了这么久的项目能一波操作提升10%以上的性能真的很牛逼。我只是告诉使用程序的普通人，你换了没用的，别折腾了，还可能有bug。
另外问那个生产环境那个，你不要想太多，生产环境可以参考v2ray开发了多久才开始有机场支持vmess。好几年前了，我也不记得了。反正至少要等标题中那个大大的beta没了之后才有可能。
我一直有个想法，可惜一直996没机会实现，就是所有的翻墙工具都是传输层的，为什么不能直接利用tun，实现一个完整的链路层级别的翻墙工具，直接绕过udp，tcp和ipv4、ipv6等顶层的问题，单纯的对点到点的流量进行加密和伪装，底层使用udp进行数据传输。
可以通过tun直接代理IP层报文
我知道tun，但是协议本身是传输层的，或者说协议本身只能接受传输层报文的输入，实际区别就是不能ping，因为ping是icmp协议的。在我看来这样做会提高复杂度，必须要多不同的传输层协议报文做处理，而且我目前没有发现明显的优势，所以我一直很费解为什么所有的翻墙工具都处理的是传输层的报文，而不是直接处理网络层的报文，把nat的问题交给操作系统。
这是拿两台服务器测试的。真是翻墙需求中，能跑到500mbps的线路要多少钱一个月？这种级别的线路会配一个志强双核的vps吗？至于客户端，电子垃圾中新一点的都能轻松跑满千兆。我并不是说没有性能提升，我也喜欢没事优化一下，但是这种优化的层级，即使我不去看测试结果我也知道只会在某些比较不常见的情况下提升较为有限的性能，因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。（我就是搞性能分析工具开发的）。
- 真实的使用场景下通常速度瓶颈大部分都是在带宽，所以大部分人换了协议速度根本不会提升。
- 软件处理数据包的延迟通常不会超过1ms即使超过了也远远不能和在网络中传输时数十毫秒甚至上百毫秒的延迟相比。所以换了协议几乎不会提升延迟
- 即使你真的有一个能翻墙跑满千兆的线路，升级下vps的配置到4核心就跑满千兆了，相比于折腾带来的大得多。
我没有否定这项工作意义的意思，我说过我也是程序员，也喜欢干这种事，一个开发了这么久的项目能一波操作提升10%以上的性能真的很牛逼。我只是告诉使用程序的普通人，你换了没用的，别折腾了，还可能有bug。
1.真是翻墙需求中，能跑到500mbps的线路要多少钱一个月？这种级别的线路会配一个志强双核的vps吗？
·········还真有，现在有钱人挺多，高于100mbps的线路在性能上就能体现出差别了。而使用100mbps以上的线路的人并不少。
·········就算是小带宽的服务器，对于很多路由器用户来说，性能提升巨大。v2ray/discussion#513 (comment)
2.软件处理数据包的延迟通常不会超过1ms即使超过了也远远不能和在网络中传输时数十毫秒甚至上百毫秒的延迟相比。所以换了协议几乎不会提升延迟
·······看视频当然没区别，打游戏你就能体会到区别了。虽然VLESS的游戏体验还是一般，因为走的是tcp，这个没办法
瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 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 来解决这个问题。
顺便一提，实际使用基本都是 TLS 二次加密，VLESS 即将推出一个具有划时代意义的试验版本 VLESS xTLS 来解决这个问题。
VLESS+TCP+TLS 和 VLESS+WS+nginx分流+TLS 都是 TLS 二次加密吗？
瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 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，这样做会有什么问题吗？
另外我问一句tls二次加密是什么意思？
多半是CDN的加密吧
瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 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反向代理，我感觉不出来任何区别。延迟这个事情总感觉这是个心理作用（我真的掐表数过，虽然人工计时不准）。
瓶颈在于带宽的确是常态，但从设计的角度来说，当然资源占用越少越好，因为现实场景是并不只有代理软件在运行，拿电脑来说，其它程序也会抢资源，甚至 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勉强能玩。
这么流批的功能，加到文档里啊。
指正文吗？因为 xTLS 最开始只是想法，这两天才着手验证了可行性，所以哪都没写。
TLS 二次加密指的是大多数传输的内容本身就是 TLS（网站、APP 等），此时再用基于 TLS 的代理工具，就出现了 TLS 嵌套。
我正在写一个魔改版 TLS：xTLS，它可以与 VLESS 完美配合，遇到 TLS data record 时稍作修改即可传输，接收方也可以识别。
因为占大头加解密所需要消耗的时间躺在那里，没法优化掉。
优化掉了。
明白了。这个东西我之前就有想过，但是觉得不太现实，或者可能带来安全隐患，就没提过，没想到真的可以实现，太惊喜了。
我以前就有想过，访问youtube，抓包，只能知道你在访问youtube，不能知道你的完整url，所以只要对youtube这个域名加密就好了。
xTLS，它可以与 VLESS 完美配合，遇到 TLS data record 时稍作修改即可传输，接收方也可以识别。
这起看来特征拉满啊
这起看来特征拉满啊
从外面看都是完整的 TLS data record，和普通 TLS 连接没有任何区别。
@kirin10000 终于抓到一个用翻墙工具加速游戏的，我问下为什么不用专门的网游加速器呢，我觉得网游加速器效果应该更好啊。我一直有这个问题，但是没有碰到这么干的人。
@kirin10000 终于抓到一个用翻墙工具加速游戏的，我问下为什么不用专门的网游加速器呢，我觉得网游加速器效果应该更好啊。我一直有这个问题，但是没有碰到这么干的人。
1.我喜欢折腾。
2.要翻墙看youtube，同时也要打游戏，你用个游戏加速器去看youtube啊？？
3.udpspeeder+udp2raw就是为自建服务器打游戏而生的，你自己去查一下，那个地方有很多用服务器打游戏的人
用服务器打游戏的人：https://github.com/wangyu-/UDPspeeder/blob/branch_libev/doc/README.zh-cn.md
@kirin10000 终于抓到一个用翻墙工具加速游戏的，我问下为什么不用专门的网游加速器呢，我觉得网游加速器效果应该更好啊。我一直有这个问题，但是没有碰到这么干的人。
有钱人都是这么干的
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口）