[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.

[wenjinlibug]

@rprx 希望releases能增加“linux arm64”、“linux arm”。因为VLESS受益最大的应该是手机端（我绝不承认自己编译不出执行文件）。

[RPRX]

@wenjinlibug

VLESS 即将发布一个 PREVIEW 版本，先合并进 v2ray-core 公测。以及，v2ray-vless 新版本会编译 linux-arm64-v8a 和 macos-64。

[lxhao61]

尽快合并到主项吧，这样才有支持VLESS的OpenWrt路由器端、手机端、图形界面客户端应用。因为基本无人用v2ray原版的无图形界面的客户端。

[RPRX]

@lxhao61

更新：VLESS 服务端已确定要加一个协议回落模式，将出现在 PREVIEW 版本中，所以还需要些时间才能发布。

[lxhao61]

@lxhao61

更新：VLESS 服务端已确定要加一个协议回落模式，将出现在 PREVIEW 版本中，所以还需要些时间才能发布。

哦，这样呀。感谢！

[guodie418]

好着急啊，不知道大佬们什么时候能融入正式版，这样我的垃圾软路由就能减轻负担了

[xhqpp]

希望能解决UDP的痛点，那就真的是完美了

[RPRX]

@xhqpp

解决 UDP 问题不仅需要改协议，还需要 v2ray 各个出入站及中间传输环节的支持，所以要等到 VLess BETA 系列后期，但会解决。

[lxhao61]

@rprx v2ray下的socks+websocket+tls、shadowsocks+v2ray-plugin及shadowsocks+websocket+tls配置应用有UDP问题不？非Vmess协议。

[RPRX]

@lxhao61

应该有问题，且若不开 Mux，还会 UdpBlocked。

[lxhao61]

@rprx 哦，还以为非Vmess协议无UDP问题。明白了，谢谢！

[ghost]

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?

[ghost]

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.

[RPRX]

@pram991

v2ray 的 Mux 是在 VLESS 之前就接管了请求，把 VLESS 当成了它的底层传输方式，提供身份认证功能。

所以开启 Mux 后，Port 和 Address 已经不是 VLESS 的事情了，无需放入 ProtoBuf。

目前 Mux 是可以在一定程度上保持连接，但 v2ray 的一些组件有问题，仍然无法实现 FullCone。

Mux.Cool 本身也可能有一些坑，VLESS 协议以后可以单独选择第三方成熟的 Mux 方案。

[fbion]

mark nb

[zhaoyadong00]

赞 期待

[RPRX]

@okudayukiko

我觉得可行。

[okudayukiko]

VMess/VLess可考慮擴展加入ICMP通道，這是為手機/電腦的V2Ray VPN模式而設計（目前PC的V2Ray Core只提供SOCKS/HTTP代理）。而VPN方案有TAP-Windows，用route或netsh設定路由表。

[1265578519]

如果解决不了NAT的问题的话，，，感觉新协议没什么意义啊，看起来对比现有的貌似也没什么区别。 除了性能提升外？还有什么亮点吗，没看出来

[RPRX]

@1265578519

现在这个时间点，大概还有很方便的协议回落？以及可扩展极强的框架。

不要太早下结论，让子弹飞一会儿~

[1265578519]

@rprx 嗯，要正式的时候，一定要同时把NAT搞出来呀，这才是能突显出新协议的优势

[RPRX]

@1265578519

v2ray-core 的第一个 VLESS 预览版，我觉得亮点是简洁而强大、安全的协议回落，接下来就是解决 UDP 问题和继续提升性能了。

有了这样的协议回落后，可以使 TCP + TLS 成为常态，比 WSS 更好。协议回落今天也刚刚升级，预计很快发布，主要是：

允许根据 TLS ALPN 的协商结果来单独转发 h2；支持 PROXY protocol 1 & 2，这样后端就能拿到请求的真实来源 IP 和端口了。

[okudayukiko]

我覺得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加密的數據。

[lxhao61]

@rprx 大神出一个VLESS支持 PROXY protocol 1 & 2回落的具体配置模板（VLESS与Nginx配合），特别是Nginx安装与配置。否则大部分不知道怎么具体配置，当然包括我。

[okudayukiko]

@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協定訪問端口時會返回的網頁。

[RPRX]

@okudayukiko

VLESS 有基于首包长度分流（VLESS 原创）的新型协议回落模式，相对于其它协议回落方案，更简洁、高效、安全，功能也更强大。 https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md

@lxhao61

设置 proxy_protocol 和 set_real_ip_from 即可（当然，之后也会出例子 https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/

[twzchi]

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吗？

[RPRX]

@twzchi

网络问题，换成 VMess 试试，也一样的。

[okudayukiko]

帶加密協定。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壓縮等功能。

[hdid]

It seems that VLESS does not support Dynamic Port; is not it?

[RPRX]

@hdid

暂不支持，因为 TLS 并不需要它。出了套加密后，ProtoBuf 将承载动态端口指令。（这一点文中也有提到

[lxhao61]

@okudayukiko

VLESS 有基于首包长度分流（VLESS 原创）的新型协议回落模式，相对于其它协议回落方案，更简洁、高效、安全，功能也更强大。 https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md

@lxhao61

设置 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）?

[RPRX]

@lxhao61

Nginx 默认版就有 proxy_protocol 等，其实不需要自己编译

h2c 是支持的，Nginx 也不需要定制模块，起个 http2 服务，然后 VLESS 设置 fallback_h2 项即可（参考 VLESS 文档，很简单

[RPRX]

@lxhao61

等下，如果你指的是将 h2 作为底层传输方式再回落，这个我没试过

[lxhao61]

@lxhao61

Nginx 默认版就有 proxy_protocol 等，其实不需要自己编译

h2c 是支持的，Nginx 也不需要定制模块，起个 http2 服务，然后 VLESS 设置 fallback_h2 项即可（参考 VLESS 文档，很简单

我看介绍，Nginx 默认不带 proxy_protocol呀。晕。

[RPRX]

@lxhao61

我用 CentOS 8 的 dnf install nginx 是都带有的，可能其它发行版不带？

[RPRX]

@lxhao61

对了，proxy_protocol 并不是必选的，它专用于传递请求的真实来源 IP 和端口，填 0 也可以配置协议回落。

[lxhao61]

@rprx 我用Debian 9，版本过低。看using-proxy-protocol资料及其它资料介绍要自己定制编译。 大神，你弄个参考模板吧。参考：https://github.com/veekxt/v2ray-template 添加vless+tcp+tls+web（nginx）与vless+h2c+tls+web（nginx）两个。

[t66y100]

希望能解决UDP的痛点，那就真的是完美了

redsocks redsocks2和ipt2socks一直都可以FullCone。

[allury]

期待出个vless的具体配置模板，小白还是不太会自己配

[lxhao61]

是的。主要nginx配置。

[okudayukiko]

/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

[okudayukiko]

另外希望統一解決V2RayNG等Android/iOS Client在連接VPN後無法使用Miracast投影的問題。現在很多VPN App的「Bypass LAN IP」其實只跳過IPv4 LAN IP，沒有跳過IPv6 LAN IP。希望Bypass LAN IP和GeoIP統一更新IPv6位址。

[smallprogram]

mark

[RPRX]

@lxhao61 @allury

https://github.com/v2fly/v2ray-examples

之后我还会上传一套 maximal 的例子

[kallydev]

Update: 反馈的地方有误，和 VLess 关系不大，这应该是 transport 层该处理的问题。

---

GFW 可能会阻断带有 ESNI 扩展的 TLS 连接，如果 VLess 会提供 TLS 1.3 支持时需要考虑到这一点。

消息来源于 GFW Report，维基百科的 服务器名称指示 条目也在 ESNI 的部分补充了这条消息。

[okudayukiko]

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憑證並不便宜。

[darhwa]

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將來成為包括國內大廠在內的市場主流，也不是沒有解封的可能。

[kallydev]

至於GFW阻斷ESNI，部分原因也是因為目前最主流瀏覽器（firefox不算），服務器都未實現，所以直接一刀切封掉完全不存在連帶損害。倘若ECH將來成為包括國內大廠在內的市場主流，也不是沒有解封的可能。

我起初误解了扩展的定义，之前的话语稍有些危言耸听。如此看在，GFW 阻断 ESNI 至少在很长一段时间内无关痛痒，感谢 @okudayukiko @darhwa 两位赐教。

[lxhao61]

@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也实现“隐藏”。