Clash 从零到精通:安装配置与规则分流完整手册

把 Clash 类客户端拆开看,本质只有三件事:在本机开一个监听端口接收流量、按一套规则判断每条连接该走哪条路、把决定走代理的连接转发到远端节点。后面章节出现的每一个配置项,都能归到这三件事里的某一件。本章不操作任何东西,只把概念讲到后面用得上的程度。

代理客户端在做什么

客户端启动后,会在本机监听一个或多个端口,最常见的是 HTTP 与 SOCKS5 合一的混合端口。操作系统或浏览器把网络请求发给这个端口,客户端拿到请求后查规则表:命中直连规则的,从本机网卡直接发出;命中代理规则的,封装后发给远端代理服务器,由服务器代为访问目标。对系统里其他程序来说,客户端就是一个普通的本地代理;对目标网站来说,访问来源是远端节点。

新手最容易混淆的一点:装了客户端不等于有了代理能力。客户端本身不附带任何节点,它是「调度器」;节点来自订阅或手动添加,才是流量的「出口」。两者缺一不可,第四章专门讲节点怎么进来。

内核:mihomo 是当前活跃主线

Clash 生态有两条内核线。原版 Clash 内核早已停止更新并归档;社区主线是 Clash Meta,后续更名为 mihomo,本站下载中心提供的图形客户端全部基于 mihomo。mihomo 在原版基础上扩展了更多代理协议、规则类型与 TUN 增强能力,配置语法保持向下兼容,旧配置文件基本可以平移。两条内核线的详细差异,博客有专文《Clash 内核区别:原版 Clash、Clash Meta 与 mihomo》逐条梳理,这里只记结论:新装一律选 mihomo 系客户端。

节点、规则、订阅:三要素

节点(Proxy)是一台远端代理服务器加一组连接参数:地址、端口、协议、凭据。常见协议有 Shadowsocks、VMess、Trojan、Hysteria 等,客户端负责按协议封装流量,普通用户不需要关心封装细节。

规则(Rule)是分流判断条件,形如「域名后缀是某值就走直连」。规则表是一份有序列表,第六章展开。

策略组(Proxy Group)是规则与节点之间的中间层:规则不直接指向某个节点,而是指向一个策略组,组内再决定用哪个节点——可以手动选,也可以自动测速选。第五章展开。

订阅(Subscription)是一个定时返回配置文本的 URL,文本里打包了节点、策略组与规则。有了订阅,上面三样东西一次到位,第四章展开。

一次请求的完整路径

以浏览器访问一个网站为例:浏览器把请求交给系统代理设置指向的本地端口;客户端接管连接,从上到下逐条匹配规则表;规则命中「代理」策略组,策略组按自身策略选出一个节点;客户端与节点建立加密连接,把请求转发出去;响应沿原路返回。整个过程在本机完成,对浏览器完全透明。

客户端没有绝对的好坏,只有平台与使用习惯的匹配。本章给出按平台对号入座的结论;逐个客户端的横向参数对比见客户端对比页,安装包统一在下载中心按平台领取。

五个平台的选择

Windows:首推 Clash Plus,界面与内核同步更新;备选 Clash Verge Rev(功能面板全)、FlClash(跨平台统一体验)、Clash Nyanpasu(界面风格独特)。

macOS:首推 Clash Plus,Apple Silicon 与 Intel 双架构分别提供安装包;备选 Clash Verge Rev 与 FlClash,同样区分芯片架构,装错架构能启动但性能打折。

Android:首推 Clash Plus;备选 Clash Meta for Android(内核同名客户端,更新勤)、FlClash、Surfboard(界面极简)。

iOS:Clash Plus 已上架 App Store,直接搜索安装,官网 clashplus.io 有平台说明。iOS 上代理客户端以系统级配置形式工作,体验与桌面端一致。

Linux:桌面环境用 Clash Verge Rev 或 FlClash,提供 deb 与 rpm 包;服务器、路由器等无界面场景直接部署 mihomo 内核,用配置文件加外部控制器管理,第九章展开。

内核线:原版与 mihomo

原版 Clash 内核停更后,基于它的经典客户端也随之停止维护:Windows 平台的 Clash for Windows、macOS 平台的 ClashX Meta。下载页保留这两个客户端仅为归档参考,卡片上带「已停止维护」标记。新装用户不需要纠结历史:直接选 mihomo 系的在维护客户端,协议支持最全,规则类型最新。

从停止维护的客户端迁移

