本文使用的一键脚本,引用自 GitHub mack-a 大佬,谢谢大佬的分享: GitHub 地址
温馨提示: 由于不可抗拒的原因,XTLS 从V2Ray 单独剥离而出 随之的,后续,此脚本大概率会有更新,见 mack-a 大佬的说明:点我
什么是 Vless XTLS?(引用自 v2fly)
VLESS 是一个无状态的轻量传输协议,它分为入站和出站两部分, 可以作为 V2Ray 客户端和服务器之间的桥梁。 由于 VLESS 没有自带加密的特性,需要可靠加密信道,如 TLS / XTLS。 关于 VLESS XTLS 具体详解
–当我们使用基于 TLS 的代理(梯子或者机场的节点),去浏览 HTTPS 网站或者使用手机 APP 时,其实是通过“两层的TLS对数据加解密”:外层是通过代理的 TLS,内层是通过网站 或者 APP 的 TLS
–那 XTLS “无缝拼接了”内外上述两条货真价实的 TLS,此时代理本身几乎无需再对数据加解密(图2)
–新的综合结论:仅对 v2ray-core 而言,理论上 direct 模式的性能相当于直接 TCP 的数据,相对于 TLS 的性能,XTLS 在有 AES 硬解的设备上的性能提升为 200% 上下,在无 AES 硬解的设备上为 300% 上下。但是,性能的提升是更能省资源、稍降延迟,但不一定能转化为网速提升,这取决于速度瓶颈在哪。
图1
图2
PS: 以上示意图,只是为了方便大家理解,并不代表实际的情况。
前期准备工作:
1. 一个VPS 2. 一个域名(可以去freenom免费注册) 3. Cloudflare 解析域名 4. VPS 自行关闭防火墙,也就是防火墙放行 80,443 端口 每周日的凌晨3点,Nginx 会自动重启以配合证书的签发定时任务进行; 在此期间,节点无法正常连接,预计持续时间为若干秒至两分钟
指令 (支持 Debian 9+ / Centos7/Ubuntu)
Root 用户: sudo -i
此脚本可能需要安装:
Centos : yum install -y wget curl
Debian : apt install wget curl -y
Ubuntu: apt-get install wget -y
# 一键安装脚本:
wget -P /root -N --no-check-certificate "https://raw.githubusercontent.com/mack-a/v2ray-agent/master/install.sh" && chmod 700 /root/install.sh && /root/install.sh
# 安装前必看
2021-6-26 更新:
1. 请务必使用新域名和新建一个VPS操作系统、防火墙开放443和80 端口,否则有可能会出现 “提示 TLS 安装失败 请检查 ACME 日志”
2. 如果还出现“TLS 安装失败”问题:请点击这里 1 | 请点击这里 2
3. 使用纯净系统安装,如使用其他脚本安装过,请重新build系统再安装
2020-12-8 更新:
最近GCP封禁异常流量,不建议谷歌云用户搭建翻墙程序。
如果你是非得要用谷歌云去搭建节点,确保搭建好的节点能用后。
请一定要、一定要、一定要隔天再使用节点,不然,很有可能因为短时间内流量太大,谷歌云账号被封禁。
2..根据自身的情况,成功安装相应的协议后,可以开启使用 BBR plus+FQ 进行加速(开启后,可能对科学上网的速度有比较大的提升),方法如下
A. 进入ROOT 用户,再次输入并运行一键安装脚本, 弹出对话框后,输入 “11” (安装BBR );弹出新的对话框后,输入“1” (安装【推荐原版BBR+FQ】)
B. 此时会弹出新的对话框,核对你现在VPS的内核版本为“BBR加速内核”(如果非谷歌云VPS,内核版本有所不同),如下图。核对完成后,输入“11”(使用BBR+FQ加速)即可。
C. 此时会弹出 “BBR+FQ修改成功,重启生效!”;在新的对话框里,输入“reboot”,就会重启VPS并启用刚刚BBR加速选项;待VPS重启后,BBR加速就完成了。
3. 使用非谷歌云VPS,开启BBR 加速
脚本内各个协议组合方式
- VLESS+TCP+TLS
- VLESS+TCP+xtls (xtls-rprx-origin 和 xtls-rprx-direct)
- VLESS+WS+TLS
- VMess+TCP+TLS
- VMess+WS+TLS
- Trojan[Mux 多路复用]
- Trojan-Go+WS[Mux 多路复用]
PS:
Origin (xtls-rprx-origin) 会持续监测数据流,确保输出符合 TLSv1.3(实践中发现只需替换掉 TLSv1.2 尾部的 alert),并处理可能的中间人攻击等异常情况。
Direct (xtls-rprx-direct) 模式现在则是 Origin 经验的简化版,Write 只去掉了 TLSv1.2 尾部的 alert,Read 则一律直接交给内层 TLS 处理。
建议 Direct 模式:
1.理论上 direct 模式的性能相当于直接 TCP 的数据,即两倍+(有 AES 硬解);
2.有些路由器上性能可以提升到原先的三倍(无 AES 硬解);
3.根据这两个新的发现,新的综合结论是仅对 v2ray-core 而言,相对于 TLS 的性能,XTLS 在有 AES 硬解的设备上为 200% 上下,在无 AES 硬解的设备上为 300% 上下。
4.由于每个人的硬件环境不同,需要自行测试。另外需要注意,性能提升一定更省资源、稍降延迟,但不一定能转化为网速提升,这取决于速度瓶颈在那。
5.其实 XTLS 相对于 TLS 的提升并不容易被准确测试,因为会被设备上其它非 core 开销所影响,
组合推荐
- 中转/gia —> VLESS+TCP+TLS/XTL or Trojan
- 移动宽带 —> VMESS+WS+TLS/Trojan-Go+WS + Cloudflare
- Trojan建议开启Mux[多路复用],仅需客户端开启,服务端自适应。
- VMess/VLESS也可开启Mux,效果需要自己尝试,XTLS不支持Mux。仅需客户端开启,服务端自适应。
脚本特性
- VLESS/VMess/Trojan-Go三种工具合并为一个脚本,可以体验不同的工具之间的不同特性、兼容更多的设备。
- 支持Debian、Ubuntu、Centos
- 支持个性化安装,VLESS+TCP为必选,其余为可选项。
- 脚本自动检查升级
- 自动更新TLS证书
- 支持快捷方式启动,安装完毕后,shell输入[vasma]即可打开脚本,脚本执行路径[/etc/v2ray-agent/install.sh]
客户端
- VLESS 协议本身还会有不兼容升级,但客户端配置文件参数基本上是只增不减的。所以如果你开发了用 core 的客户端,现在就可以适配。 iOS 客户端的协议实现则需紧跟升级。
- 视觉标准:UI 标识请统一用 VLESS,而不是 VLess / Vless / vless,配置文件不受影响,代码内则顺其自然。
encryption
应做成输入框而不是选择框,新配置的默认值应为none
,若用户置空则应代填none
。flow
也应做成输入框,新配置的默认值应为空。
以下为已支持图形化配置 VLESS 的部分客户端列表,推荐使用:(按实现时间先后顺序排列)
- Qv2ray (opens new window)(v2.7.0-pre1 预览版)
- v2rayN (opens new window)(v3.27+),支持 Windows
- v2rayNG (opens new window)(v1.3.0+),支持 Android
- PassWall (opens new window)(v3.9.35+),支持 OpenWrt
- v2rayA (opens new window)(v1.0.0+),支持 Linux
Qv2ray 客户端
一定下载链接的对应的客户端,不然无法正常使用Qv2ray 客户端
一定下载链接的对应的客户端,不然无法正常使用Qv2ray 客户端
一定下载链接的对应的客户端,不然无法正常使用Qv2ray 客户端
#如需使用以下协议,请更新相应的插件及插件核心,不更新可能会导致崩溃问题
- Trojan插件: https://github.com/Qv2ray/QvPlugin-Trojan/releases/tag/v3.0.0-pre3
- SSR 插件: https://github.com/Qv2ray/QvPlugin-SSR/releases/tag/v3.0.0-pre3
- NaiveProxy插件: https://github.com/Qv2ray/QvPlugin-NaiveProxy/releases/tag/v3.0.0-pre3
- Trojan-Go插件: https://github.com/Qv2ray/QvPlugin-Trojan-Go/releases/tag/v3.0.0-pre3
- SS插件: https://github.com/Qv2ray/QvPlugin-SS/releases/tag/v3.0.0-pre3
- Command: https://github.com/Qv2ray/QvPlugin-Command/releases/tag/v3.0.0-pre3
# TROJANGO 插件核心下载:
# NaiveProxy 插件核心下载(插件路径设置方法,参照Trojan-go插件):
Windows(64位)
MacOS
安卓手机客户端:
V2rayNG ( 支持 Vless,Vmess协议 )
iOS手机客户端:
最新版Shadowrocket (支持Vless) 1.确认小火箭版本和下图一致( 2.1.64 ) 2.按照下面界面配置 注意事项
为了防止上层应用使用 QUIC,启用 XTLS 时客户端 VLESS 会自动拦截 UDP/443 的请求。若不需拦截,请在客户端填写
xtls-rprx-origin-udp443
,服务端不变。可设置环境变量
V2RAY_VLESS_XTLS_SHOW = true
以显示 XTLS 的输出,适用于服务端与客户端(仅用于确信 XTLS 生效了,千万别设成永久性的,不然会很卡)。不能开启 Mux。XTLS 需要获得原始的数据流,所以原理上也不会支持
WebSocket、不适用于 VMess。此外,UDP over TCP 时,VLESS 不会开启 XTLS 的特殊功能。
性能测试
2020.10.21 最新补充:
发现下面用多台服务器进行模拟测试时,有可能较多的数据未触发 XTLS 的特殊功能(实际使用无此问题),故模拟测试的相关结论暂无参考意义。
不过理论上 direct 模式的性能相当于直接 TCP 的数据,即两倍+(有 AES 硬解);发现有些路由器上性能可以提升到原先的三倍(无 AES 硬解);
根据这两个新的发现,新的综合结论是仅对 v2ray-core 而言,相对于 TLS 的性能,XTLS 在有 AES 硬解的设备上为 200% 上下,在无 AES 硬解的设备上为 300% 上下。
由于每个人的硬件环境不同,需要自行测试。另外需要注意,性能提升一定更省资源、稍降延迟,但不一定能转化为网速提升,这取决于速度瓶颈在哪。
其实 XTLS 相对于 TLS 的提升并不容易被准确测试,因为会被设备上其它非 core 开销所影响,进程 CPU limit 或许是个比较合适的方式(core 内再细分就无太大意义了)。
- XTLS 作为一个特殊的实用性技术,实际测试及模拟测试应当符合它的实用场景,即代理大流量 TLS 数据(16k data record),且最好是独立机器以便观察。若测试方式有误,甚至有可能不如普通 TLS,比如使用 XTLS 且开启它的特殊功能(flow)后只跑非 TLS 数据,会不断产生尝试识别 TLS data record 的开销(v4.31.0+ 已解决此问题)。
- 目前有两类测试结果:一类是实测在硬路由(无 AES 硬解)上换用 XTLS,一位用户同样跑满 CPU 时网速 翻倍,另一位用户相同网速时 CPU 使用率减半(AC86U),还有一位用户的树莓派 4B 服务端上也有明显提升,这些反馈均来自 v2fly TG 群。另一类是用多台服务器(有 AES 硬解)和 CPU limit 进行模拟测试,详细的数据、结论等可以看 这里 (opens new window)。暂时可以有这样的综合结论:仅对 v2ray-core 而言,XTLS 目前在无 AES 硬解的设备上可以提升 100% 左右,在有 AES 硬解的设备上可以提升 50% 左右。一般来说,设备性能越弱、TLS 流量越大,XTLS 带来的提升就会越明显。而对于移动设备,计算量减少实测更 省电。
- 根据上面的测试,XTLS 现在的
xtls-rprx-origin
算法仍有很大提升空间,也会继续优化(主要是接收方行为)。XTLS 以后还会推出其它的算法,进一步减少计算量。
v4.31.0+,XTLS 新增 Direct 模式xtls-rprx-direct
、xtls-rprx-direct-udp443
,理论上拥有接近 XTLS 极限的性能,它与 Origin 的不同之处详见 这里 (opens new window)。