在 OpenWrt 路由器与旁路由上直跑 mihomo 内核：部署方式概览

部署边界：内核运行、流量接管与设备网关

在 OpenWrt 上启动 mihomo，只代表路由器上有一个代理内核进程。要让手机、电视和电脑经过它，还需要解决入口、路由与 DNS 三件事。配置文件能够加载、控制面板能够打开，都不能单独证明局域网流量已经被接管。

mihomo 延续了 Clash Meta 的配置体系，负责代理协议、规则匹配与连接处理；OpenWrt 负责接口、路由、防火墙和服务管理。LuCI 插件可以把这些操作封装到界面，但插件、内核与订阅配置仍是三个分别更新的对象。

• 显式代理：在设备或应用中填写代理服务器地址及端口，适合先验证配置；不遵循代理设置的应用不会自动进入内核。
• 透明代理：由路由器用防火墙和策略路由接管经过它的流量，终端通常不需要逐个设置 HTTP 代理。
• TUN：内核通过虚拟网络接口处理 IP 流量，仍需要系统路由、防火墙转发和回环排除共同配合。

主路由与旁路由：先确定实际经过的路径

主路由部署

主路由直接承担上网出口，局域网设备的默认网关通常就是它。流量天然经过该设备，透明接管较容易统一，但内核重启、规则重载与 DNS 配置错误的影响范围也更大。保留直连出口与管理地址例外，比一次性接管所有连接更重要。

同网段旁路由部署

下面是一组用于说明拓扑的地址，不是现场实测值：主路由为 192.168.10.1，旁路由为 192.168.10.2，测试电脑为 192.168.10.100/24。旁路由的上游默认路由指向主路由，测试电脑的默认网关则指向旁路由。

旁路由与终端在同一网段时，直连连接的返回流量可能由主路由直接送回终端，形成非对称路径。是否需要源地址转换、如何处理 ICMP 重定向，应结合连接跟踪和实际路由判断；不能把“打开 NAT”作为所有拓扑的固定答案。双网口、独立下游网段的旁路由则更接近普通路由器，路径通常更清晰。

• 只把终端 DNS 改为旁路由，并不等于把业务连接也交给旁路由。
• 通过 DHCP 下发网关和 DNS 时，对应 IPv4 选项通常是 3 和 6；修改后需要客户端续租。
• 同一广播域不要无计划地开启第二个 DHCP 服务器，否则不同设备可能获得不同网关。
• IPv6 默认路由通常由路由通告提供，仅修改 IPv4 网关不会自动覆盖 IPv6 路径。

架构与系统检查：选择能运行的 mihomo 文件

下载前先核对 OpenWrt 版本、CPU 架构与可用存储。OpenWrt 23.05、24.10 的常见官方镜像使用 firewall4 与 nftables；第三方固件可能改动组件，因此要检查实际环境，不要仅凭固件名称选择脚本。

ubus call system board
uname -m
opkg print-architecture
df -h /overlay /tmp
free -m
command -v fw4
command -v nft
test -c /dev/net/tun && echo "TUN device available"

上面的 opkg 命令适用于使用 opkg 的固件；若系统使用其他包管理器，应按该固件说明查询。uname -m 返回的是运行环境架构，不能替代对 CPU 指令集和发布资产说明的检查。

• x86_64：对应 amd64 家族，但不同优化构建可能要求不同 CPU 指令集，老旧软路由应核对资产标注。
• aarch64：通常对应 arm64；若硬件支持 64 位但固件运行在 32 位环境，应以实际系统为准。
• ARM、MIPS：还要核对 ARM 代际、浮点要求，以及 MIPS 大小端，不能只看产品宣传中的芯片系列。
• 空间与内存：内核、规则集和地理数据库都会占空间；/tmp 通常位于内存中，重启后内容不保留。

出现 Exec format error 时先检查架构；出现 Illegal instruction 时核对指令集要求。文件存在却提示无法执行，还可能涉及加载器或权限，不应直接判断为订阅失效。

