平台部署 预计阅读 15 分钟

路由器直跑 mihomo 内核部署思路:主路由、旁路由与透明代理的取舍

梳理在路由器或旁路由设备上直接运行 mihomo 内核的整体思路:固件与硬件门槛、主路由与旁路由两种接法的差异、透明代理的流量走向,以及适合和不适合上路由器的场景。

先确定目标：路由器代理解决什么问题

把 mihomo 放进路由器，核心变化不是把桌面客户端搬到另一台设备，而是把代理入口前移到局域网网关。手机、电视、游戏机、智能设备发出的流量先到网关，再由网关依据目标域名、目标 IP、来源设备和协议类型决定 DIRECT、REJECT 或某个代理组。终端可以继续使用普通网络设置，分流逻辑集中在路由器。

这类部署最适合设备数量多、部分设备无法安装客户端、需要统一规则或者希望按来源设备分流的网络。比如电视走流媒体节点，办公电脑走固定出口，打印机与 NAS 始终直连，访客网络完全绕过代理。规则可以统一维护，不必逐台修改。

路由器透明代理也会扩大故障影响面。mihomo 配置加载失败、DNS 上游不可达、策略路由丢失或防火墙规则顺序错误，都可能让一组设备同时断网。因此，部署前先写清楚三个目标：哪些设备需要代理、哪些协议必须支持、mihomo 停止时是否允许自动直连。目标不同，主路由、旁路由和透明代理方案的取舍也不同。

固件、架构与硬件门槛

先看 CPU 架构，不要只看路由器型号

mihomo 提供不同架构的 Linux 内核文件。常见软路由是 x86_64，新款 ARM 路由器多为 aarch64，部分旧设备是 armv7 或 mipsle。下载错架构时，执行文件通常直接报告 Exec format error。可通过 SSH 检查：

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

以下讨论以 OpenWrt 24.10.0、Linux 6.6 和 mihomo 1.19.3 的常见能力为参照，不代表所有固件都已包含相同模块。第三方固件可能调整内核、nftables、DNS 服务和启动管理方式，实际部署要以设备上的命令输出为准。

内存与存储要给规则集留余量

只启动 mihomo 内核与一份小型 YAML 配置，资源需求并不高；但 GeoIP、GeoSite、规则集、Fake-IP 映射、连接表和控制面板都会继续占用内存。硬件规划可以从下面的区间起步：

设备资源 适合场景 部署判断
128 MB 内存、16 MB 闪存 小规则、少量设备 空间紧，升级与回滚困难，不建议承担全家透明代理
256 MB 内存、128 MB 存储 10 至 20 台设备、常规规则集 可运行，需控制日志等级和规则集数量
512 MB 及以上内存 TUN、较大规则集、多设备并发 维护余量更合理
x86_64、1 GB 及以上内存 千兆接入、容器、复杂策略 适合主路由或独立网关

存储不要只算 mihomo 可执行文件。配置、运行日志、规则数据库和更新时的临时文件也需要空间。建议至少预留 50 MB 可写空间；如果规则数据与日志放在本机，预留 100 MB 以上更稳妥。闪存空间不足时，可把数据目录放到挂载磁盘，但启动脚本必须等待挂载完成。

吞吐取决于单核性能、协议与加密

路由器包装上写的“千兆”通常指硬件 NAT 条件下的转发，不等于代理吞吐。透明代理会让流量进入用户态，协议加密、规则匹配和连接复用都消耗 CPU。一个四核 ARM 设备在普通 NAT 下能跑满 940 Mbps，不代表 mihomo 经由加密节点仍能达到同一数字。

测试时至少记录三组数据：直连测速、终端运行客户端测速、路由器透明代理测速。还要观察 top 中是否有单核接近 100%。如果透明代理只有 180 Mbps，而终端客户端可达 600 Mbps，瓶颈通常在路由器 CPU、虚拟网卡处理或协议实现，不是订阅节点本身。

主路由直跑：路径最短，故障范围最大

