夜雨聆风晚上11点多，剪着视频，QQ头像变灰，宿友直呼断网了。
光猫已经设置为桥接模式，路由器通过 PPPoE 拨号连接外网。按往常的做法，我会打开路由器管理界面翻看系统日志，但这次我决定尝试用 Claude Code（AI 编程助手）通过 SSH 直接连上路由器找原因。
一、先连上去看看
SSH 连接命令`bash
ssh root@192.168.2.1 -o StrictHostKeyChecking=accept-new`
首次连接会遇到主机密钥警告，加-o StrictHostKeyChecking=accept-new参数可自动接受新密钥。
登录后第一件事是查看系统日志：
bash logread | grep -i ppp
日志里反复出现这样的信息：
Timeout waiting for PADO packets这是 PPPoE 协商超时的典型表现。PPPoE 拨号有三个阶段：发现（Discovery）、会话（Session）、终止（Termination）。当路由器发送发现请求后，ISP 的 BAS（宽带接入服务器）没有回应，导致超时报错。
排查过程中我还尝试关闭了 PCIe ASPM 节能和 EEE 节能参数，但问题依然存在。
后来 WAN 连接恢复了（电信机房网络故障解除），说明这次掉线的根本原因是 ISP 侧故障，而非路由器本身的问题。不过在排查过程中，我发现旧版 OpenWrt 内核对intel i226-v网卡驱动的支持存在一些不稳定因素，固件更新后网卡驱动的表现确实更稳定了，两件事就这样重合在了一起。
二、固件更新：更彻底的解决方案
在排查过程中，我想到了一个更彻底的思路——路由器上安装的 OpenWrt 系统已经运行了较长时间，内核版本相对较旧，系统日志里反复出现的网卡异常，可能和旧内核对网卡驱动的支持不完善有关。
与其不断在现有系统上打补丁，不如直接升级系统固件，从根本上解决驱动兼容性问题。
于是我下载了新版固件包，直接在U盘上刷写新的内核和系统分区，插回路由器通电重启。
重启完成后，再次查看系统日志和内核日志：
bash logread | grep -i "eth\|link\|down"
dmesg | grep -i "rtl\|eth\|aspm"
原本偶尔出现的网卡状态异常记录明显减少了，WAN 口连接稳定性有了可感知的提升。
经验总结：遇到硬件层面的反复异常时，与其执着于系统层面的参数调优，不如优先考虑更新固件——新版固件往往修复了大量已知问题，能从根本上提升系统稳定性。
三、修复双重代理冲突
这个案子里还有一个小插曲。路由器新固件预装了Mihomo（一个 Clash Meta 兼容的内核），后来又装了 OpenClash，这两个同时运行的时候就产生了冲突。
Mihomo 监听在 9090 端口做 API 管理，但 OpenClash 也有自己的 9090 端口。OpenClash 的 YACD 控制面板打开后一片空白，F12 看网络请求返回 "Unauthorized"——是 Mihomo 先抢了那两个端口，导致请求根本没到 OpenClash。
解决方法是完全卸载 Mihomo：
opkg remove --force-depends luci-app-nekobox mihomo同时还需要清理 Mihomo 遗留的 DNS 劫持规则——它通过 nftables 把 DNS 请求重定向到自己，如果规则残留，卸载后 DNS 会仍然不通：
nft delete table inet dnsmasq清理干净后，OpenClash 的 YACD 面板才恢复正常，网络也回到了正常状态。
四、总结
用 AI 工具的好处是，可以通过自然语言指挥 SSH 连接路由器执行各种诊断命令，不用记复杂的语法，思路直接转成操作，效率比在路由器后台页面里点来点去高得多。
下次再遇到类似问题，系统排查步骤：
- 查日志 — 定位症状，确认问题范围
- 查驱动 — 确认网卡驱动版本和状态
- 升固件 — 必要时更新系统，从根本解决
- 调参数 — 最后再根据实际需要调整系统参数
