Clash 从零到精通完整手册

Clash 是一个以配置文件驱动的规则式代理内核。它本身没有图形界面,启动后读取一份 YAML 格式的配置,在本机监听若干端口,把进入这些端口的网络请求按规则逐条匹配,再决定这条连接走直连、走某个代理节点,还是直接拒绝。你在各类客户端里看到的开关、节点列表、模式切换,底层都是对这份配置和这套匹配流程的封装——理解了这一点,后面每一章都会变得好懂。

原始的 Clash 内核已停止开发,目前生态的事实标准是社区延续的 Mihomo 内核(常被称作 Clash Meta)。Mihomo 完整兼容原有配置格式,并在此基础上补充了更多代理协议、规则类型与 DNS 能力。本站获取客户端页收录的软件,要么直接内置 Mihomo,要么与其配置格式兼容,因此本手册的示例默认以 Mihomo 的行为为准。

客户端与内核是两层东西。内核负责真正的流量转发;客户端负责把内核管起来:替你下载订阅、生成配置、拉起内核进程、设置系统代理、展示节点延迟。换客户端不影响你对内核的理解,配置文件在不同客户端之间大体通用,这也是先学概念再挑软件的原因。

一份完整配置大致由五块组成:端口声明、节点列表(proxies)、代理组(proxy-groups)、规则(rules)与 DNS 设置。骨架如下:

mixed-port: 7890        # HTTP 与 SOCKS 共用的混合监听端口
mode: rule              # 运行模式:rule / global / direct
log-level: info

proxies: []             # 节点列表,通常由订阅填充
proxy-groups: []        # 代理组:把节点组织成可选择的策略
rules:                  # 规则:自上而下匹配,命中即停
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

规则引擎的匹配方式只有一条铁律:自上而下逐条比对,第一条命中的规则决定这条连接的去向,后面的规则不再参与。所以规则的顺序就是优先级,精确规则放前面、兜底规则放最后,这个原则贯穿第 6 章的全部内容。

代理组是 Clash 区别于简单代理工具的关键抽象。规则的出口不直接指向某个节点,而是指向一个组;组内再决定用哪个节点——可以手动选择,也可以按延迟自动挑选。订阅更新、节点增减都发生在组内部,规则本身不用改,这让配置具备了长期可维护性。

最后是端口:内核默认只在本机回环地址 127.0.0.1 上监听,浏览器或系统代理把流量交到这个端口,内核才开始工作。端口号、监听地址都可配置,涉及局域网共享时才需要放开,细节见第 5 章。

挑客户端之前先回答三个问题:用什么系统、要不要 TUN 模式接管全部流量、愿不愿意在配置上花时间。三个问题想清楚,选择范围会立刻收窄。下表是本站下载页收录客户端的速查,与获取客户端页保持一致:

Clash Plus 是全平台首推:Windows、macOS、Android、iOS 四端覆盖,是清单里唯一在 App Store 上架的选择,iOS 用户没有第二条正路。界面把订阅、模式、节点选择收在一层菜单里,默认设置对新手友好,进阶选项也没有阉割,适合作为第一个客户端。

Clash Verge Rev 是 Linux 桌面的主力,也是本手册 Linux 示例的默认对象。它直接内置 Mihomo 内核,提供 deb 与 rpm 安装包,支持配置覆写、Merge 脚本与服务模式,TUN 相关的权限处理也做得比较完整——愿意深入配置的用户会喜欢它暴露出来的细节。

FlClash 用 Flutter 编写,桌面端与移动端界面几乎一致,如果你在手机和电脑之间频繁切换、希望两边操作习惯统一,它是最省心的选择。Clash Nyanpasu 是 Windows 上的另一个活跃分支,界面风格更轻快,功能取向与 Verge Rev 接近,作为备选足够可靠。

Android 上除了 Clash Plus,Clash Meta for Android 是最贴近内核原生行为的选择,配置项直接映射内核字段,适合想看清底层的用户;Surfboard 则走轻量路线,导入订阅即用。Clash for Windows 与 ClashX Meta 均已停止维护,老用户可以继续使用手头版本,新装机不建议从它们开始。

