Windows
适合桌面办公、浏览器代理和需要 TUN 接管的程序。下载页集中列出图形客户端,并区分仍在维护的项目与归档项目。安装后先导入订阅,再按需开启系统代理;只有不读取系统代理的应用才需要进一步配置 TUN。
前往下载内核换代对照台
从系统流量接管到 DNS 解析链路,常用配置不再只是简单转发。选择左侧能力,可查看它解决的问题、配置入口与使用边界。
TUN 模式用于接管不读取系统代理设置的应用,包括部分游戏启动器、命令行工具和独立网络程序。启用后,内核通过虚拟网卡统一接收流量,再交给规则系统判断直连、代理或拒绝。与只打开系统代理相比,它覆盖更完整,但也更依赖管理员权限、路由设置和 DNS 配合。初次使用应先采用 mixed 栈,并确认本地网段仍能直连;遇到局域网设备不可达时,再检查路由排除项,而不是反复更换节点。
tun:
enable: true
stack: mixed
auto-route: true
strict-route: false
规则模式把域名、IP、进程和网络类型逐项交给配置文件判断,策略组再决定实际使用哪个节点。它解决的是“所有流量都走同一路径”带来的访问绕行问题:本地服务可直连,指定站点可进入代理组,未命中流量由末尾规则统一接管。配置时应把范围更具体的规则放在前面,把兜底规则放在最后;策略组名称必须与规则目标完全一致。与单纯全局代理相比,这种方式更适合长期运行,也便于定位某个请求究竟命中了哪条规则。
proxy-groups:
- name: 手动选择
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,手动选择
- MATCH,DIRECT
统一 DNS 处理可以减少系统解析结果与代理规则不一致的情况。客户端接管查询后,可按域名类别选择解析服务器,并让 Fake-IP 映射与连接记录保持对应。它解决的重点不是单纯追求更快响应,而是让“域名规则判断”和“实际连接目标”处于同一条链路。配置时需要保留局域网域名、时间同步服务和部分游戏域名的过滤规则;如果关闭内核 DNS,则应同步检查系统、浏览器和其他安全软件是否另行启用了加密解析,避免多条解析链互相覆盖。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
respect-rules: true
mihomo 将多类代理协议放入同一配置体系,客户端只需把订阅内容交给内核,不必为每种节点单独安装连接程序。协议兼容并不等于所有参数可以混用:传输层、TLS、服务端名称、用户标识与端口仍要和提供方给出的信息对应。导入失败时应先确认订阅是否完整,再检查客户端是否正确调用 mihomo 内核。相比依赖旧核心的客户端,新生态更适合处理持续演进的协议字段,但错误字段依然会在启动日志中明确暴露,需要按日志逐项修正。
订阅更新通常会替换远端配置,如果把个人规则直接写进订阅原文,下次刷新就可能丢失。覆写与合并机制把本地端口、DNS、规则和策略组修改放在独立层,再与订阅内容组合生成运行配置。它适合需要固定局域网设置、补充直连规则或重命名策略组的用户。使用时要分清“追加”和“覆盖”:追加规则仍受先后顺序影响,覆盖同名字段则会替换原值。修改后应查看最终生成的 YAML,而不是只检查覆写片段本身。
mode: rule
mixed-port: 7890
allow-lan: false
log-level: info
客户端下载入口
图形客户端负责订阅导入、策略切换和系统代理控制,mihomo 内核负责实际连接与规则判断。先按设备系统进入下载页,再根据安装方式和使用习惯选择客户端。
适合桌面办公、浏览器代理和需要 TUN 接管的程序。下载页集中列出图形客户端,并区分仍在维护的项目与归档项目。安装后先导入订阅,再按需开启系统代理;只有不读取系统代理的应用才需要进一步配置 TUN。
前往下载适合 Apple Silicon 与 Intel Mac。选择安装包时先确认处理器架构,首次打开还需要允许系统网络扩展或代理权限。菜单栏客户端便于日常切换策略,桌面型客户端则更适合查看连接记录、规则命中和订阅内容。
前往下载Android 客户端通常通过系统 VPN 接口接管应用流量,不需要修改每个应用的代理设置。导入配置后可以按应用决定是否经过代理。遇到后台断连,应检查系统省电策略、VPN 权限和后台运行限制,而不是只调整节点。
前往下载iPhone 与 iPad 通过系统网络扩展建立代理连接。安装后需要允许添加 VPN 配置,再在客户端中导入订阅。移动网络与 Wi-Fi 切换时,系统可能重新建立连接;若规则未按预期生效,可先重新载入配置并检查当前策略组。
前往下载桌面用户可以选择带图形界面的客户端,服务器、软路由与容器环境则更常直接运行 mihomo 内核。直跑内核时需要自行管理配置路径、运行权限、日志与开机启动,并明确透明代理所需的路由和防火墙规则。
前往下载快速上手预览
第一次使用不必立刻修改全部配置。先完成客户端安装和订阅导入,确认基本连接正常,再逐步处理策略组、DNS 与 TUN。
进入下载页后选择当前操作系统,再根据处理器架构和使用场景挑选客户端。Windows 与 macOS 用户通常从图形客户端开始,Android 与 iOS 需要授予系统 VPN 权限,Linux 服务器用户则可以直接使用内核。安装完成后先打开客户端确认界面能够正常加载,不要在尚未导入配置时反复切换系统代理。
在配置或订阅页面粘贴服务提供方给出的订阅地址,更新后选中刚导入的配置。随后进入代理或策略页面,确认选择组中已经出现可用节点。订阅地址不是普通网页链接,不应直接在浏览器中判断内容是否完整;如果客户端提示解析失败,应检查复制时是否带入空格、地址是否过期,以及配置内容是否符合 YAML 结构。
先选择规则模式,再开启系统代理或移动端 VPN。打开连接记录观察请求是否进入预期策略组,同时访问一个本地服务确认直连规则仍然有效。若普通浏览器可以连接、独立应用却没有流量,再考虑启用 TUN;若域名解析异常,则回到 DNS 设置检查增强模式与过滤列表。按这一顺序排查,可以把节点、规则、系统接管和解析问题分开定位。
开源生态与内核交接
客户端界面与代理内核是两层独立组件。理解这层关系,才能判断更新来自哪里,也能在出现问题时找到正确的日志与配置入口。
Clash 最初建立了以 YAML 配置、规则列表和策略组为中心的使用方式,许多桌面与移动客户端都围绕这套结构开发。旧核心停止推进后,用户已有的订阅格式、规则习惯和客户端操作逻辑并没有同时消失。mihomo 在兼容常见 Clash 配置的基础上继续维护内核能力,因此今天看到的许多“Clash Meta 客户端”,本质上是图形界面调用 mihomo 完成连接、DNS、规则匹配和流量接管。
这种交接意味着迁移通常不需要从零重写配置,但也不代表所有旧字段都应该原样保留。长期未更新的模板可能包含已经失去意义的选项,或者依赖旧客户端的私有字段。迁移时更稳妥的做法是先导入原配置,查看启动日志,再逐项整理 DNS、TUN 和策略组,而不是一次性复制大量覆写内容。
mihomo 内核负责网络连接和规则执行,Clash Plus、Clash Verge Rev、FlClash 等客户端负责图形操作、系统集成和配置管理,规则集项目则提供可复用的域名或 IP 分类。这些组件可以按各自节奏更新,用户也能根据平台更换界面而保留相近的配置思路。遇到界面崩溃、托盘失效或系统代理无法切换时,应优先检查客户端;遇到配置解析、协议连接和规则命中问题时,则应查看内核日志。
分层结构也减少了对单一客户端的依赖。桌面端配置可以迁移到另一款调用 mihomo 的客户端,服务器配置也能在明确路径与权限后直接交给内核运行。不过,不同客户端对覆写脚本、配置存储和系统服务的实现并不相同,迁移前仍需导出本地规则,并记录当前使用的 DNS 与策略设置。
一份 Clash 配置主要声明端口、代理节点、策略组、DNS 和规则。客户端读取配置后,可能先合并订阅与本地覆写,再把最终结果交给 mihomo。真正决定连接走向的是合并后的运行配置,而不是订阅原文或某个单独的覆写片段。排查问题时,应找到客户端生成的最终配置并结合日志判断,这比只盯着订阅编辑器更可靠。
规则按顺序匹配,前面的具体条件通常优先于后面的宽泛条件;策略组则决定命中后如何选择节点。DNS 解析会影响域名规则与 IP 规则看到的目标,TUN 又决定哪些应用流量能够进入内核。四者相互连接,因此“换节点仍然无效”并不能直接证明节点存在问题,也可能是请求根本没有进入内核,或被更靠前的规则送往了其他策略。
客户端更新和内核更新解决的问题不同。客户端更新可能改变安装方式、界面布局、系统服务和订阅管理;内核更新则更可能涉及协议实现、DNS 行为、规则语法与网络栈。更新后如果基本连接正常,通常不需要立即重写配置。只有日志出现字段弃用、解析失败,或原有网络行为发生明确变化时,才需要查阅对应文档并调整相关段落。
长期使用时可以保留一份结构简单的基础配置:明确运行模式、端口、DNS、策略组和末尾规则,再通过规则集或覆写扩展需求。配置越庞杂,更新时越难判断是哪一层产生冲突。先保证基础链路可工作,再逐项增加自定义规则,是从旧核迁移到新核时成本更低的维护方式。
配置与排查文章
从 DNS 工作机制、证书错误到路由器部署,文章按具体问题拆解配置链路,便于在客户端能够连接但行为不符合预期时继续定位。
从 DNS 查询进入内核开始,梳理虚假地址池如何保存域名映射、连接阶段如何还原目标,以及浏览器、游戏、局域网服务分别适合怎样的过滤策略。文章同时说明 Redir-Host 的解析路径,帮助判断异常究竟来自地址映射还是上游解析。
阅读全文 →证书错误可能来自系统时间、浏览器缓存、节点链路、本地安全软件或解密设置。文章按报错出现范围逐层验证:先判断是否仅单个站点受影响,再对照直连结果、系统证书状态和代理日志,避免把所有证书问题都归因于节点。
阅读全文 →对比主路由直接运行和旁路由接管两种结构,说明二进制架构、配置目录、透明代理、DNS 转发与开机启动之间的关系。内容侧重部署前的架构判断,帮助确认哪些流量会经过内核、原路由是否仍承担 DHCP 与网关职责。
阅读全文 →