网络故障恢复手册
本页目录
适用环境：主路由 192.168.31.1，N100 旁路由 192.168.31.7，客户端通常把网关和 DNS 指向 .7。先恢复必要的连接，再定位代理或 DNS 故障。网络架构说明正常路径，监控说明告警来源。
配置核对：2026-09-12。 下述自动行为来自 N100 的 /usr/local/sbin/nikki-failopen.sh、本机 wifi-watchdog.service 与实际执行脚本的只读核对；没有在本次核对中执行断网演练。轮询间隔、动作耗时和实际断网时间是三个不同量。
先判断断在哪一层
在受影响的客户端先查看当前 IP、默认网关和 DNS，再分别探测 .1、.7。能打开一个已有连接的网页，不足以证明新建连接或 DNS 正常。
| 观察 | 下一步检查 | 恢复路径 |
|---|---|---|
.1 和 .7 都不可达 | 本机 Wi-Fi/网线、地址、另一台设备、主路由供电 | 先恢复局域网连接 |
.1 可达，.7 不可达 | N100 电源、交换端口、地址与本地控制台 | 临时将客户端网关和 DNS 改为 .1 |
.7 可达，域名解析失败 | 分别向 .7、.1 查询，查看 AdGuard 与 mihomo 日志 | 按 DNS 或代理故障分支处理 |
| DNS 正常，新建外网连接失败 | 主路由 WAN、mihomo 路由、目标可达性 | 比较直连和代理路径 |
ping 失败只能说明这次 ICMP 探测没有得到回复。防火墙、地址变更、二层连接、设备启动和系统故障都可能造成它；“超过三分钟”不能单独诊断为内核崩溃。用另一台同网段设备、SSH、路由器客户端列表或本地控制台补证。详见网络故障排查方法论。
N100 自动降级：代理故障与 DNS 故障分开看
守护由 procd 管理，启动后先等 60 秒，随后每轮探测结束后睡眠 10 秒；连续 3 次失败触发动作。探测几乎立即返回时，稳定运行中的检测等待大致为 20–30 秒，再加探测和执行耗时。脚本仅用 curl --connect-timeout 3，没有设置整个请求的 --max-time，因此不能保证 30 秒内切换。curl 超时说明区分了连接阶段与整个传输期限。
| 分支 | 当前健康判据 | 连续失败后的动作 | 判定恢复后的动作 |
|---|---|---|---|
| mihomo | 本机 :9090 返回 HTTP 200、401 或 403 | 删除 table inet nikki；建立 table inet failopen，做出口 masquerade，并将送往 .7:53 的 UDP/TCP DNS 转到 .1:53 | 删除 failopen 表，重启 nikki 重建正常规则，清理标记 |
| AdGuard（未处于代理整体降级时） | 本机 :8083 返回 200，或发现任一进程监听 53 端口 | 仅将送往 .7:53 的 UDP/TCP DNS 转向本机 mihomo 127.0.0.1:1053，保留代理规则 | 删除 DNS 救援规则和对应标记 |
第二行绕过 AdGuard；第一行才是整体退回主路由直连。API 回应或端口监听只是存活信号，不能证明上游 DNS、代理节点和真实业务恢复。AdGuard 的端口兜底判据较宽，另一个监听 53 的进程也可能使它判为健康。
先在客户端测试独立 DNS 查询和新连接，再在 N100 上观察状态。以下命令只读取状态：
# 从管理机登录 N100；下方命令在该 SSH 会话中执行
表或标记不存在可能只是该模式未启用。核对规则、标记和最近日志是否一致，再查实际请求；不要整段复制删表命令。手工删 nikki 表而漏掉 TCP DNS、出口 SNAT 或恢复标记，可能制造第二个故障。
自动恢复无效时，先让一台客户端直连
当 .1 的局域网和 WAN 正常，而 N100 不能恢复时，记录一台客户端的原设置，再将默认网关和 DNS 同时改为 192.168.31.1，保留同网段未冲突的地址。仅改 DNS 无法绕过失效网关；仅改网关也可能继续向失效的 .7 查询。
先验证该客户端能解析域名并建立预期直连连接。依赖代理的目的地在直连模式下未必可用。确认后，在主路由 DHCP 设置中把网关和 DNS 从 .7 改为 .1，让其他客户端续租。已有租约和静态配置不会因保存 DHCP 设置立即改变。
如果 N100 可登录，只是守护未运行，可在确认没有手工救援规则与服务竞争后启动它：
# 在 N100 上执行；会启动检测及其自动规则切换
它仍有启动宽限，不是立即全屋切换的命令。规则与标记已经不一致时，保留日志和规则输出，并继续用客户端直连；按架构文档恢复所属组件，避免手工规则与自动恢复竞争。
N100 修复后，不以“已开机两分钟”为恢复标准。先确认代理、DNS、正常防火墙规则和守护日志，把测试客户端的网关/DNS 改回 .7，分别验证局域网、普通外网和需要代理的目标。通过后恢复主路由 DHCP 设置，检查客户端实际续租结果。
停电与主路由故障
N100 配置了通电自启和组件自启。原文约两分钟的估计不能覆盖磁盘检查、容器启动、WAN 获取和守护宽限；恢复仍按上一节验证。若 .7 长时间不可达，直连是恢复路径，诊断则需要电源、交换端口和本地控制台证据。
若主路由失效，N100 不能替代它的 PPPoE、NAT、DHCP 和 Mesh 根节点职责。先区分“局域网管理地址不可达”和“后台可达但 WAN 未连接”，检查供电、线路、WAN 状态及上游光猫。当前没有主路由热备；光猫桥接不提供主路由的故障接管能力。
li-home-0 Wi-Fi：当前脚本的升级流程
systemd timer 为 OnBootSec=60、OnUnitActiveSec=30、AccuracySec=5。每次用 ping -c 5 -W 1 探测 .1，故障计数跨执行保存在 /var/tmp/wifi-watchdog：
- 网卡
wlp9s0存在时，前两次连通性失败只记日志。 - 第三次失败先尝试
nmcli connection up。恢复则清零；失败则在同一次执行继续驱动重载。 - 重载先关无线，尝试卸载
mt7925e及相关 mt76 模块，再载入并连接。两次重载至少间隔 300 秒；网卡消失时也走受此冷却保护的重载分支。 - 后续探测成功才清零。服务执行期间，timer 到期不会并行启动另一份。
不能再按旧表理解为“失败 1–3 次重连、4–6 次射频、7 次以后重载”，也不能把某一步约 25 秒的耗时当成总断网时间。探测、确认阈值、调度误差、命令超时和冷却都影响它。
# 在 li-home-0 本机控制台，或仍可用的管理连接中读取
确认主路由正常且是本机无线故障后，才考虑人工重连或重载。重载会断开通过该无线连接的管理会话，优先用本地控制台或有线管理。不要在冷却期间循环重载来“加快恢复”，应查网卡、固件和最近日志。
回滚完成的判据
记录调整前后的客户端网关、DNS、DHCP 设置和时间。先让一个客户端通过解析、新建直连、必要的代理访问测试再推广，恢复正常路径也按相同顺序验证。
旧 .8 旁路由只有在确认代理服务、转发、DNS 和规则仍可用时才能作为备选。启动 mihomo 服务不证明整条旧路径恢复。无需为了 DHCP 回滚立即关闭 N100，保留它便于读日志和修复。