[Bug] 活动连接数居高不下，很多连接时长几天前的都还在

imshuai commented 11 months ago

Verify steps

[X] 确保你使用的是本仓库最新的的 mihomo 或 mihomo Alpha 版本 Ensure you are using the latest version of Mihomo or Mihomo Alpha from this repository.
[ ] 如果你可以自己 debug 并解决的话，提交 PR 吧 Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
[X] 我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
[X] 我已经使用 Alpha 分支版本测试过，问题依旧存在 I have tested using the dev branch, and the issue still exists.
[X] 我已经仔细看过 Documentation 并无法自行解决问题 I have read the documentation and was unable to solve the issue.
[X] 这是 Mihomo 核心的问题，并非我所使用的 Mihomo 衍生版本（如 OpenMihomo、KoolMihomo 等）的特定问题 This is an issue of the Mihomo core per se, not to the derivatives of Mihomo, like OpenMihomo or KoolMihomo.

Mihomo version

Mihomo Meta v1.17.0 linux arm64 with go1.21.4 Sat Dec 2 11:02:32 UTC 2023 Use tags: with_gvisor

What OS are you seeing the problem on?

Linux

Mihomo config

mixed-port: 7890
allow-lan: true
bind-address: "192.168.4.4"
mode: rule
ipv6: true
external-controller: "127.0.0.1:9090"
interface-name: enxb827eb7678ab
geodata-mode: true
geodata-loader: memconservative
geox-url:
  geoip: "https://cdn.jsdelivr.net/gh/Loyalsoldier/v2ray-rules-dat@release/geoip.dat"
  geosite: "https://cdn.jsdelivr.net/gh/Loyalsoldier/v2ray-rules-dat@release/geosite.dat"
  mmdb: "https://cdn.jsdelivr.net/gh/Loyalsoldier/geoip@release/Country.mmdb"
tcp-concurrent: true
#keep-alive-interval: 60
global-client-fingerprint: random
unified-delay: true #更换延迟计算方式,去除握手等额外延迟
profile:
  store-selected: true # 储存 API 对策略组的选择，以供下次启动时使用
  store-fake-ip: true # 储存 fakeip 映射表，域名再次发生连接时，使用原有映射地址