服务器与路由器场景不需要图形界面,直接部署裸 Mihomo 内核:一个二进制文件加一个配置目录即可长期运行,配 systemd 管理进程,细节在第 8 章与第 9 章展开。

所有安装包从获取客户端页对应平台的卡片下载。Linux 用户先确认发行版与 CPU 架构:主流桌面发行版基本是 x86_64(amd64),下载时对准包名里的架构标识,别把 arm64 包装到英特尔或 AMD 的机器上。

Ubuntu / Debian 系

下载 .deb 包后用 apt 本地安装,apt 会自动解析并补齐依赖,这比 dpkg 直装少踩一次依赖坑:

sudo apt update
sudo apt install ./clash-verge-rev_amd64.deb

注意命令里的 ./ 前缀不能省:它告诉 apt 这是本地文件而不是软件源里的包名。安装完成后可以在应用菜单找到图标,也可以直接在终端输入程序名启动。

Fedora 系

sudo dnf install ./clash-verge-rev.rpm

dnf 同样会处理依赖。若提示缺少 webkit2gtk 一类组件,按提示确认安装即可,那是图形界面渲染所需的系统库,并非软件本身的问题。

Arch 系

# 已有二进制包时本地安装
sudo pacman -U clash-verge-rev.pkg.tar.zst

# 或从 AUR 构建(以 paru 为例)
paru -S clash-verge-rev

AUR 路线的好处是后续升级随系统滚动,坏处是构建耗时;两条路装出来的东西一致,按习惯选。

其他平台

Windows 双击安装器按引导完成,首次启动时防火墙会询问是否放行网络访问,选择允许,否则内核无法监听端口。macOS 把应用拖入「应用程序」文件夹,首次打开如被系统拦下,到「系统设置 → 隐私与安全性」里点「仍要打开」;下载前分清 Apple Silicon 与 Intel 两种包。Android 直接安装 APK,系统询问「安装未知应用」权限时对浏览器或文件管理器授权一次即可;iOS 在 App Store 搜索安装 Clash Plus。

首次启动检查

不论哪个平台,第一次启动后花一分钟确认三件事:一,托盘或状态栏出现了程序图标,说明主进程活着;二,打开客户端的日志页面,能看到内核启动输出而不是红色报错;三,设置里找到「开机自启」并按需打开。Linux 桌面用户如果客户端提供「服务模式」,建议此时顺手安装——它会注册一个系统服务替你以足够的权限拉起内核,第 7 章的 TUN 模式会用到。

订阅本质上是一个 URL:服务商把节点列表(通常是一份完整的 Clash 配置,或可被客户端转换的节点清单)放在这个地址上,客户端定期去拉取,拉回来的内容落地成本地配置文件,再交给内核加载。理解「订阅 = 远程配置的来源」这层关系,后面订阅更新、覆写、失效排查都顺理成章。

导入订阅

各客户端流程一致:完整复制服务商提供的订阅链接,打开客户端的「订阅」或「Profiles」页面,粘贴到输入框,点导入或下载。成功后列表里会出现一个配置项,点击启用,再回到「代理」页面就能看到节点列表。如果节点列表是空的,说明下载或解析环节出了问题,不要反复重试同一个动作,按下文的失败排查走。

更新订阅

服务商的节点会变动,订阅需要定期更新。多数客户端支持给订阅设置自动更新间隔(如每 24 小时),也可以随时手动点更新按钮。注意一个容易吃亏的行为:更新订阅会用远程内容覆盖本地文件,你直接改在订阅文件里的自定义规则会在下一次更新时消失。正确做法是使用客户端的「覆写」或「Merge」机制,把自定义内容放在订阅之外的独立文件里,更新时自动合并,第 9 章会展开。

导入失败排查

订阅导入报错时,按层次自查:链接是否完整(末尾参数被截断很常见)、在浏览器里打开该链接是否返回文本内容而不是 404 或一个网页、服务商是否限制了 User-Agent(部分订阅只对 Clash 系 UA 返回配置)、返回内容是否为合法 YAML。逐项对照的完整清单见技术笔记《Clash 订阅链接失效与解析失败排查清单》。

配置文件在哪

