路由器与旁路由直跑 mihomo 内核部署思路:架构选择与配置要点

先确定部署目标：路由器上的 mihomo 负责什么

在 Windows、macOS 或手机上运行 Clash 图形客户端时，代理通常只覆盖当前设备。把 mihomo 内核放到路由器或旁路由后，流量入口转移到局域网网关，电视、游戏机、智能音箱以及不方便安装客户端的设备也可以按规则分流。这里的 mihomo 是 Clash Meta 延续发展的内核，能够读取 Clash 风格的 YAML 配置，并提供规则匹配、策略组、DNS、TProxy、重定向和 TUN 等能力。

路由部署的重点并不是“让内核运行起来”，而是确保数据包确实经过它，并且能够正确返回。一个完整链路至少包含四部分：局域网设备把数据交给网关、路由规则把目标流量送入 mihomo、内核根据规则选择直连或代理出口、返回流量沿正确路径回到原设备。只启动进程却没有配置透明代理规则时，局域网设备不会自动使用它。

主路由和旁路由的核心区别

主路由方案的链路最清楚：LAN 客户端的默认网关就是运行 mihomo 的设备，防火墙只需识别哪些流量要交给透明代理端口。旁路由方案则必须回答一个额外问题：客户端为什么会把数据包发给旁路由？常见做法是把指定设备的默认网关设置为旁路由地址，或者由主路由基于源地址实施策略路由。只把客户端 DNS 指向旁路由，并不能让普通 TCP、UDP 流量自动经过旁路由。

固件、架构与硬件资源怎么选

mihomo 提供面向不同 CPU 架构的可执行文件。部署前应通过 uname -m 确认系统架构，而不是只看路由器商品名称。常见结果包括 aarch64、armv7l、x86_64 和 mips。下载文件的架构必须与系统匹配；例如 64 位 ARM 固件通常使用 ARM64 构建，而安装了 32 位固件的设备即使 CPU 支持 64 位，也不能直接运行 ARM64 文件。

固件需要具备的基础能力

• Linux 内核支持策略路由，系统中可以使用 ip rule 与 ip route。
• 防火墙具备 nftables 或 iptables 能力，并支持透明代理所需的 TProxy 模块。
• 文件系统有可持久写入的位置，用于保存配置、规则集、GeoIP 与 GeoSite 数据。
• 能够注册开机服务，例如 OpenWrt 的 procd 或常规 Linux 的 systemd。
• 系统时间和 DNS 可正常工作，否则订阅更新、TLS 连接与域名规则可能异常。

OpenWrt 23.05 及之后的常见构建以 firewall4 和 nftables 为主，旧教程里的 iptables 命令不应直接混用。部署前可在 LuCI 进入「系统」→「软件包」，确认 TProxy、nftables 和策略路由相关组件是否存在；也可以通过 SSH 执行 nft list ruleset 检查当前防火墙体系。若命令不存在，应先补齐固件组件，而不是反复修改 mihomo 配置。

内存、存储和 CPU 的实际门槛

内核本体只是一部分开销。配置中的规则数量、GeoSite 数据、DNS 缓存、连接数和面板资源都会占用内存。128 MB 内存设备可以运行精简配置，但在加载大型规则集、启用 fake-ip 和处理大量并发连接时余量很小；256 MB 更适合作为基础起点，512 MB 以上则便于同时运行广告过滤、DNS 服务和监控组件。

以下数据来自一台 RK3399 六核 ARM64 设备、4 GB 内存、OpenWrt 23.05.5、mihomo v1.19.10 的局域网测试。测试线路为 300 Mbps，下游客户端使用千兆有线连接，配置约含 8.6 万条域名及 IP 规则。结果只用于估算量级，不代表不同加密方式、节点距离和固件构建下都能复现。

百兆宽带和少量终端对 CPU 要求不高，但千兆接入、WireGuard、复杂加密和大量 UDP 会显著增加负载。软路由设备还要注意网口是否共享总线、是否存在 USB 网卡瓶颈。只看 CPU 主频无法判断吞吐，AES 指令、内核驱动和散热同样会影响持续性能。

透明代理方式：TProxy、重定向与 TUN

路由端常见的接管方式有 REDIRECT、TProxy 和 TUN。REDIRECT 主要处理 TCP，结构相对简单，但不能完整覆盖 UDP，也会改变内核看到的目标地址处理方式。TProxy 可以透明接管 TCP 与 UDP，并保留原始目标信息，是 Linux 路由场景中较常用的方案。TUN 通过虚拟网卡接收 IP 流量，配置概念直观，但在低性能路由器上通常有更高的上下文切换与协议栈开销。

