路由器与旁路由直跑 mihomo 内核:全屋透明代理部署概览

为什么要把代理下沉到路由层

桌面客户端(Clash Verge Rev、FlClash 之类)把代理跑在某一台设备上,好处是配置直观、界面友好,但覆盖面只到这一台机器。家里的电视盒子、智能音箱、平板、打印机、以及朋友借用的手机,统统被漏在代理之外——它们要么走公网直连,要么根本没法配置代理。把 mihomo 内核直接部署在路由器或旁路由上,相当于把"代理"这件事从终端设备上摘下来,挂到网络出口这一层,连到这台路由器的所有设备自动获得代理能力,不需要在每台终端上重复安装、重复配置订阅。

这种"全屋代理"思路特别适合几类场景:家里设备数量多且类型杂、需要给不支持自定义代理的智能设备(电视、机顶盒)提供出口、或者本身就想省掉给每台设备单独维护客户端的运维成本。代价是部署门槛比装一个桌面客户端高得多,需要接触配置文件、命令行和一定的网络基础知识,遇到问题也要靠日志自己排查,不像客户端有可视化的连通性提示。

硬件选型:主路由刷机还是旁路由

落地前先确定硬件路线,常见两条:

• 主路由直接刷入支持 mihomo 的固件:适合本身就打算换路由器、且对现有路由稳定性要求不高的场景。优点是省一台设备、拓扑简单;缺点是主路由承担全部转发压力,固件出问题会导致全屋断网,风险更集中。
• 旁路由方案(推荐给多数家庭):在现有主路由后面接一台小型设备(常见是 x86 迷你主机、树莓派、或支持刷机的二手路由器),只让它运行 mihomo,主路由继续负责 DHCP 与常规路由,把网关地址或默认路由指向旁路由。这种拓扑改动小、主路由稳定性不受影响,出问题只需要把默认路由指回主路由即可临时恢复上网,回退成本低,更适合第一次尝试全屋代理的用户。

硬件规格上,mihomo 本身对 CPU 和内存要求不算高,一般千兆环境下双核、512MB 以上内存的设备就能稳定跑起来;如果家里带宽超过 500Mbps 且规则数量较多,建议预留更充裕的内存与稍强的 CPU,避免规则匹配和连接数上升后出现转发瓶颈。存储方面几十到上百 MB 即可满足内核与配置文件的日常使用。

系统环境准备

不同硬件路线对应不同的系统环境,但流程思路一致:

1. 确认系统架构:下载 mihomo 内核前先确认设备是 amd64、arm64 还是其他架构,架构不匹配会导致二进制文件无法执行。
2. 准备运行环境:如果是基于 Linux 的旁路由(常见发行版或 OpenWrt 系固件),确保系统具备基础的网络工具(iproute2、iptables 或 nftables)与开机脚本能力;如果走的是支持第三方插件的路由固件,优先查看该固件是否已有现成的 mihomo/Clash 插件包,能省掉手动编译和依赖排查的步骤。
3. 关闭冲突组件:如果设备上此前跑过其他代理或透明代理方案,先确认相关的转发规则、DNS 劫持规则已经清理,避免新旧规则叠加导致流量走向混乱、排查困难。
4. 预留管理入口:部署前先打通 SSH 或固件自带的管理后台,方便后续查看内核日志、重启服务,不要等到网络中断之后才发现管理入口本身也走了代理规则导致连不上。

配置文件落位与关键字段

mihomo 使用的配置文件延续 Clash 系配置的 YAML 结构,核心字段包括入站端口、模式、DNS 段与代理规则,这部分与桌面客户端里"导入订阅"背后发生的事情本质一致,只是在路由层需要手动落位文件路径并管理服务生命周期。典型的最小骨架大致如下:

mixed-port: 7890
mode: rule
log-level: info
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

实际使用时,proxies 与 rules 段通常由订阅链接提供的远程配置替换,不需要手写每一条节点信息。把订阅生成的配置文件放到内核约定的配置目录后,内核启动时会读取该文件建立代理组与规则表。多数部署会把配置文件单独存放、内核以固定参数指向该文件路径,便于后续更新订阅时只替换配置文件本身,不用重新调整启动脚本。