如果机器上还在用 Clash for Windows 或 ClashX Meta,短期继续使用没有问题,但新协议与新规则类型不会再获得支持,遇到节点连不上先怀疑这一点。迁移成本很低:记下现有订阅链接,装一个 mihomo 系客户端,重新导入订阅即可;订阅里自带的策略组与规则会自动带过来,不需要逐条手抄。

本章按平台讲安装路径与装完之后的检查项,下载链接不在这里重复,统一去下载中心按平台领取。四大平台首次安装的通用流程与新手高频坑,博客另有《Clash 首次安装与初始设置》一文可作对照。

Windows

下载 .exe 安装包按向导安装即可;多数客户端同时提供便携版,解压即用、不写注册表,适合放 U 盘或多机迁移。系统要求以下载页各卡片标注为准,主流客户端要求 Windows 10 及以上。首次启动如果系统弹出防火墙提示,允许客户端在专用网络通信——仅本机使用也建议放行,避免后续排查网络问题时多一层干扰。

macOS

下载与芯片对应的 dmg:Apple Silicon 选 arm64 版,Intel 机型选 x64 版。把应用拖进「应用程序」后首次打开,如果系统提示「无法验证开发者」,到「系统设置 → 隐私与安全性」里点「仍要打开」。菜单栏出现客户端图标即启动成功。

Android 与 iOS

Android 从下载页拿 apk 直接安装,系统会要求允许「安装未知来源应用」,装完可以把这个授权关掉。首次连接时系统弹出 VPN 连接请求,这是 Android 上代理客户端的标准工作方式,必须允许,否则客户端无法接管任何流量。iOS 在 App Store 安装 Clash Plus,首次添加配置时同样要允许系统弹出的 VPN 配置请求。

Linux

桌面发行版用 deb 或 rpm 包装 Clash Verge Rev 或 FlClash,装完从应用菜单启动。服务器与路由器场景不要图形界面:下载对应架构的 mihomo 内核二进制,配上 config.yaml,用 systemd 托管进程,通过外部控制器管理,具体思路见第九章。

首次启动四项检查

装完先别急着导入订阅,花两分钟确认四件事:

• 界面语言:多数客户端首次启动可在设置里切换中文界面。
• 开机自启:在设置里打开,避免每次开机手动启动。
• 系统代理开关的位置:先找到它在哪——第四章导入订阅之后要开它,流量才真正进客户端。
• 混合端口号:记下来(常见默认 7890),以后命令行工具临时走代理、局域网共享都要用到这个端口。

四项确认完,安装阶段结束,进入第四章导入订阅。

节点、策略组、规则三样东西,靠一个订阅链接一次到位。本章讲订阅是什么、怎么导入、怎么更新,以及更新失败时按什么顺序排查。

订阅链接是什么

订阅链接是一个返回配置文本的 URL,文本内容就是节点列表、策略组与规则表。客户端定时请求这个 URL 拿到最新配置。订阅链接由节点服务方提供,客户端本身不附带任何节点。链接里通常带有用户凭据,地位等同账号密码:不要贴到公开场所,不要导入来历不明的订阅,换设备时手动搬运而不是转发群聊。

导入订阅的三种方式

URL 导入(最常用):复制订阅链接,打开客户端的「配置/订阅」页,新建配置,粘贴 URL,起个名字保存。剪贴板导入:部分客户端能识别剪贴板里的订阅链接,复制后打开客户端会提示一键导入。本地文件导入:手上现成有 config.yaml 时,从配置页选择「导入本地文件」,或直接把文件放进客户端的配置目录。

导入只是让配置出现在列表里,还要把它设为「启用/活动」配置,客户端才真正按这份配置工作。多份订阅可以共存,切换活动配置即切换整套节点与规则。

更新订阅与自动更新

节点会增减、规则会修订,订阅需要定期更新。客户端一般同时提供手动「更新」按钮与自动更新间隔,建议打开 24 小时自动更新,再养成「感觉节点不对劲先手动更一次」的习惯。更新失败时客户端沿用旧配置继续工作,不会立刻断网;但长期更新失败意味着节点列表停留在旧版本,失效节点会越积越多。

订阅更新失败:按四步排查

①网络可达性:订阅地址本身能否访问。先关掉系统代理用直连试一次——部分订阅地址在代理环境下反而被拦。②链接有效性:链接是否过期、被重置或套餐到期,找服务方核对。③客户端标识:部分服务方按客户端 UA 分发不同格式,换客户端或把客户端更到新版后再试。④系统时间:TLS 证书校验依赖系统时间,时间偏差过大直接握手失败,校准时间再更新。

