2026-08-22 进阶配置预计阅读 12 分钟

旁路由运行 mihomo 内核概览:OpenWrt 部署思路与透明代理要点

不装图形客户端,直接在路由器或旁路由上跑 mihomo 内核,让全屋设备走同一套分流。本文梳理架构选择、TProxy 与 redir 差异和网关设置。

一、先确定旁路由负责哪一段流量

mihomo 是代理内核，不负责自动完成 OpenWrt 的全部网络配置。订阅提供节点和规则，内核负责选择出站；设备流量能否进入内核，仍由默认网关、路由表、防火墙和 DNS 链路共同决定。只把 YAML 放到路由器上运行，不等于局域网设备已经接入透明代理。

本文采用一个明确的 IPv4 示例：主路由为 192.168.10.1/24，负责宽带拨号和 DHCP；旁路由为 192.168.10.2/24，默认网关指向主路由；测试电脑为 192.168.10.100/24。这些地址仅用于说明，实际部署前必须替换为当前网络地址，并检查是否与 DHCP 地址池冲突。

接入方式	流量入口	适用场景
显式代理	应用手动连接旁路由的 7890 端口	先验证节点、订阅与规则
单臂旁路由	终端默认网关改为 192.168.10.2	少量设备逐步接入
双网口下级路由	终端进入独立下游网段	需要清晰的转发边界
主路由策略引流	主路由按源地址或策略转发	需要集中管理接入设备

二、OpenWrt 部署前的检查

确认系统架构与防火墙后端

在 SSH 中记录系统版本、CPU 架构和可用存储。OpenWrt 22.03 起默认使用 firewall4 与 nftables，但升级、定制固件或第三方插件可能改变实际环境。不要把旧版 iptables 规则直接粘贴到 nftables 环境，也不要同时运行两套接管相同流量的透明代理插件。

ubus call system board
uname -m
df -h /overlay
free -m
command -v fw4
command -v nft
ip route show
ip -6 route show

uname -m 输出只能帮助识别架构，仍需根据设备 CPU 特性选择 mihomo 构建。某些旧设备不支持较新的指令集。出现启动即退出或非法指令错误时，应先核对二进制构建，而不是反复修改订阅。

区分内核、配置与服务管理

建议把可执行文件、工作目录和服务脚本分开管理。例如将内核放在 /usr/bin/mihomo，配置放在 /etc/mihomo/config.yaml，运行状态交给 OpenWrt 的 procd 服务管理。下面路径是部署约定，不代表系统已预装相关文件。

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

第二条命令检查配置是否可以加载，并非完整的联网测试。使用规则集、GeoIP 或 GeoSite 数据的配置还需要对应资源；检查外部资源能否下载、目录是否可写，以及首次启动是否依赖尚未建立的代理连接。服务脚本应设置启动顺序、异常重启和日志输出，避免 SSH 会话结束后进程随之退出。

三、先用显式代理验证订阅和规则

部署顺序应当是“内核运行 → 显式代理可用 → DNS 可用 → 透明接管”。这样可以把节点不可用与路由配置错误分开。下面片段只是连通性基线，没有代理节点，最后一条规则全部直连；它不能替代订阅，也不能用于判断代理出口是否可用。

mixed-port: 7890
allow-lan: true
bind-address: 192.168.10.2
mode: rule
log-level: info
ipv6: false

rules:
  - MATCH,DIRECT

把片段合并到实际配置时，同一顶层字段只能保留一份。启用局域网监听后，应在 OpenWrt 防火墙中仅允许可信 LAN 访问 7890，不要向 WAN 开放，也不要配置公网端口转发。监听地址必须是旁路由实际拥有的地址。

先在测试电脑中把 HTTP 代理设为 192.168.10.2:7890，确认请求能到达内核。
再加载有效的 Clash 格式订阅，确认代理组包含可用节点，并选中目标节点。
观察连接记录中的命中规则和出站。规则模式的结果取决于规则顺序，不取决于代理组名称是否含有“自动”字样。
关闭电脑端显式代理，再进入透明代理测试，避免两种入口叠加造成误判。

