5.16版本服务端似乎在性能上有问题

[milkman-wang]

完整性要求

• 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我提供了完整的配置文件和日志，而不是出于自己的判断只给出截取的部分。
• 我搜索了 issues, 没有发现已提出的类似问题。
• 问题在 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...

[RPRX]

根据你的描述可以排除先是 X25519MLKEM768 的问题，REALITY 服务端确实有升级仓库版本，但前后都是 AEAD 应该没区别吧

[RPRX]

还有你用的是 Vision REALITY 还是 XHTTP REALITY？这两个试一下

[milkman-wang]

还有你用的是 Vision REALITY 还是 XHTTP REALITY？这两个试一下

我是一直没有使用xtls-rprx-vision流控的，看到你说Vision REALITY 我就想着打开一下看看，然后速度恢复了，关掉流控以后依然可以复现
顺便测试了一下XHTTP REALITY，查找了一下文档XHTTP REALITY似乎不支持xtls-rprx-vision流控，所以跟Vision REALITY不开流控是同样的情况，性能异常

[Fangliding]

普通的TLS呢？

[IDSSC]

测试环境，服务器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

[Fangliding]

pprof图 好像替换函数替换到某个效率不行的函数去了(没用到AES-NI?) 可疑commit XTLS/REALITY@514f864

cc: @yuhan6665

[IDSSC]

        "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

[IDSSC]

同时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上效率太低了。

[yuhan6665]

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

[yuhan6665]

@yuhan6665 真不愧是技术社区 平时闲扯皮没人说正事 更新版本处理速度变慢了马上给你怼上 pprof 感谢反馈👍