主路由部署是最直接的结构。主路由同时承担拨号或上联、DHCP、DNS、防火墙、NAT 和 mihomo。所有终端的默认网关指向主路由，流量天然经过代理规则，不需要额外修改下一跳。

终端设备
  ↓ 默认网关
主路由：DHCP / DNS / 防火墙
  ↓ 透明代理规则
mihomo：规则匹配
  ├─ DIRECT → WAN
  ├─ REJECT → 丢弃
  └─ 代理组 → 远端节点 → 目标站点

主路由方案的优势

  • 网络拓扑简单，默认网关只有一个。
  • 来源 IP、MAC 对应地址和访客网络接口更容易识别。
  • DNS 劫持、IPv4 策略路由与防火墙规则集中管理。
  • 终端之间访问 NAS、打印机和投屏设备时，路径更可控。

主路由方案的代价

  • 配置错误会影响全网，恢复操作必须能绕过代理。
  • 固件升级可能重置防火墙自定义规则或软件包。
  • 主路由 CPU 同时处理 PPPoE、SQM、Wi-Fi、NAT 和代理，资源竞争更明显。
  • 部分硬件 NAT、流量分载和软件流量卸载可能绕开透明代理链，需要关闭或重新验证。

如果选择主路由直跑，至少保留一个管理入口。可以留一条只允许局域网访问的 SSH 路径，也可以给管理电脑设置静态地址，并准备停止 mihomo、清理策略路由和恢复 DNS 的命令。不要把管理域名、路由器自身更新流量和代理节点地址再次送回代理，否则容易形成回环。

旁路由部署：改动较小，但回程路径要算清

旁路由通常是一台接入主路由 LAN 的独立设备。它不一定负责拨号，也不一定接管全网 DHCP。mihomo 在旁路由运行，选定终端把默认网关或策略下一跳指向旁路由，再由旁路由转发到主路由出网。

测试电脑 192.168.10.50
  ↓ 网关 192.168.10.2
旁路由 192.168.10.2：mihomo
  ↓ 上游网关 192.168.10.1
主路由 192.168.10.1
  ↓
互联网

接法一：终端手动指定旁路由网关

这是最容易排错的旁路由方式。主路由地址设为 192.168.10.1，旁路由设为 192.168.10.2，测试电脑默认网关改成 192.168.10.2。旁路由自身的默认路由仍指向 192.168.10.1。如果测试失败，只需把电脑网关改回主路由。

DNS 可以先显式设置为旁路由地址，确认 mihomo DNS 正常后再做 DHCP 下发。旁路由必须开启 IPv4 转发，并允许 LAN 流量从入接口转发到主路由。若两台设备处于同一网段，要特别检查回程是否绕过旁路由；只看网页能否打开不足以判断透明代理是否完整。

接法二：主路由按设备下发不同网关

支持 DHCP 选项或策略路由的主路由，可以按 MAC 地址给指定设备下发旁路由网关。这样不必在电视、手机上手工填写静态地址。配置时要给旁路由固定租约，避免它的地址变化。还要明确 DNS 由谁下发：网关指向旁路由、DNS 却继续指向公共解析器，可能造成域名规则失效或解析路径泄漏。

旁路由常见的回环错误

最典型的问题是旁路由自己的代理连接又被透明代理规则捕获。mihomo 连接远端节点时，数据再次进入 mihomo，最终超时。处理方法包括按进程身份绕过、按防火墙标记绕过、将节点服务器 IP 加入直连集合，以及让路由器本机流量与转发流量进入不同链。

另一个问题是主路由把返回包直接交给终端，而去程经过旁路由。普通 TCP 有时仍可工作，但依赖连接跟踪、源地址转换或 TProxy 标记的流程可能失配。工程上更稳的做法是让旁路由执行必要的 SNAT，或者用独立子网明确分隔上下游，避免同网段内的非对称路由。

透明代理的三条实现路线

透明代理不是单一开关。Linux 路由器上常见方案包括 Redirect、TProxy 和 TUN。三者都能把终端流量交给 mihomo，但支持的协议、路由方式和排错重点不同。

