OpenWrt 旁路由跑 mihomo：透明网关与 DNS 重定向一口气步设置

先确认：你要的是「旁路由网关」，不是「主路由刷机」 要点速览

本篇正文出厂你已在 OpenWrt 上能持续持续持续运行 mihomo（通过 OpenClash、ShellCrash、自编译 ipk 或人工二进制均可），关键点放在网络拓扑、网关与 DHCP、防火墙透明重定向、DNS 劫持四块；

旁路由普遍接法是：光猫或主路由的 LAN 口出一根线，接到 OpenWrt 的 WAN 口（或单臂复用同一交换机 VLAN），OpenWrt 拿到主路由网段里的一个地址，举个小例子 192.168.1.2；拨号与 Wi‑Fi 主控仍由主路由完成。

你希望的是：家里手机、电脑、电视不用单独填 HTTP 代理，只要把出厂网关和 DNS 服务器改成旁路由地址，流量就会进 mihomo（Clash Meta 系内核）做规则分流。这与「在 Windows 上开系统代理」或「手机填电脑 IP 端口」不是同一条路径；若你更熟悉后者，可先读 局域网代理与 Allow LAN 排障 对照差异。

mihomo 订阅正文与策略组 YAML 不在此展开，规则与 DNS 模式细枝末节可参考 规则分流指南 与 mihomo Sniffer 排障。

第一口气：固定旁路由 LAN 管理地址，避免与主路由冲突 关键信息

另一做法是旁路由采用不同网段的 LAN（举个小例子 192.168.2.1），主路由加静态路由把 192.168.2.0/24 指到旁路由 WAN——两种都能做透明代理，但 DHCP 设置项与「网关到底填谁」要与你选的方案一致，混用会导致一半设备上不了网。

关键点是：若旁路由的 LAN 网段与主路由相同（举个小例子都是 192.168.1.0/24），普遍做法是：旁路由 WAN 从主路由 DHCP 拿地址，旁路由 LAN 关闭 DHCP 或仅作管理口，客户端网关填旁路由的 WAN 侧地址（即主路由网段里的那个 IP）。

无论哪种接法，请把旁路由在主路由网段内的地址设为静态绑定（主路由 DHCP 静态租约），避免旁路由 WAN 地址变化后全屋设备网关失效。记下这个地址，下文记为 BYPASS_IP。

第二步：让全屋设备把网关和 DNS 指到旁路由 关键点梳理

实操二选一：（A）主路由继续发 DHCP，在 DHCP 里把出厂网关（option 3）和 DNS（option 6）改成 BYPASS_IP；（B）关掉主路由 DHCP，只在旁路由上对 LAN 开 DHCP，下发的网关与 DNS 均为旁路由自身接口地址。

全屋代理的本质是：终端发出的非本网段 IP 流量先发到出厂网关；你把出厂网关从主路由改成 BYPASS_IP 后，这些包会先到旁路由，再由旁路由上的 mihomo 决定是否转发到上游节点。

仅改网关、不改 DNS，经常会出现「网页时好时坏、流媒体地区错乱」——因为部分系统或应用仍向运营商 DNS 发查询，被污染后拿到的 IP 与代理出口不一致。

这里要多说一句：家用环境若设备较多，推荐（A），动主路由一处即可。改完后在终端上执行 ip route 或查看网络详情，确认出厂路由下一跳已是 BYPASS_IP，DNS 也为同一地址。

第三步：在 mihomo 启用透明代理与 DNS 入站 完备说明

同时开启 DNS 监听（举个小例子 listen: 0.0.0.0:53 或内核文档中的等价写法），并设置 enhanced-mode 为 fake-ip 或 redir-host 之一——与桌面端一样，fake-ip 对分流更友好，但要求各个 DNS 查询都经过 mihomo，否则会出现「解析结果与内核会话不匹配」的怪困扰。若你刚入门旁路由，可先采用 redir-host 减少联调难度，再按 TUN 与全局代理文 中的 DNS 思路逐步切到 fake-ip。

mihomo 要在配置中启用透明代理监听（普遍字段为 tproxy-port 或 redir-port，视你采用的防火墙方案为 TPROXY 还是 REDIRECT）。

确认 mihomo 进程监听在 0.0.0.0 而非仅 127.0.0.1，否则防火墙把包重定向过来后仍无人接收。改配置后重启服务，在 OpenWrt 上用 netstat 或 ss -lntup 核对端口已处于 LISTEN。

