旁路由的坏配置会被 DHCP 放大。一旦主路由继续把网关或 DNS 指向旁路由，手机电脑每次重连都会回到同一个坏链路。

这类故障不要从插件页面开始点来点去，确认设备到底拿到了哪个网关、哪个 DNS，再看 OpenClash / PassWall 有没有在重启后重新接管入口。

判断你是哪一种故障

故障表现更可能原因现场先看
所有设备断网，主路由可进DHCP 网关仍指向旁路由主路由 DHCP 下发项
只能进旁路由，外网不通旁路由默认网关或 DNS 错iStoreOS 网络接口
重启后又断插件自启恢复坏规则OpenClash/PassWall 自启
改回后部分设备仍异常客户端租约没刷新设备重新获取 DHCP

如果表里有两项同时命中，处理更靠近系统入口的那一项。端口、服务、透明代理入口、DNS 监听都属于入口层；订阅、规则、策略组属于配置层。入口没通时，配置层再正确也看不出效果。

为什么不要一上来重刷 iStoreOS？

重刷会清掉一部分状态，也会把证据一起清掉。很多人重刷后短时间恢复，是因为旧服务、DNS 缓存或监听端口被重启释放了，并不代表根因消失。下一次更新、重启或切换网络后，问题可能原样回来。

更稳妥的做法是保留现状，做最小化测试。只开一个入口，只用一个测试域名，只改一个字段。每次改动后都记录现象，这比反复导入新配置更快。

现场定位先看哪 4 个位置？

  • UI 路径：iStoreOS → 网络 → 接口 → LAN。
  • 主路由路径：DHCP 服务器 → 网关 / DNS 下发。
  • 插件路径：OpenClash 或 PassWall → 停止运行 → 关闭自启。
  • 命令关键词：route -n、ip route、logread。

可以直接执行或在 UI 里完成这些检查：

ip route
uci show network.lan
uci show dhcp
/etc/init.d/openclash stop || true

日志里如果同时出现端口占用和 DNS 失败，处理端口。DNS 组件起不来时，后面的规则命中、策略选择和连接测速都会失真。

哪些字段会把整网带偏？

字段或组件所在位置影响范围回滚提醒
主路由 DHCP主路由后台给设备下发网关/DNS第一项改回主路由
旁路由静态 IPiStoreOS LAN管理入口不要和主路由冲突
默认网关旁路由出站指向主路由写错会让旁路由自断
OpenClash 自启插件入口重启后恢复规则回滚时先关
PassWall 自启插件入口可能接管 DNS回滚时先关

这张表不是让你照抄字段，而是先分清「谁负责入口，谁负责规则，谁负责 DNS」。同一个 DNS 字段在桌面客户端里只是本机设置，放到 OpenWrt 上就可能影响整段局域网。

10 分钟回滚顺序

  1. 在主路由 DHCP 页面把网关和 DNS 下发地址改回主路由。
  2. 让一台测试电脑释放并重新获取 DHCP，确认能进主路由后台。
  3. 登录 iStoreOS，停止 OpenClash / PassWall，并关闭开机自启。
  4. 比对旁路由 LAN 静态 IP、默认网关、DNS，避免和主路由冲突。
  5. 管理入口连续 3 次可访问后，再逐个恢复插件功能。

如果家里有手机、平板、电视盒子和 NAS，先拿一台测试机做验证。确认 DHCP、DNS、后台入口恢复后，再同步到其他设备。多端共用订阅时，可以准备一份配套订阅线路作为基线输入，但旁路由回滚仍要从网关和日志开始。

哪些情况不该继续改配置？

出现下面几种情况，先停手：第一，日志已经提示文件缺失或权限不足，却还在改规则；第二，同一台设备上同时开了两个 DNS 接管组件；第三，服务重启后错误字符串变化很大，说明你一次改了太多变量。

还有一种常见误区是把「测速失败」当成所有问题的根因。测速只是客户端发起的一次请求，不能证明 DNS、TUN、Rewrite 或策略组都正常。要用真实 App 或浏览器请求补一次验证。

怎么验证已经恢复？

  • 同一个测试域名连续打开 3 次，结果一致。
  • 日志里不再出现 DNS 监听失败、端口占用或插件反复重启。
  • 连接记录进入预期策略组或出站，而不是落到兜底项。
  • DNS 返回值、监听端口和 UI 状态三者能互相对应。

验证要回到最初的失败样本。不要换一个网站就宣布修好，也不要只看 UI 绿色状态。能复现同一个动作，并在日志里看到清晰命中，才算完整链路。

记录哪些证据才有用？

处理「iStoreOS 旁路由改错后怎么回滚网络」这类问题时，建议把证据写成一行，而不是只截一张失败截图。可记录客户端版本、系统版本、当前入口端口、DNS 监听地址、失败域名、日志关键词和最后一次改动时间。以后同一个配置换到另一台设备上，能直接判断是环境差异还是配置差异。

如果团队里有多人维护配置，变更前后最好各保留一份导出的配置。不要只说「我改了 DNS」或「我开了 TUN」，而是写清具体字段，例如端口从 7890 改到 7897，Fake-IP 过滤新增了 *.lan，或 Script 里新增了一个策略组。这样的记录能减少重复试错，也方便回滚。

相关阅读