开源生态 · 全平台客户端与配置文档

Clash帮助中心:客户端下载与问题排查

从当前设备开始:选择合适的 Clash 客户端,导入订阅后核对 规则命中与策略组;连接异常时,再按系统代理、DNS 和内核日志逐层定位。

永久免费 代码开源 五大平台 中文配置文档

CONFIG TRIAGE

先判断问题属于哪一层

Clash 的界面、内核、订阅、规则和系统网络设置是不同层。遇到异常时先缩小范围,再修改配置;一次改动一个变量,才能知道哪一步真正有效。

DOMAIN-SUFFIX

规则从上到下匹配,首次命中后停止

规则分流解决的是“某个请求应该交给哪个策略组”。排查时先在连接记录中找到目标域名,再看它命中的规则类型与目标策略。若请求提前命中宽泛规则,后面的精确规则不会执行。调整时应把更具体的域名规则放在更宽泛的 GEOIP 或 MATCH 之前,并确认规则指向的策略组名称确实存在。规则正确但出口仍不符合预期时,问题通常已经进入策略组层,不应继续反复改域名规则。

DOMAIN-SUFFIX,youtube.com,PROXY

PLATFORM ROUTES

按当前设备选择客户端

先确认操作系统与处理器架构,再进入对应平台查看客户端。桌面安装包、移动端应用和命令行内核的用途不同,不要仅凭文件名相似就混用。

DESKTOP / 01

Windows

适合需要托盘控制、系统代理切换和图形化订阅管理的桌面用户。下载前在“设置 → 系统 → 系统信息”确认是 x64 设备;安装被系统拦截时,应先核对文件来源和安全提示内容,不要关闭整套安全防护。

前往下载

DESKTOP / 02

macOS

先在“关于本机”确认 Apple 芯片或 Intel 处理器,再选择对应安装包。首次启动可能需要在系统设置中确认应用权限;若系统代理已经开启但浏览器仍直连,应检查客户端内核是否实际运行。

前往下载

MOBILE / 03

Android

Android 客户端通过系统 VPN 接口接管流量。首次连接要确认 VPN 授权,并将客户端从电池优化限制中排除;锁屏后断开通常属于后台进程被系统回收,不应先修改订阅或规则。

前往下载

MOBILE / 04

iOS

iOS 客户端首次连接时会请求添加 VPN 配置,这是系统建立网络隧道所需的授权。导入订阅后若没有节点,先检查订阅内容是否兼容当前客户端,再确认蜂窝网络权限与 VPN 状态。

前往下载

DESKTOP / SERVER / 05

Linux

桌面环境可选择图形客户端,服务器、路由器和容器环境通常直接使用 Mihomo 内核。安装前确认发行版、CPU 架构与包格式;服务启动后先读取日志和监听端口,再配置系统服务与开机启动,避免把“进程未运行”误判为规则问题。

前往下载

FIRST CONNECTION

三步完成首次连接

首次设置只处理主链路:配置来源、出口策略、系统接管。高级 DNS、TUN 和规则覆写留到基础连接验证通过之后再调整。

  1. 导入订阅或本地配置

    打开客户端的配置或订阅页面,粘贴完整订阅地址并执行更新。看到配置名称、策略组和节点列表后,再把该配置设为当前启用项。若提示更新失败,先确认订阅没有过期,并在关闭系统代理的状态下测试地址是否可访问。不要连续导入同一地址制造多份重复配置,否则后续很难确认正在使用哪一份。

    PROFILE → IMPORT → ACTIVATE
  2. 选择规则模式与出口策略

    新配置通常已经提供规则模式和若干策略组。先保持规则模式,在主策略组中选择一个可用出口;不确定节点状态时,可逐个切换做短时间连接测试。全局模式适合临时判断是否为规则问题,但不适合作为长期排查结论。若全局可用而规则模式不可用,应回到连接记录查看请求命中了哪条规则。

    MODE: RULE · GROUP: PROXY
  3. 开启系统接管并验证请求

    桌面端开启系统代理,移动端确认 VPN 授权;需要接管不遵循系统代理的应用时,再评估 TUN 模式。连接后先访问一个直连站点和一个需要代理的站点,并在客户端连接记录中核对两类请求的策略。测试结束后若只有单个应用不生效,应检查该应用是否使用独立代理或自带 DNS,而不是立即重装客户端。

    SYSTEM PROXY / VPN → CONNECTIONS

OPEN SOURCE CONTEXT

理解客户端、内核与配置的关系

Clash 不是单一安装包名称。实际使用由图形客户端、代理内核、订阅配置和系统网络接口共同组成。知道每一层负责什么,才能避免在错误位置反复尝试。

克隆 Mihomo 源码仓库
git clone https://github.com/MetaCubeX/mihomo.git
HISTORY

项目历史:名称延续,组件已经分化

