关于“旁路由”的一些吐槽
Caution
同网段旁挂网关会强制终端的去程经过旁路由；主路由因持有直连路由，会将回程直接发送给终端，从而形成不对称路径。许多教程为了强制回程也经过旁路由，会再用 MASQUERADE 增加一层 NAT，代价是丢失终端身份，并影响硬件卸载、IPv6 路径和可观测性。一个不位于不可绕过的三层边界、也无法控制完整双向流量的「网关」，不是合理架构，而是用 NAT 掩盖路由错误的补丁。
| # | 章节 |
|---|---|
| 0 | 关于「旁路由」 |
| 1 | 「旁路由」是一种错误的组网方式 |
| 2 | 多拨和流控真的是刚需？ |
| 3 | 网上教程真的没问题？ |
| 4 | 软路由就是旁路由？ |
| 5 | 软路由做主路由性能不够？ |
| 6 | 软路由做主路由不够稳定？ |
| 7 | 「折腾不影响家庭网络」是旁路由的优点？ |
| 8 | 「折腾」是一种学习一种进步？ |
| 9 | 「如无必要，勿增实体」 |
| 10 | 家庭网络应当是什么样的 |
| 11 | 我动主路由会死怎么办 |
本文与 OpenClash 无关。
Important
本文所说的「旁路由」，仅指当前简中互联网教程中最常见的同网段旁挂网关：主路由、旁路由和终端位于同一个二层广播域，终端把旁路由设为默认网关，旁路由再把主路由设为默认网关。本文不讨论 WAN-LAN 串联的二级路由。
例如：主路由为 192.168.1.1，旁路由为 192.168.1.2，终端为 192.168.1.100；终端的默认网关指向 192.168.1.2，旁路由的默认路由再指向 192.168.1.1。以下所有技术分析均以这种拓扑为准。
Caution
本文以尖锐的语气表达作者对「旁路由」网络架构的批判态度。
Important
本文技术观点以 OpenWrt 是成熟且稳定的现代开源路由系统为前提。因人为进行破坏性修改而导致 OpenWrt「不稳定」，不能证明 OpenWrt 本身存在不稳定特性，也不能证明「旁路由」架构具有必要性。
截至目前，所有反驳本文的 Issue 或 Discussion 均作删除处理。这些反驳都刻意回避上述前提，只反复强调「崩溃后不影响家庭网络」，却不分析崩溃原因，也不尝试达到「不崩溃」这一基本门槛。
此类 Issue 或 Discussion 属于传播错误技术观点，没有讨论价值；除非反驳者先说明，为何成熟且稳定的现代开源路由系统在其环境中连主网关职责都无法承担。
如果一个成熟且稳定的现代开源路由系统在使用中频繁崩溃，甚至无法承担主网关职责，那么这种使用前提本身就是错误的。无论「旁路由」架构多么复杂，也无法掩盖这一问题，只会在错误基础上继续增加复杂度。
对于刻意回避以上事实以及本文核心观点的任何反驳，均属于浪费作者和其他社区用户的时间。
鉴于旁路由相关问题较多，本项目维护者基于近十五年的 OpenWrt 使用经验，说明对家庭环境中非必要部署「旁路由」的看法。
企业环境不在本文讨论范围内。企业旁路网关与本文所指的家庭旁路由并非同一类方案，配置方法也不同，不应混淆。
某些特殊情况下不得不使用旁路由，也不在本文范围之内。能识别出这种情况的用户，本身已经具备足够的组网技能，能够针对当前网络状况做出必要的技术部署，无需阅读和了解本文所表达的技术观点。
本文仅针对「完全没有必要却刻意部署旁路由」和「为避免崩溃而部署旁路由」这两类常见的错误观点，并反驳简中社区对 OpenWrt 与软路由的普遍偏见，以及视频网站中的误导性教程。
本文仅表达作者的个人观点。若观点不一致，请关闭本页；本文不接受相关讨论。
Warning
是否叠加更多旁路由属于使用者的自由，但请勿因此影响本项目仓库和讨论区。
在 Issue 或 Discussion 中发布相关争论内容，将被删除；相关账号可能被屏蔽。
以下漫画为转载内容，版权归原作者所有。因历史转载未保留原始出处，如权利人认为使用不当，请联系删除或补充署名：
首先明确三个观点：
家庭环境下的「旁路由」是一种错误的组网方式，不应该部署所谓的「旁路由」或「旁路网关」，强烈建议使用 OpenWrt 作为唯一主路由。
「旁路由」是特定限制下产生的一种妥协性组网方式。
在有条件部署 OpenWrt 主路由，且单台主路由能够满足需求时，刻意增加旁路由属于没有意义的重复建设。
判断一种网关拓扑是否合理，不看盒子数量，也不看管理页面有多花哨，只看四件事：路径是否确定、状态由谁维护、故障能否收敛、问题能否观测。同网段旁挂网关在这四项上几乎全部交白卷，却靠 NAT 和防火墙脚本把「暂时能上网」伪装成「架构完成」，这才是本文认定它错误的技术依据。
由于这是一种妥协性组网方式，因此以下特殊情况除外。
「特殊情况」仅指特定环境和技术条件造成的限制，例如：
- 没有网关设备的控制权，且不愿意使用二级路由；
- 某些生产环境下网络存在特殊限制；
- 现有主路由设备无法替换，只能继续使用运营商光猫提供的无线功能；
- 其他确有客观限制、无法将 OpenWrt 部署为主路由的情况。
Warning
绝不包括由于错误技术观点和错误使用方式产生的无中生有的情况，例如：
- 「稳定性」
- 「安全性」
- 「不影响其他人」
- 「方便折腾」
- 「更灵活」
- 「更高端」
使用 OpenWrt 作为主路由时出现上述问题，通常与使用方式错误或维护能力不足有关，并非 OpenWrt 本身的问题；通过正确部署和维护通常可以避免。
如果因此部署「旁路由」，等于试图用一个新的错误行为解决另一个错误行为造成的后果。
出现此类问题时，应及时纠正使用方式并提升排障能力，不应转而把部署旁路由当作解决方案，更不应在错误部署后得出「网络更稳定、更安全、更灵活，或修改配置不影响其他人」等错误结论。
网上部分教程提供的家用旁路由设置方式，采用同一局域网内的网关层层转交，存在严重的组网问题。
一个合格的受控网关应当位于流量不可随意绕过的三层转发边界上，并拥有明确的逻辑入接口、出接口和回程设计；如果还要承担透明代理、状态防火墙等功能，就必须保证双向路径受控，或者针对非对称路由做完整设计。同网段旁挂网关却既不是二层桥，也不是正常的串联路由节点：它只是被部分终端「自愿」选中的同网段下一跳。终端随时可以改回主路由，局域网内通信更是通过 ARP 或 ND 直接完成，根本不会经过它。把这样一个并不处于网络边界、无法形成强制转发面的设备称为「更安全」「更可控」，在网络工程上就是自欺欺人。
据维护者回忆，十几年前使用 OpenWrt 时，家庭网络中并没有普遍使用旁路由；这一方案是在近几年软路由普及后才大量出现。
部分论坛教程作者对网络拓扑缺乏基本理解，却仍在不断发明新的错误方案。
当前家用宽带价格已经较低，多数家庭是否真的需要使用 iKuai 实现多拨和带宽叠加？
流控和多拨对绝大多数家庭用户都不是刚需，大部分需求都可以由单台 OpenWrt 主路由解决，刻意增加旁路由只会引入额外问题。
从技术上说，多 WAN、故障切换、策略路由和队列管理本来就是边界网关的职责，不是把网关拆成两台设备的理由。OpenWrt 本身已有 mwan3、PBR 和 SQM/CAKE 等成熟组件，完全可以在同一个主路由上维护出口选择、源地址、连接状态和流量队列。控制面集中在一个明确的三层边界，才便于保证规则顺序、故障收敛和按终端统计。
常见的 Multi-WAN「负载均衡」是按连接或会话选择出口，并不等于把多条宽带无条件叠加成一条更快的单连接；真正的链路聚合还需要对端配合或专门的隧道聚合机制。将负载均衡与带宽聚合混为一谈，再以「多拨叠加」为家庭用户制造性能焦虑，是对技术概念的误用。
至于 iKuai，本文的态度很明确：对于没有多拨和流控刚需的家庭用户，它是为少数卖点引入的一层无效冗余。先让 iKuai 占据主路由位置，再挂一台 OpenWrt 承担代理、DNS、IPv6 或其他真正需要的网关功能，不是「专业分工」，而是用另一套系统弥补功能缺口。两台设备互相打补丁，换来的只有两份配置、两套状态和更多故障点。
没有相关刚需时，不值得为多拨叠加投入额外时间和设备成本。
需要上行多拨叠加的用户，例如 PCDN 使用者，不属于本文讨论范围。请根据自身需求部署，并自行承担运营商限速或断网风险。
本文仅针对网上将主路由、旁路由和终端全部放入同一网段的基础旁路由教程。策略路由、动态路由、VRF、透明桥接等经过完整设计的专业方案不在此列，也不能用来为面向初学者教程中的错误拓扑背书。
Warning
大量旁路由教程会让终端把旁路由设为网关、旁路由再把主路由设为网关，然后开启 IP 动态伪装（MASQUERADE）或复制来历不明的防火墙规则。它们只强调「必须这样设置」，却没有解释这种拓扑的非对称路径及其补救配置。
假设终端 192.168.1.100 访问互联网，未在旁路由上做源地址转换时，数据路径如下：
去程：终端 192.168.1.100 -> 旁路由 192.168.1.2 -> 主路由 192.168.1.1 -> 互联网
回程：互联网 -> 主路由 192.168.1.1 -> 终端 192.168.1.100
为什么回程不经过旁路由？因为对主路由而言，192.168.1.0/24 是自己的直连网段。它收到回包后会直接通过 ARP 找到终端的 MAC 地址，然后把包交给终端，根本没有理由绕到 192.168.1.2 再走一遍。
这就是一个典型的非对称三角转发： 旁路由看到去程，却看不到回程。普通无状态转发偶尔看起来能用，不代表拓扑正确；透明代理、状态防火墙、连接跟踪、策略路由、流量统计和故障检测都可能依赖双向流量。当一个状态设备只能看到半条连接时，出现偶发断流、规则时灵时不灵、连接状态异常，才是符合技术原理的结果。
更荒唐的是，旁路由收到终端的数据包后，下一跳主路由仍在同一个接口、同一个广播域内。旁路由可能发送 ICMP Redirect，接受该消息的终端会被直接告知「以后去找主路由，别再绕我了」。也就是说，连 IP 协议都在试图纠正这个多余的绕路，而教程作者却忙着增加规则阻止网络恢复正常。
所谓「开启 IP 动态伪装」，本质上是旁路由把终端源地址 192.168.1.100 改写成自己的 192.168.1.2：
去程：终端 -> 旁路由执行 SNAT（源地址变成 192.168.1.2）-> 主路由 -> 互联网
回程：互联网 -> 主路由 -> 旁路由 192.168.1.2 -> 旁路由还原连接 -> 终端
主路由现在只能把回包交给旁路由，回程才被强行拉回同一条路径。随后主路由还要再执行一次面向公网的 NAT，于是同一条连接维护两层地址转换、两份连接跟踪状态和两套超时计时器。
Caution
所以，二次 NAT 不是最初的病因，而是维持错误拓扑的补丁。先人为制造非对称路径，再用源地址伪装把路径拉回，最后把「能够上网」当作配置成功——这不是网络优化，而是在错误拓扑上继续叠加补丁。
这里需要明确因果关系。主路由对家庭网段的直连路由和邻居解析，才是回程直接送达终端的根本原因；硬件 NAT、软件流量卸载或各种 FastPath 只是可能让部分数据更早绕过内核防火墙和连接跟踪，使症状更加明显或更加混乱。某些教程发现关闭硬件 NAT 后现象发生变化，便将硬件 NAT 误判为根因，这是把症状当成病因。关闭加速可能暂时改变现象，却没有消除三角转发，只是牺牲性能去迁就错误架构。
-
硬件加速和透明代理相互冲突。 主路由希望把已经识别的流量交给硬件或快速转发路径，旁路由却要求每个包都经过自己的 netfilter、连接跟踪和代理规则。同接口转发、二次 NAT、策略标记和透明代理经常不在硬件卸载的支持范围内。结果不是绕过规则，就是被迫关闭加速，让本来能轻松线速转发的主路由陪着旁路由一起进行无意义的 CPU 转发。
-
经旁路由转发的终端在主路由眼中变成同一个设备。 MASQUERADE 以后，主路由看到的源地址几乎全是旁路由。按设备限速、SQM、公平队列、家长控制、访问控制、流量审计和故障追踪都会失去原始终端身份。部署两台路由器原本号称「功能更强」，结果却丢失了最重要的可观测性。
-
入站连接、UPnP 和 P2P 被继续复杂化。 端口转发、NAT-PMP、PCP、UPnP、游戏主机联机、BT、PT、远程访问和部分实时通信都依赖网关对映射关系的正确维护。终端的映射请求通常只能控制它发现的本地 NAT 或 IGD，而真正持有公网 NAT 的却是另一台主路由；没有专门的代理、级联映射和完整状态维护，一次请求不会自动打通两层 NAT。需要入站时又要同时处理主路由和旁路由上的状态、转发或例外规则。NAT 层级增加、打洞成功率降低、端口映射「看着成功但外面不通」，都是这套结构的正常副产品。
-
两份连接跟踪会增加状态失效的机会。 任意一台设备重启、规则重载、连接跟踪表溢出或超时策略不一致，都可能让长连接失效。旁路由失效后，把终端网关改回主路由也只能恢复新连接，原有 NAT、代理和会话状态不会凭空迁移。所谓「旁路由坏了不影响上网」，通常只是故障后手动修改网关的委婉说法，与高可用无关。
-
IPv4 路径看似受控后，IPv6 仍可能绕过旁路由。 IPv6 默认路由由 RA 产生，不是照抄一个 DHCPv4 网关选项就能解决。主路由继续发送 RA 时，终端很可能直接选择主路由走 IPv6，绕过旁路由上的代理、审计和过滤；两台设备同时发送 RA 时，默认路由和 DNS 选择还可能随终端实现、优先级与超时发生变化。最终，同一域名可能在不同时间通过 IPv4 旁路由或 IPv6 直连，表现为代理泄漏、分流漂移和「只有某些设备偶发无法访问」。为修补这一问题继续叠加 RA Relay、NDP Proxy、策略路由甚至 NAT66，只是在错误上增加更多补丁。
-
它根本不是安全边界。 同网段终端访问 NAS、摄像头、打印机和其他 IoT 设备时，会通过 ARP 直接二层通信，旁路由一个包也看不到。任何终端只要静态指定主路由为网关，也能绕过旁路由。一个既拦不住东西向流量、又能被终端主动绕开的设备，没有资格承担访问控制或安全审计；NAT 更不是防火墙，多做一次 NAT 不会凭空多出一层安全。
-
DHCP、DNS 和故障切换变成互相牵制。 有的教程关闭主路由 DHCP、改由旁路由分配地址；有的让主路由 DHCP 下发旁路由网关和 DNS；还有人同时启用两边的 DHCP，导致响应结果不确定。旁路由停止后，已有终端仍缓存旧网关，新终端可能无法取得地址；DNS 若由旁路由生成 Fake-IP，而实际连接又经主路由或 IPv6 绕行，还会产生解析状态与转发路径不一致。把 DHCP 租期当成故障切换机制，和把重启当成排障方法一样不可靠。
-
故障定位被拆成两半。 不做 SNAT 时，旁路由只有去程、主路由直接处理回程；做了 SNAT 后，主路由又看不到真实终端。抓包、连接跟踪、策略命中、MTU、PMTU、丢包和时延问题不得不在两台设备之间来回拼图。网络不是不能复杂，而是每一层复杂性都应当换来明确收益；这套结构增加了观测点和状态机，却没有增加任何不可替代的能力。
-
直连流量也被迫绕路。 每个本可由主路由直接处理的数据包，都要在旁路由的同一个 LAN 接口上收一次、再发一次，额外经过 CPU、netfilter、连接跟踪和队列。全双工网卡不等于带宽必然「拦腰砍」，但额外的每包处理、队列竞争和不可卸载路径会实实在在降低包转发能力，并在高负载下增加时延、抖动和 Bufferbloat。测速掉一半不是旁路由的必然定律，却绝对不是值得炫耀的玄学故障。
Note
这套拓扑的问题不是个人好恶：RFC 1812 第 5.2.7.2 节明确规定了同接口转发、源地址与下一跳同网段时的 ICMP Redirect 条件；RFC 4861 第 6.3 节和 RFC 4862 第 5.5.3 节说明了 IPv6 默认路由由 RA 建立；RFC 7648 第 1.1 节则专门描述了 NAT 级联及端口映射代理所需的额外复杂性。相关协议标准已经说明这些问题，但许多教程并未考虑。
大量复杂设置反而可能使网络体验不如低价消费级路由器，显然得不偿失。
有些用户甚至使用光猫作为主路由，再增加 OpenWrt 旁路由，这会进一步放大上述问题。
2025 年 9 月 7 日：
有人反驳我，说他用光猫做主路由、用 50 元 ARM 设备做旁路由，并使用光猫 Wi-Fi，既好用又安全、灵活、实惠，质问我凭什么反对部署旁路由……
真有复杂策略需求，就先把三层边界、路由方向、回程路径、故障域和可观测性设计明白，再使用 ROS 或真正具备相应能力的路由系统；没有这些需求，就老老实实让 OpenWrt 当唯一主路由。
至于 iKuai，不应勉强将其归入「专业路由系统」。没有多拨和流控刚需却仍部署 iKuai，再挂 OpenWrt 补齐所需功能，不是模块化设计，只能说明前一套功能不完整的系统占据主路由位置，却无法承担完整的网关职责。把 iKuai 放在 OpenWrt 前面不会使网络更高级，只会让状态路径更长、来源信息更少、排障更加困难。
不要盲目照搬网上的复杂教程。
许多 UP 主依赖此类选题获得流量。在内容竞争下，复杂方案更容易被包装为「高级」，因而家用网络被不必要地复杂化。
Important
软路由≠旁路由，OpenWrt 也从来不是一个为旁路由而生的系统。
「软路由」描述的是路由功能由通用 CPU 和软件网络栈实现，「主路由」和「旁路由」描述的是设备在拓扑中的位置与转发责任，两者根本不是同一维度。软路由完全可以而且应当成为唯一边界网关；反过来，就算拿一台昂贵的硬件设备放在同网段旁挂位置，它仍然是一个能被绕过、看不全回程的错误网关。用硬件形态替拓扑错误背书，属于连术语都没分清。
我反对将软路由与旁路由直接等同的教程；它们会让初学者误以为使用软路由就必须部署旁路由。
这会误导初学者，为部署旁路由而人为创造需求，并使网络环境不必要地复杂化。
尤其不要模仿那些结构复杂得如同「蜘蛛网」的家用网络拓扑图；它们往往包含大量不必要的转发路径，只是在用复杂度营造专业感。
有些教程认为软路由性能不足，必须使用硬路由作为主路由才能提高整体网络性能；这一观点没有技术依据。
以 ARM 软路由为例，在合理固件、正常散热和大包 NAT 等常见家用负载下，基于 RK3328 的 NanoPi R2S 这类入门设备已经可以接近千兆接口的有效吞吐；基于 RK3399 的 NanoPi R4S 对普通千兆家宽则有更充足的性能余量。
如需突破千兆，配备双 2.5GbE 接口的 ARM 设备已经较为常见；在匹配的包长、规则和卸载条件下，可以达到 2.5 Gbit/s 级别的家用转发性能。
x86 设备就更不要说了，2019 年的 J4125 在常见大包 NAT 和合理配置下已经足以应付多千兆家用负载，更不用说更新的平台。对于普通家庭网络，CPU 通常仍有充足余量，首先碰到的往往是接口带宽、驱动、规则或加密负载限制。
Note
作者不推荐 All-in-One；部分用户只是在预算限制下采用此类方案。正确配置的一体化部署不必然因其形态本身降低稳定性。
所以，哪儿来的性能焦虑？
讨论「跑满」必须先说清测试条件：大包还是 64 字节小包、单流还是并发、纯 NAT 还是透明代理、是否启用加密隧道、规则集规模多大、是否允许流量卸载。只贴一张测速图就宣布某种架构性能更好，和只看汽车最高时速就判断底盘一样外行。
跑不满时，应先检查固件来源、网卡与驱动、CPU 软中断、IRQ 分配、流量卸载、MTU、规则复杂度和散热，而不是直接宣布「软路由不能做主路由」。质量较差的第三方固件、错误配置和驱动问题，不会因为把设备改名为「旁路由」就自动消失。
更关键的是，如果某台软路由性能真的不足，把它放到旁路由位置也不会变快：需要代理的流量仍然必须经过它，它照样是瓶颈。正确做法是升级或优化唯一主路由，而不是保留瓶颈，再额外增加一台主路由陪它绕路。
至于小包转发性能，一些低性能软路由设备的小包转发性能确实不如硬路由，但这跟旁路由一点关系都没有。
对于家庭环境，在正常负载和合理配置下，很难从实际体验中察觉小包转发性能的差异。
而且小包转发性能取决于 CPU 单核与多核调度、网卡与驱动、IRQ、内存访问、流量卸载和规则复杂度等多项因素，并不存在「硬路由天然强、软路由天然弱」的简单结论。追求小包转发性能和使用软路由作为主路由并不冲突。
软硬路由的小包转发性能实测，可以参考 CHH 论坛的帖子：https://www.chiphell.com/thread-2630826-1-1.html
这一观点没有技术依据。
此类观点通常来自长期使用质量较差的第三方固件、但未正确定位故障来源的使用者。
OpenWrt 早已是成熟的路由系统；作为家用主路由时，系统本身并不存在「必须退居旁路由才能稳定」的技术前提。
路由器稳定性取决于硬件供电与散热、内核和驱动支持、固件来源、软件包数量、配置变更质量以及升级流程。控制好这些变量后，OpenWrt 作为主路由可以长期稳定运行；任由这些变量失控，即使退居旁路由，也只会从「全家一起断」变成「使用它的终端继续断」。拓扑绕路不能修复驱动，不会减少内存泄漏，也不会让质量较差的固件突然获得质量保证。
项目维护者在生产环境部署了多个型号的设备，均使用持续滚动、没有发布版稳定性承诺的 OpenWrt SNAPSHOT，并已长期稳定运行。
维护者还亲眼见过商用汽车 OBD 检测或编程适配器使用 OpenWrt 承担无线网络通信；不过个人见闻无法让读者独立复核，下面只列能够从厂商、基金会及客户案例页面直接核验的公开资料：
-
工业路由与电信基础设施：Teltonika RutOS。 Teltonika 明确说明，RutOS 是基于 OpenWrt、出厂预装于其全部网络设备的统一操作系统。在 Teltonika 公布的 PhilTower/PowerX 项目中，搭载 RutOS 的 RUT956 4G 路由器已经部署到 218 个电信塔站，用于远程数据采集、设备控制、自动化与事件通知，并计划再扩展约 700 个站点。这不是家里运行几天不断线的截图，而是分散在大量无人值守站点上的真实基础设施部署。查看项目案例
-
运营商级家庭网关：prplOS/prplWare。 prpl Foundation 明确说明，prplOS 是面向宽带路由器和网关、构建于 OpenWrt 之上的运营商软件平台，支持 TR-069、USP、容器化应用及云端管理。该基金会的公开 FAQ 还说明，prplWare 已经在 Orange 的约旦和摩洛哥网络中投入较大规模部署；其认证页面列出的 prplOS 设备则包括 Sagemcom Fast 5598/5298、Nokia Beacon 19、Arcadyan Mozart 等运营商网关与路由器。查看认证设备与对应 OpenWrt 基线
-
公共交通、连锁零售与商用设备：Turris Omnia。 Turris 官方文档明确说明，Turris OS 是基于 OpenWrt 的发行版。其官方客户资料中，瑞典 Dialect 表示其需求是为公交车、列车、出租车及站点寻找数百台同时承担网关和 Wi-Fi 热点的设备，并称 Omnia 完全适合；连锁零售商 OXALIS 为捷克和斯洛伐克的 79 家门店选择 Omnia，通过 VPN 安全连接总部；法国 Qarnot Computing 则直接把 Omnia 用作商用计算供暖设备的控制单元，并明确评价其平台稳定性出色。查看 Turris Omnia 官方客户资料
上述系统并不是从 openwrt.org 下载后原封不动刷入的通用镜像，而是厂商在 OpenWrt 基础上完成硬件适配、驱动集成、测试验证、升级管理和技术支持的产品化发行版。说明这一点并不会削弱论据，而是在陈述工程事实：OpenWrt 提供的是足以承载运营商 CPE、工业路由器和商用网关的成熟技术底座；最终稳定性取决于围绕这套底座进行了多少严谨的工程工作，而不是它是否被降为「旁路由」。
这些案例当然不能证明任何来源不明的第三方固件、任何劣质硬件或任何随意安装插件的配置都必然稳定；但它们足以反驳「OpenWrt 天生不稳定，所以只能放在旁边」这一错误观点。运营商和工业厂商不会在同一广播域中再增加一个旁挂网关来维持系统运行，而是让 OpenWrt 衍生系统直接处于网关、控制和运维路径的核心位置，再通过硬件选型、版本冻结、自动化测试、分批升级、远程监控与故障回滚保证可靠性。
把劣质供电、过热、闭源驱动、来源不明的固件、插件堆叠、错误配置和无回滚升级造成的问题，全部归因于「OpenWrt 做主路由」；然后再用同网段旁挂网关制造第二套网关、非对称路径和策略分裂，不是稳定性设计，而是用一处工程失败掩盖另一处工程失败。
既然 OpenWrt 衍生系统能够在电信塔站、运营商 CPE、公共交通和连锁门店中承担网关职责，为何在家庭设备上就「不稳定」，甚至必须退居旁路由？应优先检查硬件、固件、配置和运维方式。
部分初学者长期使用质量较差的第三方固件，并进行破坏性修改；出现问题后，又传播「OpenWrt 不稳定」「某型号设备不稳定」或「OpenWrt 只能作为旁路由」等错误观点，并继续制作教程误导更多用户。
Caution
根据作者观察，此类内容在抖音、小红书和什么值得买等平台较为常见。
旁路由所谓「修改配置不影响家庭网络」的「优点」并不成立。
把部分终端的默认网关交给旁路由以后，旁路由就是这些终端事实上的单点故障。它死机、重启、规则重载、代理异常，或者 DHCP、DNS 停止，这些终端照样断网。其他仍使用主路由的终端没断，只能证明你把家庭网络人为切成了两套行为不一致的客户端，并不能证明旁路由提供了冗余。
真正的高可用需要共享的虚拟网关地址、健康检查、确定性的主备选举和自动路由收敛，例如 VRRP；涉及 NAT、代理等状态功能时，还要考虑连接状态同步，否则切换后现有会话照样全部重建。让两批终端分别记住两个网关地址，再让家人在断网后手动改网关、拔旁路由或等 DHCP 续租，不叫容灾，叫把运维工单外包给家人。
Important
如果认可旁路由架构的这种「优点」，应先反思：为何修改 OpenWrt 配置会导致频繁断网或系统崩溃？相关操作方式和方向是否存在问题？
如果硬件本身没有故障，而 OpenWrt 仍频繁崩溃，应首先检查第三方固件是否存在问题。
此前有使用者在 Issue 中长篇说明旁路由的所谓「优点」。
总结其观点：我给亲朋好友家里都部署了旁路由，这样远程修改配置时，即使出现问题也不会影响整个家庭网络。
Caution
在技术能力不足且缺少回滚方案的情况下，将旁路由部署到亲友网络并远程反复修改，是不负责任的做法。
网上发布的固件，尤其是恩山论坛中大量出现的固件发布帖，除少数成熟作品外，很难确认其质量。
低门槛的云编译让更多用户可以编译固件，但也产生了大量缺少验证的第三方固件。许多固件只是基于官方源码勾选若干插件后完成云编译，其存在价值和质量都值得质疑。
频繁更换固件、盲目选择「高大全」版本、启用大量不必要的插件，并忽略系统日志中的持续报错，都会显著增加系统故障概率。
如果把体验各种质量较差的第三方固件视为乐趣，本文不再评价。
没有特殊需求时，放弃官方发布版、Image Builder、attendedsysupgrade、owut 和现成的 ASU，转而反复刷入他人编译的固件，通常没有必要。
修改和实验确实是学习过程，但许多初学者使用质量较差的固件和教程，反复经历「刷机 → 修改 → 故障 → 再次刷机」的循环。这一方向错误，只会浪费时间。
真正的技术学习至少应当包含明确假设、基线数据、日志与抓包、单变量变更、结果验证和可执行回滚。连故障发生在哪一层都没确认，就靠换固件、抄脚本和反复重启碰运气，不是在做实验，只是在随机改变系统状态。重复一百次也不会自动获得网络工程能力。
Caution
制造此类低质量固件和教程，并传播错误技术观点，会误导使用者，造成不必要的时间、设备和网络成本。
如无必要，勿增实体。——奥卡姆剃刀原则
切记，如无必要，勿增实体，大到设备，小到插件，原则皆是如此。
这里的「实体」不只是一台多出来的盒子，还包括第二套 DHCP、DNS、NAT、连接跟踪、防火墙、策略路由、升级流程和故障状态。可靠性工程里，每增加一个串联依赖和一份状态，就增加一个故障点、一组组合故障以及一层排障成本。没有换来隔离、吞吐、冗余或管理边界的复杂性，就是纯负债。
尽量简化家庭网络中的软硬件。单台主路由能够满足需求时，不要额外增加旁路由。
没有多拨和流控的刚需，就不要去装 iKuai，更不要把它当成软路由前面必须摆放的「主路由底座」。
没有在 Web 页面上查看下游设备解析请求的刚需，就不要去装 AdGuard Home。
一个 OpenClash 靠规则和设置就能完成 DNS 分流，就不要再去装 MosDNS 进行套娃二次分流。
官方发布版能满足需求，就不要使用所谓的「高大全」固件。
没有修改源码的明确需求，且 Image Builder 能够满足需求时，不要盲目使用云编译。
如需运行 Docker，可以使用入门级 x86 工控机并安装 PVE，或使用入门级 ARM 设备安装 Debian 或 Armbian。不要在 OpenWrt 中运行 Docker；OpenWrt 可以安装 Docker，但并不适合作为 Docker 主机，本文不再展开。
Note
有人可能认为这也属于「增实体」，与前文矛盾。但如无必要，勿增实体允许在确有需求时增加必要设备，因此并不矛盾。
预算有限时可以购买二手设备；如果暂时无法承担设备成本，应优先学习相关知识并改善预算，而不是在现有路由器上反复进行高风险修改。
如果预算确实有限，也可以使用免费 VPS 运行 Docker，避免给路由器增加负担。
如果刚接触家庭网络，目标应当是构建稳定、高效且功能完整的网络。
一个清晰的家庭网络拓扑应当是：
光猫桥接/运营商上联 -> OpenWrt 唯一主路由 -> 交换机 -> AP、终端和各 VLAN
路由、NAT、防火墙、DHCP、DNS 和策略控制集中在唯一的三层边界；交换机与 AP 只负责二层接入和无线覆盖，不再偷偷创造第二套路由逻辑。这样每条跨网段流量都有确定路径，每条连接都有明确的状态所有者，每个故障也都有可定位的责任边界。
搭建家庭网络时，可以使用单台 OpenWrt 主路由（x86 或 ARM）配合工作在 AP（桥接）模式的 Mesh 设备，或者使用由 AC 管理的 AP；AP 数量较少时无需额外部署 AC。固件应优先使用官方发布版，并通过 attendedsysupgrade 或 owut 升级；有容量需求时，可以借助官方 ASU 生成扩容固件。做好配置备份并控制变更后，系统通常可以长期稳定运行。若仍频繁故障，应修复硬件、驱动、固件或配置问题，而不是再增加旁路由。
需要隔离 IoT、访客、儿童设备或服务器时，就在唯一主路由和受管交换机或 AP 上正确划分 VLAN、子网与防火墙区域，让所有跨网段流量必然经过明确的三层边界。需要真正冗余时，再部署具备健康检查和路由收敛能力的主备网关。安全靠不可绕过的边界，可靠靠可验证的切换，不靠在同一个 LAN 里多摆一台会 NAT 的盒子。
需要分流时，则正确配置好 OpenClash 的绕过功能，并拆分直连和非直连规则。在 OpenWrt 自身网络与绕过规则正常的前提下，即使代理服务器临时不可用或 OpenClash 停止工作，也不影响绕过区域（例如中国大陆）的直连访问与家人日常使用。
Important
对于家宽环境而言，无明确收益地增加软硬件复杂度，通常只会增加故障点和维护成本，并降低可靠性。
如果目标只是反复刷机和尝试不同配置，而不是构建稳定网络，则本文不适用。
如果确实无法修改主路由，在各设备上分别安装 Clash 客户端，也比增加旁路由更合适。
如果只是希望少数设备使用代理，就只让这些设备使用明确的应用代理、系统代理或客户端；如果希望所有设备统一受控，就应取得网关控制权并把 OpenWrt 放到真正的主路由位置。不要把「我不能改主路由」偷换成「同网段旁挂网关在技术上是正确的」，妥协方案仍然是妥协方案。
如果还需要运行 Docker，可以将原旁路由设备改装为 Debian 或 Armbian，专门运行 Docker，不再作为旁路由。
如果设备不支持 Debian 或 Armbian，请参见第 9 节的最后两段。
Caution
根据维护者处理 Issue 的经验，旁路由相关疑难问题常见于路径不对称、NAT 套娃、IPv6 绕行、DNS 状态错位和来源地址丢失。这些都是此类拓扑反复引发的典型故障。
项目维护者部署的所有设备均采用主路由，以尽量简化网络环境。因此，任何旁路由设置问题均不提供解答，相关 Issue 将直接关闭。