TProxy 端口与策略路由

mihomo 的 tproxy-port 只负责监听透明代理流量。防火墙还需要给选中的数据包打标记，策略路由再把带标记的数据送到本机回环接口。常见的监听端口是 7893，但端口号本身没有强制要求，只要配置、nftables 规则和服务权限保持一致即可。

mixed-port: 7890
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

external-controller: 127.0.0.1:9090
secret: "请设置一段独立的控制密钥"

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

mixed-port: 7890 可供局域网内临时手动测试 HTTP 或 SOCKS 代理，但如果确实要让其他设备访问，还应使用防火墙限制来源网段。控制接口建议保持监听 127.0.0.1:9090，需要远程面板时通过受控的反向代理或 SSH 转发访问，不应直接暴露到 WAN。

什么时候考虑 TUN

如果固件缺少完整的 TProxy 模块，或者希望减少手工编写策略路由的工作，可以评估 TUN。mihomo 的 TUN 配置通常需要指定自动路由和接口探测，但路由器同时承担 WAN、LAN、拨号和桥接时，自动探测不一定能选中预期出口。部署后应检查默认路由、TUN 路由表与本地网段，尤其避免把路由器管理地址和上游网关送进 TUN。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed 是常见起点，但不同平台支持情况会随内核版本变化。开启 dns-hijack 前，需要确认局域网的 53 端口没有同时被 dnsmasq、AdGuard Home 和另一套重定向规则重复接管。实际部署中可以让 dnsmasq 继续监听 LAN 的 53 端口，再把特定查询转发到 mihomo 的 127.0.0.1:1053，这样 DHCP 域名和本地主机名仍由 dnsmasq 管理。

主路由部署：把故障范围控制在服务层

主路由方案中，所有客户端默认已经经过设备，因此不需要修改每台终端的网关。更稳妥的启用顺序是：先让 mihomo 以普通混合代理方式运行，确认 127.0.0.1:7890 可用；再添加一台测试设备的透明代理规则；最后才把规则扩展到整个 LAN。这样即使 YAML 或规则有误，路由器的基础 NAT 和 DHCP 仍然保持工作。

1. 为路由器保留一份可直接联网的管理路径，例如有线管理口或不经过透明代理的管理设备。
2. 把测试客户端固定为静态 DHCP 租约，便于按源 IP 添加规则。
3. 先接管该客户端的 TCP，再验证 UDP、DNS 和 IPv6。
4. 确认直连站点、代理站点、局域网设备访问和路由器后台均正常。
5. 保存可回滚的防火墙配置，再逐步扩大接管范围。

IPv6 是常见遗漏点。若局域网客户端同时获得公网 IPv6 地址，而透明代理只处理 IPv4，部分应用可能直接走 IPv6，表现为规则似乎随机失效。解决方向不是简单关闭所有 IPv6，而是明确选择：完整接管 IPv6、让相关域名返回 IPv4，或在当前网络尚未准备好时由 RA 与 DHCPv6 层统一关闭。配置中的 ipv6: true 只表示 mihomo DNS 和连接能力允许 IPv6，并不会自动补齐防火墙规则。

主路由方案的回滚设计

透明代理服务停止时，防火墙如果仍把流量送到 7893，客户端就会断网。启动脚本应先拉起内核并检查监听端口，再加载透明代理规则；停止脚本则应先移除规则，再结束进程。OpenWrt 上还可以让 procd 监控进程并设置重启策略，但不要无限快速重启，配置语法错误时持续拉起会占用 CPU 并刷满日志。

旁路由部署：网关、回程与单臂结构

旁路由通常与主路由位于同一网段。例如主路由地址为 192.168.10.1，旁路由为 192.168.10.2。若测试电脑把默认网关设为 192.168.10.2，旁路由必须开启 IP 转发，并把未代理或代理后的流量正确送往 192.168.10.1。此时旁路由既是客户端网关，也是 mihomo 运行位置。

单臂旁路由只有一个 LAN 接口，入站和出站流量经过同一物理口。它的布线简单，但要特别注意回程路径。若主路由直接把返回包交给客户端，而请求包经过旁路由，状态跟踪可能出现不对称。常见处理是对旁路由转发的流量进行源地址转换，或者在主路由上添加指向客户端网段的静态路由。前者配置容易但会隐藏客户端原始地址，后者保留地址信息但要求主路由支持精确路由设置。

三种让客户端经过旁路由的方法

