路由器与旁路由直跑 Clash 内核:mihomo 部署方案概览

为什么要把代理放到路由器层

桌面客户端与手机 App 只能覆盖装了软件的那台设备,家里的电视盒子、游戏主机、智能音箱、平板往往没法逐一配置,而且系统代理和 TUN 模式各家实现不一致,遇到不支持自定义 DNS 或不支持虚拟网卡的设备就会束手无策。把代理下沉到路由器或旁路由这一层,相当于在网络出口处统一接管流量,连入这张网的所有设备都自动获得分流能力,不需要逐台安装客户端,也不用担心某个设备本身架构冷门装不上软件。这也是很多家庭网络最终选择在网关层部署 mihomo 内核的核心原因。

mihomo 是 Clash Meta 项目延续下来的内核实现,相比早期 Clash 内核,协议支持更全、规则引擎更灵活,且原生提供 TUN 模式与丰富的进程级分流能力,非常适合被固件化后长期挂在路由器上跑。下文会分主路由与旁路由两种拓扑分别说明落地思路。

主路由与旁路由:两种拓扑该怎么选

"主路由"指直接刷入支持第三方软件的固件(常见是 OpenWrt 系),让路由器本身承担 mihomo 运行环境;"旁路由"则是在现有路由器之外,额外接一台小型设备(迷你主机、闲置的路由器刷成纯网关、甚至一台 NAS 的虚拟机),通过网关劫持或者局域网内 DHCP 选项,把需要代理的设备指向这台旁路由处理。

• 主路由方案:优点是拓扑简单,一台设备完成路由与代理两件事,不需要额外硬件;缺点是对路由器本身的固件兼容性、CPU 性能要求更高,一旦代理进程异常也可能影响到整个网络的路由转发,风险集中在同一台设备上。
• 旁路由方案:优点是主路由保持出厂固件不变,稳定性和售后不受影响,旁路由这台设备专职跑代理,出问题只需重启这一台,排障边界清晰;缺点是多了一台硬件、多了一层网络配置(网关指向、DHCP 分发),初期搭建门槛略高。

如果家里只有一台支持刷第三方固件的路由器,且愿意接受"全部集中在一台设备"的风险敞口,主路由方案更省事;如果希望代理环境和基础网络解耦、方便随时重置或更换代理设备而不影响上网,旁路由是更稳妥的选择,也是目前家庭网络里更常见的做法。

硬件选型与固件基础

mihomo 本身是用 Go 编写的单一二进制程序,资源占用不算重,但透明代理场景下需要同时处理 NAT 转发、DNS 查询与规则匹配,选型时建议关注三个维度:

1. CPU 架构与算力:优先选支持硬件加速的多核 ARM 或 x86 平台,纯路由级别的低功耗单核芯片在高并发连接下容易出现规则匹配延迟。
2. 内存容量:规则集加载、连接表维护都吃内存,建议至少预留 512MB 以上给代理进程与固件本身,规则较多或开启日志追踪时可适当再放宽。
3. 存储与固件生态:主路由方案通常依赖 OpenWrt 或其衍生固件,需要确认目标设备有稳定的第三方固件支持与社区维护;旁路由方案则更自由,迷你主机跑 Linux 发行版、老旧路由器刷 OpenWrt 纯网关模式都是常见选择。

固件层面,mihomo 官方及社区提供了适配 OpenWrt 的软件包与 LuCI 管理界面,可以通过包管理器安装,也可以直接放置编译好的二进制配合 init 脚本运行,两种方式在后文的自启动部分都会涉及。

透明代理模式:TUN、TPROXY 与 REDIRECT 怎么选

在网关层接管流量,核心是把局域网设备发出的 TCP/UDP 流量透明地导向 mihomo 监听的端口,再由内核按规则决定放行、代理或拦截。常见的三种实现方式各有取舍:

• TUN 模式:mihomo 创建一张虚拟网卡,把流量在三层直接接管,配置直观、对 UDP 支持完整,是目前推荐的默认方式,尤其适合需要精确控制 IPv4/IPv6 分流的场景。
• TPROXY:依赖 Linux 内核的透明代理机制,在网关设备上用 iptables/nftables 把流量重定向到 mihomo,能保留原始目的地址信息,兼容性较好,常见于成熟的 OpenWrt 分流脚本方案。
• REDIRECT:较早期的实现方式,仅支持 TCP 重定向,UDP(尤其是依赖 UDP 的游戏、部分视频协议)需要额外处理,新部署一般不再首选。

