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

RPRX commented 4 years ago

官网文档：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 就可以获得性能提升：

替换服务端和客户端的可执行文件。
将两边的协议都改为 "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 实现的障碍之一，参考 https://github.com/v2ray/v2ray-core/issues/1429#issuecomment-549667805
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 commented 4 years ago

补充一下接收方的逻辑：

若解密后仍是 TLS data record 结构，则等内层这个 record 全部传输完后，后面收到的 TLS data record 就不解密而直接转发

切换状态后若收到 TLS alert record，则先尝试解密，成功则自己处理，失败则转发，同时 EOF（若收到其它类型的 record 则照旧）

需要注意的是，客户端和服务端都同时是“发送方”和“接收方”

klzgrad commented 4 years ago

首先这个与多路复用不能共存。多路复用上重放一个record，整个连接理应全部关闭，但xtls里无从得知是否应该关闭。

什么是发送方什么是接收方，没有说清楚。但非完全的TLS栈想仿真TLS的错误处理，就会有鹦鹉问题。

最后即使没有鹦鹉问题，也可以通过插入alert发现rtt上的差异。

RPRX commented 4 years ago

首先这个与多路复用不能共存。多路复用上重放一个record，整个连接理应全部关闭，但xtls里无从得知是否应该关闭。

什么是发送方什么是接收方，没有说清楚。但非完全的TLS栈想仿真TLS的错误处理，就会有鹦鹉问题。

最后即使没有鹦鹉问题，也可以通过插入alert发现rtt上的差异。

中间人攻击（不管是 data 还是 alert）会攻击到内层 TLS，它发的 alert 会穿透上来，XTLS 发现了会转发后 close
发送方（write）和接收方（read）同时存在于客户端和服务端
目前的这个逻辑，对错误的反应与正常的 TLS 应当相同

RPRX commented 4 years ago

比较通俗的解读：

就是把两个 TLS 无缝衔接，外面也看不出区别，且两个都是完全真实的 TLS，所以至少这里不存在可探测的鹦鹉问题。

补充：要求外层 TLS 为 1.3，内层 data record 可以为 1.2，但长度不能超过 1.3 的上限。

RPRX commented 4 years ago

VLESS 对 XTLS 的控制：

若 flow 填了某个值，则客户端 VLESS 发起请求前会打开 XTLS 的特殊功能（发送和接收的特殊功能都打开）。

VLESS 向服务端发起请求时将附带特殊指令，服务端验证 UUID、确认用户可以用这个特殊指令后，也会打开 XTLS 的特殊功能。

这样完全不影响其它 TLS 请求，也能防止服务端被主动探测。

klzgrad commented 4 years ago

你没有看懂我提出的问题

RPRX commented 4 years ago

你没有看懂我提出的问题

“多路复用”指的是 h2 还是 mux

补充：“多路复用”可以指代很多东西，下次麻烦先说清楚

RPRX commented 4 years ago

我猜你指的是“将多条 XTLS 聚合成一个连接”，目前 XTLS 是直接基于 Golang 的 TLS 库改来的，在最底层。不过如果做这个聚合，那么某一条 XTLS 发现上层应用发送了一个 alert 就转发并关闭整个聚合连接也可以做到，但正常关闭的 alert 也会影响整个聚合连接。

至于 v2 的 Mux，的确不能开启，因为它是 Mux over VLESS over XTLS，到 XTLS 已经不是一条相对纯粹的 TLS 数据流了。

目前 TCP 的 mux 是没有必要的，因为 h2 已经普及，浏览器自己就可以利用好一条连接。UDP 的参考 https://github.com/v2fly/v2ray-core/issues/112#issuecomment-688271288 。

RPRX commented 4 years ago

（似乎“将多条 XTLS 聚合成一个连接”本身就难以实现，XTLS 暂时也不考虑任何 mux 方案）

ghost commented 4 years ago

（似乎“将多条 XTLS 聚合成一个连接”本身就难以实现，XTLS 暂时也不考虑任何 mux 方案）

目前 XTLS 打算做多个链接聚合吗？不想要可以关闭吗？

RPRX commented 4 years ago

（似乎“将多条 XTLS 聚合成一个连接”本身就难以实现，XTLS 暂时也不考虑任何 mux 方案）

目前 XTLS 打算做多个链接聚合吗？不想要可以关闭吗？

目前不打算做。

XTLS 核心算法已开源：https://github.com/rprx/XTLS

VLESS XTLS 即将发布。

RPRX commented 4 years ago

VLESS XTLS 已发布：https://github.com/rprx/v2ray-vless/releases

稍后补充更多说明。

1265578519 commented 4 years ago