在装有 curl 的测试电脑上，可以执行 curl -I --proxy http://192.168.10.2:7890 https://example.com。该命令用于验证 HTTP 代理请求链路；要确认是否经过节点，还需结合所命中的规则、出站记录及可信的出口查询结果。

四、TProxy、redir 与 TUN 的边界

方式	主要能力	必须配套的系统设置
`redir-port`	接收重定向后的 TCP 连接	NAT 重定向、地址排除与回环排除
`tproxy-port`	接收透明代理的 TCP、UDP 流量	TPROXY 规则、标记和策略路由
`tun`	通过虚拟网络接口接收 IP 流量	TUN 支持、路由接管与防火墙转发

redir 主要处理 TCP

配置 redir-port: 7892 只是建立监听端口，还需要防火墙把符合条件的 TCP 流量重定向过去。UDP 不能依靠这一入口完成同样的透明接管。网页能打开但游戏、语音或 QUIC 异常时，应先检查 UDP 的实际路径，而不是直接增大超时时间。

TProxy 需要标记与策略路由配合

tproxy-port: 7893 可作为 TCP 和 UDP 的透明代理入口，但对应内核模块、防火墙规则及路由表必须齐备。系统通过 fwmark 与 ip rule 把被标记的数据包送到本地接收路径。标记值和路由表编号需要避开已有 VPN、多 WAN 与其他插件，不能假定某个固定数字在所有设备上都空闲。

TUN 不等于只开一个开关

mihomo 的 TUN 可结合 auto-route 等字段建立路由，但 OpenWrt 的转发策略、接口识别及 IPv6 路由仍需验证。较新的 mihomo 在 Linux 上还提供 auto-redirect 相关能力，其行为应以所装内核版本的文档为准。不要把不同教程中的自动重定向和手写 TProxy 规则同时启用。

五、网关、回程与防火墙转发

单臂旁路由中，测试电脑的默认网关指向 192.168.10.2，旁路由自己的默认路由仍应指向 192.168.10.1。不要把主路由和旁路由的默认路由相互指向对方。DHCP 仍由主路由提供时，可以先手动修改电脑，验证成功后再通过 DHCP 选项 3 下发网关、选项 6 下发 DNS。

IP 转发：用 sysctl net.ipv4.ip_forward 检查 IPv4 转发状态，正常转发需要值为 1。
防火墙区域：在 LuCI 的「网络」→「防火墙」→「常规设置」检查接口所属区域及转发规则。界面文字会随版本变化，以实际区域和接口绑定为准。
同网段回程：主路由可能直接把返回包交给电脑，形成不对称路径。旁路由上的连接跟踪、过滤规则和统计可能因此与预期不同。
ICMP Redirect：同一接口收发时，系统可能提示终端改走更直接的网关。需要检查旁路由的重定向发送行为以及终端是否接受重定向。

部分单臂方案使用受控的源地址转换，让直连流量的回程重新经过旁路由。代价是上游看到的来源可能统一变为旁路由地址，影响按设备统计和策略。不要把“开启所有区域的地址伪装”当成通用修复；双网口、独立下游网段和不同防火墙策略需要分别设计。

六、DNS：先明确 53 与 1053 的职责

OpenWrt 常由 dnsmasq 监听 53 端口，提供 DHCP 和局域网域名解析。让 mihomo 同时绑定同一地址的 53 端口会产生冲突。较容易排查的结构是：终端查询旁路由的 53，由 dnsmasq 转交给 mihomo 的本地 1053，再由 mihomo 查询上游。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

这只是 DNS 段示例。上游地址必须从当前网络可达，且其连接路径需要与实际代理策略协调。在 LuCI「网络」→「DHCP/DNS」→「常规设置」的 DNS 转发中，可以按当前版本支持的语法设置 127.0.0.1#1053；同时核对 resolv 文件来源，避免 dnsmasq 又把请求送回自身。

