Xray-core 服务端直接开启 HTTP/3 时的内存优化实践

背景概述

在 Xray-core 项目中，服务端直接配置 HTTP/3（H3）协议支持时，部分用户遇到了内存占用快速飙升的问题。这种情况通常发生在服务端直接暴露 Xray 的 H3 服务，而非通过前置反向代理（如 Nginx/Caddy）的场景下。

问题现象分析

典型的问题表现为：

1. 服务端内存消耗呈指数级增长
2. CPU 使用率随后达到 100%
3. 最终导致 Xray 服务不可用

通过案例排查发现，这往往与 splithttpSettings 中的两个关键参数配置不当有关：

• maxUploadSize（最大上传尺寸）
• maxConcurrentUploads（最大并发上传数）

核心问题定位

当这两个参数值被意外颠倒配置时（例如将本应设置并发数的值误设为上传尺寸），会导致：

1. 系统允许的并发连接数异常增大（如设置为 8）
2. 每个连接分配的内存缓冲区过小（如设置为 1000000）
3. 最终结果是系统无法有效管理连接资源

最佳实践建议

1. 参数规范配置

   • maxUploadSize 应设置为合理的字节数（通常 8-64MB）
   • maxConcurrentUploads 应根据服务器配置设置（建议 100-1000）

2. 架构优化方案

   • 推荐在生产环境使用反向代理前置架构
   • 反向代理可提供连接管理、BBR 拥塞控制等优势
   • Xray 作为后端服务只需处理有效流量

3. 性能监控

   • 部署内存监控告警系统
   • 定期检查连接数变化趋势
   • 建议使用 Prometheus + Grafana 监控方案

配置示例

"splithttpSettings": {
  "maxConcurrentUploads": 500,
  "maxUploadSize": 8388608, // 8MB
  "path": "/your-path"
}

技术原理延伸

HTTP/3 基于 QUIC 协议，相比 HTTP/2 具有：

• 改进的多路复用能力
• 更快的连接建立（0-RTT）
• 更好的丢包恢复机制

但这也意味着：

• 需要更精细的连接管理
• 内存分配策略需要优化
• UDP 协议栈需要特别调优

总结

直接使用 Xray-core 开启 HTTP/3 服务时，务必注意关键参数的合理配置。对于生产环境，建议采用反向代理+Xray后端的架构模式，既能获得 HTTP/3 的现代协议优势，又能保证服务的稳定性。当出现内存异常时，应优先检查并发连接相关参数的配置合理性。