这个XTLS对比MUX有什么优势吗？

ghost commented 4 years ago

fallbacks似乎有点问题，我用的(VLESS+TCP+TLS) + (VMess + ws +TLS) + Web的配置，也就是推荐配置，使用V2Ray进行分流。之前一直用(VLESS+TCP+TLS)，今天用(VMess + ws +TLS)的时候，在客户端log中发现了这个

v2ray.com/core/transport/internet/websocket: failed to dial to (wss://我的域名/我的path): 404 Not Found > websocket: bad handshake v2ray.com/core/transport/internet/websocket: failed to dial WebSocket >

而且不止出现了一次，虽然依然能正常上网，但是返回404说明有一部分内容被falllbacks到web服务器去了。因为之前一直用(VLESS+TCP+TLS)，所以我并不清楚之前有没有这样的问题。我使用的是V2Ray-4.28.0版本，套上了cloudflare的cdn，连接cdn时使用的是ipv6。附上我的服务端完整配置：

{
    "inbounds": [
        {
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "",
                        "level": 2
                    }
                ],
                "fallbacks": [
                    {
                        "path": "/我的path",
                        "dest": 1246,
                        "xver": 0
                    },
                    {
                        "dest": "/etc/nginx/unixsocks_temp/default.sock",
                        "xver": 0
                    },
                    {
                        "alpn": "h2",
                        "dest": "/etc/nginx/unixsocks_temp/h2.sock",
                        "xver": 0
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "tls",
                "tlsSettings": {
                    "alpn": [
                        "h2",
                        "http/1.1"
                    ],
                    "certificates": [
                        {
                            "certificateFile": "/etc/nginx/certs/cer",
                            "keyFile": "/etc/nginx/certs/key"
                        }
                    ]
                },
                "sockopt": {
                    "tcpFastOpen": true
                }
            }
        },
        {
            "port": 1246,
            "listen": "127.0.0.1",
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": "",
                        "level": 1,
                        "alterId": 0
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "wsSettings": {
                    "path": "/我的path"
                },
                "sockopt": {
                    "tcpFastOpen": true
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "settings": {},
            "streamSettings": {
                "sockopt": {
                    "tcpFastOpen": true
                }
            }
        }
    ]
}

我观察了下log，上面说的那个问题出现挺频繁的，并非偶然，大概隔两分钟就会出现一次。我不知道用ipv4连接cdn有没有这个问题，因为我这边网络只支持ipv6。我观察了nginx的log，确实出现了访问 "/我的path" 的请求，而且出现了很多次

更新：原因已找到，不是V2Ray的问题。我观察到nginx log中访问 "/我的path" 的请求都是http/2.0请求。也就是说，cloudflare回源的时候将部分http/1.1请求升级到http/2.0请求。我特意改了一个错误的path进行实验(这里记为path2)，结果验证了我的想法。在nginx的log中可以看到大部分 "/path2 http/1.1" 请求以及小部分 "/path2 http/2.0" 请求

最后更新：可以确定百分百为cloudflare的问题，百度云cdn，相同的配置，没有问题

RPRX commented 4 years ago

这个XTLS对比MUX有什么优势吗？

https://github.com/rprx/v2ray-vless/releases/tag/xtls

ghost commented 4 years ago

更换fallbacks的path后，重启v2ray服务端，需要大约10秒才生效，期间即使是对应的正确的path，正确的http版本，也会被fallbacks到默认的后端服务器，而不是正确的后端服务器，原因不明。配置文件同我上一条评论(已折叠)，V2Ray版本已经更换为4.28.1 。在这样的配置中，更换新的path，重启v2ray服务端和客户端，10秒内无法进行ws连接，V2Ray客户端不断显示404错误，nginx日志中显示大量

"GET /我的新path HTTP/1.1" 404 62 "-" "Go-http-client/1.1"

请求。 10秒后，fallbacks恢复正常，不会再返回404错误

xyli09 commented 4 years ago

国密推行以后，tls岂不是也完蛋了

tsanie commented 4 years ago

@rprx 新型协议回落模式能否新增sni匹配的这样能把nginx丢掉

之前也有人提过这个功能，可以做到，但似乎。。。有点越界，还是先用 Nginx 分流 SNI 比较好？

这里还是希望能加入这个功能，可以多一种选择。

还有个原因是我发现用 nginx stream 分流到 vless + tcp + tls 上后访问日志的远程 ip 都变成 127.0.0.1 了，纯 tcp 流量似乎只能通过开启 proxy_protocol 来解决，但是这样一来通过 cdn 过来的 ws 流量又不通了。

好像还有个 proxy_bind 方案，但是看了下说明放弃了。

vless 作为流量入口的话这些问题就都不存在了，虽然好像问题也不是太大……

RPRX commented 4 years ago

但是这样一来通过 cdn 过来的 ws 流量又不通了。

应该不会有这个问题。

RPRX commented 4 years ago

（SNI 分流功能可能会加入）

ruisiji commented 4 years ago

（SNI 分流功能可能会加入）

@rprx VLESS 做的事情是不是有点多？VLESS 能否只处理其所使用的 HOST:PORT/PATH，不满足于这三者的流量直接原封不动的传给 Ngninx/Haproxy 等已经稳定且使用广泛的程序？

另外，当开启 XTLS 时能否将 Nginx/CDN 放在 VLESS 之前并且还依然保持高效？

RPRX commented 4 years ago

@ruisiji

现在就是原封不动地传递。VLESS 的事情取决于需求，回落也只是一次性判断，后面就不会管了，纯搬运。

XTLS 必须最前置，不支持 CDN。

RPRX commented 4 years ago

@ruisiji

可能对现在的模式存在些误解。。。建议研究下文档

mclovin-2k commented 4 years ago

XTLS已经有了，就等XUDP了。

rhjdvsgsgks commented 4 years ago

XTLS已经有了，就等XUDP了。

估计难，udp本来就不是加密的

RPRX commented 4 years ago

XUDP 也是 over TCP 的，特点是聚合隧道和实现对 UDP 的精细控制，包括 FullCone。

ruisiji commented 4 years ago

可能对现在的模式存在些误解。。。建议研究下文档

也许是我被自己的 use case 给束缚住了，始终无法理解 VLESS + XTLS + HTTPS Web Server 怎样组合使用。

~~你能否提供 VLESS + XTLS + HTTPS Server1 + HTTPS Server2 这样的示例呢？~~

你能否提供 VLESS + XTLS + Nginx(HTTPS Server1 + HTTPS Server2) 这样的示例呢？

RPRX commented 4 years ago

@ruisiji

（已在另一个 issue 中回复）

ruisiji commented 4 years ago

Sorry, 我修改了一下问题，能否再查看一下？

imess commented 4 years ago

Sorry, 我修改了一下问题，能否再查看一下？

TLS是端对端加密，直接对话的双方是终结点，nginx前置，xtls在后不就失去意义了，虽然不清楚nginx的4层转发是否可行

RPRX commented 4 years ago

@ruisiji

可以 Google 一下 Nginx SNI 分流的用法。

RPRX commented 4 years ago

TLS是端对端加密，直接对话的双方是终结点，nginx前置，xtls在后不就失去意义了，虽然不清楚nginx的4层转发是否可行

Nginx 的 SNI 分流不会影响

zhaoyadong00 commented 4 years ago

XUDP 也是 over TCP 的，特点是聚合隧道和实现对 UDP 的精细控制，包括 FullCone。

不能理解实现思路或者细节，可以详细讲解一下吗。

ruisiji commented 4 years ago

现在就是原封不动地传递。

这里的原封不动应该不是我所理解的『原封不动』，否则 VLESS 发现当前流量不是自己的流量，就直接以TCP流量方式传给后面就行了，如果后面是 Nginx 的话，那么 Nginx 接收到的就是纯TCP流量，它自己处理起来就和普通的用法一样。

而当前情况下，貌似把 VLESS + XTLS 放在前面的话，后面是没法挂多个 HTTPS web server 的。

我再确认一下： XTLS 是不是压根没法放在 CDN 后面，就算损失性能（多一次TLS解密）也不行？

RPRX commented 4 years ago

XUDP 也是 over TCP 的，特点是聚合隧道和实现对 UDP 的精细控制，包括 FullCone。

不能理解实现思路或者细节，可以详细讲解一下吗。

https://github.com/v2fly/v2ray-core/issues/112#issuecomment-688271288

rhjdvsgsgks commented 4 years ago

~~同不理解，希望能说下具体是什么原理依我看来如果不把 udp 直接嵌到某些流中的话就不算 x 了，但直接嵌进去的话不就是直接暴露明文了吗~~

看起来好像就是个 udp over tcp ，并没有像 xtls 一样把原始数据嵌入到新的流中？🤔

RPRX commented 4 years ago

就是个加强版 UDP over TCP

RPRX commented 4 years ago

@ruisiji

请先看完文档

https://www.v2fly.org/config/protocols/vless.html

RPRX commented 4 years ago

@ruisiji

补充：对回落功能和 XTLS 的理解是错误的，文档里有正确答案。

ghost commented 4 years ago

也许是我被自己的 use case 给束缚住了，始终无法理解 VLESS + XTLS + HTTPS Web Server 怎样组合使用。

~你能否提供 VLESS + XTLS + HTTPS Server1 + HTTPS Server2 这样的示例呢？~

你能否提供 VLESS + XTLS + Nginx(HTTPS Server1 + HTTPS Server2) 这样的示例呢？

@ruisiji 你可以翻一下我的脚本里的V2Ray-XTLS+TCP+Web配置文件部分，可能对你有帮助

ruisiji commented 4 years ago

多谢！

我知道 Nginx + SNI 可以放 vless和Web server 前面，但是这样的话 Web server 会多增加一次本地流量转发。

例如：

User -- Nginx SNI（443） -- Nginx Web（8443）

User -- Nginx SNI（443） -- vless（9443）

此前vmess是：（这里的443就已经是Web server了）

User -- Nginx（443）

User -- Nginx（443） -- vmess

On Sun, Sep 27, 2020, 17:01 kirin10000 notifications@github.com wrote:

也许是我被自己的 use case 给束缚住了，始终无法理解 VLESS + XTLS + HTTPS Web Server 怎样组合使用。

你能否提供 VLESS + XTLS + HTTPS Server1 + HTTPS Server2 这样的示例呢？

你能否提供 VLESS + XTLS + Nginx(HTTPS Server1 + HTTPS Server2) 这样的示例呢？

@ruisiji https://github.com/ruisiji 你可以翻一下我的脚本里的V2Ray-XTLS+TCP+Web配置文件部分，可能对你有帮助

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/v2ray/v2ray-core/issues/2636#issuecomment-699607618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGJ5YJT46IXQW5PQWZAEQMTSH35OTANCNFSM4O4UQCXA .

RPRX commented 4 years ago

@ruisiji

即使是 VLESS 前置，对 Web 而言也是多一次本地流量转发。

ruisiji commented 4 years ago

@rprx 希望大拿能够攻克一下难关，允许将 VLESS + XTLS 放在 CDN 后面，这样使用场景就能大大的扩展了。

另外就是关于 UDP 的支持了，这个呼声非常高，不知道用 CDN 的话，还能不能很好的支持了。

看样子将 VLESS 当成 VMESS 用的话是可以放 CDN 后面的，但 XTLS 和 UDP 貌似就没实现了。

ghost commented 4 years ago

@rprx 希望大拿能够攻克一下难关，允许将 VLESS + XTLS 放在 CDN 后面，这样使用场景就能大大的扩展了。

另外就是关于 UDP 的支持了，这个呼声非常高，不知道用 CDN 的话，还能不能很好的支持了。

看样子将 VLESS 当成 VMESS 用的话是可以放 CDN 后面的，但 XTLS 和 UDP 貌似就没实现了。

XTLS不可能放CDN后面的，CDN是同服务器建立TLS连接，同时和客户端建立另外一个TLS连接，在CDN中与服务器的建立的TLS连接会解密，并重新进行TLS加密与客户端连接

RPRX commented 4 years ago

@ruisiji

XTLS 原理上无法支持 CDN（除非 TCP 转发）和 WS，且 CDN 与 XTLS 的需求场景也不相符，套 CDN 本身对性能就不会很敏感。

VLESS 的 UDP 是 over TCP 的，一开始就支持、有实现，包括 CDN。建议避免出现这样的认知偏差。

ghost commented 4 years ago

想了解一下XTLS和TLS在对UDP的处理上有区别吗？使用XTLS会不会增加UDP包传输延迟？

RPRX commented 4 years ago

想了解一下XTLS和TLS在对UDP的处理上有区别吗？使用XTLS会不会增加UDP包传输延迟？

1.有区别 2.应该不会

目前在灰度测试一个新的带长度的 UDP 格式（启用 XTLS 时），如果没什么问题，下个版本会变成 UDP 的默认传输格式

hexsen929 commented 3 years ago

也许是我被自己的 use case 给束缚住了，始终无法理解 VLESS + XTLS + HTTPS Web Server 怎样组合使用。 ~你能否提供 VLESS + XTLS + HTTPS Server1 + HTTPS Server2 这样的示例呢？~ 你能否提供 VLESS + XTLS + Nginx(HTTPS Server1 + HTTPS Server2) 这样的示例呢？

@ruisiji 你可以翻一下我的脚本里的V2Ray-XTLS+TCP+Web配置文件部分，可能对你有帮助

大佬请问如何配合宝塔面板呢。

xiaopanggege commented 3 years ago

@rprx 针对被qian方面的考虑，vmess是不是会更安全一些？

RPRX commented 3 years ago

@rprx 针对被qian方面的考虑，vmess是不是会更安全一些？

不会。

v2ray / v2ray-core