客户端会把订阅落地在自己的配置目录里,Linux 下通常位于 ~/.config 或 ~/.local/share 下以客户端命名的子目录,裸内核默认读取 ~/.config/mihomo/config.yaml。知道位置有两个用途:备份,以及在客户端界面异常时直接查看文件内容判断问题出在配置还是程序。

手动维护配置的用户可以完全不用订阅:自己编写 config.yaml,把节点写进 proxies,客户端以「本地文件」方式导入。这条路自由度最高,也最考验对字段的理解,建议先用订阅跑通全流程,再逐步过渡。

内核有三种运行模式,对应配置里的 mode 字段。规则模式(rule)是日常默认:每条连接过一遍规则表,该直连的直连、该走代理的走代理,速度与可用性兼顾。全局模式(global)把所有流量都交给代理出口,适合临时验证「到底是不是分流规则的问题」,不适合长期开着——国内流量绕一圈国外节点,又慢又费流量。直连模式(direct)让所有流量都不走代理,等价于临时停用而不必退出程序。排障时在三种模式间切换对比,是定位问题最快的手段之一。

端口:流量的入口

模式决定流量的去向,端口决定流量怎么进来。现代配置推荐只声明一个 mixed-port(约定俗成用 7890):它同时接受 HTTP 与 SOCKS5 两种协议,浏览器、系统代理、命令行工具都指向这一个端口即可,不必再分别维护 port 与 socks-port。

「开了 Clash 但网页没走代理」的第一原因,是流量根本没进这个端口。桌面客户端的「系统代理」开关做的事,就是把操作系统的代理设置指向 127.0.0.1:7890;这个开关没开,内核就只是空转监听。GNOME 用户可在「设置 → 网络 → 网络代理」确认,KDE 在「系统设置 → 网络 → 代理」,两处都应显示回环地址加端口号。

终端程序不吃系统代理

Linux 下大量命令行工具(curl、git、包管理器)不读取桌面环境的代理设置,它们认环境变量。临时给当前终端会话挂上代理:

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

写进 ~/.bashrc 可长期生效,但更推荐做成 shell 函数按需开关,避免代理停用后终端请求全部挂起。验证是否生效:curl -I https://www.google.com 能快速返回响应头即为成功。

局域网共享与端口冲突

默认监听 127.0.0.1 意味着只有本机能用。把 allow-lan 设为 true 并将绑定地址放开后,同一局域网的手机、电视盒子可以把这台机器当作代理服务器,配置方法与防火墙放行、安全边界的完整讨论见技术笔记《Clash 混合端口与局域网共享代理设置》。另一类高频问题是启动时报 address already in use——7890 被别的进程占了,定位与改端口的全流程见《Clash 端口被占用怎么办》;改完 mixed-port 记得同步更新系统代理与环境变量里的端口号,漏一处就会出现「一半程序能上一半不能」的怪象。

规则分流是 Clash 的灵魂。每条规则由三段组成:类型,匹配内容,出口——出口可以是某个代理组、内置的 DIRECT(直连)或 REJECT(拒绝)。第 1 章讲过的铁律在这里复述一遍:自上而下匹配,首条命中即定终身。常用规则类型如下:

两个细节值得单独讲。其一,IP 类规则会触发域名解析:一条连接的目标如果还是域名,内核要先解析出 IP 才能比对 IP-CIDR,这次解析可能带来延迟甚至泄露查询。给纯内网段规则加上 no-resolve 参数,让它只匹配「本来就是 IP 的连接」,是通行做法。其二,MATCH 必须放最后一条,它是所有规则都没命中时的兜底出口;兜底指向哪个组,决定了「陌生流量」的默认去向。

代理组:规则的出口

规则出口指向组而不是节点,组的类型决定选择策略:select 手动挑选,url-test 定期测延迟自动选最快,fallback 按顺序找第一个可用的,load-balance 把请求分散到多个节点。组还可以互相嵌套——手动组里放一个自动测速组,平时交给自动,特殊时期手动指定,是最常见的组织方式:

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: []        # 订阅节点通常经 provider 注入

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,github,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这五条规则是一个可直接使用的最小骨架:前两条把明确需要代理的域名送进 PROXY 组,第三条放行内网,第四条让归属地为中国大陆的 IP 直连,最后兜底走代理。日常扩展就是往前面插入更精确的域名规则。