早期 Clash 提供规则匹配、策略组、代理协议和控制接口等基础能力。随着原项目状态变化,社区出现了继续维护的内核分支和多种图形客户端。今天用户口中的“Clash”经常指整个配置与客户端生态,而不是唯一程序。选择软件时应同时确认客户端维护状态、所用内核和目标平台,不能只看名称中是否包含 Clash。

ECOSYSTEM

开源生态:界面不同,配置基础相通

不同客户端会重新组织订阅、代理组、日志和系统代理等操作入口,但底层仍围绕 YAML 配置、规则匹配和控制接口工作。这种分工让桌面端、移动端和服务器端可以选择不同外壳,也意味着某个界面教程不能逐按钮套用到所有客户端。跨平台迁移时,优先理解字段和流量路径,再寻找对应界面位置。

CORE

内核关系:Mihomo 处理实际网络流量

Mihomo 是当前 Clash 生态中常见的持续维护内核。图形客户端负责下载配置、展示策略、调用控制接口和管理系统权限,真正建立连接、执行规则、处理 DNS 与转发流量的是内核。客户端能打开不代表内核已经成功启动;节点列表存在也不代表代理链路可用。遇到异常时,内核日志比界面上的笼统提示更接近故障位置。

UPDATE

更新机制:客户端、内核与订阅分开检查

客户端更新解决界面功能和平台兼容问题,内核更新涉及协议、规则与网络处理能力,订阅更新则替换节点和服务方提供的策略内容。三者不是同一条更新通道。排查“更新后不能用”时,要记录究竟更新了哪一层,并保留上一份可用配置用于对照。配置字段发生兼容变化时,先阅读客户端说明,再逐项迁移本地覆写。

FAULT ORDER

固定排查顺序比反复重装更有效

第一步确认订阅:检查有效期、更新结果和当前启用配置。第二步确认内核:查看是否成功启动、端口是否被占用、日志是否存在配置解析错误。第三步确认策略:用连接记录判断目标请求命中了哪条规则和哪个策略组。第四步确认系统接管:桌面端检查系统代理,移动端检查 VPN 授权,TUN 用户检查虚拟网卡与权限。第五步才处理 DNS:区分域名解析失败、解析结果不符和连接阶段失败。

每完成一步都做同样的测试,并记录结果。若直连网络本身不可用,先恢复基础网络;若只有个别节点超时,优先更换节点;若所有节点都失败但订阅可更新,检查系统时间、协议参数和网络限制;若浏览器可用而特定应用不可用,再检查该应用是否绕过系统代理。这样的顺序能把同一现象拆成可验证的问题。

QUICK ANSWERS

常见问题精选

Clash 订阅更新失败先检查哪里?

先确认订阅有效期和地址完整性,再关闭当前系统代理,用直连网络测试订阅地址。浏览器可以访问而客户端仍失败时,检查系统时间、配置目录写入权限,以及客户端是否错误地通过失效代理执行更新。相关字段含义可在术语手册中继续核对。

系统代理已经开启,为什么部分应用仍然直连?

部分应用不会读取系统代理,或会使用独立网络栈与自带 DNS。先在连接记录中确认客户端是否看到了该应用请求;完全没有记录时,问题位于系统接管层,可评估 TUN 模式。已有记录但策略不对时,再检查规则和进程匹配。

节点全部超时和个别节点超时有什么区别?

个别节点超时通常指向节点状态或具体线路;全部节点同时超时更可能与订阅失效、本地网络、系统时间、内核未启动或协议参数有关。先用直连网络确认普通网页可访问,再查看内核日志,不要一开始就批量修改 DNS 与规则。

规则模式不可用,但全局模式可以访问,下一步看哪里?

这说明基础代理链路大概率已经建立,下一步应查看目标域名在规则模式下命中的规则和策略组。重点检查宽泛规则是否提前截获请求、规则引用的策略组是否存在,以及该策略组当前选择的出口是否可用。

FIELD NOTES

近期使用与排查文章

文章按具体症状展开,先给判断依据,再给操作顺序。遇到节点超时、首次安装或移动端导入问题时,可从对应场景直接进入。

故障排查

Clash 节点超时无法连接怎么办:按这个顺序排查最快

先区分全部节点超时与个别节点超时,再依次检查订阅、直连网络、系统时间、内核状态和协议参数。每一步都有明确的停止条件,避免同时改动多个设置。

阅读全文 →
平台指南

iOS 上用 Clash:App Store 获取客户端与配置导入步骤

说明客户端获取、首次 VPN 授权和订阅导入的完整顺序,并区分订阅链接与本地配置文件两种入口。导入后没有节点时,可按兼容性与网络权限继续定位。

阅读全文 →
入门指南

Clash 第一次安装设置全流程:跨平台通用要点与常见坑

从选择安装包、导入订阅到开启系统代理,梳理五大平台共有的设置主线。安装被拦截、订阅导入失败和代理未生效分别放到对应层处理。

阅读全文 →