dns:
  enable: true
  prefer-h3: true
  ipv6: true
  default-nameserver:
    - 223.5.5.5
    - 114.114.114.114
  nameserver-policy:
    'geosite:cn': https://doh.pub/dns-query
    'geosite:gfw': [tls://8.8.4.4, https://1.0.0.1/dns-query]
    'rule-set:google,proxy': [tls://8.8.4.4, https://1.0.0.1/dns-query]
  nameserver:
    - https://doh.pub/dns-query
    - https://223.5.5.5/dns-query
    - https://doh.360.cn/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - 8.8.8.8
    - 8.8.4.4
    - tls://1.0.0.1:853
    - tls://dns.google:853
  proxy-server-nameserver:
    - https://doh.pub/dns-query

Mihomo log

No response

Description

最新版的Mihomo，使用metatubexd作为UI，活动连接数居高不下，很多连接时长几天前的都还在，是不是我哪里设置不对？

关于keep-alive-interval

我尝试过设置为15、60、300、3600以及关闭，都不能正常的断开连接

Skyxim commented 11 months ago

关闭 home-pc 这个设备后是否释放连接

imshuai commented 11 months ago

浏览器关闭，甚至设备直接关机后还是存在未释放活动连接

发自我的小米在 Skyxim @.***>，2023年12月18日 18:58写道：

关闭 home-pc 这个设备后是否释放连接

— Reply to this email directly, view it on GitHubhttps://github.com/MetaCubeX/mihomo/issues/921#issuecomment-1860151578, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADXGMJAIPEHQCHFKD2ZQ6W3YKAOU3AVCNFSM6AAAAABAY4IGJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRQGE2TCNJXHA. You are receiving this because you authored the thread.Message ID: @.***>

hunshcn commented 10 months ago

outbound 是 tuic 吗

imshuai commented 10 months ago

不是tuic，我的节点基本都是vless或者vmess

发自我的小米

outbound 是 tuic 吗

― Reply to this email directly, view it on GitHubhttps://github.com/MetaCubeX/mihomo/issues/921#issuecomment-1864479409, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADXGMJGZQ7KIBUIJX3LXZ7TYKLSFBAVCNFSM6AAAAABAY4IGJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRUGQ3TSNBQHE. You are receiving this because you authored the thread.Message ID: @.***>

hunshcn commented 10 months ago

那可能需要加 pprof 看下 stack 了。目前我发现限速网络（client -> clash 通过受限网络）下使用了 net.Pipe 的 plain http inbound （已确认）和 tuic v4/v5 outbound（未确认）有可能出现死锁。

ByteArray0 commented 10 months ago

流量过CDN了吗？

Skyxim commented 10 months ago

那可能需要加 pprof 看下 stack 了。目前我发现限速网络（client -> clash 通过受限网络）下使用了 net.Pipe 的 plain http inbound （已确认）和 tuic v4/v5 outbound（未确认）有可能出现死锁。

有具体的问题点么，或者能否共享下 pprof

hunshcn commented 10 months ago

那可能需要加 pprof 看下 stack 了。目前我发现限速网络（client -> clash 通过受限网络）下使用了 net.Pipe 的 plain http inbound （已确认）和 tuic v4/v5 outbound（未确认）有可能出现死锁。

有具体的问题点么，或者能否共享下 pprof

我使用的是原版内核，但是问题应该是一样的。

plain http inbound，网络为 client <-> clash <-> proxy <-> target net.Pipe 没有 close，同时 client <-> clash 处于网络受限环境（比如网络打满或者质量差的局域网）。原本会对 net.Pipe right 和 outbound 进行双向的 io.Copy。在某个时刻可能会陷入 right.Read() 和 right.Write()，然后 client conn 意外断开，conn 断开没有 close net.Pipe 的 left/right，就导致双向 io.Copy 卡在right.Read() 和 right.Write()。永久性 hang 住。

pprof

解决方法是在 conn 断开的时候把产出的所有 net.Pipe clsoe 掉。

这个问题我也找了好久

yyysuo commented 10 months ago

动了sysctl.conf了？还原一下。

Magic989 commented 10 months ago

其实我也经常出现这种问题，直接在 Windows 上运行内核，时间长了会有部分连接不会自动断开，关闭进程连接依旧存在，哪怕是直接断网静置一段时间连接也还在，不知道什么原因，但不影响使用（就是面板会有点卡卡的）。

xzycn commented 3 months ago

@Skyxim 使用 http 入站，访问部分http网站就会有这问题，例如访问 ipinfo.io。即使没有上游代理也会有这问题。因为https网站和http实现不一样，所以https目前没有看到这问题。问题应该正如上面说的，出在net.Pipe。

重现步骤：运行最新 mihomo(1.8.6)，不用设置配置文件。然后运行 curl -x localhost:7890 ipinfo.io -v，就会一直卡住，该连接也一直存在，处于 established 状态(keepalive的原因)。

xzycn commented 3 months ago

@xzycn 实验发现，代理会加上头部 Accept-Encoding: gzip，ipinfo 使用gzip压缩后，content-length 大小变了，但是body还是压缩前的大小，代理这样按照这个值，读取就出现异常。所以有几个问题： 1、代理为什么会自己加上头部 Accept-Encoding: gzip 2、网站自身的问题 3(附加)、可以兼容下这种异常情况

wwqgtxx commented 3 months ago

@xzycn 实验发现，代理会加上头部 Accept-Encoding: gzip，ipinfo 使用gzip压缩后，content-length 大小还是写的压缩前的大小，代理这样按照这个值，就一直等不到完整的内容，一直等着。所以有几个问题： 1、代理为什么会自己加上头部 Accept-Encoding: gzip 2、网站自身的问题 3(附加)、可以兼容下这种异常情况

fixed in: https://github.com/MetaCubeX/mihomo/commit/cc7823dad80e1031335a582d85c23425907c668b

MetaCubeX / mihomo