路由器直跑 Clash 内核方案概览:OpenWrt 与旁路由部署思路详解
介绍在主路由与旁路由两种拓扑下直接运行 mihomo 内核的部署思路,覆盖固件选择、透明代理链路、DNS 劫持与开机自启配置,并说明与桌面客户端方案的取舍。
为什么要把 Clash 内核搬到路由器上
桌面客户端把代理能力局限在安装了客户端的那台电脑上,手机、电视盒子、游戏机想要同样的分流规则,要么各装一份客户端,要么完全绕不过去。把 mihomo 内核直接部署到路由器,相当于把代理能力下沉到网络出口这一层,家里所有联网设备不用装任何软件,连上这台路由器就自动走规则分流。这对多设备家庭、智能电视、不支持装应用的硬件(如某些电视盒子、打印机联网模块)尤其有意义。
这条路径的代价是配置门槛明显高于桌面客户端:需要接触固件刷写、透明代理链路、DNS 劫持这几个偏底层的环节,任何一步配置错误都可能导致全屋断网,不适合对命令行和网络基础知识完全陌生的用户直接上手。如果只是单台设备的日常使用,桌面或移动客户端的图形界面配置显然更省心;只有当"全屋所有设备统一分流"成为刚性需求时,路由器方案才值得投入这份配置成本。
两种拓扑:主路由直跑与旁路由挂载
路由器部署 Clash 内核主要分两种拓扑,选型时先想清楚自己的硬件条件和折腾意愿。
主路由直跑:把家用路由器刷成 OpenWrt
这种方案是把家里原本的路由器(或专门买一台支持刷机的型号)刷成 OpenWrt 固件,再在固件里安装 mihomo 内核及配套管理插件,让路由器本身承担代理转发的全部工作。优点是链路最短,不需要额外硬件,局域网内所有设备的流量天然经过这台路由器出口;缺点是对路由器的 CPU 和内存有一定要求——运行 mihomo 加上规则匹配、DNS 解析,对入门级路由器的处理器是不小的负担,如果原路由器性能不足,代理开启后网速可能明显下降甚至出现卡顿。刷机本身也有变砖风险,需要提前确认设备型号支持的固件版本,并保留好恢复用的原厂固件和刷机工具。
旁路由挂载:额外接一台小设备做代理网关
旁路由方案是在现有路由器(继续负责基础联网,不改动)之外,额外接入一台小主机或迷你路由器专门跑 mihomo 内核,通过修改局域网内其他设备的网关或 DNS 指向,把需要代理的流量导到这台旁路由处理。常见硬载体是树莱派、迷你 x86 主机,或者第二台刷了 OpenWrt 的路由器,以桥接模式接入现有网络。这种方案不需要动主路由的固件,风险和门槛都低于主路由直刷,而且旁路由性能不够时可以单独升级硬件,不影响主路由的基础联网功能。多数家庭用户在"要不要折腾主路由"上犹豫时,旁路由是更稳妥的起点。
刷第三方固件通常会清空设备原有配置甚至触发保修条款风险,务必先确认路由器型号在 OpenWrt 官方设备列表中的支持状态,并备份原厂固件包。旁路由方案不涉及刷机,风险敞口小得多,建议作为第一次尝试的优先选项。
透明代理链路:流量如何被路由器接管
路由器层面实现代理接管,核心机制是透明代理(Transparent Proxy),这与桌面客户端的系统代理或 TUN 模式原理相通,但落地方式不同。设备(手机、电视盒子)本身不知道自己的流量正在被代理,它按正常方式发出请求,路由器在网络层把这些流量透明地重定向到本机的 mihomo 进程处理,处理完再转发出去,客户端设备完全无感知,不需要在每台设备上单独配置代理地址。
实现透明代理依赖路由器操作系统的流量重定向能力,OpenWrt 上常见的做法是通过防火墙规则(iptables 或 nftables)把特定端口段或协议的流量导向 mihomo 监听的透明代理端口,再配合 mihomo 配置文件里的 tproxy-port 或类似字段完成接管。这一层配置是整套方案里最容易出错的部分,规则写错的直接后果是设备联网正常但代理规则完全不生效,或者反过来所有流量都无法出网。建议先在测试设备上验证链路通畅,再逐步扩大到全屋设备。
| 环节 | 作用 | 常见坑点 |
|---|---|---|
| 防火墙重定向规则 | 把局域网设备流量导向 mihomo 透明代理端口 | 规则顺序错误导致部分流量绕过代理 |
| mihomo 透明代理端口 | 接收被重定向的流量并按规则分流 | 端口未开启监听或权限不足 |
| 路由表与策略路由 | 确保代理后的流量正确回程 | 多网卡环境下路由表冲突 |
DNS 劫持:分流规则生效的前提
透明代理只解决了流量转发路径的问题,代理规则要按域名精准分流,还需要 DNS 层面的配合。如果设备直接查询运营商 DNS,拿到的是真实 IP,mihomo 只能靠 IP 段或 GeoIP 规则粗略判断,精细的域名规则(如按站点分流到不同代理组)就无法生效。解决办法是在路由器上把局域网内所有设备的 DNS 查询劫持到 mihomo 内置的 DNS 服务器,让 mihomo 自己接管域名解析,再根据解析结果和规则决定这条流量走直连还是走代理。
这一步在 OpenWrt 上通常通过修改 dnsmasq 配置或直接用防火墙规则把 53 端口的查询强制转发到 mihomo 的 DNS 监听端口实现。mihomo 配置文件里对应的字段包括 DNS 服务器地址、是否启用 fake-ip 模式等,fake-ip 能进一步提升域名分流的准确性,但对部分需要真实 IP 的场景(比如某些局域网内网服务发现协议)可能产生兼容问题,配置时需要按实际使用的应用场景做取舍。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29上面是 mihomo 配置文件里 DNS 段的一个简化示例,实际部署时还需要结合 fake-ip 排除范围、国内域名直连列表等字段做更细致的调整,具体字段含义可以在概念速查页里查到详细解释。
开机自启与稳定运行配置
路由器和桌面电脑的使用场景不同,路由器几乎是 7×24 小时通电运行,断电重启后必须自动恢复代理服务,不能指望人工干预。OpenWrt 上给 mihomo 配置开机自启,一般通过 /etc/init.d/ 下编写符合 procd 规范的启动脚本,并用 service mihomo enable 注册到系统服务里,这样固件重启后会自动拉起进程。旁路由方案如果用的是通用 Linux 发行版,则通常用 systemd 编写对应的 .service 文件,设置 Restart=on-failure,让进程异常退出后自动重启。
除了开机自启,长期稳定运行还要考虑几个细节:订阅更新是否设置了定时任务、日志文件是否会无限增长占满存储空间、内存占用是否随运行时间增长(内存泄漏在部分老版本内核上出现过,建议保持内核版本更新)。对于旁路由这种独立小主机,还建议配置看门狗脚本定期检测 mihomo 进程状态,异常时自动拉起,避免深夜服务挂掉却无人察觉,导致全屋设备第二天早上发现网络异常。
部署完成后按这个顺序验证:先确认 mihomo 进程正常监听端口,再确认防火墙重定向规则生效(用测试设备访问已知走代理的站点验证),最后确认 DNS 劫持链路正确(用 nslookup 类工具检查解析结果是否为 fake-ip 段)。三步都通过后才建议把全屋设备网关切换过来。
与桌面客户端方案的取舍
路由器方案和桌面客户端方案不是互相替代关系,更适合按场景搭配使用。如果家里只有一两台常用设备需要代理,装一个桌面客户端(如 Clash Verge Rev 或 FlClash)配置图形界面,几分钟就能完成,不需要碰命令行和固件。但如果家里设备数量多、种类杂,尤其是电视盒子、游戏机、智能音箱这类无法自行安装客户端的设备也需要走分流规则,路由器方案就是唯一能一次性覆盖全部设备的办法。
另外要考虑的是维护成本:桌面客户端更新只需要下载新版本重新安装,而路由器上的内核升级往往需要手动替换二进制文件或重新刷入固件包,操作路径更繁琐,出错后排查也更麻烦,普通用户直接在生产环境的路由器上做大改动前,最好先在测试环境或备用设备上验证一遍。对大多数家庭用户而言,更务实的组合是:主力设备装桌面客户端保证灵活性和及时更新,家里确实有多设备统一分流的硬需求时,再单独配置一台旁路由承担这部分职责,两者互补而不是二选一。
规则与配置从哪里来
不管是路由器上的 mihomo 还是桌面客户端,规则集、策略组、订阅链接的写法都是同一套 mihomo 配置语法,没有额外的路由器专属格式。这意味着已经在桌面客户端上跑通的配置文件,理论上可以直接搬到路由器的 mihomo 实例上使用,只需要额外补充透明代理端口、DNS 监听地址这几个路由器场景特有的字段。如果是第一次接触策略组、规则分类这些概念,建议先在桌面客户端上理清配置逻辑,再迁移到路由器环境,这样出问题时更容易判断是规则写错还是路由器链路配置的问题。