博客-v37 部署 7 天体检报告：稳定运行 + 一个反复出现的隐形 bug
v37 已经放在展厅稳定跑了 7 天，今天做了一次全面体检。一切看起来很美，但有一个 bug 已经第三次踩到我头上了 —— 这次打算从根上解决它。
一句话结论
sysupgrade-v37.bin（md5 353fc69dac266a5b7a5dea4647b24eb6）从 7/26 刷入至今表现稳定 —— 5G HE160 2401 Mbps 持续、WireGuard 隧道穿越学校骨干漫游多次零中断、SMB 跨隧道 ~440 Mbps、坑 #6 修复（bridge-nf 开机时序）持久不复发。
但有一个真 bug：U-Boot 网页刷机不清 overlay。每次刷完，开箱时 opkg 安装的旧 JS 文件会盖住 /rom 里的 v36+ 补丁版本 —— 无线 Edit 弹窗选择器消失、信道分析页空白。你看不到不代表它不在那，只是没去动无线配置而已。
健康体检数据
uptime: 6h15m (今天的 14:09 重启; 之前 5+ 天未中断)
load: 0.17 (15min 平均 0.04, 极度空闲)
内存: 130MB / 495MB (swap 0)
存储: overlay 264KB / 53MB, /tmp 448KB
WG: handshake 56s 前, transfer 31MB rx / 8MB tx, endpoint 自学到
WiFi: rax0 = 5G HE160 ch56 2401Mbps
ra0 = 2.4G HE40 ch8 573Mbps
eth1: 6h 内仅 1 次闪断（早先是 5 次 — 网线稳了）
桥接-nf: 1 (永久生效)
MSS clamp: nft mangle set 1360 在位
错误日志: 干净 (只有 dropbear auth/Disconnect)
隧道跟踪日志显示 7/26 以来有过若干次 WAN IP 切换，Plan C（office 端 endpoint_host=0.0.0.0）每次都能在 2 分钟内自动重连，这版固件的核心承诺兑现。
阴影复活 — 第三次
体检时发现 /overlay/upper/www/luci-static/resources/view/network/wireless.js 和 network.js 又出现了。这两个文件 v37 /rom 里有 v36 选择器补丁 + v35 语法修复的版本，应该是正确的版本。但 overlay 上的这两个文件是：
- md5
82b7a83c24c6739e4cc6c25bae68a6ee(wireless.js) - md5
582a43988dfb6bdb69446c2b3fea98bd(network.js) - mtime 2025-09-19 —— 设备开箱时 opkg 装 rpcd-iwinfo 的原始时间
字节和 7/26 我删过的那两个文件完全一致。也就是说：删了之后又回来了，文件本身没有任何"被重新写过"的痕迹 —— mtime 还是两年前。
那它是怎么回来的？
真相只有一个：你又 U-Boot 刷了一次。
为什么 U-Boot 刷机会恢复 overlay？
OpenWrt 的 squashfs 根 + overlayfs 上层设计：
/rom在 firmware 分区（MTD）—— 刷机时被覆盖/overlay/upper在独立的 overlay 分区（/dev/ubi0_2）—— U-Boot 网页刷机从来不碰它
也就是说：U-Boot 网页刷机只是覆盖 firmware 二进制，用户的 overlay 数据原封不动保留。这设计本来是为了让用户刷机不丢配置。但反过来说 —— 任何"刷前就在 overlay 里的脏东西"，刷完也依然在 overlay 里。
这台机器的原始 overlay 里就有这两个 JS 文件（开箱时 opkg 装的 luci + rpcd-iwinfo）。它们：
- 没有 v35 的 SyntaxError 修复 —— 但有别的早期问题
- 没有 v36 的 5 个选择器补丁 —— 所以无线 Edit 弹窗打不开信道/模式/频宽下拉
- 不含 v37 的 3 个 channel_analysis 补丁 —— 信道分析页空白
每次刷机都"看似能用"只是因为用户没去动无线配置。一旦动了编辑，或者打开过信道分析页，立刻穿帮。
这条经验在文档里早就有 —— 但没人在意
Openwrt 连接另一个openwrt 上网.md 笔记里早就写过：
刷机后第一件事：
ls /overlay/upper/www/检查残留
但这条经验只在我主动想起来时才查。我已经踩了三次：7/22 首次（v25 无限重启事故期间就发现 overlay shadow 在破坏 LuCI）、7/26 现场修过、今天 8/2 又复发。该把这个检查自动化了。
永久方案：v38 rc.local 自检
我打算在 v38 加一段 rc.local 自检：
|
|
逻辑很直白：如果这个文件存在，但不包含 v36 补丁标记 freq.mhz>50000，就说明它是 opkg 时代的旧版本 —— 删掉它，让 overlay 自动回落到 /rom 里的新版本。
安全性：
- 只针对这两个特定文件路径，不会乱动其它 overlay
- 用补丁标记检测，不会误删正常文件
- 幂等，每次开机跑一次
- 净效果：U-Boot 网页刷机后不再需要任何手工 overlay 清理
预计 v38 build ~2 分钟（在 192.168.1.143 增量编译），其它 v37 全部继承。
还没解决的两个问题
1. IDM 下载群晖 20MB/s，SMB 到另一台机 55MB/s
体检期间用户报：IDM 下载 192.168.1.102（群晖）只有 20MB/s，SMB 到 192.168.1.175 能跑 55MB/s。
我从路由器分别 ping 两台：
.102 (群晖): 0% 丢包, avg 1.10ms
.175 (SMB): 0% 丢包, avg 1.06ms
隧道链路质量完全一样，瓶颈不在隧道。我顺手抓了 15 秒 IDM 下载的实际流量：
10.7s 226MB → 21.1 MB/s (隧道这边已经达成 21MB)
也就是说隧道只能给到 ~21MB/s —— 不是隧道满速，是 HTTP 流的实际吞吐受限。
我注意到一个细节：群晖的 MAC 00:e0:1e:2d:61:d8 不是群晖的 OUI（群晖应该是 00:11:32）。如果是黑群晖/虚拟机，虚拟网卡的上限可能就是 200Mbps 左右。
待用户验证：从 \\192.168.1.102 用 SMB 拷一个大文件。如果 SMB 也只有 ~20MB/s → 群晖这台机器本身上限就是这样（虚拟网卡/网线/CPU）；如果能到 ~55MB/s → 纯群晖 HTTP 服务慢，IDM 换 SMB 共享盘就解决。
2. eth1 网线还在闪
6h 内 eth1 还闪了 1 次。早先 5 次，现在 1 次 —— 在好转，但还是不稳。建议换根网线，不急但早换早踏实。
致谢
- 呼啦大棒（right.com.cn 教程）—— X1 Pro 刷机基础
- Gzxhwq/hanwckf/padavanonly —— mt_wifi 闭源驱动 + ImmortalWrt 24.10 fork 预编译基线
- Claude Code —— v36/v37 的补丁编写、squashfs 雕刻验证、永久方案设计
- 办公室 OpenWrt / iKuai 至今没被动过，OpenClash nftables 链序安然无恙 —— 这就够了
关键词 / Tags
花生壳 X1 Pro · Cudy TR3000 · MT7981B · ImmortalWrt 24.10 · overlayfs 阴影 · U-Boot 网页刷机不清 overlay · v37 部署报告 · WireGuard 异地组网 · MSS clamp 持久化 · bridge-nf 开机时序 · Health Audit 7天 · rc.local 自检