最后强调一次维护姿势:自定义规则不要直接写进订阅文件(下次更新会被覆盖),用客户端的覆写机制注入到订阅规则之前。规则越靠前优先级越高,所以「我的规则在上、订阅规则在中、GEOIP 与 MATCH 在底」是稳定的三明治结构。GEOIP 判断依赖本地数据库,长期不更新会出现归属地误判,更新方法见第 8 章。

系统代理有个先天局限:它只是一份「建议」,遵不遵守由应用程序自己决定。浏览器会遵守,大量游戏、聊天软件、走 UDP 的程序根本不看代理设置。TUN 模式换了一条路:内核创建一块虚拟网卡,配合路由规则把整个系统的出站流量都引到这块网卡上,应用程序对此毫无感知——从它们的视角看,网络本来就长这样。要让「所有程序无差别走分流」,TUN 是正解。

配置示例

tun:
  enable: true
  stack: system          # 可选 system / gvisor / mixed
  auto-route: true       # 自动配置路由表
  auto-detect-interface: true
  dns-hijack:
    - any:53             # 劫持发往 53 端口的 DNS 查询

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

逐项解释:stack 是虚拟网卡的协议栈实现,system 依赖操作系统、性能好,gvisor 是用户态实现、兼容性问题少,mixed 取两者折中,Linux 上一般先试 system。auto-route 与 auto-detect-interface 负责路由表的自动增删,让流量进虚拟网卡、内核自身的出站流量走物理网卡,不开它们就得手工维护路由,极易把自己锁在断网状态。

为什么 TUN 必须管 DNS

TUN 拿到的是 IP 层流量,如果 DNS 解析仍在系统层完成,内核看到的全是 IP、失去了按域名分流的能力,所以 dns-hijack 把 DNS 查询也抓进来。fake-ip 模式更进一步:内核对每个域名查询先返回一个保留段假 IP,应用拿假 IP 发起连接,内核凭假 IP 反查出域名再做规则匹配——省掉一次真实解析,延迟更低。副作用是个别对 IP 有校验的程序会不适,那时可换回 redir-host 模式或给特定域名配置 fake-ip-filter 排除项。

Linux 上的权限

创建虚拟网卡与改路由需要 CAP_NET_ADMIN 权限。桌面客户端走「服务模式」最省事:客户端注册一个系统服务,由服务以特权拉起内核,界面里一键开关 TUN。裸内核用户可以用 setcap 给二进制授权,免去每次 sudo:

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' /usr/local/bin/mihomo

常见坑有三个:一,TUN 与系统代理同时开着,流量被处理两次,关掉系统代理开关即可;二,切换网络(如插拔网线、连不同 Wi-Fi)后 NetworkManager 重写路由导致断流,重启一次 TUN 让 auto-route 重建路由;三,内核异常退出没来得及清理路由,表现为关了 Clash 反而上不了网,同样以「再开再关」或重启网络服务恢复。TUN 开启后,验证方式是随便找一个不支持代理设置的命令行程序访问网络,观察客户端连接页里是否出现了它的进程名。

配置跑通之后,维护工作其实很少,但有几件事值得形成习惯,能把「突然连不上」的概率压到最低。

三样东西要定期更新

第一是订阅:开自动更新或每周手动点一次,节点变更服务商不会挨个通知你。第二是 GeoIP / Geosite 数据库:第 6 章的 GEOIP,CN,DIRECT 依赖本地数据库判断 IP 归属,数据库陈旧会把该直连的流量送去代理、或反过来,多数客户端在设置里提供一键更新入口,裸内核可替换配置目录下的数据库文件后重启。第三是客户端本身:从哪装的就从哪升——apt 装的用 apt 升级、AUR 装的随系统滚动,不要在同一台机器上混两种安装来源,那是「卸载不干净、两个版本打架」这类玄学问题的温床。

学会看日志

