Windows
适合桌面日常使用,可选择 Clash Plus、Clash Verge Rev、FlClash 或 Clash Nyanpasu。 安装后需要确认系统代理权限;使用 UWP 应用时,还应检查回环限制是否影响本机代理访问。
集中整理 Clash 客户端安装包、mihomo 内核配置与 YAML 规则分流资料。先按操作系统选择图形客户端,再依照字段说明导入订阅、检查 DNS 行为并确认规则命中结果。
Clash 的请求处理不是单一开关,而是一条由监听入口、DNS、规则匹配、策略组和出站连接组成的处理链。 下列索引按实际配置关系拆开说明,便于判断一个字段位于哪一层,以及修改后会影响哪些请求。
rules 是自上而下执行的有序列表。域名、IP、进程名和规则集都可以作为匹配条件;
一旦某条规则命中,内核便把请求交给该条目指定的策略组、DIRECT 或
REJECT,后续条目不再参与判断。因此,具体域名规则通常放在前面,范围较大的
GEOIP、GEOSITE 与最终兜底规则放在后面。
排查分流结果时,应先查看请求实际命中的规则,再检查规则指向的策略组,而不是直接更换节点。
常见偏差来自规则顺序、域名后缀范围、规则集未更新,或 DNS 返回结果与 IP 类规则的预期不同。
配置字段页进一步列出了 DOMAIN、DOMAIN-SUFFIX、
IP-CIDR、MATCH 等语法及其适用边界。
策略组位于规则与代理节点之间。手动选择组适合需要固定出口的场景;自动测试组会依照配置中的探测地址、 间隔与容差选择可用项;故障转移组则按成员顺序寻找能够连接的出站。策略组还可以包含另一个策略组, 由此把地区、用途与切换方式拆成清晰层级,减少规则文件里重复列出节点名称。
配置时需要同时核对 type、成员来源、健康检查和引用名称。规则中的策略名称必须与
proxy-groups 中的名称逐字对应;节点由订阅更新后,如果组成员依赖固定名称,也可能出现旧名称失效。
对多数图形客户端而言,日常切换只改变策略组当前选项,不会重写原始订阅内容。
DNS 模块负责接收应用查询、选择上游服务器,并把域名结果交给后续规则判断。启用
fake-ip 时,内核先从保留地址池返回映射地址,应用建立连接后再依据映射关系恢复原域名,
从而保留域名规则所需的信息。部分局域网设备、连接性检测和依赖真实地址的程序,可通过
fake-ip-filter 设置例外。
DNS 故障通常需要区分“域名无法解析”和“解析成功但连接失败”。检查顺序包括监听地址、默认解析器、 代理服务器域名的解析路径、加密 DNS 可达性以及系统是否仍把查询发给其他接口。只修改上游地址未必能解决问题, 因为启动阶段解析、规则判断和代理链路可能使用不同的服务器集合。
阅读 DNS 与 Fake-IP 术语 →图形客户端通常会保存远程订阅、本地配置副本和当前运行配置。订阅更新负责获取服务提供方发布的节点与基础策略; 本地覆写用于追加 DNS、规则或界面相关设置;运行配置则是客户端完成合并后交给内核的最终结果。 三者不是同一个文件,直接编辑缓存副本可能在下一次更新时被替换。
维护配置时,应先确定客户端支持的覆写方式,再决定使用前置、后置或字段级合并。YAML 缩进必须保持一致, 同名键的覆盖规则由客户端实现决定,数组字段也可能采用替换而非追加。导入失败时先用最小配置验证语法, 再逐段恢复代理、策略组、DNS 和规则,可以更快定位不兼容字段。
查阅覆写与合并方法 →首页只提供平台入口。安装包格式、客户端差异、系统要求和停止维护状态集中列在下载页, 避免把不同架构的文件混在同一处。进入对应标签后,再依据设备架构与使用方式选择客户端。
适合桌面日常使用,可选择 Clash Plus、Clash Verge Rev、FlClash 或 Clash Nyanpasu。 安装后需要确认系统代理权限;使用 UWP 应用时,还应检查回环限制是否影响本机代理访问。
Apple Silicon 与 Intel 设备应下载对应架构。首次启动可能需要在系统设置中确认网络扩展或代理权限; 如果菜单栏已显示连接状态但请求未经过内核,应进一步核对系统代理与增强模式设置。
可选择 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。导入订阅后,系统会要求建立 VPN 连接;省电策略、后台限制和厂商网络管理功能可能中断常驻连接,需要按设备系统单独确认。
iPhone 与 iPad 可从 App Store 获取 Clash Plus。首次连接需要授权添加 VPN 配置; 导入订阅后先选择策略,再启动连接。系统状态栏出现 VPN 标记只表示隧道已建立,实际访问结果仍取决于规则和出站。
桌面环境可使用 Clash Verge Rev 或 FlClash;服务器、路由器和容器环境通常直接部署 mihomo 内核。 选择文件时应区分软件包格式与 CPU 架构,并自行配置服务管理、工作目录和配置文件读取权限。
判断客户端是否适合当前设备,需要分清图形界面、代理内核与配置格式三个层次。 它们可以由不同项目维护,但通过相近的配置结构和控制接口协同工作。
Clash 生态形成了一套广泛使用的配置模型:代理节点由 proxies 描述,策略选择由
proxy-groups 组织,请求依据 rules 依次匹配,DNS 模块则负责解析与域名映射。
原始 Clash 项目停止持续开发后,社区分支继续扩展兼容字段,其中 mihomo 是当前常见的维护中内核之一。
因此,许多新客户端界面虽然名称不同,底层仍围绕相近的配置结构、控制接口与规则语义工作。
Clash Plus、Clash Verge Rev、FlClash 和其他图形客户端主要负责订阅管理、配置切换、系统代理控制、 日志查看与内核生命周期管理。真正执行 DNS 处理、规则匹配和出站连接的是客户端内置或调用的内核。 遇到问题时先判断故障位于界面层还是内核层:界面无法保存设置属于客户端行为,配置解析失败通常与字段或内核兼容性有关, 连接建立后特定网站仍走错出口,则应检查规则与策略组。
开源仓库中的提交历史、版本发布、问题讨论和配置文档可以交叉核对。比起只看客户端名称, 更有效的判断方式是确认近期提交是否持续、安装包是否覆盖当前架构、内核版本是否支持配置中使用的字段, 以及重大变更是否附带迁移说明。Clash中文站在客户端对比页区分维护中项目与归档项目, 下载页也把停止维护状态直接标在对应卡片上,便于在安装前完成选择。
客户端升级、内核升级和订阅更新是三类不同操作。客户端升级可能改变界面或覆写机制,内核升级可能新增或调整字段, 订阅更新则主要替换节点与服务方提供的规则。执行变更前应导出当前可用配置,记录正在使用的策略模式, 再一次只更新一个层次。若出现解析错误,可回到旧配置并根据日志中的字段位置逐项修正,而不是同时替换客户端、内核和订阅。
下列问题用于完成首次判断。涉及完整字段、客户端差异或逐步排障时,应继续进入对应的帮助页面, 以免在没有日志和配置上下文的情况下直接修改多个设置。
Clash 通常指配置模型及其相关生态;mihomo 是持续维护的兼容内核之一;Clash Plus、Clash Verge Rev、 FlClash 等属于图形客户端。图形客户端负责配置和系统集成,内核负责解析、匹配与连接。 可在术语手册中查看更完整的层次说明。
先确认基础网络可用,再依次检查客户端是否启动内核、系统代理或 VPN 权限是否生效、策略组是否选中可用出站、 DNS 是否能够解析,以及请求最终命中了哪条规则。不要一开始同时修改 DNS、模式和订阅, 逐层检查更容易保留有效线索。完整顺序见帮助中心故障排查。
规则模式按配置文件中的规则决定每个请求去向,适合常规使用;全局模式把大部分请求交给指定策略, 适合临时验证代理链路;直连模式主要用于确认问题是否由代理路径引起。排查结束后通常回到规则模式, 并通过日志确认关键域名命中预期策略。
远程订阅更新通常会替换本地缓存副本。需要长期保留的 DNS、规则或策略调整,应写入客户端支持的覆写文件或合并配置, 而不是直接编辑订阅缓存。不同客户端对数组追加、同名键覆盖和脚本覆写的支持并不完全相同, 应先查阅覆写与合并章节。
需要继续定位安装、订阅、开机自启、Fake-IP 或 UWP 回环问题时,前往 帮助中心查看分类问答 →
文章按具体任务展开,重点记录可复现的检查顺序、字段边界和平台差异。 阅读时可先完成基础检查,再根据日志与配置现象进入对应章节。