fake-ip 返回的是用于连接映射的地址，不是目标网站的真实地址。只有终端随后访问该地址的连接也能被 mihomo 接收，映射才有意义。若 DNS 已经走旁路由、网关却仍指向主路由，可能出现“能够解析，但所有网页超时”的现象。

局域网主机名优先留在 dnsmasq 处理；确有兼容问题时，再按域名配置 fake-ip 排除或域名解析策略。
53 端口重定向只能覆盖匹配到的传统 DNS。浏览器内置 DoH、应用自带加密 DNS 和其他隧道需要单独判断。
仅设置 dns.ipv6: false 不会关闭终端 IPv6，也不会接管 IPv6 流量。终端仍可能通过主路由通告的 IPv6 默认路由直连。

建议先完成 IPv4 验证，再单独规划 IPv6 的 RA、DNS 通告、默认路由与代理路径。需要双栈接管时，应同时验证 AAAA 查询和实际 IPv6 连接，不能只看 IPv4 出口。

七、按层验收与故障定位

每次只调整一个环节，并记录调整前后的结果。下面的检查顺序能区分“流量没到旁路由”“已经到内核但规则不对”和“节点本身失败”。

基础网络：测试电脑能够访问主路由、旁路由管理地址；旁路由默认路由正确，系统时间准确。
显式代理：通过 7890 访问测试站点，检查连接记录、代理组选择与出站错误。
DNS：执行 nslookup example.com 192.168.10.2，确认查询进入预定解析链路；启用 fake-ip 时核对映射结果。
透明接管：关闭应用代理后发起新连接，确认 mihomo 仍能看到连接，并命中预期规则。
UDP 与 IPv6：分别测试需要 UDP 的应用和 IPv6 目标。TCP 成功不能证明另外两条路径成立。
重启恢复：重启旁路由，检查服务启动、DNS 可用性、防火墙规则恢复及节点域名解析。

现象	优先检查
显式代理正常，透明代理没有记录	终端网关、转发链、规则计数及 TUN 路由
能解析域名，连接一直超时	fake-ip 流量是否进入内核、代理回环、节点可达性
网页正常，部分实时应用失败	UDP 入口、节点 UDP 支持、MTU 与防火墙
修改规则后旧连接仍走原出口	关闭测试连接并重新建立，避免复用现有会话
重启后全网无法解析	dnsmasq 上游、mihomo 启动顺序及资源下载依赖

需要抓包时，可在已安装 tcpdump 的设备上用 tcpdump -ni br-lan host 192.168.10.100 观察测试电脑流量；其中 br-lan 必须替换为实际 LAN 接口。日志中包含订阅地址、节点凭据或访问域名时，分享前先移除敏感信息。

八、配置维护与回退

订阅更新、内核升级和防火墙改动应分开进行。把设备专用的 DNS、监听地址、入口端口与路由策略保留在本地管理层，避免远程订阅更新覆盖旁路由设置。若使用覆写或配置合并功能，应检查最终生成的 YAML，而不是只检查原始订阅。

升级前保存当前内核版本、有效配置、服务脚本和防火墙规则；先执行配置测试，再安排服务重启。
主路由 DHCP 的网关与 DNS 修改要记录原值。回退时两项一起恢复，避免网关恢复后仍依赖已停止的 DNS。
控制接口只向必要的管理地址开放，设置访问凭据；订阅文件按敏感配置管理，不放入公开仓库。
故障旁路需要预先设计。终端继续指向已关机的旁路由时，主路由不会自动接替它的网关地址。

旁路由部署的关键是入口、解析和出站三条链路一致。先完成单设备显式代理验证，再选择一种透明接管方案，最后扩大 DHCP 下发范围。需要对照规则模式、订阅导入及客户端操作时，可继续查看Clash 使用教程；字段说明可查阅完整文档。