订阅返回的配置文本长这样(片段):

proxies:
  - name: "节点-示例"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["节点-示例", "DIRECT"]

rules:
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

拿到一份配置能认出这三段,后面章节改配置就不慌了:proxies 是节点、proxy-groups 是策略组、rules 是规则表。

三种代理模式决定「规则表用不用、怎么用」。切换入口一般在客户端首页或托盘菜单,随时可切、立即生效,不需要重启客户端。判断当前处于哪个模式,看客户端首页或托盘图标的模式标识即可。

规则模式(Rule)

默认推荐,日常常驻。每条连接按规则表从上到下逐条匹配:命中代理就走节点,命中直连就走本地网卡。国内网站直连保证速度,国外网站走代理保证可达,两者互不干扰。订阅自带的规则表已经覆盖主流场景,大多数人常年不需要动它。

全局模式(Global)

所有连接无条件走代理策略组选出的节点,规则表整体停用。适用场景有两个:临时验证节点是否可用;访问某些必须全程同一出口的服务。长期挂全局会把国内流量也绕到境外节点,速度变慢还容易触发网站风控,用完记得切回规则模式。

直连模式(Direct)

所有连接不走任何节点,客户端只接管不转发。适用场景:对照测试——怀疑「是节点坏了还是客户端坏了」时,切直连能访问说明客户端与规则没问题,问题在节点;在完全可信的网络里短暂停用代理时也可以用。

策略组:节点的分组容器

策略组是规则与节点之间的中间层。规则不直接指向节点,而是指向策略组;策略组按自己的类型决定最终用哪个节点。常见四种类型:

• select 手动选择:组内列出节点,用户手点切换,最常用,适合「主力节点+备用节点」的固定组合。
• url-test 自动测速:定时对组内节点发起测速请求,自动切到延迟最低的一个,适合节点多、不想手动维护的场景。
• fallback 故障转移:按列表顺序用第一个可用节点,挂了自动切下一个,适合追求稳定不追求最快的场景。
• load-balance 负载均衡:把连接分摊到组内多个节点,适合大流量下载类场景。

策略组在配置里长这样:

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["自动选择", "节点-示例", "DIRECT"]
  - name: 自动选择
    type: url-test
    proxies: ["节点-示例"]
    url: http://example.com/generate_204
    interval: 300

订阅自带的策略组通常已经够用:一个手动选择组管日常,一个自动测速组管兜底。想按地区、按用途自己分组,属于第九章的手写配置内容。

规则分流是 Clash 类客户端的核心能力,也是它区别于「全局进隧道」式工具的核心价值。本章把规则类型讲全、把匹配顺序讲透,再给一套国内外分流的实战配置与验证方法;更细的规则写法案例,博客有《Clash 规则分流配置实战》一文可作补充。

规则类型清单

mihomo 支持的规则类型很多,日常高频使用的就这几类:

• DOMAIN:精确匹配单个域名,如 DOMAIN,example.com,PROXY,只命中这一个域名本身。
• DOMAIN-SUFFIX:匹配域名后缀,如 DOMAIN-SUFFIX,example.com,PROXY,命中该域名及其所有子域名,是最常用的域名规则。
• DOMAIN-KEYWORD:域名包含某关键词即命中,如 DOMAIN-KEYWORD,example,PROXY,覆盖面大、误伤面也大,慎用。
• GEOSITE:按域名分类库匹配,如 GEOSITE,cn,DIRECT 命中分类库里的中国大陆域名合集,一条顶几万条手写规则。
• IP-CIDR:按目标 IP 段匹配,如 IP-CIDR,192.168.0.0/16,DIRECT 让局域网地址全部直连。带 no-resolve 参数的规则不触发 DNS 解析,纯 IP 连接才命中。
• GEOIP:按 IP 归属地匹配,如 GEOIP,CN,DIRECT,域名会先解析成 IP 再查归属地库。
• PROCESS-NAME:按发起连接的进程名匹配,桌面端可用,如让某个下载工具固定走代理。
• DST-PORT / SRC-IP-CIDR:按目标端口、来源 IP 段匹配,常用于局域网共享与网关场景。
• MATCH:兜底规则,匹配一切,必须是规则表的最后一条。

匹配顺序:从上到下,首条命中即停

规则表是一份有序列表:每条新连接从第一条开始向下比对,命中哪条就按哪条执行,后面的规则不再看。这条机制引出两条铁律:①越具体、越特殊的规则放越前面,越宽泛的放越后面;②MATCH 兜底永远在最后,它一旦靠前,后面的规则全部失效。排查「某网站走的路线不对」时,第一反应应该是查顺序——是不是有一条更宽的规则排在前面把它截走了。