日志是排障的第一现场。配置里 log-level: info 适合日常,排障时临时调成 debug 看细节,问题解决后调回来(debug 量大且影响性能)。几条高频日志行值得眼熟:dial tcp ... i/o timeout 通常指向节点不可达,connection refused 多为目标端口没开或被本机防火墙拦截,规则命中行则能告诉你某条连接实际匹配了哪条规则、走了哪个出口——分流不符合预期时先看这一行,而不是盲改规则。逐条解读见技术笔记《看懂 Clash 运行日志》。

备份与恢复

值得备份的只有配置目录:订阅地址、覆写文件、自定义规则都在里面,打包一份丢进你的常规备份流程,换机或重装时解包回原路径即可复原。裸内核场景一条命令的事:tar czf mihomo-backup.tar.gz ~/.config/mihomo。客户端场景先在设置里确认配置目录路径再打包。

开机自启

桌面客户端在设置里勾选自启即可。服务器上的裸内核交给 systemd 管理,写一个服务单元:

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo daemon
After=network-online.target

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

[Install]
WantedBy=multi-user.target

随后 sudo systemctl enable --now mihomo 一步完成注册与启动,journalctl -u mihomo -f 实时跟踪日志。Restart=on-failure 保证进程异常退出后自动拉起,长期无人值守场景必配。

最后留一个排障总原则:一次只改一个变量。改了端口就先验证端口,换了节点就先测节点,同时动三处配置再出问题,你将无从知道是哪一处引起的。启动类故障(闪退、白屏、内核拉不起来)的分类排查见《Clash 客户端启动闪退与崩溃处理》。

走完前八章,日常使用已经没有障碍。这一章给愿意继续深入的用户画一张路线图,每个方向都有明确的收益,按需求挑着走即可,不必全部点亮。

方向一:覆写与配置合并

第 4 章提过订阅更新会覆盖本地改动,覆写机制就是解法:把自定义端口、TUN 设置、私有规则写在独立的覆写文件里,客户端在每次加载订阅时自动合并。Clash Verge Rev 提供 Merge(YAML 层面的字段合并)与脚本(以代码方式改写最终配置)两种形式,前者能覆盖九成需求,后者留给真正的特殊场景。掌握覆写之后,你的个性化配置就和订阅彻底解耦了——换订阅、换服务商,自己的东西一行不丢。

方向二:provider 拆分

proxy-providers 与 rule-providers 把节点和规则从主配置里拆出去,各自独立成远程或本地文件、独立设置更新周期。规则集(rule-set)尤其实用:社区维护着按用途分类的域名清单,配置里引用清单名而不是逐条抄写域名,规则表从几百行缩到十几行,可读性与维护性都上一个台阶。

方向三:外部控制接口

配置里声明 external-controller: 127.0.0.1:9090 后,内核会开放一套 RESTful 接口,切换节点、查看连接、测延迟都能通过 HTTP 请求完成。配合社区的 Web 面板,浏览器里就能管理运行中的内核——这正是服务器场景的标准操作方式,也是理解「客户端到底替你做了什么」的最好教材:客户端界面上的每个按钮,背后都是这套接口的某次调用。

方向四:服务器裸内核部署

把第 8 章的 systemd 单元、本章的外部控制接口、第 7 章的 TUN 组合起来,就是一台旁路网关或软路由的完整方案:局域网设备把网关指向这台机器,全家设备统一分流,终端设备上不需要装任何东西。这个方向动的是路由与 DNS 基础设施,建议在虚拟机里演练一遍再上真实网络,并给自己留一条不经过网关的管理通道。

学习资源的使用顺序

建议的查阅顺序:概念疑问先查术语手册(按内核与客户端、代理协议、规则与分流、网络与端口、配置文件字段五类组织);操作路径回看使用文档;具体故障对着技术笔记的排查文逐项过;高频短问题在 FAQ 类内容里通常有现成答案。手册本身也会随内核与客户端生态的变化持续修订,遇到与实际界面不一致的地方,以客户端内的最新文案为准,思路不变。

精通没有捷径,但有明确的标志:看到一条日志能说出它属于哪个环节,拿到一份陌生配置能预判它的分流行为,网络异常时知道先切哪个模式、看哪一行输出。到那时,这份手册就完成使命了——祝顺利。