Redirect：适合先跑通 TCP

Redirect 通常通过 NAT 规则把 TCP 连接重定向到 mihomo 的 redir-port。配置示例：

redir-port: 7892
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

它的优点是概念简单，适合验证 HTTP、HTTPS 和大多数 TCP 应用。限制也直接：UDP 不能靠 TCP Redirect 完整处理。QUIC、部分游戏、语音和基于 UDP 的 DNS 需要额外方案。若只做网页访问验证，Redirect 是合理起点；准备接管全网时，通常还要加入 TProxy 或 TUN。

TProxy：保留目标地址，覆盖 TCP 与 UDP

TProxy 借助策略路由、数据包标记和防火墙透明代理目标，把 TCP 与 UDP 送到 mihomo 的 tproxy-port。内核需要相应的透明代理模块，OpenWrt 还要确保 nftables 或 iptables 规则与当前防火墙体系匹配。

tproxy-port: 7893
mixed-port: 7890
allow-lan: true
mode: rule

TProxy 的关键不只是一条端口规则。数据包通常先被标记，再由 ip rule 选择专用路由表，把目标送回本机透明代理端口。若只写防火墙规则，没有策略路由，连接会直接失败。若代理节点 IP、局域网网段和保留地址没有提前绕过，则可能出现回环或本地服务失联。

排查 TProxy 时，可依次检查监听端口、nftables 计数器、策略规则和路由表：

ss -lntup
nft list ruleset
ip rule show
ip route show table all
conntrack -L | head

TUN：接管面更完整，路由冲突也更多

mihomo 的 TUN 模式创建虚拟网卡，将匹配流量送入用户态协议栈。它通常能统一处理 TCP 与 UDP，也便于在不同 Linux 环境复用配置。一个精简示意如下：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053

auto-route 与 auto-redirect 是否能按预期工作，取决于操作系统、mihomo 版本和防火墙环境。在已有多 WAN、VPN、WireGuard、策略路由或容器网络的设备上，自动写入的路由可能与现有规则冲突。部署前应保存 ip rule、ip route 和 nft list ruleset 输出，以便对比。

TUN 也不是性能保证。用户态网络栈、GRO、MTU 和 UDP 处理都会影响吞吐。若某些站点加载到一半停止，可尝试检查路径 MTU。PPPoE 常见接口 MTU 为 1492，叠加隧道后可用值更低；不要在没有抓包依据时随意把 TUN MTU 调到极端数字。

DNS 决定域名规则能不能命中

透明代理最容易被低估的部分是 DNS。规则里写了 DOMAIN-SUFFIX，不代表路由器一定知道连接对应哪个域名。如果终端直接访问外部 DNS、启用加密 DNS，或者只把目标 IP 交给透明代理，域名规则的命中率会下降。

Fake-IP 的流量链

  1. 终端向路由器查询域名。
  2. mihomo DNS 返回 Fake-IP 地址，并保存域名映射。
  3. 终端连接这个 Fake-IP。
  4. 透明代理截获连接，mihomo 从映射中恢复原始域名。
  5. 规则引擎按域名选择 DIRECT、REJECT 或代理组。

Fake-IP 适合依赖域名分流的网络，但局域网域名、打印机发现、部分游戏和特殊应用可能需要加入过滤列表。路由器管理域名、本地域名后缀和私有地址解析应优先交给本地 DNS，不要送往远端代理。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.lan"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver 用于解析代理节点服务器域名。这个解析链必须能在代理尚未建立时工作，否则会出现先有节点连接才能解析、先能解析才能连接节点的依赖环。实际配置还应结合所在网络选择可达的上游，不要机械复制地址。

端口 53 的接管边界

传统 DNS 使用 UDP 或 TCP 53，可以在路由器上重定向到 mihomo DNS，例如转发至本机 1053。但 DoH 使用 HTTPS，DoT 常用 TCP 853，不能只靠一条 53 端口规则接管。若终端启用了系统级加密 DNS，需要通过设备管理关闭、用规则限制已知端点，或接受该设备不参与域名增强解析。

