Clash 从零到精通完整手册

Clash 是一个规则驱动的网络代理工具。它的工作方式可以压缩成一句话:读取一份 YAML 格式的配置文件,按配置里定义的规则,决定每一条网络连接是直接发出、还是交给某个代理节点转发。理解这句话,后面所有章节都是它的展开。

内核与客户端

"Clash"这个词在日常语境里其实指两层东西。第一层是内核:一个没有图形界面的命令行程序,负责真正的流量处理、规则匹配和协议实现。原始 Clash 内核已经归档,目前社区活跃维护的继任者是 mihomo 内核。第二层是客户端:包在内核外面的图形界面,负责订阅管理、开关切换、日志展示这些人机交互工作。Clash Plus、Clash Verge Rev、FlClash 这些名字都属于客户端层,它们内部驱动的是同一类内核。这也解释了一个常见疑问:为什么不同客户端能用同一份订阅——因为配置文件是写给内核的,客户端只是搬运工。项目谱系的完整梳理见这篇笔记。

四个绕不开的名词

• 节点(proxy):一台可用的代理服务器,配置里的一条 proxies 记录,包含服务器地址、端口、协议与密钥。
• 订阅(subscription):服务商托管的一个 URL,访问它会返回完整配置或节点列表。客户端定期拉取,节点变更自动同步,不需要手动改文件。
• 策略组(proxy-group):把多个节点打包成一个可选单元,比如"手动选择组""自动测速组"。规则的出口指向策略组,而不是直接指向某个节点。
• 规则(rule):一行"匹配条件 + 出口"的声明,例如"github.com 结尾的域名走代理组"。规则列表自上而下匹配,命中即停。

一条连接的完整旅程

浏览器发起访问,连接先进入 Clash 监听的本地端口。内核取出目标域名或 IP,从规则列表第一条开始逐条比对,命中某条后,把连接交给该规则指定的策略组;策略组再根据自身类型(手动选择或自动测速)确定最终节点;数据经节点转发到目标。整个过程发生在本机,毫秒级完成。之后讲的每一个功能——模式切换、规则编写、TUN——都只是改变这条旅程里某一段的行为。

客户端选错不会造成损失,但会浪费时间。选型只需要回答三个问题:用什么系统;是否需要 TUN 模式接管全局流量;项目是否仍在维护。第三个问题最容易被忽略——已停止维护的客户端不会跟进内核更新,新协议、新规则类型都用不上,系统升级后还可能出现兼容问题。

平台速查表

几条选型经验

Clash Plus 覆盖全部五个平台,界面统一、订阅管理完整,是省心的默认答案;多设备用户尤其受益于操作逻辑一致。Clash Verge Rev 基于 mihomo 内核,配置能力最深,适合愿意接触 YAML 的用户,也是 Linux 桌面的首选。FlClash 走轻量路线,资源占用低,老机器与后台常驻场景表现好。Clash Nyanpasu 仅 Windows,界面风格独特,功能与 Verge Rev 接近。Surfboard 是 Android 上的轻客户端,只做基本代理,不追求高级功能。

四个维度(系统占用、TUN 支持、订阅管理、易用度)的逐项打分对照,见横向评测页,那里有更细的结论;博客里的选型对照笔记补充了具体使用场景。确定选择后直接前往下载页,各平台安装包按同样的顺序排列。

安装本身不复杂,但每个平台都有一道系统级关卡:桌面系统的安全提示、移动系统的 VPN 授权。提前知道会出现什么提示、该点哪个按钮,就不会在第一步卡住。

Windows

从下载页获取安装程序,双击运行。首次运行时 SmartScreen 可能弹出"Windows 已保护你的电脑"——这是对未签名或低下载量程序的通用提示,不是病毒警告。点击"更多信息",再点"仍要运行"即可继续。安装路径建议保持默认;如果之后要用 TUN 模式,首次启动时按客户端提示安装系统服务,授权一次后续不再询问。

macOS

下载 .dmg 镜像,打开后把应用图标拖入 Applications 文件夹。首次打开时 Gatekeeper 会提示应用来自网络下载,选择"打开"确认。注意芯片架构:Apple Silicon 机型(M 系列)下载 arm 版,Intel 机型下载 x64 版,装错架构会经转译层运行,性能明显下降。开启增强模式或 TUN 时,系统会要求输入密码安装辅助工具,属于正常授权流程。

Android

