liandu2024：Open-Box v0.1.305 修复故障转移四项缺陷与内核 10 秒复查失效，并说明测速容量上限
liandu2024 在 Open-Box issue #514（故障转移管理器四重放大缺陷报告）回复：四条缺陷与定时测速问题逐条对代码核实属实，另查出一个内核问题，修复已随 v0.1.305 发布（该版带新内核，升级后内核会重启一次）。修复项：1) 全局测速名额——故障转移/定时/手动测速共用面板一份名额，同一时刻最多 4 个请求在内核侧，按「复查→例行/手动→定时」三档排队，定时测速有活时至少保 1 个名额；2) 各组轮次各跑各的，部署/重启内核后错开几秒开始，读回正文纳入期限并有看门狗兜底；3) refresh 接口作废进行中轮次、撤掉排队测速并立即开新一轮，组卡片新增按组「重新检测」；4) 拒绝状态下每分钟复查一次、每个页签强制测一个候选，组卡片标红并写出各原因节点数；5) 面板复查带的「失败时刻」只到毫秒、内核按纳秒比较，导致未复测，内核 tcp14 起有此问题、tcp21 修好；6) 定时测速改为逐个节点测、不再掐断重发，未等到结果不再当「未知」缓存整个间隔；7) 可接受状态码示例改为 200-299。不改：全部页签不通即切「拒绝」是设计（fail-closed）。容量：按其配置每秒约需测 12 个，内核每秒只能测完 1~2 个，建议精简大组节点或调大间隔（如 2 分钟改 5~10 分钟）。
作者原文@liandu2024谢谢这么细的报告。四条缺陷和补充评论里定时测速那条,我们逐条对着代码核实过,都属实;另外还查出一个让「出不来」雪上加霜的内核问题,一并修了。这些修复已随 v0.1.305 发布,照常在面板 / LuCI 里升级即可(这版带新内核,升级完内核会重启一次):
这次修掉的
- 全局测速名额:故障转移、定时测速、手动测速现在共用面板里的一份名额,同一时刻最多 4 个请求在内核那边(和内核一样多),按「复查 → 例行 / 手动 → 定时」三档排。排队在面板这边,拿到名额才发、才开始计时,不会再因为排队被掐断记成「未知」。定时测速有活时至少保 1 个名额、最多占一半,不会被饿死,也挤不掉故障转移。
- 组和组互不拖累:每个组的轮次各跑各的,不再等所有组跑完;部署 / 重启内核后各组按顺序错开几秒开始,不再同一秒齐发。读回应正文也纳入期限(你指出的
res.json()挂住那处),另有看门狗兜底。- 刷新立刻生效:
POST /api/openbox/failover/refresh会作废正在跑的轮次、撤掉还在排队的测速、马上开新一轮。组卡片展开后新增「重新检测」按钮(POST /api/openbox/failover/recheck),把这个组的节点全部强制重测一遍,检测时显示「检测中 x/y」。- 进了「拒绝」能自己出来:拒绝状态下改成每分钟复查一次,每个页签强制测一个候选(多节点页签测内核子组当前选中的那个),通了马上切回;整组的盘点照常按间隔做。组卡片标题会标红「已拒绝」,展开后写出原因和各原因的节点数,比如「状态码 404(18 个)、超时(2 个)」,一眼能看出是测速地址的问题还是节点真挂了。
- 10 秒复查其实没测(内核问题,BrownDust2 出不来也有它的份):面板复查时带的「失败时刻」只到毫秒,内核按纳秒比较,把那次失败本身当成了「复查结果」,于是没被组选中的节点(单节点页签、子组没选中的成员)根本没复测。内核从 tcp14 起都有这个问题,tcp21 修好。
- 定时测速不再掐断重发:改成逐个节点测(走上面的名额,带组的可接受状态码),不管成没成都记账,到下一个间隔才再测,也不会再把内核那一批测速掐断。没等到的结果也不再被当成「未知」缓存一整个间隔。
- 可接受状态码的示例改成
200-299。不改的(和你的判断一致):全部页签都不通就切「拒绝」是设计(fail-closed);测速地址请用站点自己的
robots.txt这类会回 2xx 的地址。「相关观察 A」(改档案时applied只反映在线换了出站)我们记下了,这次没动。容量:你这份配置按各组的间隔算,每秒要测约 12 个,而内核每秒只能测完 1~2 个(4 个名额,相邻两次起测隔 0.25 秒)。调度修好以后也测不过来,只是不会再卡死、误判,检测会变慢。测速跟不上时面板会提示,建议精简大组的节点,或者把间隔调大(比如 2 分钟的组改成 5~10 分钟)。
升级后如果还有组卡在「拒绝」或「检测中」,麻烦把
GET /api/openbox/failover/status的输出(可以脱敏)和logread | grep -E 'failover|latency'贴上来。