部署方式：LuCI 插件、独立进程与容器

方式一：由 LuCI 插件统一管理

适合需要订阅更新、开机启动和透明代理规则联动的环境。选择明确支持当前 OpenWrt 防火墙体系及 mihomo 的插件，并阅读对应版本文档。不同插件的菜单、覆写机制与内核更新渠道不一致，不能把一个插件的设置步骤直接套给另一个插件。

插件运行时通常会生成最终配置。如果手动编辑生成文件，下一次订阅更新或服务重启可能覆盖修改。应使用插件提供的持久覆写入口，同时避免再启动第二个独立内核争抢端口。

方式二：独立二进制与 procd 服务

适合希望明确控制运行参数和防火墙规则的用户。下面约定内核路径为 /usr/bin/mihomo，数据目录为 /etc/mihomo；它们是本文示例路径，并非所有插件的默认路径。先放入经过检查的配置，再以前台方式观察错误。

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

-t 用于配置测试，成功后也仍需验证 DNS、出口和转发。前台运行稳定后，再建立 /etc/init.d/ 下的 procd 服务，配置启动命令、标准输出、异常重启和停止清理。不要用反复执行后台命令代替服务管理，否则容易遗留多进程和旧规则。

方式三：容器内运行

容器适合已有容器管理体系的软路由，但会额外引入网络命名空间、数据卷和权限边界。TUN 需要容器能够访问对应设备并获得必要网络管理权限；透明代理还要明确规则究竟安装在宿主机还是容器内。仅映射 7890 端口通常只能提供显式代理，不能自动接管整个局域网。

透明代理与 TUN：选择一套接管规则

透明代理是接管目标，TUN 是实现路径之一。另一类常见实现是 REDIRECT 或 TPROXY：REDIRECT 常用于 TCP 重定向；TPROXY 可用于 TCP、UDP，但依赖策略路由、报文标记与对应内核模块。选择哪种方式，应由插件支持情况、固件组件和拓扑决定。

使用 TUN 前，可在 LuCI 的「系统」→「软件包」核对是否安装与当前内核匹配的 kmod-tun，并检查 /dev/net/tun。模块不能随意跨固件内核版本安装。存在设备文件仅代表具备基础条件，不代表后续路由已配置正确。

• 明确由谁负责路由：如果插件负责生成接管规则，不要再照搬另一份开启自动路由的独立配置。
• 排除内核自身的代理出口连接、路由器管理地址、上游网关和必要局域网网段，避免连接反复进入内核。
• 在 LuCI「网络」→「防火墙」核对区域和转发关系，不要通过全局放行来掩盖规则错误。
• 排查时临时关闭软件或硬件流量卸载后复测；卸载可能改变后续报文经过的处理路径。

DNS 接管：监听端口、上游解析与 Fake-IP

OpenWrt 常由 dnsmasq 提供局域网 DNS。一个容易理解的链路是：终端请求路由器的 53 端口，dnsmasq 再把需要交给内核的请求转发到本机 127.0.0.1:1053。这样可以保留 dnsmasq 的本地主机名处理，但要根据实际配置避免将内核查询再次转发回自己。

下面只展示 mihomo 的 DNS 片段，不是完整可运行的路由器配置。它采用普通上游便于说明端口关系，正式部署时还需按网络可达性、隐私需求和代理服务器域名解析方式选择上游。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

1. 确定唯一的 53 端口入口。如果 dnsmasq 已监听局域网的 53 端口，mihomo 不应再绑定相同地址和端口。
2. 设置转发。LuCI「网络」→「DHCP/DNS」中的 DNS 转发可使用 127.0.0.1#1053 这种 dnsmasq 地址格式；还要检查是否继续采用上游下发的解析服务器。
3. 防止循环。mihomo 的解析上游不能又指回这个 dnsmasq 入口。代理服务器域名也必须具备可用的初始解析路径。
4. 覆盖实际查询。传统 DNS 同时涉及 UDP 和 TCP 53；应用内 DoH 使用 HTTPS，不会因重定向 53 端口就自动进入相同解析链。

