连接迟迟不回收导致大量too many open files报错

[suikastar]

操作系统

Linux

系统版本

Linux version 5.4.150 (jenkins@65136d6f01cb) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 unknown)) #0 SMP Mon Jan 30 09:23:25 2023

安装类型

sing-box 原始命令行程序

如果您使用图形客户端程序，请提供该程序版本。

No response

版本

1.9.3

描述

用浏览器访问网站，早就关闭访问了，但十几个小时过去了，连接不回收，导致资源不够，无法访问新的网站

重现方式

路由器上使用 https://github.com/juewuy/ShellCrash ，用singbox内核，选tproxy模式进行透明代理

日志

No response

支持我们

• [ ] 我已经 赞助

完整性要求

• [X] 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• [X] 我保证提供了可以在本地重现该问题的服务器、客户端配置文件与流程，而不是一个脱敏的复杂客户端配置文件。
• [X] 我保证提供了可用于重现我报告的错误的最简配置，而不是依赖远程服务器、TUN、图形界面客户端或者其他闭源软件。
• [X] 我保证提供了完整的配置文件与日志，而不是出于对自身智力的自信而仅提供了部分认为有用的部分。

[suikastar]

协议是Trojan

[suikastar]

国内网站都不回收，应该跟协议没关系，都没走代理

[suikastar]

~~似乎问题出现在直连上？我在复现期间访问的GitHub和Google连接已经回收了，复现时霸榜的都是国内域名和国内ip。~~ 二次编辑：经过多次测试观察，也有能回收的国内请求，也有不能回收的国外请求。

[suikastar]

相关配置文件如下

相关配置.zip

[suikastar]

根据过往issues，我使用了tun模式后，对m.ithome.com和github.com进行访问，然后立刻断开设备与路由器的WiFi链接，确保不是chrome浏览器在搞什么后台同步长连接啥的问题。换台设备观察连接状态，问题依旧。

[suikastar]

弱弱的问一句，决定回不回收是受这两个值控制？如果QQ或微信之类的服务器就是能保持空闲连接十多分钟不断开，路由器里运行的内核再每75秒发送一次心跳，那这连接不是永生了？

@nekohasekai

[suikastar]

哦，心跳包是不是也会同时发给手机，可我手机WiFi都关了，应该通不了，讲道理应该可以回收了

[suikastar]

可能有价值的分析

[suikastar]

https://github.com/vernesong/OpenClash/issues/2614#issuecomment-1665241053

按此解释，结合singbox项目默认值，无效连接最多会在内核中占据内存持续 10min + 75s * 9 = 21.25min，然后被移除，复现步骤修正为： 1.手机通过WiFi连接装有singbox的路由器 2.手机打开各类app和国内外网站建立连接 3.手机关闭WiFi，断开与路由器连接 4.等待21.25分钟后，去面板查看连接是否已经移除

[suikastar]

vernesong/OpenClash#2614 (comment)

按此解释，结合singbox项目默认值，无效连接最多会在内核中占据内存持续 10min + 75s * 9 = 21.25min，然后被移除，复现步骤修正为： 1.手机通过WiFi连接装有singbox的路由器 2.手机打开各类app和国内外网站建立连接 3.手机关闭WiFi，断开与路由器连接 4.等待21.25分钟后，去面板查看连接是否已经移除

遵守此步骤的最新测试结果为： 1.临界时间到了后，观察面板，陆续回收了20-30多条连接； 2.但还有10多条连接，苦等，依然没有回收。

[zzhi-github]

My inbound is tproxy, I also encountered memory leak issue. Sing-box service was killed and restarted due to too large memory. Is it a systematic issue?

[LiHang941]

我也遇到的相同的问题，每天会重启一次singbox用来解决这个问题，每次清理前连接数在5000左右

[yanhao98]

我记得我之前用 vless reality （可能）协议遇到过不断开的问题。后来不知道怎么折腾了一番没有遇到过了。

[kingsey]

我用tproxy会这样（特定的几个网址），换用其他入站了

[llity]

docker版遇到一样的问题，连接一直激活，内存暴涨，然而次数没有流量。

[llity]

有什么解决办法吗

[tisyang]

我也遇到了，outbound 为 direct 分流局域网的 web 服务，浏览器关闭后，sing-box 继续持有大量局域网的 web 服务连接，久久不释放

[LiHang941]

有什么解决办法吗

h2mux就好了

[llity]

h2mux就好了

可以详细到来吗

[tisyang]

运行环境：

sing-box version 1.10.0-beta.5

Environment: go1.23.0 linux/amd64
Tags: with_gvisor,with_quic,with_dhcp,with_wireguard,with_ech,with_utls,with_reality_server,with_acme,with_clash_api
Revision: 1332f13ce91e8f15ec67954d242732cbd45e39f8
CGO: disabled

主要复现过程：

1. Firefox 设置全局代理为本地 SOCKS5 到 sing-box 的 mixed inbound.
2. sing-box mixed inbound 根据 geoip/geosite/ip_is_private 分流到 direct，其他到 proxy.
3. Firefox 访问局域网服务（该服务提供同端口的 http/websocket 服务，web前端 会有周期性的 http 请求），然后关闭页面，关闭 firefox.
4. ss -tnp 会发现大量保留的 ESTAB 的通往该局域网的连接，久久不释放.

另外，发现如果是国内页面不带 websocket 的，连接基本都可以回收，但是如果页面是 http(s) + websocket 的，则基本无法回收，怀疑大概率是混合代理 websocket 出的问题。

更新测试： 使用 1.9.4 版本测试，关闭页面不会回收连接，但是关闭 Firefox 会回收这些连接。

[llity]

一直没有回收，不知道什么原因

[llity]

我也遇到了，outbound 为 direct 分流局域网的 web 服务，浏览器关闭后，sing-box 继续持有大量局域网的 web 服务连接，久久不释放

我这里也是大量的direct没有回收

[tisyang]

我也遇到了，outbound 为 direct 分流局域网的 web 服务，浏览器关闭后，sing-box 继续持有大量局域网的 web 服务连接，久久不释放

我这里也是大量的direct没有回收

你试试 1.9.4 版本

[llity]

你试试 1.9.4 版本

已经是1.9.4了哦，你的正常？

[tisyang]

你试试 1.9.4 版本

已经是1.9.4了哦，你的正常？

不正常，但是比 1.10beta5 要好一点点，关掉浏览器就回收了

[llity]

不正常，但是比 1.10beta5 要好一点点，关掉浏览器就回收了

晕，怎么被关闭了，我这个是PT一直挂着的，没法关闭。

[llity]

@tisyang 1.10直接使用1.9.4的配置文件可以吗

[tisyang]

@tisyang 1.10直接使用1.9.4的配置文件可以吗

应该是可以行的。

我的换 1.9.4 后，问题消失，不影响正常应用了。

[tisyang]

通过修改 sagernet/sing 下的 http.Transport，参考 https://pkg.go.dev/net/http#hdr-Clients_and_Transports 的参数，基本可以解决 Direct 出口连接某些网站连接数过多的问题，有兴趣的可以自行编译测试一下。

自行编译需要将 https://github.com/SagerNet/sing-box/blob/dev-next/go.mod#L57 这行注释打开，然后在将 关修改过的sagernet/sing 和 sagernet/sing-box 放到同一目录，进 sing-box 后 make 即可。

目前测试之前出现问题的网页，开3个标签页，连接数可以稳定在 170+ 左右（页面主要有一堆定时的 fetch 操作会不断创建 http 请求）。