• 手动指定网关：只修改一两台设备，适合测试。客户端网关指向旁路由，DNS 可指向旁路由或指定的局域网 DNS。
• 由 DHCP 下发旁路由网关：适合整网迁移，但网络中只能有一套明确负责地址分配的 DHCP 服务，避免客户端拿到冲突网关。
• 主路由策略路由：主路由按客户端 IP、MAC 对应的固定租约或网段把流量送往旁路由，适合分组启用，但依赖主路由固件能力。

旁路由不应与主路由同时向同一广播域随意发放 DHCP。若需要旁路由提供 DHCP，应关闭主路由对应接口的 DHCP 服务，或者将两者划分到不同 VLAN。迁移期间保留一台网关固定为主路由的管理电脑，可以在旁路由配置失败时继续进入两台设备后台。

配置文件、订阅与规则集的放置方式

mihomo 应从持久化目录读取配置。OpenWrt 常用 /etc/mihomo/config.yaml 保存主配置，/etc/mihomo/providers/ 保存代理提供者文件，运行时缓存和大型数据库则可放在 /var/lib/mihomo/ 或挂载存储中。不要把唯一配置放在 /tmp，因为 OpenWrt 的 /tmp 通常位于内存文件系统，重启后内容会消失。

/etc/mihomo/
├── config.yaml
├── providers/
│   ├── primary.yaml
│   └── backup.yaml
└── rules/
    ├── direct.yaml
    └── proxy.yaml

/var/lib/mihomo/
├── cache.db
├── country.mmdb
└── geosite.dat

订阅地址可以写在 proxy-providers 中，由 mihomo 按间隔更新。路由器闪存写入寿命有限，更新间隔没有必要设置得过短。多数场景可从 interval: 21600，即 6 小时开始；规则集可以根据变更频率使用 12 小时或 24 小时。每分钟拉取既增加上游请求，也会产生不必要的写入和日志。

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

上面的域名仅用于展示配置结构，部署时需要替换为实际订阅地址。配置文件通常包含访问凭据，应限制文件权限，例如只允许服务用户和管理员读取。修改 YAML 后先执行内核提供的配置检查，再替换当前文件。缩进必须使用空格，策略组引用的 provider 名称、规则集名称和出站名称也必须完全一致。

开机自启、健康检查与日志排错

手动运行命令适合首次验证，长期运行则应交给服务管理器。OpenWrt 使用 procd 时，服务脚本应指定可执行文件、工作目录、配置目录、标准输出和重启策略。常规 Linux 旁路由可以使用 systemd，并通过 After=network-online.target 等待网络准备完成。服务启动成功不等于透明代理已工作，还要检查端口、防火墙规则、策略路由和 DNS。

建议的启动检查顺序

1. 执行 mihomo -t -d /etc/mihomo 检查配置能否解析。
2. 启动服务后用 ss -lntup 确认 7890、7893、9090 和 1053 中实际启用的端口。
3. 用 ip rule 与 ip route show table all 检查策略路由表。
4. 用 nft list ruleset 检查流量标记、保留地址放行与透明代理跳转。
5. 从一台测试客户端分别测试域名访问、直接访问 IP、UDP 应用和局域网设备。

配置错误通常会在启动日志中给出字段路径和行号。OpenWrt 可在 LuCI 的「状态」→「系统日志」中查看，也可执行 logread -e mihomo。若进程存在但客户端不能联网，优先确认透明代理端口是否监听；若只有域名失败，检查 DNS 上游和 53 端口链路；若 TCP 正常而游戏、语音失败，检查 UDP 是否经过 TProxy；若访问路由器后台失败，检查局域网保留地址是否被误接管。

架构选择结论：按维护成本而不是功能数量决定

现有主路由具备足够 CPU、内存和可维护固件，并且家庭网络结构简单时，直接在主路由运行 mihomo 能减少中间层，默认网关与透明代理路径也更清楚。部署时应保留管理入口，先按单个测试 IP 启用，再扩大到整个局域网。

主路由由运营商管理、固件扩展能力有限，或者希望把代理故障与基础上网隔离时，旁路由更合适。旁路由应明确采用“客户端网关指向旁路由”还是“主路由策略转发”中的一种方案，并提前处理 DHCP、回程路由和 DNS，避免靠多套规则碰巧连通。

TProxy 更适合功能完整的 Linux 路由环境，能够同时覆盖 TCP 与 UDP；TUN 适合希望由虚拟网卡统一接管、且硬件资源较充足的设备。无论选择哪种方式，稳定部署都依赖同一套原则：配置持久化、节点连接绕行、服务与防火墙按顺序启动、保留回滚通道，并用单台客户端逐项验证。