无论选哪种,配置文件里都要打开对应的透明代理开关并声明监听端口,例如启用 TUN 模式时的关键字段大致如下(具体参数以当前版本文档为准):

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

auto-route 负责自动写入路由表,auto-detect-interface 帮内核识别出口网卡,两者配合可以省去大量手动改路由规则的步骤,是目前旁路由方案里最常用的组合。

DNS 接管与防污染

透明代理只解决了流量转发,如果 DNS 查询仍然走运营商默认线路,规则里基于域名的分流会因为拿到"错误"的解析结果而失效,常见表现就是明明配置了规则,某些网站访问依旧异常缓慢或直接不通。因此网关层部署必须同步接管 DNS:

1. 在 mihomo 配置里启用内置 DNS 服务器,并设置为局域网设备可访问的监听地址与端口。
2. 结合 fake-ip 或 redir-host 模式,让内核先拿到域名再决定去往哪个上游解析,配合规则引擎实现按域名分流而不是单纯按 IP 段分流。
3. 在路由器的 DHCP 设置里,把下发给局域网设备的 DNS 服务器地址指向网关自身(即运行 mihomo 的设备),避免设备绕过网关直接查询外部 DNS。

如果是旁路由拓扑,还需要在主路由上确认 DHCP 选项 6(DNS)确实指向了旁路由地址,否则即便旁路由配置正确,局域网设备依然会拿到主路由分发的默认 DNS,导致分流规则形同虚设。这一步是排查"规则配了但没生效"问题时最常被忽略的环节。

开机自启与长期稳定性

网关层的代理进程需要具备"重启路由器后自动恢复"的能力,否则一次意外断电就会让全屋断网或者退回未分流状态。落地时建议关注以下几点:

• init 脚本或系统服务:OpenWrt 下可以编写 procd 服务脚本,把 mihomo 注册为系统服务,支持 enable、start、stop 等标准操作,固件重启后由 procd 自动拉起。
• 看门狗与自愈:配合简单的定时任务(cron)检测进程是否存活,一旦异常退出就自动重启,避免因内核偶发崩溃导致长时间断网而无人察觉。
• 配置与规则集分离:把订阅生成的节点配置与本地自定义规则分成不同文件引用,更新订阅时不会覆盖手工调整过的路由规则,减少每次订阅刷新后需要重新排查的工作量。
• 日志留存:开启适度的连接日志与内核日志输出到本地文件,方便在设备离线或分流异常时回溯具体是哪一条规则或者哪次 DNS 查询出了问题。

旁路由方案由于独立于主路由运行,通常更容易做日志留存和进程守护,也更适合放一些实验性的规则修改;主路由方案则建议保持配置相对保守,重大改动前先备份当前可用的配置文件。

落地前的决策清单

把前面几节的判断标准归纳成一份简单清单,方便对照自己的家庭网络现状:

1. 现有路由器是否支持稳定的第三方固件?支持且愿意承担集中风险 → 优先考虑主路由方案。
2. 是否有闲置的迷你主机、旧路由器或小型 NAS 可以专职跑代理?有 → 旁路由方案排障更清晰、风险更分散。
3. 家里是否存在不支持自定义 DNS 的智能设备(电视盒子、音箱等)?存在 → 提前规划好网关层的 DNS 劫持策略。
4. 是否需要频繁更换代理设备或重刷固件测试?频繁 → 旁路由更方便随时替换而不影响主网络。
5. 是否有长期无人值守的场景(出差、异地)?有 → 务必配置好自启动与看门狗,避免断电后无法远程恢复。

不管最终选择哪种拓扑,核心思路是一致的:先在网关层把流量与 DNS 都收拢到 mihomo 内核,再用清晰的规则文件描述分流逻辑,最后用系统服务和日志机制保证长期稳定运行。把这三层分别做扎实,家庭网络里的每一台设备才能真正共享同一套代理策略,而不需要逐台折腾配置。