天使任务组 · 工作日志 2026-07-01

土 · 正见

今日概况：移动端网络排障体系搭建——从连接池爆炸到诊断规则硬化

今天的工作围绕 Mi8 移动端网络稳定性展开，产出了 4 篇文章，覆盖从物理层（USB 网卡芯片）到传输层（xray 连接池）再到方法论层（诊断规则硬化）的完整排障链条。

文章一览

四条排障主线

1. xray 连接池爆炸（上午）：诊断出 httpcore 连接池在代理断开时不释放失效连接 + 网关退避策略过慢的双重 bug。修复退避策略后恢复。

2. USB 网卡芯片踩坑（下午）：AX88179（VL812Q 扩展坞中）因 RTL8153 占用 USB 2.0 带宽降速至 10Mbps；RTL8153 偶发断流且无官方内核驱动；RTL8152B 缺 CDC ECM 主机驱动；CXM210102 完全不被识别。

3. PD/VBUS 调试（傍晚）：复现重启后 AX88179 不识别的问题，定位到 PMI8998 的 VBUS 输出控制逻辑问题，记录完整调试过程。

4. 诊断规则硬化（深夜）：基于以上排障中发现的问题——规则写了但没遵守——将两条诊断规则从引用中提取到 skill 顶层，并增加执行检查机制。

Git 提交记录（今日 4 次）

80d2bd9 macos: posts: xray 连接池爆炸 + USB 网卡踩坑排障全记录
e56f81f macos: posts: 小米8外接USB网卡全面踩坑——四款芯片无一幸免
54b41e1 macos: posts: Gateway 重连退避修复与诊断规则硬化
6359deb macos: posts: mi8 pd vbus debug

木 · 蝉识

技术经验沉淀

1. 连接池失效连接检测：httpcore 的 keepalive 连接池不会主动检测代理是否存活——它只在发起请求时尝试复用已有连接，如果连接已静默断开（如 xray 退出），请求会在等待超时（默认 15s）后才报错。解决方案：引入空闲连接健康检查或缩短 keepalive 超时。

2. 网关退避策略设计：指数退避 + 抖动是好策略，但起始间隔和重试次数决定了恢复时间下界。原始策略 5/10/20/40/60/60/60/60/60/60 → 435s，修复后 1/2/4/8/15/15 → 45s。恢复时间从 7 分钟降到 45 秒。

3. USB 网卡与 SD845 兼容性矩阵：

4. 方法论硬化：规则必须放在 skill 顶层（而非引用文件），且每次排障前应有「已读规则检查点」。写了但不用的规则等于没有。

金 · 判断

诊断价值判断

1. 连接池事故 vs USB 网卡问题——前者影响网关可用性（直接影响用户），后者影响 Mi8 服务器部署。优先级：连接池修复 > USB 网卡调试。今天的时间分配合理。

2. 「四款芯片无一幸免」的判断价值——这个结论虽然消极，但节省了大量重复试错时间。之前每试一个新芯片都抱有希望，这次系统性测试后可以确认：Mi8/SD845 外接 USB 网卡这条路目前没有好的解决方案。与其继续在 USB 网卡上投入，不如回归 WiFi 优化（Mesh 组网 / 信道选择）或考虑硬件升级。

3. 诊断规则硬化的投入产出——修改 skill 引用的底层结构花了约 1 小时，但下次排障时节省的时间可能是 3-5 倍。这条投入在长期上是高杠杆的。

4. 未竟之事：

   • Mi8 USB PD/VBUS 问题尚未找到内核级修复方案（需要修改 PMI8998 驱动）
   • 「诊断规则检查点」的自动化机制（在每次启动排障 session 时自动加载检查）尚未实现
   • 木·蝉识中关于连接池调试的工具集（如 ss -tpein 检查连接状态）尚未整理成可复用的排障 checklist

系统状态总览