[Bug]: 无操作时 Core/TUN 数据面间歇失效，进程与监听仍存活

[Ezio1997-K]

环境

• Bettbox 1.18.8 / Windows
• 内置 Mihomo 1.19.29
• TUN system stack，fake-ip DNS
• 36 份订阅的自动更新均已关闭；下述故障发生前后没有手动更新或配置操作

实际表现

在正常使用过程中，当前订阅的节点会突然全部 TIMEOUT。切换到另一份订阅时，界面可能长时间保留旧节点列表；新列表出现后仍可能全部 TIMEOUT。期间普通网络请求失败，数分钟后又可能自行恢复。

该问题并不要求订阅更新失败作为触发器：关闭全部自动更新且不进行任何手动操作后，仍多次复发。

元数据现场

使用不记录节点、订阅、IP、域名或远端地址的探针，捕获到多轮零操作故障，例如：

• 2026-07-31 23:59:41–2026-08-01 00:01:54，约 134 秒；
• 2026-08-01 00:26:42–00:29:46，约 184 秒，之后仍有多次短暂复发。

上述窗口中：

• Bettbox App、BettboxCore、Helper 的 PID 均未变化；
• mixed-port 监听始终存在；
• 本地网关探针没有失败；
• TUN/mixed 的域名路径大量失败；部分采样只有域名路径失败，另有部分采样中域名与字面 IP 路径同时失败；
• Windows System 日志在对应窗口没有网卡、TCP/IP、DHCP、DNS、NLA/NDIS 状态事件。

因此，“进程存在、IPC/监听端口存在”不能代表真实数据面可用。DNS/TUN 链异常很突出，但不是唯一失败形态。

透明说明：该探针在异常时会提高采样频率，可能放大连接压力，发现后已停止。原始的全节点 TIMEOUT 在启用探针之前已经多次发生，所以探针不是最初原因，但其后的复发频率不能完全视为无扰动测量。

源码侧可观察问题

当前 main 中：

1. _waitForCoreReady() 只等待 IPC socket 5 秒，且超时被吞掉后继续启动；
2. checkCoreHealth() 只查询 getIsInit，无法发现 TUN/mixed 数据面不可用；
3. Core 初始化与状态设置的 bool 返回值未检查；
4. profile 硬切换后会清空 logs/requests，最有价值的事发证据会消失；
5. profile 切换期间旧 groups/providers 可继续显示，造成新配置已生效的假象。

另有两条晚于 Mihomo 1.19.29、目前仅在 Alpha 的官方修复与现场失败形态相关，但尚不能认定为完整根因：

• MetaCubeX/mihomo@fb002210：TUN DNS hijack 在 PackBuffer 重新分配时可能发送全零或旧数据；
• MetaCubeX/mihomo@63f15f2d：嗅探首次读取失败不应关闭连接。

期望行为

• IPC 未在超时内就绪时，重启/启动应明确失败并清理半启动 Core，而不是继续显示成功状态；
• Core 初始化返回失败时应终止启动链；
• profile 切换开始后不应继续展示旧节点列表；
• 切换/重启不应清空故障日志，或至少应先生成诊断快照；
• 应将 getIsInit 明确视为控制面健康，而不是数据面健康。

不确定性

目前仍不能完全排除运营商或代理上游的短时抖动，因为 Windows TUN 可能拦截看似绑定物理接口的外部探针。这个 Issue 报告的是已证实的客户端可观测性和生命周期缺陷，以及与现场匹配的 Core 修复候选；不会把尚未完成真实旁路复现的部分写成已确认根因。

相关：#308、#209

[appshubcc]

https://github.com/appshubcc/Bettbox/actions/runs/30784391345

复杂的逻辑没有添加，针对请求配置失败场景，连接已经默认主动close