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

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

旁路由常见接法是：光猫或主路由的 LAN 口出一根线，接到 OpenWrt 的 WAN 口（或单臂复用同一交换机 VLAN），OpenWrt 拿到主路由网段里的一个地址，例如 192.168.1.2；拨号与 Wi‑Fi 主控仍由主路由完成。你希望的是：家里手机、电脑、电视不用单独填 HTTP 代理，只要把默认网关和 DNS 服务器改成旁路由地址，流量就会进 mihomo（Clash Meta 系内核）做规则分流。这与「在 Windows 上开系统代理」或「手机填电脑 IP 端口」不是同一条路径；若你更熟悉后者，可先读 局域网代理与 Allow LAN 排障 对照差异。

本文默认你已在 OpenWrt 上能运行 mihomo（通过 OpenClash、ShellCrash、自编译 ipk 或手动二进制均可），重点放在网络拓扑、网关与 DHCP、防火墙透明重定向、DNS 劫持四块；mihomo 订阅内容与策略组 YAML 不在此展开，规则与 DNS 模式细节可参考 规则分流指南 与 mihomo Sniffer 排障。

第一步：固定旁路由 LAN 管理地址，避免与主路由冲突

若旁路由的 LAN 网段与主路由相同（例如都是 192.168.1.0/24），常见做法是：旁路由 WAN 从主路由 DHCP 拿地址，旁路由 LAN 关闭 DHCP 或仅作管理口，客户端网关填旁路由的 WAN 侧地址（即主路由网段里的那个 IP）。另一做法是旁路由使用不同网段的 LAN（例如 192.168.2.1），主路由加静态路由把 192.168.2.0/24 指到旁路由 WAN——两种都能做透明代理，但 DHCP 选项与「网关到底填谁」要与你选的方案一致，混用会导致一半设备上不了网。

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

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

全屋代理的本质是：终端发出的非本网段 IP 流量先发到默认网关；你把默认网关从主路由改成 BYPASS_IP 后，这些包会先到旁路由，再由旁路由上的 mihomo 决定是否转发到上游节点。仅改网关、不改 DNS，往往会出现「网页时好时坏、流媒体地区错乱」——因为部分系统或应用仍向运营商 DNS 发查询，被污染后拿到的 IP 与代理出口不一致。

实操二选一：（A）主路由继续发 DHCP，在 DHCP 里把默认网关（option 3）和 DNS（option 6）改成 BYPASS_IP；（B）关掉主路由 DHCP，只在旁路由上对 LAN 开 DHCP，下发的网关与 DNS 均为旁路由自身接口地址。家用环境若设备较多，推荐（A），动主路由一处即可。改完后在终端上执行 ip route 或查看网络详情，确认默认路由下一跳已是 BYPASS_IP，DNS 也为同一地址。

第三步：在 mihomo 打开透明代理与 DNS 入站

mihomo 需要在配置中启用透明代理监听（常见字段为 tproxy-port 或 redir-port，视你使用的防火墙方案为 TPROXY 还是 REDIRECT）。同时开启 DNS 监听（例如 listen: 0.0.0.0:53 或内核文档中的等价写法），并设置 enhanced-mode 为 fake-ip 或 redir-host 之一——与桌面端一样，fake-ip 对分流更友好，但要求所有 DNS 查询都经过 mihomo，否则会出现「解析结果与内核会话不匹配」的怪问题。若你刚入门旁路由，可先采用 redir-host 降低联调难度，再按 TUN 与全局代理文 中的 DNS 思路逐步切到 fake-ip。

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

第四步：OpenWrt 防火墙——透明重定向与「排除自己」

透明代理依赖 nftables/iptables 规则：对来自 LAN 的 TCP做 REDIRECT 到 mihomo 的 redir 端口，或对 TCP/UDP 使用 TPROXY 把会话交给用户态。具体命令因固件与 mihomo 封装而异（OpenClash 常自带一键；手写时需区分 PREROUTING 链与接口名 br-lan、eth0）。通用原则是：

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

UDP 游戏、语音与部分 QUIC 依赖 TPROXY 或正确放行；若只做了 TCP REDIRECT，会出现「网页能开、游戏掉线」的现象。完成规则后，从 LAN 客户端 traceroute 第一跳应为 BYPASS_IP，第二跳再出到运营商或代理节点侧，具体取决于 mihomo 出站方式。

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

DNS 重定向的做法是：在旁路由上拦截目的端口为 53 的 UDP/TCP（无论客户端填的是哪个「公共 DNS」），全部转到 mihomo 的 DNS 入站。这样手机 App 内置的 8.8.8.8 也会被拉回内核解析路径，避免「代理走新加坡、解析走本地」导致的鉴权失败。注意放行或直通内网域名与路由器 hostname，否则访问主路由后台可能被错误劫持。

若使用 DoH/DoT 直连（客户端绕过 53），单靠 53 劫持覆盖不全，需要配合 mihomo 内的 sniff 与规则或采用全局 TUN 类方案；旁路由场景下多数家用设备仍以 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，便于先缩小变量。

小结

OpenWrt 旁路由跑 mihomo 做全屋代理，关键是三件事：默认网关指向旁路由、DNS 重定向把 53 统一进内核、透明代理把 TCP/UDP 会话交给 mihomo 入站；三者缺一就容易表现为「能连 Wi‑Fi 但网页随机失败」或「分流规则永远不命中」。与在单台电脑上使用图形客户端相比，路由器侧更考验网络基础；若你还需要在 PC 或 Mac 上单独调试规则，可通过本站 下载页 获取各平台客户端做对照实验。

把旁路由当作专用网关维护好后，日常换订阅或改策略主要在 mihomo 一侧完成，局域网设备无需逐台配置代理端口。相比泛泛了解 Clash 界面，按本文顺序固定拓扑与 DNS，排障会快得多。→ 立即免费下载 Clash，开启流畅上网新体验