Fake-IP 返回的是映射地址，内核再通过映射关联域名。如果终端收到了 198.18.0.0/16 范围内的地址，却把连接发给未接管该地址段的网关，就会出现“解析有结果但网页打不开”。因此 Fake-IP、DNS 下发和流量入口应成套验证。

打印机、投屏和依赖局域网域名发现的应用需要额外测试，必要时使用精确的 Fake-IP 过滤及本地域名解析规则。IPv6 的 DNS 下发、AAAA 结果与出口路径也应一起检查；不要仅凭 IPv4 测试成功就判断所有连接都已接管。更多字段说明可查阅完整手册的 DNS 部分与Fake-IP 术语说明。

验证顺序：从配置测试到局域网实际连接

采用固定顺序能够把问题限定在一层，而不是同时修改规则、DNS 和防火墙。以下端口均为本文示例：显式混合代理为 7890，内核 DNS 为 1053，控制接口如需启用可限制在 127.0.0.1:9090。

1. 内核层：执行配置测试，检查运行日志。独立 procd 服务可结合 logread 查看启动错误，插件则优先使用其日志页面。
2. 监听层：安装了 ss 时执行 ss -lntup；否则使用固件提供的等效工具，确认 7890、1053 等端口的监听地址与协议。
3. 显式代理层：在允许局域网访问且防火墙已限制来源的前提下，让测试电脑通过旁路由 7890 端口请求网页，先证明订阅与出口可用。
4. DNS 层：从测试电脑向预期的 DNS 入口查询，观察内核日志与返回结果，区分解析超时、映射正常和上游循环。
5. 路由层：关闭测试电脑的显式代理，仅保留测试网关和 DNS，检查连接是否仍进入内核。路由器上同时查看 ip route show、ip rule show 及相关路由表。
6. 协议层：分别检查普通网页、视频、UDP 应用和 IPv6 连接；TCP 成功不代表 UDP 或 IPv6 已走相同路径。

若需要从终端执行显式代理测试，以下命令要求终端已安装 curl，且旁路由确实按上述示例开放了 LAN 代理入口。示例网址只是测试目标，不表示预期一定匹配代理策略。

curl --proxy http://192.168.10.2:7890 --connect-timeout 10 -I https://example.com/
nslookup example.com 192.168.10.2

不要只看公网 IP 是否变化：规则模式下，某些目标本来就会直连。应结合连接记录中的目标、命中规则、策略组和最终出口判断。吞吐量也没有通用的“软路由标准值”，加密协议、单核性能、MTU、线路质量和日志量都会影响结果，应在同一设备与同一目标间比较直连和代理。

长期运行：更新、权限与故障回退

• 配置更新：订阅更新后先做语法与资源加载检查，再替换当前配置。保留上一份可用配置，持久修改放在插件覆写或独立维护的文件中。
• 内核更新：先核对新内核对当前字段、规则和启动参数的支持，更新后重新执行配置测试；订阅刷新不会替代程序更新。
• 管理接口：控制接口优先绑定回环地址。确需局域网访问时设置访问凭据并限制来源，WAN 侧不应开放代理或控制端口。
• 存储管理：避免长期开启大量调试日志写入闪存；规则资源更新应考虑下载失败与剩余空间，不要把唯一配置放在临时目录。
• 停止清理：停止服务时要撤销由该服务创建的接管规则、路由和 DNS 转发，防止进程停止后仍把流量送向失效入口。

回退时先把测试终端的网关与 DNS 恢复为原值，再撤销旁路由接管；主路由部署则应使用预先准备的服务停止与规则恢复路径。保持本地有线管理方式，比发生故障后依赖已中断的远程连接更可靠。

如果需求只是让一台电脑使用订阅，可以先从桌面客户端完成配置验证，再考虑路由器接管。路由部署的主要工作不在于复制内核文件，而在于确保流量进入、域名解析、代理出口与返回路径彼此一致。