-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] AnyTls在安卓上设置min-idle-session导致断流 #1891
Comments
cc @anytls |
|
测试在19:17:53客户端进行首次连接,为方便测试仅对tg进行分流,19:18:50息屏,19:29:23开屏打开tg,可以看到19:29:25客户端日志内有请求,服务端未收到,服务端首次收到tg请求是19:29:52,这是客户端开屏后发起的第八次请求,分别是 附服务端及客户端debug日志:
客户端clashmetaforandroid 内核版本1.19.3
|
测试仅修改客户端min-idle-session为0时无此问题,从单一变量角度来看猜测与该参数有关 |
非直接运行内核产生的问题 |
日志仍然不够详细,未显示服务器何时断开了Session。也未显示客户端侧使用复用的Stream代理中继时遇到的错误是否为超时。 不过我在 mihomo 文档中找到了一些提示:
是否因为您的连接长时间处于非活动状态,已被 NAT 清除? |
日志无论是sing-box服务端还是mihomo客户端都只能开到debug这个层级了。NAT丢失也是一种可能,keepalive在安卓上的关闭加上无数据传输导致运营商掐断长连接NAT是可预期的,但是本质与主题内描述的问题是一样的,猜测是min-idle-session只是固定保留了这些数量的session但是并未确保可用。这些不可用的session在下次请求时被继续复用,并以三个为一次循环进行关闭,失败三个session后丢弃请求,4的配置会经历两轮甚至更多才能开始创建新session导致了产生这种断流现象。 |
最开始说过了。如果服务器(或者你的NAT,断开时应该向双方发送RST)断开了 TCP 连接,客户端收到 TCP RST 之后将使 recvLoop 返回,Client 就会清理掉这个 session。这样就实现了不可用会话的被动清理,也是可以预期的行为。 如果没有更多的信息,比如显示复用连接在每个步骤花费的时间,去除 Telegram Android 客户端直接复现问题,继续讨论是没有意义的。 |
验证步骤
操作系统
Android
系统版本
Android15
Mihomo 版本
v1.19.3
配置文件
描述
disable-keep-alive在安卓默认为true,anytls的min-idle-session确定了保留的session数但并未考虑其底层tcp连接状态。在手机锁屏后一段时间后,服务端持续未收到keepalive包断开tcp连接,而在tcp上的旧session并未检测连接状态只是按min-idle-session数进行了保留。下次手机解锁后会依然尝试用这些旧session直到经过
这里的逻辑完全关闭完现存的旧连接。以我min-idle-session: 4的配置来说需要逐一关闭两轮,第一轮抛出一个too many closed session 然后需要下一次尝试建立连接才会再走一次逐一关闭,关闭掉剩下的一个session,创建新的session。而这其实会造成开屏后较长时间的断流不可用。
重现方式
环境安卓 配置anytls协议min-idle-session大于0 最好大于3
待息屏一段时间服务端/运营商断开tcp连接后 开启屏幕会触发一段时间的断流
其他配置了keepalive的系统平台无问题,安卓配置min-idle-session=0无问题
日志
The text was updated successfully, but these errors were encountered: