2026-09-09 平台部署预计阅读 12 分钟

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

概述在路由器或旁路由上直接运行 mihomo 内核的整体结构,包括架构选择、配置文件存放、TProxy 与 Redir 的区别,以及网关指向。

旁路由结构：先确认流量经过哪里

在 OpenWrt 上运行 mihomo，需要分别处理内核进程、流量接管和 DNS。内核读取 config.yaml，根据 rules 选择出站；Linux 路由与防火墙决定哪些数据包进入内核；DNS 决定终端如何获得地址，以及域名信息能否参与分流。启动进程只完成其中一部分，不等于局域网已经启用透明代理。

本文采用单网口、同网段旁路由作为说明环境。以下地址仅用于解释拓扑，部署时应换成实际网络地址，并确认没有地址冲突。

设备	示例地址	职责
主路由	`192.168.10.1/24`	连接运营商网络，保留 DHCP 服务
OpenWrt 旁路由	`192.168.10.2/24`	运行 mihomo，处理转发与 DNS
测试电脑	`192.168.10.100/24`	先单独验证，不立即修改全网配置

测试电脑的 IPv4 默认网关指向 192.168.10.2，旁路由的默认路由仍指向主路由 192.168.10.1。两者不能相互指向而形成循环。旁路由必须开启 IPv4 转发，并允许相应接口或防火墙区域之间的转发；这与放行发往旁路由本机的输入端口是两件事。

内核架构与配置目录

确认 CPU、系统与运行环境

先通过 SSH 查看系统信息，再选择对应的 Linux 内核构建。x86_64 通常对应 amd64，aarch64 通常对应 arm64；32 位 ARM 还要核对指令集与浮点 ABI。不能仅凭路由器商品名称判断，也不要把 OpenWrt 软件包架构名直接当成内核发布文件名。

uname -m
ubus call system board
cat /etc/openwrt_release
df -h /overlay /tmp
free -m

选择 amd64 构建时，还要留意发布说明中的 CPU 指令集要求。启动出现 Illegal instruction，应检查是否选了高于设备能力的构建；出现 Exec format error，先排查架构和文件类型。若是 Permission denied，再检查执行权限与挂载选项，不应直接归因于订阅内容。

持久化文件与临时日志分开存放

独立部署可以约定内核位于 /usr/bin/mihomo，配置目录位于 /etc/mihomo，主配置为 /etc/mihomo/config.yaml。这些是本文采用的路径，不是所有 OpenWrt 管理插件的默认位置。若已有管理插件，应由同一管理入口维护进程和防火墙，避免再启动第二个实例。

/etc/mihomo/config.yaml：保存主配置。内含订阅地址或凭据时，限制读取权限。
/etc/mihomo/providers/：可存放配置中引用的 provider 文件，具体相对路径由相应字段指定。
/tmp/：适合临时诊断文件，重启后通常不会保留，不适合存放唯一配置副本。
规则集与地理数据：按实际配置准备。先检查闪存与内存，不要默认启用全部数据源。

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

以上命令假定内核和配置已放到对应路径。-t 用于检查配置，不能证明节点可达或防火墙接管正确。通过后可前台运行，观察启动日志；需要后台常驻时，再用 OpenWrt 的 procd 服务管理进程，不要依赖 SSH 会话中的临时后台任务。

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

先验证 mixed-port，再接入透明代理

建议先让一台测试电脑显式使用代理，排除订阅、出站和规则问题。以下是可用于监听检查的基础配置：它不包含代理节点，末尾规则全部直连，只用于确认进程、端口和请求链路。要验证代理出站，应使用自己的有效配置，并检查 proxies、proxy-providers、proxy-groups 与 rules 的名称引用。

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

rules:
  - MATCH,DIRECT

mixed-port: 7890 提供 HTTP 与 SOCKS 代理入口。allow-lan: true 允许其他设备连接，bind-address 限定监听地址；该地址必须已经配置在旁路由上。还需在 OpenWrt 防火墙中仅对可信 LAN 放行 TCP 7890，不要对 WAN 开放代理端口。

测试电脑可执行下列请求。基础配置下它应直连成功；换成有效节点与规则后，再结合 mihomo 日志确认实际出站。单次 HTTP 成功不能证明 UDP、DNS 或全网透明代理已经正常。

curl -I --proxy http://192.168.10.2:7890 https://example.com/

若此处失败，先检查监听地址、防火墙输入规则和内核日志，不必急着调整 TProxy。若电脑显式代理正常，而改网关后失败，问题范围才转向转发、防火墙接管、策略路由与 DNS。

Redir、TProxy 与 TUN 的区别

接入方式	mihomo 字段	主要适用范围	系统侧配套
Redir	`redir-port: 7892`	Linux 上的 TCP 透明重定向	防火墙 REDIRECT 规则与流量排除
TProxy	`tproxy-port: 7893`	Linux 上的 TCP、UDP 透明代理	TPROXY 规则、数据包标记与策略路由
TUN	`tun.enable: true`	通过虚拟网络接口接收 IP 流量	TUN 支持、路由与防火墙配合

Redir：端口监听不等于完成接管

redir-port 是透明代理入口，不是让应用填写的 HTTP 代理端口。Linux 上的 Redir 常用于 TCP，不能据此宣称 UDP 已被代理。只部署 TCP 重定向时，QUIC、游戏或语音的 UDP 流量可能直连或失败，具体取决于剩余防火墙规则。

TProxy：需要策略路由把包交给本机

TProxy 可以处理 TCP 与 UDP，并保留原始目标信息。部署时需要将选定流量标记，再通过 ip rule 和对应路由表将其交给本机透明监听。只有 tproxy-port: 7893 而没有这些系统规则，终端流量不会自动进入 mihomo。

防火墙还必须排除局域网、广播、多播、必要的本机服务与内核自身的出站连接，防止循环代理。标记值和路由表编号需要避开系统中已有的 VPN、分流或多拨规则；不能从另一台设备照抄一组数字就认为一定可用。

TUN：另一条接管路径，不是叠加开关

TUN 依赖系统提供可用的 TUN 设备与相应权限。tun.auto-route 用于自动配置路由，tun.auto-redirect 在支持的 Linux 环境中还会涉及防火墙接管。它们不应与管理插件现有的透明代理规则盲目叠加。旁路由应先选定一套主要接管方案，再按该方案处理排除规则与回滚。

DNS 转发：dnsmasq 与 mihomo 各监听一个端口

OpenWrt 常由 dnsmasq 对 LAN 提供 53 端口 DNS 服务。若 mihomo 也绑定同一地址的 53 端口，会发生冲突。一种便于检查的结构是：终端查询旁路由 53 端口，dnsmasq 再把请求转发到本机 mihomo 的 1053 端口。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

这段配置用于说明本机转发关系，列出的上游是普通 DNS，并不保证在所有网络中适用。dnsmasq 的上游可指向 127.0.0.1#1053；还应检查是否继续读取其他上游，避免请求绕开预期路径。不要再让 mihomo 的上游指回 dnsmasq 的 53 端口，否则会构成解析循环。

redir-host 与 fake-ip 需要匹配接管方式

redir-host 向终端返回真实地址；fake-ip 则返回映射地址，并由内核在接管连接时恢复域名关联。使用 fake-ip 时，获得映射地址的终端必须能够把后续连接交回 mihomo。若 DNS 已切换而透明接管尚未完成，可能出现“域名能解析，但连接全部失败”。

先以单个终端验证 DNS 链路，确认日志中有对应查询，再扩大范围。
若使用带域名的加密 DNS 上游，还需按配置处理上游域名的引导解析。
终端的私有 DNS、浏览器安全 DNS 可能绕过 DHCP 下发的服务器，需分别核对。
修改 DNS 或 fake-ip 模式后，清理测试终端的 DNS 缓存并重建连接，避免旧结果干扰判断。

网关指向、回程路径与 IPv6

先改单台终端，再调整 DHCP

在 LuCI 的「网络」→「接口」中确认旁路由 LAN 地址为 192.168.10.2，其 IPv4 网关为 192.168.10.1。界面字段可能随版本或管理插件变化，最终以接口地址与路由表为准。测试电脑先手动设置网关和 DNS 为旁路由地址，验证完成后再考虑全网下发。

若主路由仍负责 DHCP，可由主路由下发选项 3 为 192.168.10.2、选项 6 为 192.168.10.2。它们分别表示 IPv4 网关和 DNS 服务器。不要在同一广播域同时启动两个未经规划的 DHCP 服务；修改后还需让终端续租，已有租约不会立即全部更新。

同网段回程不一定经过旁路由

在单臂旁路由结构中，直连流量从旁路由送往主路由后，主路由可能直接把回包交给终端，形成非对称路径。部分部署会在旁路由到主路由方向使用源地址转换，使回包返回旁路由，但这也会隐藏终端源地址。是否需要 SNAT 或 masquerade，取决于拓扑、状态跟踪与接管方案，不能统一要求“全部开启”。

同网段转发还应留意 ICMP Redirect：终端可能收到更直接路径的提示，改变后续走向。若出现首次经过旁路由、随后绕过的情况，应连同终端路由缓存和旁路由相关内核参数一起检查。

IPv4 网关设置不会接管 IPv6

主路由通过 RA 下发的 IPv6 默认路由可能仍然有效。即使配置中写了 ipv6: false，也不等于关闭整个局域网的 IPv6。需要代理 IPv6 时，应单独设计 IPv6 路由、防火墙与 DNS；暂未部署时，可先在测试终端控制 IPv6 使用范围，分别验证 IPv4、IPv6，避免把绕行误判为规则失效。

验证顺序与回滚检查

排障按“本机、显式代理、单终端透明代理、全网下发”的顺序进行。每次只改一层，并记录修改前的网关、DNS 和防火墙状态。管理界面可以打开，只能证明到旁路由的本地连接可达，不能证明公网转发正常。

查进程与配置。执行 mihomo -t，前台观察启动错误；确认没有第二个实例占用 7890、7892、7893 或 1053。
查旁路由自身联网。执行 ip -4 route，核对默认下一跳；确认时间与 DNS 可用，避免 HTTPS 请求因系统时间异常失败。
查显式代理。使用前述 curl --proxy 请求，查看日志中的规则与实际出站，而不只看页面是否打开。
查透明接管。测试终端关闭显式代理，设置旁路由网关；检查 ip rule show、ip route show table all 与防火墙规则计数。
查 DNS 和协议范围。执行 nslookup example.com 192.168.10.2；TCP 成功后再测试所需 UDP 应用，最后单独测试 IPv6。

进入常驻阶段后，用 procd 管理自动启动、异常退出与日志，并确认依赖的网络和文件已就绪。规则更新、provider 拉取和订阅下载都可能产生额外网络请求，应确认这些请求不会再次被错误接管。有限闪存设备避免长期保存高频调试日志。

旁路由部署的验收目标不是单个开关显示“运行中”，而是网关指向、DNS 转发、透明入口与出站规则能够逐层对应。需要查询配置字段时，可查看配置参考；需要先在电脑上验证同一份订阅时，可从客户端开始，确认配置有效后再迁移到 OpenWrt。