XTLS
5.16版本服务端似乎在性能上有问题
完整性要求
- [x] 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
- [x] 我提供了完整的配置文件和日志，而不是出于自己的判断只给出截取的部分。
- [x] 我搜索了 issues, 没有发现已提出的类似问题。
- [x] 问题在 Release 最新的版本上可以成功复现
描述
看到reality出了X25519MLKEM768新特性，所以把服务端客户端都更新试了一下，reality节点的sni也对应换到了支持X25519MLKEM768的域名speed.cloudflare.com 随后测速发现异常，相比4.30版本速度少了一半，且测速时CPU占用也是100% 发现异常后首先尝试把sni换回X25519的域名，无果 随后尝试回退服务端xray到4.30，客户端保持5.16，遂发现速度恢复正常 继续尝试5.16版本使用vless-reality以外的协议性能是否正常，如shadowsocks，遂发现速度正常 结论：服务端xray升到5.16后使用reality会出现性能异常
重现方式
服务端升到5.16版本
客户端配置
N/A
服务端配置
{
"listen": null,
"port": 23346,
"protocol": "vless",
"settings": {
"clients": [
{
"email": "1",
"flow": "",
"id": "1"
}
],
"decryption": "none",
"fallbacks": []
},
"streamSettings": {
"network": "tcp",
"realitySettings": {
"dest": "speed.cloudflare.com:443",
"maxClient": "",
"maxTimediff": 0,
"minClient": "",
"privateKey": "1Y",
"serverNames": [
"speed.cloudflare.com"
],
"shortIds": [
""
],
"show": false,
"xver": 0
},
"security": "reality",
"sockopt": {
"V6Only": false,
"acceptProxyProtocol": false,
"dialerProxy": "",
"domainStrategy": "UseIP",
"interface": "",
"mark": 0,
"penetrate": false,
"tcpFastOpen": true,
"tcpKeepAliveIdle": 300,
"tcpKeepAliveInterval": 0,
"tcpMaxSeg": 1440,
"tcpMptcp": true,
"tcpUserTimeout": 10000,
"tcpWindowClamp": 600,
"tcpcongestion": "bbr",
"tproxy": "off"
},
"tcpSettings": {
"acceptProxyProtocol": false,
"header": {
"type": "none"
}
}
},
"tag": "inbound-23346",
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic",
"fakedns"
],
"metadataOnly": false,
"routeOnly": true
},
"allocate": {
"strategy": "always",
"refresh": 5,
"concurrency": 3
}
},
客户端日志
N/A
服务端日志
2025/05/19 10:02:35 WARNING - XRAY: common/errors: This feature WebSocket transport (with ALPN http/1.1, etc.) is deprecated and being migrated to XHTTP H2 & H3. Please update your config(s) according to release note and documentation before removal.
2025/05/19 10:02:35 WARNING - XRAY: common/errors: This feature gRPC transport (with unnecessary costs, etc.) is deprecated and being migrated to XHTTP stream-up H2. Please update your config(s) according to release note and documentation before removal.
2025/05/19 10:02:35 WARNING - XRAY: common/errors: This feature gRPC transport (with unnecessary costs, etc.) is deprecated and being migrated to XHTTP stream-up H2. Please update your config(s) according to release note and documentation before removal.
2025/05/19 10:02:35 WARNING - XRAY: common/errors: This feature WebSocket transport (with ALPN http/1.1, etc.) is deprecated and being migrated to XHTTP H2 & H3. Please update your config(s) according to release note and documentation before removal.
2025/05/19 10:02:35 WARNING - XRAY: common/errors: This feature gRPC transport (with unnecessary costs, etc.) is deprecated and being migrated to XHTTP stream-up H2. Please update your config(s) according to release note and documentation before removal.
2025/05/19 10:02:34 INFO - XRAY: infra/conf/serial: Reading config: &{Name:bin/config.json Format:json}
2025/05/19 10:02:34 DEBUG - XRAY: A unified platform for anti-censorship.
2025/05/19 10:02:34 DEBUG - XRAY: Xray 25.5.16 (Xray, Penetrates Everything.) 800b8b5 (go1.24.3 linux/amd64)
2025/05/19 10:02:34 DEBUG - X-UI: restart xray, force:true
2025/05/19 10:02:33 DEBUG - X-UI: Attempting to stop Xray...
还有你用的是 Vision REALITY 还是 XHTTP REALITY？这两个试一下
我是一直没有使用xtls-rprx-vision流控的，看到你说Vision REALITY 我就想着打开一下看看，然后速度恢复了，关掉流控以后依然可以复现 顺便测试了一下XHTTP REALITY，查找了一下文档XHTTP REALITY似乎不支持xtls-rprx-vision流控，所以跟Vision REALITY不开流控是同样的情况，性能异常
测试环境，服务器J4125 arch Linux 客户端 arm64 Debian 配置全程未改变只换xray内核版本 前端xray的vless + xtls-rprx-vision + reality， 后端是服务器上caddy2的tls1.3/1.2的http2/3站点
同时，v25.4.30 版本使用vless + xtls-rprx-vision + reality 服务器 到 客户端 下载 420Mbps，上传 320Mbps 服务器 到 服务器 下载1003Mbps，上传 1003Mbps （服务器不存在瓶颈，瓶颈是千兆网口）
同时v25.5.16版本使用vless + xtls-rprx-vision + reality 服务器 到 客户端 下载 290Mbps，上传 300Mbps 服务器 到 服务器 下载 380Mbps，上传 390Mbps （性能比上个版本至少差2.5倍）
服务器 v25.5.16 客户端 v25.4.30 使用vless + xtls-rprx-vision + reality 服务器 到 客户端 下载 260Mbps，上传 300Mbps
pprof图 好像替换函数替换到某个效率不行的函数去了(没用到AES-NI?) 可疑commit https://github.com/XTLS/REALITY/commit/514f8647eac04939916eb68e894da95dff2e5402
cc: @yuhan6665
"streamSettings": {
"network": "raw",
"security": "tls",
"tlsSettings": {
"alpn": ["http/1.1"],
"cipherSuites": "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"curvePreferences":["x25519"],
"certificates": [
{
"ocspStapling": 3600,
"certificateFile": "/etc/ssl/ecc_cert.cer",
"keyFile": "/etc/ssl/ecc_key.cer"
}
],
"rejectUnknownSni": true,
"minVersion": "1.2"
},
测试环境，x25519 前端xray的vless + xtls-rprx-vision + tls， 后端是服务器上caddy2的tls1.3/1.2的http1站点
同时，v25.4.30 版本使用vless + xtls-rprx-vision + tls 服务器 到 客户端 下载 800Mbps，上传 360Mbps 服务器 到 服务器 下载1003Mbps，上传 1003Mbps
同时v25.5.16版本使用vless + xtls-rprx-vision + tls 服务器 到 客户端 下载 380Mbps，上传 300Mbps 服务器 到 服务器 下载 1006Mbps，上传 999Mbps
服务器 v25.5.16 客户端 v25.4.30 使用vless + xtls-rprx-vision + tls 服务器 到 客户端 下载 780Mbps，上传 360Mbps
测试环境，X25519MLKEM768 前端xray的vless + xtls-rprx-vision + tls， 后端是服务器上caddy2的tls1.3/1.2的http1站点
同时v25.5.16版本使用vless + xtls-rprx-vision + tls 服务器 到 客户端 下载 780Mbps，上传 300Mbps 服务器 到 服务器 下载 1000Mbps，上传 990Mbps
同时v25.5.16版本 vless + xtls-rprx-vision + reality/tls 回落 vless + xhttp + reality/tls vless + xtls-rprx-vision + reality 服务器 到 服务器 下载 1005，上传 996 服务器 到 客户端 下载 990，上传 960 vless + xhttp + reality 服务器 到 服务器 下载 390，上传 390 服务器 到 客户端 下载 372，上传 325 (不稳定） X25519MLKEM768 vless + xtls-rprx-vision + tls 服务器 到 服务器 下载 1000，上传 1001 服务器 到 客户端 下载 990，上传 990 vless + xhttp + tls 服务器 到 服务器 下载 390，上传 390 服务器 到 客户端 下载 340，上传 320 (不稳定） X25519 vless + xtls-rprx-vision + tls 服务器 到 服务器 下载 1000，上传 990 服务器 到 客户端 下载 993，上传 1001 vless + xhttp + tls 服务器 到 服务器 下载 390，上传 390 服务器 到 客户端 下载 350，上传 320 (不稳定）
同时v25.4.30版本 vless + xtls-rprx-vision + reality/tls 回落 vless + xhttp + reality/tls vless + xtls-rprx-vision + reality 服务器 到 服务器 下载 1003，上传 1003 服务器 到 客户端 下载 995，上传 995 vless + xhttp + reality 服务器 到 服务器 下载 1003，上传 1003 服务器 到 客户端 下载 365，上传 325 (不稳定） vless + xtls-rprx-vision + tls 服务器 到 服务器 下载 1003，上传 1003 服务器 到 客户端 下载 995，上传 995 vless + xhttp + tls 服务器 到 服务器 下载 390，上传 390 服务器 到 客户端 下载 355，上传 330 (不稳定）
前面速度低是反向代理的原因，反向代理瓶颈在bridges节点 现在用正常方式的服务测试一遍了，XHTTP异常的地方是X86服务器J4125区区390Mbps，arm64 a53客户端的XHTTP速度都有320Mbps，看着就不正常XHTTP在x86上效率太低了。
I think I know why.. when I need to copy gcm package from golang tls to reality. (The reason we need to copy is because this gcm config moved to internal https://github.com/golang/go/blob/master/src/crypto/tls/cipher_suites.go#L564) I only copied the software version (generic implementation). Which is probably slow. We likely need to copy architect specific implementation for aes (gcm also?) from here that should fix it
pprof图 好像替换函数替换到某个效率不行的函数去了(没用到AES-NI?) 可疑commit XTLS/REALITY@514f864
cc: @yuhan6665
你上传的图片是一个 Go 程序的 CPU 火焰图（Flame Graph），用于分析 xray 的 CPU 使用情况。从图中可以看出：
🔥 性能瓶颈总结： 主消耗路径： 主函数调用链是：
rust 复制 编辑 task -> xray/internal/proxy/freedom.(*Handler).Process -> proxy.read -> buf.Copy -> buf.CopyInternal -> buf.WriteMultiBuffer.WriteTo -> reality.(*Conn).Write -> reality.(*Conn).encrypt -> encryptBlockGeneric 主要 CPU 时间集中在两个地方：
encryptBlockGeneric: 3.59s (40.61%)
gcm.ghashMul: 2.72s (30.77%)
这两者几乎占据了总 CPU 使用的 70%+，表明加密操作是当前性能瓶颈。
🔐 加密相关热点函数： aes.encryptBlockGeneric 是最大的性能热点（40.61%），这是 Go 标准库在硬件不支持 AES-NI 的情况下使用的 纯软件 AES 加密实现。
gcm.ghashMul 是 GCM 模式下的 hash 操作，占用了约 31%。
🧠 可能的优化建议： 开启硬件加速：
检查你的系统是否启用了 AES-NI 指令集（可以通过 cat /proc/cpuinfo | grep aes 检查）。
如果未开启，可以考虑使用支持 AES-NI 的 CPU，或者在虚拟化环境中启用该特性。
使用更高效的加密库：
检查是否可以使用基于汇编优化的库（例如 golang.org/x/crypto 的一些替代实现，或直接使用 CGO 绑定调用更快的加密库）。
降低加密负担：
如果安全要求允许，考虑是否可以使用相对较轻的加密算法或简化加密层级。
使用 freedom 出站协议时是否一定需要 reality 加密？如果是内部网络可能可考虑关闭。
并发优化：
当前加密操作全部集中在单线程，如果你的流量较高，可以通过增加并发连接数来缓解瓶颈（前提是 I/O 不受限）。
📌 附注： 图中的 syscall.Syscall6 和 poll.Recv 占用比例不高（分别为 14% 和更低），说明系统调用和网络接收不是主要瓶颈，CPU 主要耗费在加密计算上。
根据上面的讨论，应该是 REALITY 仓库的更新没用上 AES-NI 硬件加速，等待 @yuhan6665 修复
目前这不是一个大问题，因为传播最广泛的 REALITY 都搭配了 Vision，直接 XTLS 裸奔，绕过了 AES 加解密，XHTTP 还是 CDN 最多
还有就是 v25.5.16 发一周了，看起来确实没啥 breaking，都没人开 issue，主要是适合偷的那些网站几乎还不支持 x25519mlkem768
而 REALITY session id 关联的 x25519 暂不存在问题，因为它不参与 TLS 加解密，留到以后破解这玩意儿没用，且前提是公钥泄露
@yuhan6665 真不愧是技术社区 平时闲扯皮没人说正事 更新版本处理速度变慢了马上给你怼上 pprof 感谢反馈👍
大佬，这个版本影响速度啊 reality vision 我这边之前AWS JP的油管速度30万，更新Xray-core v25.5.16后油管速度悲催啊有时候不到2万，有时候甚至1万都不到 5个小时前更新后还以为运营商降速了，刚好奇是不是更新内核，然后爬起来把服务端和客户端内核更换为25.4.30油管速度立即恢复到30万了 终于可以安心睡觉了
@yuhan6665 Memory usage has also been increased dramatically since the last release, making xray-core unsuitable for OpenWrt routers.