第四步：OpenWrt 防火墙——透明重定向与「排除自行」 要点速览

UDP 游戏、语音与部分 QUIC 依赖 TPROXY 或对路放行；若只做了 TCP REDIRECT，会出现「网页能开、游戏掉线」的现象。

换个说法：透明代理依赖 nftables/iptables 规则：对来自 LAN 的 TCP做 REDIRECT 到 mihomo 的 redir 端口，或对 TCP/UDP 采用 TPROXY 把会话交给用户态。

具体命令因固件与 mihomo 封装而异（OpenClash 常自带一键；手写时需区分 PREROUTING 链与接口名 br-lan、eth0）。通用原则是：

匹配源为内网网段、目标为公网地址的流量（可排除 RFC1918 私网目的，避免打环）；排除旁路由本机发往 mihomo 上游、NTP、主路由管理UI UI 界面的流量，否则规则再次把本机发出的包重定向进自身，会造成 CPU 飙高或间歇断网；若主路由与旁路由同网段双 DHCP，当心不要把主路由管理流量误导向代理端口。

落到实处：完成规则后，从 LAN 客户端 traceroute 第一跳应为 BYPASS_IP，第二跳再出到运营商或代理节点侧，具体取决于 mihomo 出站方式。

第五步：DNS 重定向（端口 53）——防污染与分流一致 关键信息

若采用 DoH/DoT 直连（客户端绕过 53），单靠 53 劫持覆盖不全，要配合 mihomo 内的 sniff 与规则或采用全局 TUN 类方案；

DNS 重定向的做法是：在旁路由上拦截目的端口为 53 的 UDP/TCP（无论客户端填的是哪个「公共 DNS」），全部转到 mihomo 的 DNS 入站。

这样手机 App 内置的 8.8.8.8 也会被拉回内核解析路径，避免「代理走新加坡、解析走本地」导致的鉴权无法完成。当心放行或直通内网域名与路由器 hostname，否则访问到到主路由后台或许被疏漏劫持。

旁路由采用使用场景下多数家用设备仍以 UDP 53 为主，先把 53 劫持做稳，再观察异常 App。劫持规则变更后，不妨在客户端执行 ipconfig /flushdns 或开关飞行模式清空缓存。

第六步：验证顺序——先 DNS，再 TCP，再 UDP 关键点梳理

1. 客户端网关与 DNS 均为 BYPASS_IP，能 ping 通主路由与互联网 IP（如 1.1.1.1）。
2. 在客户端用 nslookup example.com BYPASS_IP 或等价工具，确认应答来自 mihomo（可对照日志中的查询记录）。
3. 浏览器访问到到纯 IP 或已知域名，查看 mihomo 连接日志是否出现对应会话与策略命中。
4. 最后测游戏/视频等 UDP 密集采用使用场景，必要时针对 QUIC 调整规则或 TPROXY。

普遍坑：回环、双 NAT、与主路由 UPnP 完备说明

旁路由再做一次 NAT 时，部分 P2P 与游戏联机或许受限，这是拓扑代价而非 mihomo 单点故障。若出现「只有旁路由本机通、LAN 不通」，第一顺位查防火墙转发（forward）区域是否允许 WAN→mihomo 与 LAN→WAN；

别忽略了：OpenWrt 防火墙区域接错时，透明规则会在疏漏链上不生效。另一个高频困扰是客户端仍保留手工 IPv6 DNS，导致部分解析绕开旁路由；可在 LAN 侧暂时关闭 IPv6 或同步下发 IPv6 DNS，便于先缩小变量。

小结 要点速览

把旁路由当作专用网关维护好后，日常换订阅或改策略关键点在 mihomo 一侧完成，局域网设备无需逐台配置代理端口。

OpenWrt 旁路由跑 mihomo 做全屋代理，关键是三件事：出厂网关指向旁路由、DNS 重定向把 53 统一进内核、透明代理把 TCP/UDP 会话交给 mihomo 入站；

三者缺一就容易表现为「能连 Wi‑Fi 但网页随机无法完成」或「分流规则永远不命中」。与在单台电脑上采用图形客户端相比，路由器侧更考验网络基础；若你还要在 PC 或 Mac 上单独调试规则，可通过本站 下载页 获取各平台客户端做对照实验。

相比泛泛了解 Clash UI UI 界面，按本篇正文顺序固定拓扑与 DNS，排障会快得多。→ 立即免费下载 Clash，开启流畅上网新上手感觉