实测导读与核心结论（TL;DR）： 旁路由部署中最常见的技术灾难：在主路由的 DHCP 服务中将【默认网关】和【DNS】直接修改为旁路由 IP（试图实现全屋设备自动无感出海），结果导致国内网页大面积白屏打不开、局域网设备互相搜不到、甚至主路由后台管理界面直接失联瘫痪。产生根因主要有两点：1. 旁路由单臂路由回路：数据包从主路由发往旁路由，旁路由处理后又原路丢回主路由，触发了 Linux 内核的反向路径过滤（rp_filter）被当作伪造数据丢弃；2. DNS 递归死循环：主路由把 DNS 解析丢给旁路由，旁路由的上游又指向主路由，两者互相踢皮球陷入死锁。本文提供三条权威配置修正铁律，确保网络坚固稳定。
1. 根因剖析：为什么单臂旁路由会丢包断流
【致命死循环拓扑】：
设备发包 ──> 主路由 ──> 转发给旁路由 ──> 旁路由内核处理 ──> 丢回主路由 ──> 宽带出口
▲ │
└──────────(数据包原路折返，触发丢弃！)─────────┘
由于数据包的源 MAC 地址与流入接口在同一个交换机 VLAN 广播域内，Linux 内核会判定该数据包为异常 ARP 欺骗或路由回路，从而直接丢弃。
核心解法：强制开启 MASQUERADE
必须在旁路由的防火墙规则中，强制将发回主路由的数据包的源 IP 改写为旁路由自己的 IP：
# 解决旁路由单网口 NAT 数据包转发回路
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
2. 根治 DNS 死锁的三条铁律
- 旁路由绝不指向主路由 DNS：在 OpenWrt 的 LAN 接口设置中，自定义 DNS 必须填写权威公网 DNS（如阿里的
223.5.5.5或腾讯的119.29.29.29），绝对不能填192.168.1.1； - 关闭多余的 DHCP 服务：整个局域网内必须且只能有一个 DHCP 服务器（通常为主路由），在旁路由的 LAN 接口设置中必须勾选【忽略此接口】；
- 关闭主路由的 IPv6 DHCP：由于大部分旁路由插件对 IPv6 分流支持不完善，建议在主路由中关闭 IPv6 或禁用 IPv6 DNS 下发，防止流量绕过旁路由从 IPv6 直连通道泄漏。
配合高质量企业专线（如 光速云 2.5Gbps 双向 IEPL 专线），可确保出海链路响应延迟低于 40ms，彻底杜绝丢包白屏。
3. 蜂巢式关联与扩展阅读矩阵
- 软路由全流程搭建：回顾旁路由标准安装，参考 OpenWrt 软路由科学出海全流程；
- 全屋智能设备实操：配置电视与游戏机网络，查阅 全屋智能设备无感出海方案；
- DNS 安全机制：学习 Fake-IP 防泄漏机制，参考 DNS 污染与 DNS 泄漏深度防护教程；
- 返回聚合中心：探索全套教程体系，查看 客户端教程库聚合中心。