安装 APK 时系统可能提示"不允许安装未知来源应用",在设置里为浏览器或文件管理器临时开启该权限即可。首次点击连接,系统弹出"XX 想要设置 VPN 连接"对话框——Android 客户端通过系统 VPN 接口接管流量,必须同意才能工作,这一步只出现一次。部分厂商系统会激进清理后台,建议在电池优化设置里将客户端加入白名单,否则锁屏后连接可能被切断。

iOS

iOS 的分发渠道是 App Store,搜索 Clash Plus 或通过官网 clashplus.io 提供的入口获取。安装后首次启动,同样会请求添加 VPN 配置的权限,在系统弹窗中确认并验证一次面容或密码即可。iOS 的代理在系统网络层生效,所有应用统一走客户端的规则,不需要逐个应用设置。首次配置的逐步截图版流程,见博客iPhone 首次配置笔记。

Linux

桌面发行版推荐 .deb 包,Debian/Ubuntu 系直接安装:

sudo apt install ./clash-verge.deb
# 如提示依赖缺失:
sudo apt --fix-broken install

Fedora 系使用 .rpm 包配合 dnf install。无图形界面的服务器直接下载 mihomo 内核二进制,解压后配合 systemd 常驻运行,内核下载入口同样在下载页内核区。

客户端装好之后是空的——没有节点,连不上任何地方。节点数据通过订阅进入客户端,这是整条链路里唯一需要外部提供的东西。

订阅的本质

订阅是服务商托管的一个 URL。客户端访问它,得到一份完整的 Clash 配置(或节点列表),里面已经写好 proxies、proxy-groups 和 rules 三大段。之后客户端按设定的间隔重新拉取,服务商更换服务器、增删节点,本地自动同步。导入方式所有客户端一致:复制订阅链接,在订阅或配置页面粘贴,确认下载。具体到每个平台点哪里,教程页有分步说明,此处不重复。

看懂配置文件的骨架

订阅下载下来就是一份 YAML 文本。不需要会写,但看懂骨架对排查问题极有帮助。一份最小配置的全局段长这样:

mixed-port: 7890          # HTTP 与 SOCKS 共用的本地监听端口
allow-lan: false          # 是否允许局域网内其他设备接入
mode: rule                # 启动时的代理模式
log-level: info           # 日志级别,排查时可临时调为 debug
external-controller: 127.0.0.1:9090   # 本地控制接口

下面依次是 proxies(节点列表)、proxy-groups(策略组)、rules(规则列表)。三段的关系:规则指向策略组,策略组指向节点。任何一段名字对不上,配置就会加载失败,客户端日志会给出具体行号。

订阅转换是什么

如果服务商只提供其他格式的节点信息(比如通用分享链接),需要经过"订阅转换"服务把它翻译成 Clash 配置格式。转换过程会经手第三方服务器,订阅内容对其可见,存在泄露面。能拿到原生 Clash 订阅就优先用原生;必须转换时,选择可信的自建或开源转换端。

多台设备共用一份订阅时,推荐"订阅链接集中管理"而不是互相拷贝配置文件,三种同步方案的取舍见多设备同步笔记。

模式决定"规则列表是否参与决策"。三种模式是互斥的全局开关,客户端主界面一键切换,对应配置里的 mode 字段。

常见误用是长期挂 GLOBAL。全局模式下国内网站的流量也绕道境外节点,速度反而变慢,还白白消耗流量配额。正确姿势:99% 的时间停在 RULE,GLOBAL 与 DIRECT 只作为排查工具短暂使用——"切 GLOBAL 能访问、切回 RULE 不能",说明问题出在规则;"切 DIRECT 也不能访问",说明问题与代理无关。

系统代理与模式的区别

另一个容易混淆的开关是"系统代理"。它不属于三种模式,而是决定"操作系统是否把流量送进 Clash":开启后,系统级代理设置指向 Clash 的本地端口,遵守该设置的应用(浏览器等)流量才会进来;不遵守系统代理的应用(部分游戏、命令行程序)则完全绕过。想让所有程序无差别进入 Clash,需要第七章的 TUN 模式。层级关系记住一句话:系统代理/TUN 决定流量进不进来,模式决定进来之后怎么走。

规则分流是 Clash 区别于简单代理工具的核心能力,也是 RULE 模式背后的全部逻辑。订阅自带的规则集能覆盖大部分需求,但早晚会遇到"某个网站分流不对"的时刻——这时候需要看懂规则,必要时自己补一条。

规则的语法