规则引用的目标可以是策略组也可以是保留字:DIRECT 直连、REJECT 拒绝连接(常用于广告与追踪域名拦截)、策略组名则交给该组决定出口。

GEOSITE 与 GEOIP 数据文件

GEOSITE 与 GEOIP 规则依赖两个分类数据文件(geosite.dat 与 geoip 系数据),它们随客户端分发、也持续由社区更新。数据文件过时会导致新域名归类不准,表现为「该直连的走了代理」或反之。主流客户端在设置里提供数据文件更新入口,建议与订阅更新一起列入月度维护,详见第八章。

实战:国内外分流配置

一套典型的国内外分流规则表(节选,顺序即匹配顺序):

rules:
  # 局域网与保留地址直连
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # 国内域名与 IP 直连
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  # 其余全部交给代理策略组
  - MATCH,PROXY

在这个骨架上做加减:某个国外站点想强制走代理,在 GEOSITE 行前加一条 DOMAIN-SUFFIX,目标域名,PROXY;某类广告域名想直接掐掉,加 GEOSITE,category-ads-all,REJECT 并放在最前。订阅自带规则表时,优先在客户端的「覆写/自定义规则」入口追加,而不是直接改订阅文件——订阅一更新,手改的内容就丢了。

验证分流结果

改完规则必须验证。打开客户端的「连接」面板,访问目标网站,看新产生的连接条目:面板会显示这条连接命中的规则、最终走的策略组与节点。命中与预期不符,就按连接面板显示的规则名回去调顺序。客户端日志开到 debug 级别时,也会逐条打印规则判定过程,适合更细的排查。

系统代理有一个天然盲区:它只对「遵循系统代理设置」的应用生效。浏览器、多数桌面软件会读系统代理;但命令行工具、部分游戏、一些自己管理网络栈的应用,以及几乎所有 UDP 流量,都会绕过它直连。TUN 模式解决的就是这个盲区。

TUN 是什么

TUN 模式在系统里创建一张虚拟网卡,并修改路由表,让全系统的 TCP/UDP 流量都先经过这张虚拟网卡进入客户端,再由客户端按规则分流。接管发生在网络层,不依赖应用是否配合,因此命令行、游戏、系统服务、UDP 应用全部纳入分流范围。Android 上客户端本来就以 VPN 服务方式工作,效果与 TUN 等价;TUN 主要是桌面端(Windows/macOS/Linux)的增强开关。

与系统代理的分工

两者不冲突,可以叠加:系统代理管「听话的应用」,TUN 管「不听话的」。多数客户端开 TUN 时会自动处理好与系统代理的关系,不需要手动二选一。日常浏览为主、偶尔用命令行的用户,只开系统代理足够;经常跑命令行工具、玩外服游戏、需要 UDP 转发的用户,建议常驻 TUN。

开启条件

TUN 要动系统网络栈,权限要求比普通代理高。Windows 上主流客户端以「服务模式」实现:在客户端设置里按提示安装服务,之后 TUN 开关即可正常使用,不需要每次以管理员身份启动客户端本体。macOS 首次开启会要求输入系统密码授权安装帮助程序。Linux 桌面端同样需要授权;服务器上用内核直接开 TUN 时,进程需要相应网络权限。

配置示例

图形客户端里 TUN 通常只是一个开关,底层对应配置里的 tun 段,手写配置时长这样:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

几个关键字段:stack 是虚拟网卡的协议栈实现,mixed 是兼容性与性能兼顾的常用值;auto-route 让客户端自动配置路由表;auto-detect-interface 自动识别出口网卡,避免流量打环;dns-hijack 把系统里所有发往 53 端口的 DNS 查询劫持进客户端的 DNS 模块,配合第九章的 DNS 配置使用。

注意事项

①与其他 VPN/加速器冲突:系统里同时存在两个改路由表的虚拟网卡,流量走向会不可预期,同一时间只保留一个。②防火墙拦截:部分安全软件会拦虚拟网卡驱动,开 TUN 后断网先查这一项。③关闭要干净:异常退出可能残留路由表项导致断网,重启客户端开关一次 TUN 或重启系统即可恢复。④不是所有场景都需要:只刷网页不开 TUN,少一层接管少一类故障。

客户端装好之后,真正花时间的不是配置而是维护:订阅会更新、数据文件会过时、节点会失效、客户端自身也在迭代。本章给出一份可照做的维护清单,外加常见故障的自查路径。FAQ 页收录了更碎的问答,本章只讲成体系的维护动作。

