liandu2024 说明 Open-Box tcp31 故障确认与 failover 重选机制
在 Open-Box issue #759 中，liandu2024 说明已核对 tcp31 随包补丁源码：拨号或探测失败会经 `confirmFailure` 和 `HistoryStorage.Failed` 做约 10 秒确认，随后通过已注册组的 `Reselect → performUpdateCheck` 重新选择，并非只删除 history 后等待 1800 秒。他要求补充实际 sing-box 文件 SHA256、脱敏配置、两份 controller proxies 原始 JSON 和一次拨号失败日志，以区分确认探测未完成、探测地址不同或其他重选路径；并明确 v0.1.370 未标记为已修复。
作者原文@liandu2024已核对实际发布的 tcp31 补丁源码，你给出的内核
now/history现象值得继续查，但引用的urltest.go不是本项目 tcp31 随包源码的对应实现：DialContext／ListenPacket失败调用的是confirmFailure，会经HistoryStorage.Failed做约 10 秒的失败确认，结束后通过已注册组的Reselect → performUpdateCheck重新选择；并非仅删 history 后等 1800 秒。这个机制用于避免一次瞬时失败就换节点。本次构建相关确认／重选测试也已通过。这不否认你观测到的残留选择，也不能单凭版本字符串证明正在运行的二进制与上述源码一致。请只补：①实际运行的 sing-box 文件 SHA256；②同一故障窗口的匿名配置中该 failover 及 lane 的定义，以及相隔约 15 秒的两份 controller proxies 原始 JSON（保留 tag 对应关系、now/history/url/interval/tolerance，去掉服务器与凭据），③该窗口的一次拨号失败日志。现有节点统计不必重写。我们据此区分确认探测未完成、探测地址不同或其他重选路径。本条保持打开；v0.1.370 未把它标为已修复，也不会直接改成“一次失败立即切换”。