规则段的写法与桌面端一致,常见的判断优先级是域名规则、IP 规则、最后落到 MATCH 兜底,例如国内域名直连、特定服务走代理、其余流量按策略组分流。规则数量多了之后建议使用规则集(rule-provider)引用远程规则文件而不是把几千条规则堆进主配置,既方便更新也减轻内核启动时的解析负担。

透明代理模式:TUN 与网关劫持怎么选

路由层部署要解决的核心问题,是让接入设备"无感"地把流量交给 mihomo,常见有两种思路:

TUN 模式接管全部出口

在旁路由或刷机路由上开启 TUN 模式,内核会创建一张虚拟网卡并自动接管系统路由表,所有经过这台设备转发的流量都会先进入 mihomo 处理再按规则分流。这种方式配置相对简单,不需要额外配置 iptables 转发规则,兼容性也更好,是目前路由层部署里最主流的接管方式,配置里对应上文示例中的 tun.enable 与 auto-route 字段。

网关劫持与 DNS 分流

让局域网内其他设备把这台跑 mihomo 的机器当作默认网关(或者只在旁路由上把默认路由指过来),设备的 DNS 请求与 TCP/UDP 流量就会经过这台设备统一处理。这种做法需要在网络层面调整默认路由或 DHCP 网关地址,对网络基础知识要求更高,但好处是接入设备完全零配置,插上网线或连上 Wi-Fi 就自动获得代理能力,这也是"全屋代理"最终想要达到的效果。

两种思路并不互斥,大多数实际部署是"旁路由上开 TUN 接管本机转发流量" + "局域网设备把网关指向旁路由"组合使用,让旁路由变成局域网设备的统一出口。

开机自启与稳定性维护

路由或旁路由通常长期通电运行,断电重启后如果内核不能自动拉起,全屋网络会跟着中断,因此开机自启不是可选项而是必需项。基于系统服务管理器的设备,常见做法是把内核启动命令写成服务单元,设置为随系统启动自动运行并在异常退出后自动重启;走固件插件体系的路由,一般插件本身已经内置了自启逻辑,只需要在管理界面里勾选"随路由启动"即可。

• 定期检查内核日志,关注规则匹配异常或节点连接失败的报错,避免"跑起来了但实际没生效"的情况被长期忽略。
• 订阅更新后重新加载配置(多数部署支持热重载,不需要重启整个服务),减少更新配置造成的短暂断网时间。
• 为管理入口保留直连或白名单规则,防止某次规则更新导致连自己的管理后台都访问不到。
• 关注内核版本更新节奏,mihomo 迭代较快,新版本通常带来协议兼容性修复和性能优化,但升级前建议先看更新说明,避免配置字段变动导致启动失败。

和桌面客户端方案的取舍

路由层部署与桌面客户端并不是非此即彼的替代关系,更适合按需求组合:

• 覆盖面:路由层部署一次覆盖全屋所有设备,桌面客户端只覆盖安装了它的那一台。如果家里智能设备多、或者常有访客临时接入网络,路由层部署的边际成本更低。
• 可视化与易用性:桌面客户端有图形界面、连通性测试、节点延迟一览,出问题容易自查;路由层部署缺少这些,排查依赖日志和命令行,对非技术用户不友好。
• 灵活切换:桌面客户端可以随时按应用或按窗口切换代理策略,路由层部署的策略统一作用于整个网络,精细到单设备级别的差异化配置需要额外的策略路由知识。
• 故障影响范围:桌面客户端出问题只影响这台设备;路由层部署出问题,尤其是主路由直接刷机的情况,可能导致全屋断网,这也是前文建议优先选择旁路由方案的原因。

比较常见的组合方式,是用路由层部署给电视盒子、智能设备等"不方便单独装客户端"的终端提供基础代理能力,同时在自己的电脑、手机上继续用桌面或移动端客户端做精细化的按应用分流,两者各司其职,而不是互相替代。