很多家庭里已经有一台主路由负责拨号或从光猫接出，再额外买一台软路由刷 OpenWrt，希望把 Clash 跑在路由器这一侧：手机、平板、电脑不用每台单独装客户端，却仍能按同一套订阅与规则做国内外分流。这与在 Linux 服务器或本机用命令行开 TUN 是两条路径——前者解决的是局域网统一出口与网关透明代理问题。若你尚未熟悉 Meta 系配置的骨架，可先阅读站内的 Clash Meta 2026 最全配置指南，再回来把同一套逻辑落到旁路由上。
一、旁路由在解决什么问题？
旁路由通常指不接 WAN 拨号、而是挂在主路由 LAN 下的一台 OpenWrt 设备：它有自己的管理地址（如 192.168.1.2），对内提供网关与DNS服务，对外仍经主路由转发。主路由继续负责 DHCP、端口映射或家长控制时，旁路由只专注一件事——把需要代理的流量交给 Clash Meta（Mihomo） 处理。
这样做的直接好处是策略集中：换节点、改规则、更新 GEOIP / RULE-SET，只动旁路由一处；家人设备只需把「默认网关」和「DNS」指到旁路由 IP，无需学习应用内开关。与 Linux 本机 TUN 教程相比，旁路由面向的是多终端、无代理感知能力的场景（游戏机、电视盒子、访客 Wi‑Fi），因此更强调透明转发与防 DNS 旁路，而不是单个 shell 里的环境变量。
二、拓扑与地址规划：避免「环路」与双 DHCP 冲突
部署前务必画清三层关系：光猫 → 主路由 →（交换机可选）→ 旁路由与终端。常见稳妥做法是：主路由继续开 DHCP，默认下发网关为主路由自己；仅对需要代理的设备，手动或按 MAC 绑定，把网关改为旁路由 IP。另一种做法是关掉主路由 DHCP，完全由旁路由 DHCP——这要求你对 OpenWrt 的接口与防火墙更熟，且主路由管理地址不要与旁路由网段冲突。
旁路由的 LAN 口应和主路由同一网段（例如都在 192.168.1.0/24），旁路由自身不要用 WAN 口去接主路由当「二级路由」除非你知道如何做静态路由与 NAT；多数教程推荐的「单臂」接法是：旁路由仅一个 LAN 参与转发，关闭不必要的 WAN 接口，避免产生双 NAT 或回程路由缺失。若出现「能打开国内站、海外全挂」或「仅旁路由本机正常、下游不通」，优先检查网关是否指回主路由、旁路由是否允许转发、以及防火墙区域是否放行 LAN→WAN 转发。
三、在 OpenWrt 上运行 Clash Meta：插件与内核选择
OpenWrt 上跑 Clash 常见有三类路径：集成图形界面的插件（如 OpenClash 等社区方案）、一键脚本部署、或手动放置 Mihomo 二进制配合 init.d / procd 自启。本文不绑定某一插件版本号——不同固件与架构（x86、ARM）包名各异——但内核层在 2026 年仍建议以兼容 Clash Meta 的 Mihomo为主，以便使用 TUN、RULE-SET、嗅探等能力。
安装完成后，请确认：配置文件路径、日志位置、以及 Web 界面里是否能看到「运行中 / 已停止」状态。订阅导入后，先在旁路由本机用 curl 或浏览器插件测一遍节点，再切到下游设备验证——这样可以把问题限定在「内核 / 规则」还是「转发 / DNS」层。需要对比桌面端与路由器端体验差异时，可参考 2026 Clash 客户端横评，但路由器侧的核心仍是同一套 YAML 语义。
四、透明代理：TUN 与 REDIRECT 两条主线
透明代理的含义是：终端不配置 HTTP/SOCKS 代理地址，访问公网时仍按默认路由走网关，由网关把符合条件的连接截获并交给 Clash。在 Meta 系内核里，常见实现是TUN 虚拟网卡配合 auto-route，或iptables / nftables 的 REDIRECT / TPROXY 配合 redir-port。家庭旁路由场景下，TUN往往更直观：内核把流量导入 Mihomo，再由规则决定直连或走节点。
一段仅作结构说明的示例（实际键名与默认值请按你所用内核版本文档调整）：
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
mode: rule务必保持 mode: rule，让国内流量按 GEOIP / GEOSITE 或自建 RULE-SET 直连，否则全家带宽会被无谓地绕路。规则写法与优先级若需系统梳理，可对照 Clash 代理规则深度解析 中的 DOMAIN-SUFFIX、IP-CIDR 与 RULE-SET 章节。
4.1 DNS：透明代理的「另一半」
仅转发 TCP 连接而不接管 DNS，很容易出现「解析走了本地运营商、连接却走了代理」的异常分流或泄漏。旁路由作为网关时，应在 OpenWrt 的 DHCP / DNS 选项中，把分配给客户端的 DNS设为旁路由自身（或内网 DNS 再转发到 Mihomo 监听端口），并在 Mihomo 中开启 fake-ip 或你信任的 redir-host / mixed 方案，使域名解析与连接决策同源。
若仍使用主路由做 DNS 转发，要确保海外域名不会被抢答污染；否则 Clash 侧看到的可能已是错误 IP，规则再精准也无济于事。
五、局域网设备如何「走旁路由」：网关与分流粒度
让全家设备统一走策略，本质是两层设置：IP 层默认网关指向旁路由；DNS 指向旁路由或经旁路由转发的解析服务。手机可在 Wi‑Fi 详情里改「静态 IP」；电脑可改网卡 IPv4；游戏机与电视若不能改网关，可考虑主路由策略路由或单独 SSID 绑定不同 DHCP 选项——具体取决于主路由固件能力。
分流粒度可以只在 Clash 里完成：例如国内视频直连、海外服务走代理、局域网与内网网段直连。若你希望部分设备完全不经过 Clash，不必在 Clash 里写复杂规则，只需让这些设备的网关仍为主路由，仅「需要代理的设备」指到旁路由——这是家庭环境里最易维护的物理分流与逻辑分流组合。
六、验证清单与常见故障
建议按顺序自检：（1）旁路由本机能否访问订阅与节点；（2）下游 ping 旁路由与主路由是否均正常；（3）在下游访问国内与海外站点，观察延迟与 IP；（4）用浏览器或命令行查看 DNS 解析是否经旁路由。若仅海外异常，优先查规则与 DNS；若全网不通，优先查网关与 NAT。
环路多见于旁路由错误地把默认网关设成自己，或主路由与旁路由互相指对方；双 DHCP 会导致地址冲突；硬件 NAT 旁路在少数主路由上会绕过你的策略——必要时在主路由关闭相关加速做对比测试。所有改动前记录原始网关与 DNS，便于一键恢复。
七、结语
把 Clash Meta 放在 OpenWrt 旁路由上，本质是用一台始终在线的小机器，承接网关透明代理与局域网分流策略：它补足了单机客户端与 Linux 本机 TUN 之间的空白，让「全家共用一套规则」成为可维护的现实。相比每台设备各自装软件、各自更新订阅，路由器侧统一出口在长期运维成本上往往更低，也更适合多成员家庭与多类型终端并存的环境。
若你还需要在 Windows、macOS 或手机上保留一套图形化客户端做外出备用，可从本站获取安装包与最新分流资源，与旁路由上的内核配置互为备份，而不必重复造轮子。