把代理规则收拢到路由器层,是解决多设备分流问题的常见思路。相比在每台设备上单独安装客户端,让路由器直接运行 mihomo 内核,可以让局域网内所有接入设备(包括不支持安装客户端的电视盒子、智能音箱、游戏主机)统一走同一套分流规则,配置改一处、全网生效。这篇文章梳理路由器直跑 mihomo 的整体思路,不覆盖具体固件的逐屏点击操作,重点讲清楚决策点和容易踩的坑。
为什么要在路由器上跑 mihomo
手机、平板、电脑各自安装客户端固然灵活,但存在两个明显短板。第一,不支持安装应用的设备(智能电视、扫地机器人、部分游戏主机)完全无法接入代理网络,只能靠手动配置代理服务器地址,而很多设备根本不提供这个选项。第二,多设备各自维护一份配置,规则、订阅更新需要逐台同步,容易出现版本不一致导致的分流差异。
把 mihomo 内核部署在路由器上解决了这两个问题。局域网内所有设备默认经过路由器转发流量,只要路由器做好透明代理,设备侧不需要任何额外设置就能享受到规则分流,而配置维护也集中到了路由器这一个点。这种思路在实践中通常被称为"网关代理"或"旁路由代理",区别只在于代理是跑在承担网络出口职责的主路由上,还是跑在与主路由并列、通过策略路由接管流量的旁路由上。
主路由与旁路由的取舍
主路由直跑指的是刷了支持 mihomo 的第三方固件(常见是 OpenWrt 及其衍生版本)的路由器,直接在网络出口这一层运行代理内核,所有流量默认经过。这种方案链路最短,不需要额外硬件,但对路由器本身的固件兼容性和性能要求更高——一旦配置出问题,可能影响全屋上网,排查也不方便,做实验性配置调整前最好想清楚回退路径。
旁路由方案是在现有路由器网络里另外接一台小型设备(常见是树莂派、迷你主机或二手路由器刷机),只跑代理内核,不承担主路由的 DHCP、无线等基础职责。主路由通过策略路由或者 DHCP 网关指向把部分流量转发给旁路由处理。这种方式的好处是不动主路由的稳定配置,出问题只需要把网关指回主路由,风险可控;缺点是链路多了一跳,理论时延略高,且需要额外设备和一定的网络知识去打通策略路由。
对大多数家庭网络场景,旁路由是相对稳妥的起点:先在小范围验证分流规则是否符合预期,确认稳定后再考虑要不要收编成主路由方案。对已经在用支持刷机的高性能路由器、且有信心自己排查网络问题的用户,直接主路由部署链路更简洁。
硬件与固件的基本要求
无论走哪种方案,硬件层面有几个绕不开的门槛。
- CPU 架构与性能:mihomo 内核对 CPU 有一定要求,规则数量多、并发连接大的场景下,低功耗单核设备容易出现转发延迟或丢包。选购或复用设备时优先考虑多核 ARM 或 x86 平台,避免用性能过弱的老旧路由器承担高并发代理任务。
- 内存容量:规则集、GeoIP/GeoSite 数据库加载进内存后会占用一定空间,内存过小(比如 128MB 以下)的设备在规则数量较大时可能出现内核异常退出或响应变慢,建议预留至少 256MB 以上可用内存。
- 存储空间:固件本身、mihomo 二进制、规则数据库、日志文件都需要落地存储,如果设备自带存储太小,建议外接 U 盘或使用支持扩展存储的机型。
- 固件支持:主流选择是 OpenWrt 及其衍生固件(如支持较好的社区分支),这类固件生态成熟,插件仓库里通常能找到打包好的 mihomo 或兼容组件,省去手动编译的麻烦。原厂固件基本不具备直接运行代理内核的能力,需要先刷成支持自定义软件安装的第三方固件。
刷机本身存在设备变砖的风险,操作前请确认固件版本与设备型号完全匹配,并提前备份原厂固件与关键分区数据。
内核二进制的选择
mihomo 内核会针对不同 CPU 架构和指令集发布对应的二进制文件,常见的架构标识包括 amd64、arm64、armv7 等,选错架构会导致程序无法运行或运行后立即崩溃。除了架构匹配,还需要关注以下两点:
- 版本稳定性:路由器场景对稳定性的要求高于追新,建议选择经过一段时间验证的稳定版本,而不是刚发布的最新版,避免把网络出口暴露在未知的兼容性问题下。
- 功能特性对齐:确认所选版本是否支持你计划使用的功能,例如 TUN 模式、特定的规则语法、特定的传输协议实现。不同发布渠道打包的二进制有时会裁剪部分功能以控制体积,部署前查阅对应版本的更新说明,确认功能覆盖是否满足需求。
固件插件市场里打包好的 mihomo 组件通常已经处理好架构适配问题,对不熟悉手动部署流程的用户是更省心的起点;需要自定义编译参数或使用尚未打包进插件仓库的新版本时,才考虑手动下载二进制并配置启动脚本。
透明代理与 DNS 劫持要点
路由器直跑的核心价值在于"透明"——局域网设备不需要感知代理的存在,所有流量在网关层被自动接管。实现这一点依赖两个机制的配合。
流量透明转发
mihomo 支持通过 TUN 模式在系统层创建虚拟网卡,把经过路由器的流量重定向进虚拟网卡,再由内核按规则分流处理,这种方式对协议兼容性较好,能覆盖 TCP 与 UDP。部分固件环境也支持基于 iptables/nftables 规则的透明代理方案,原理是把特定端口段或全部流量重定向到内核监听的本地端口。两种思路各有适用场景,TUN 模式配置相对直观,但对内核版本和固件网络栈的兼容性要求更高;iptables 方案兼容性更广,但规则写法复杂,排查问题时需要熟悉网络重定向链路。
DNS 劫持与污染规避
规则分流很大程度上依赖域名解析结果做判断,如果设备的 DNS 请求绕过了 mihomo 直接发往运营商 DNS,可能拿到被污染或不准确的解析结果,进而影响分流准确性。因此路由器部署通常需要额外做一步 DNS 劫持:把局域网内所有设备发出的 53 端口 DNS 请求强制重定向到 mihomo 内置的 DNS 服务器,由内核统一处理解析与后续的分流决策。
这一步做得不彻底,最常见的表现是"某些应用能正常代理,某些应用直连走了原始网络"——往往就是这些应用内置了自己的 DNS 解析逻辑,绕开了系统 DNS 设置,连带绕开了劫持规则。排查这类问题时,先确认路由器层的 DNS 重定向规则是否覆盖了所有网段和所有端口方向,再检查具体应用是否使用了加密 DNS(如 DoH)直连特定服务器。
局域网设备接入的两种常见方案
把 mihomo 跑起来只是第一步,更关键的是让局域网内的其他设备"知道"要走这条代理路径。常见的两种接入方式各有取舍。
| 方案 | 实现方式 | 优点 | 局限 |
|---|---|---|---|
| 网关直接指向 | DHCP 分配的默认网关直接指向运行 mihomo 的设备 | 配置简单,新接入设备自动生效,无需逐台设置 | 该设备成为单点,一旦故障将影响全部下游设备联网 |
| 策略路由分流 | 主路由按源 IP 或 MAC 地址,把指定设备的流量转发给旁路由处理 | 可按设备粒度控制是否走代理,故障影响范围可控 | 需要在主路由上维护策略路由规则,新增设备需手动加入名单 |
网关直接指向适合"全屋统一走代理"的场景,配置一次即可覆盖所有新接入设备,适合家庭成员设备较多、不希望逐台设置的情况。策略路由分流适合"部分设备需要代理、部分设备保持直连"的场景,比如只让智能电视和游戏主机走代理,其他办公设备维持原有网络路径,避免不必要的链路影响。选择哪种取决于你对"全量接管"和"精细控制"的优先级排序,也可以先用策略路由做小范围验证,确认稳定后再切换成网关直接指向。
部署前的几个自查项
动手之前,建议先确认以下几件事,能省去后续排查的不少时间。
- 确认设备架构与固件版本,提前下载好对应的 mihomo 二进制或插件包,避免在断网状态下现场查资料。
- 准备好订阅链接与基础规则集,先在小范围(比如自己一台设备)验证配置文件语法正确、规则命中符合预期,再推广到全屋。
- 规划好日志留存位置,路由器存储空间有限,长期运行建议做好日志轮转或定期清理,避免存储写满导致设备异常。
- 确认回退路径:如果部署后出现全屋断网,能否快速把网关指回主路由,或者用备用网络(如手机热点)临时接入路由器管理界面进行修复。
路由器层面的代理部署收益明显,但试错成本也高于单设备客户端——出问题影响的是全屋网络。建议先在低峰时段进行部署与调试,配置稳定后再作为长期方案运行,并保留一份可快速恢复的原始网络配置备份。