维护清单

订阅更新:保持 24 小时自动更新开启;节点大面积连不上时,第一件事就是手动更一次订阅,排除「客户端拿着过期节点列表」这一最常见原因。

GEOSITE / GEOIP 数据更新:每月一次,入口在客户端设置里。数据文件决定域名与 IP 的分类准确度,长期不更新,分流结果会慢慢偏离现实。

客户端更新:客户端内置更新提示,跟随更新即可。内核更新常带协议与安全修复,不建议长期停留在旧版本。更新前不需要卸载旧版,配置会保留。

配置备份:把订阅链接单独记在密码管理器或加密笔记里;手写配置(自定义规则、覆写)导出一份副本。换机、重装时,有订阅链接加一份覆写备份就能完整还原。

节点失效的处置

单个节点连不上,先在策略组里手动切到备用节点,别急着改配置。整组节点超时,按顺序查:手动更新订阅 → 切全局模式验证是否规则误伤 → 切直连模式确认本地网络正常 → 换网络环境(手机热点)排除宽带出口问题。四步走完仍不通,再找节点服务方。

日志与连接面板

客户端有两个排查利器。连接面板:实时列出每条连接的进程、目标、命中规则、出口节点与流量计数,「某网站为什么没走代理」在这里一眼定位。日志:默认 info 级别记录关键事件;排查疑难时调到 debug,能看到规则逐条判定与 DNS 解析细节,查完记得调回 info——debug 日志量大且会记录访问目标,不适合常开。

常见故障自查表

自查表覆盖不了的问题,去FAQ 页按分类翻;博客的故障排查标签下也有按症状组织的专文,例如《Clash DNS 泄漏检测》。

前八章走完,日常使用已经没有障碍。本章给想继续深入的用户一张路线图,按投入程度从浅到深排列,每一站都有明确的目标与对应的站内资料。

第一站:覆写订阅配置

订阅自带的配置由服务方维护,直接改会在下次更新时被覆盖。正确姿势是用客户端的「覆写/Mixin」功能:定义一份自己的补充片段——追加规则、调整策略组、修改端口——客户端在每次订阅更新后自动把片段合并进去。这是从「用订阅」到「管配置」的第一步,投入小、收益立竿见影。

第二站:规则提供者 rule-providers

规则多了之后,全堆在 rules 列表里难以维护。mihomo 支持 rule-providers:把一类规则(比如某个应用的全部域名)做成独立的外部规则集文件或在线地址,配置里按名字引用,规则集可以独立更新。配合策略组,能搭出「一个应用一个规则集一个出口」的清晰结构。

第三站:DNS 模块

DNS 是分流准确性的地基。客户端内置 DNS 模块接管域名解析:nameserver 指定常规解析服务器,fallback 指定境外域名的备用解析通道,enhanced-mode 控制增强解析行为。配置得当可以消除 DNS 污染对 GEOIP 判定的干扰,并防止解析请求泄漏到代理通道之外。这一站内容较多,直接读博客两篇专文:《Clash DNS 配置详解》讲参数,《Clash DNS 泄漏检测》讲验证与修复。

第四站:局域网共享与网关

开启配置的 allow-lan: true 后,局域网内其他设备(手机、平板、电视)可以把代理指向这台机器的 IP 与混合端口,共享同一个客户端。再进一步,把客户端部署在软路由或常开设备上,配合 TUN 接管整个网段,就是家庭网关方案——所有入网设备免配置分流。

第五站:服务器与路由器部署 mihomo

无图形界面场景直接用内核:下载对应架构的 mihomo 二进制,准备一份完整 config.yaml,用 systemd 托管进程实现开机自启与崩溃重启;开启 external-controller 后,可以通过 API 或网页仪表盘远程管理——切节点、看连接、查日志都不需要登录服务器。示例单元文件:

[Unit]
Description=mihomo proxy core
After=network.target

[Service]
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

配置目录 /etc/mihomo 里放 config.yaml 与 GEOSITE/GEOIP 数据文件。改完配置用 systemctl restart mihomo 生效,用 journalctl -u mihomo 查日志。

持续学习路径

进阶内容的更新入口在站内三处:FAQ 页按「基础认知 / 安装配置 / 使用技巧 / 故障排查」分类收录高频问答;博客持续更新内核、配置、DNS、排查四类专文;教程页适合带新同事新设备时快速过一遍主线。遇到本手册没覆盖的场景,先查 FAQ 的分类导航,再翻博客标签。