每条规则是一行逗号分隔的声明:类型,匹配值,出口。出口可以是策略组名,也可以是内置的 DIRECT(直连)与 REJECT(拦截)。常用类型如下:

顺序决定一切

规则列表自上而下匹配,第一条命中的规则立即生效,后面的全部忽略。因此排列有固定章法:精确的放前面,宽泛的放后面,兜底的放最后。一个最小可用的国内外分流规则集:

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

读法:命中已知国外域名走代理;.cn 后缀直连;解析出的 IP 归属中国大陆直连;以上都没命中,兜底走代理。注意 GEOIP 需要先做 DNS 解析才能拿到 IP,把域名规则放在它前面,能让大多数连接在解析前就完成分流;IP-CIDR 规则加 no-resolve 参数可以避免为纯域名连接触发不必要的解析。

策略组:规则的出口

上例中的 PROXY 是策略组名。常见组类型:select 手动选择,url-test 定期测速自动选最快,fallback 首选节点故障时自动切换备用。一个典型组合:

proxy-groups:
  - name: PROXY
    type: select
    proxies: [AUTO, 香港节点, 日本节点]
  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港节点, 日本节点]

手动组里嵌一个自动测速组,平时选 AUTO 省心,特殊需求时手动锁定某个节点。

规则不生效的排查路径

1. 确认当前是 RULE 模式——GLOBAL 与 DIRECT 下规则完全不参与。
2. 打开客户端的连接面板,找到目标连接,看它实际命中了哪条规则。绝大多数"分流不对"是被列表更靠前的宽泛规则截胡。
3. 检查自定义规则是否写在了订阅规则之后——追加在 MATCH 后面的规则永远轮不到。
4. 域名规则不生效但 IP 规则生效,通常是 DNS 层的干扰,结合第七章的 fake-ip 排查。

带真实案例的完整实战,见博客规则分流实战笔记。

第五章留了一个缺口:系统代理只对"遵守系统代理设置"的应用有效。命令行工具、部分游戏客户端、某些聊天软件会自行建立连接,完全绕过代理。TUN 模式就是补这个缺口的方案。

原理

开启 TUN 后,客户端在系统里创建一块虚拟网卡,并把它设为默认路由。所有应用的网络流量——无论是否理会代理设置——都会先经过这块网卡进入 Clash 内核,再按规则分流。效果上等同于移动端的 VPN 接管:应用无感知,分流对全系统生效。代价是需要更高的系统权限:Windows 上要以服务方式运行或授予管理员权限,macOS 上要授权系统扩展,Linux 上需要相应的网络管理权限。各客户端首次开启时都会引导完成授权,授权一次长期有效。

配置示例

tun:
  enable: true
  stack: system
  auto-route: true              # 自动配置路由表
  auto-detect-interface: true   # 自动识别物理出口网卡

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query

图形客户端里这些项通常是现成开关,不必手写;贴出来是为了让你知道开关背后改的是什么。stack 是协议栈实现,不同实现兼容性略有差异,遇到特定应用异常时可以换一种再试。

为什么 TUN 总是和 fake-ip 一起出现

TUN 接管流量后,DNS 解析也必须由 Clash 统一处理,否则会出现"解析在外、流量在内"的错位,域名规则失效。fake-ip 模式下,内核对每次域名解析返回一个保留网段的虚拟 IP,应用拿虚拟 IP 发起连接,内核凭映射表还原出原始域名再做规则匹配——既跳过了真实解析的等待,又保证域名规则始终可靠。副作用是个别对 IP 敏感的程序(局域网发现、部分登录校验)可能不适应,此时把相关域名加入 fake-ip 过滤列表即可。

配置跑通只是开始。代理是长期使用的基础设施,值得花十分钟建立一套低成本的维护习惯,避免"某天突然全断"时手忙脚乱。

订阅更新策略

在客户端里为订阅设置自动更新间隔,24 小时一次是合理默认;服务商公告更换服务器时,手动触发一次立即更新。更新失败不会清空现有节点,客户端会继续用上一份缓存,所以偶发的更新失败不必紧张,连续多天失败才需要检查订阅地址是否已被服务商重置。

日志:排查的第一现场

所有客户端都提供日志面板。日常保持 info 级别即可;排查问题时临时调到 debug,可以看到每条连接的规则命中、DNS 解析与出口选择。看日志的基本姿势:复现问题,立刻看最新几行,关键词通常是 error、timeout、refused。定位后记得调回 info,debug 日志量大,长期开启浪费磁盘。

备份与多设备一致性

