Sing-box连接资源泄漏问题分析与解决方案

问题现象

近期在Sing-box项目中，多个用户报告了TCP连接资源无法正常回收的问题。主要表现为：

1. 用户通过浏览器访问网站后，即使关闭浏览器或断开网络连接，Sing-box仍会保持大量ESTABLISHED状态的连接
2. 问题在直接连接和网络连接中均有出现，特别是涉及WebSocket的混合连接场景更为明显
3. 连接数持续增长最终导致"too many open files"错误，影响新连接的建立
4. 内存占用随连接数增加而持续上升，部分情况下会导致进程被系统终止

技术背景分析

Sing-box作为一款网络工具，其连接管理机制直接影响系统资源的利用率。在Linux系统中，每个TCP连接都会占用文件描述符资源，系统默认限制通常为1024个。当连接数超过限制时，就会触发"too many open files"错误。

连接回收机制通常依赖于：

• 操作系统层面的TCP keepalive机制
• 应用层的心跳检测
• 空闲超时设置

在Sing-box的实现中，连接回收主要受两个关键参数控制：

• 默认空闲超时时间为10分钟
• 心跳间隔为75秒，最多重试9次

理论上，一个无效连接最长会在21.25分钟(10min + 75s×9)后被回收。但实际观察发现，部分连接会远远超过这个时间仍未被释放。

问题根源探究

通过对用户报告的分析，我们发现几个关键点：

1. WebSocket连接影响：使用HTTP+WebSocket混合协议的网站更容易出现连接不回收的情况。这可能是因为WebSocket的长连接特性与工具的连接管理机制存在兼容性问题。

2. 版本差异：用户反馈1.9.4版本比1.10-beta5版本表现稍好，关闭浏览器后能够回收连接，但仍有改进空间。

3. 分流场景：无论是直接连接还是网络连接都会出现此问题，说明问题可能存在于核心的连接管理逻辑，而非特定协议实现。

4. 系统资源限制：在资源受限的路由器环境中，这个问题尤为明显，因为这类设备通常文件描述符限制较低。

解决方案

临时解决方案

1. 降级到1.9.4版本：部分用户反馈1.9.4版本表现更好，可以作为临时解决方案。

2. 定期重启服务：通过cron设置定时任务，每天重启sing-box服务强制释放资源。

3. 调整系统限制：临时增加系统的文件描述符限制：

   ulimit -n 65535
   

长期解决方案

1. 修改http.Transport参数：通过调整Go语言标准库中的http.Transport参数，可以优化连接管理：

   • 设置更合理的MaxIdleConnsPerHost
   • 调整IdleConnTimeout
   • 启用连接状态检测

2. 核心代码优化：建议在sing-box项目中：

   • 加强对WebSocket连接的特殊处理
   • 实现更积极的连接健康检测机制
   • 提供连接回收相关的可配置参数

3. 连接池管理：实现智能的连接池机制，根据系统负载动态调整连接保持策略。

最佳实践建议

对于普通用户，建议采取以下措施：

1. 监控连接数变化，设置报警阈值
2. 在路由器等资源受限环境中，考虑使用更保守的连接保持策略
3. 对于长期运行的下载等应用，定期检查连接状态
4. 考虑使用h2mux等替代方案作为临时解决方案

对于开发者，建议：

1. 在应用层实现更精细化的连接生命周期管理
2. 增加连接状态监控和诊断接口
3. 提供连接回收相关的详细日志
4. 针对不同协议特点实现差异化的回收策略

总结