规则设计：先绕过，再接管

路由器规则的首要任务不是把更多流量送进代理，而是明确哪些流量绝不能进入代理。局域网地址、组播、广播、DHCP、路由器管理地址、代理节点服务器和必要的时间同步应先绕过。否则可能破坏设备发现、投屏、NAS 访问或节点自身连接。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,224.0.0.0/4,DIRECT,no-resolve
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

来源设备分流可通过源 IP 网段实现。比如给电视固定地址 192.168.10.60，给访客网络使用 192.168.30.0/24，再按来源选择策略。固定租约比依赖动态地址可靠。规则顺序仍然是从上到下匹配，局域网绕过规则应放在来源设备代理规则之前。

IPv6 需要单独决定。只接管 IPv4、保留 IPv6 直连时，应用可能优先使用 AAAA 记录，表现为规则时灵时不灵。可选方案有三种：完整配置 IPv6 透明代理；在测试阶段停止向受控终端下发 IPv6 默认路由；明确接受 IPv6 直连并将其纳入安全边界。不要只在 mihomo 配置里写 ipv6: false，却让终端继续通过路由器获得公网 IPv6。

一套可回滚的部署顺序

  1. 记录现状。保存主路由地址、DHCP 范围、DNS、默认路由、防火墙规则和现有 VPN 配置。
  2. 验证二进制。通过 SSH 执行 mihomo -v，确认架构正确；再使用 mihomo -t -d /etc/mihomo 检查配置。
  3. 只开控制端口。先启动 mixed-port: 7890，让测试电脑手动配置 HTTP 或 SOCKS5 代理，确认节点和规则可用。
  4. 接入 DNS。让一台测试设备把 DNS 指向路由器，使用 nslookup 或 dig 检查返回结果。
  5. 加入透明代理。优先只处理测试设备源 IP，并暂时保持其他设备直连。
  6. 测试 TCP、UDP 与本地服务。检查网页、视频、语音、游戏、NAS、打印机和投屏，不要只跑一次测速。
  7. 配置启动与回滚。mihomo 启动失败时不要继续保留强制重定向规则；停止服务后应恢复普通转发。
  8. 逐步扩大范围。从一台设备扩展到一个 VLAN，最后才考虑全网接管。

运行日志在调试阶段可设为 info，定位规则时短暂使用 debug。长期保持高日志等级会增加存储写入与 CPU 开销。稳定后应设置日志轮转，并定期观察内存、连接数和进程重启次数。

哪些场景适合，哪些场景应留在终端

适合放到路由器

  • 电视、游戏机和智能设备无法安装代理客户端。
  • 家庭或小型办公室需要统一维护规则与订阅。
  • 需要按设备、VLAN 或来源网段选择不同策略。
  • 路由器硬件性能充足，并有稳定的 SSH 管理路径。
  • 维护者理解 DHCP、DNS、路由表、nftables 和连接跟踪。

更适合继续使用终端客户端

  • 只有一两台电脑需要代理，其他设备全部直连。
  • 主路由是运营商设备，不能安装软件或查看防火墙规则。
  • 网络依赖企业 VPN、复杂多 WAN 或严格的终端认证。
  • 需要频繁切换配置，并希望故障只影响单台设备。
  • 路由器内存、存储或单核性能已经接近上限。

实际部署不必二选一。常见组合是路由器只负责电视、访客网络和无法安装客户端的设备，开发电脑继续运行桌面客户端。这样既保留设备级控制，也避免把所有复杂策略集中到一个网关。

最终判断可以归结为一条：主路由追求拓扑简单，旁路由追求改动可控，TProxy 追求 Linux 原生透明转发，TUN 追求统一接管能力。选型时先看故障边界，再看功能数量。能快速停用、能恢复 DNS、能绕过节点回环的方案，才适合长期运行。

继续配置客户端

先在电脑端验证订阅、节点与规则，再决定是否把同一套分流逻辑迁移到路由器。

去下载页 看教程
下载Clash