需要备份的东西其实很少:订阅链接本身、自定义规则片段、客户端里改过的设置项。订阅链接存进密码管理器;自定义规则单独存一份文本。多设备场景优先让每台设备各自拉取同一订阅,而不是手动搬运配置文件;部分客户端支持 WebDAV 备份,可以把界面设置也同步走。三种方案的完整对比见多设备同步笔记。

常见故障的排查顺序

断网时不要立刻改配置,按由外到内的顺序确认,九成问题在前三步就能定位。第一步:关掉客户端,直接访问一个国内网站,确认本机网络本身通畅——家用宽带掉线、Wi-Fi 认证过期这类原因和 Clash 无关,却最常被误判成客户端故障。第二步:打开客户端但切到 DIRECT 模式,如果这时一切正常,说明问题出在代理链路而不是客户端安装;如果连 DIRECT 都不通,那是本机代理设置或虚拟网卡残留的问题,退出客户端并检查系统代理开关是否被遗留在开启状态。第三步:切回 RULE 模式,在策略组里手动换一个节点并做延迟测试,全部节点都超时通常意味着订阅过期、流量配额用尽或服务商线路调整,登录服务商后台看公告与剩余流量比改任何配置都直接。

如果前三步都正常,只有个别网站或应用异常,那就属于分流问题而非连通问题,回到第六章的排查方法:看日志里那条连接命中了哪一行规则,再决定是补一条更精确的规则,还是调整规则顺序。还有一类容易被忽略的现象是"能打开网页但视频不加载、登录一直转圈",多数与 DNS 或 fake-ip 相关,可以先关掉 TUN 用系统代理复测:如果关掉就正常,说明需要把相关域名加入 fake-ip 过滤名单,而不是换节点。养成"一次只改一个变量"的习惯,每改一项就复测一次,才能真正知道是哪一处生效,否则改了五处全部恢复,下一次遇到同样问题依然是从零开始。

升级客户端

客户端更新通常同时带来内核更新,建议跟进,新规则类型与协议支持都依赖内核版本。升级前看一眼发布说明里是否有配置不兼容提示;主流客户端升级会保留订阅与设置,但重大版本跨越前,把订阅链接抄出来再动手,成本几乎为零,收益是绝对安心。新版安装包始终从下载页对应平台获取。

走完前八章,日常使用已经没有障碍。这一章给出继续深入的三个方向,按投入产出排序。

方向一:接管自己的规则

订阅自带的规则是服务商的通用方案,进阶的第一步是建立自己的规则层。多数现代客户端支持"配置覆写"或"Merge/Script"机制:在不修改订阅原文的前提下,把自定义规则注入到规则列表头部——订阅更新不会冲掉你的修改。从小处开始:把日常遇到的分流错误逐条修正,积累三个月,你会得到一份完全贴合自己使用习惯的规则层。规则集(rule-providers)是更工程化的组织方式,把规则按用途拆成可独立更新的远程文件,值得在规则超过百条后引入。

方向二:读懂 mihomo 的增强能力

mihomo 内核在经典 Clash 配置格式之上扩展了不少能力:更多协议支持、更细的 DNS 控制、进程级匹配规则、出站接口绑定等。这些特性大多需要手写配置片段才能启用,官方文档是唯一权威来源。学习方法是逐项实验:每次只加一段,加载成功再加下一段,配置报错时日志会精确到行号。在服务器或软路由上直接部署内核 + systemd,是这个方向的毕业项目——没有图形界面兜底,所有行为都由你写的 YAML 决定。

方向三:理解生态,判断信息

Clash 生态项目多、更名频繁,搜索到的教程经常基于已归档的旧项目,照做会掉坑。建立谱系认知——哪个内核是活跃的、哪些客户端基于它、哪些项目已停止维护——能让你快速判断一篇教程的时效性。开源谱系梳理是入口;之后关注各项目的发布页,而不是二手转载。

推荐的学习顺序

1. 用教程页跑通基本流程,稳定使用两周。
2. 回到第六章,看懂订阅自带的规则列表,修正一条真实遇到的分流错误。
3. 开启 TUN,理解 fake-ip,覆盖命令行与全局场景。
4. 引入配置覆写,建立自己的规则层。
5. 在闲置设备上部署纯内核,完成从用户到管理者的转变。

每一步都建立在上一步的肌肉记忆上,不建议跳级。遇到具体名词回名词解释查,客户端相关疑问看横向评测,工具本身随时从下载页获取。