Clash 从零到精通：客户端、订阅与规则分流

一、核心概念：客户端、内核与流量路径

理解 Clash 的第一步不是记住一串配置字段，而是分清三个层次：客户端界面、代理内核和外部订阅服务。客户端负责展示配置文件、策略组、连接状态和系统开关；mihomo 是实际解析 YAML、匹配规则、建立代理连接的内核；订阅服务则负责提供一份或多份节点与策略配置。不同软件可能使用相近的界面名称，但只要内核、配置格式和系统接管方式不同，操作结果就可能不同。

一次普通的网页请求通常先由应用交给系统网络栈，再根据客户端开启的系统代理、增强模式或 TUN 接管方式进入内核。内核读取当前配置，依次处理 DNS、规则匹配、策略组选择和出站连接，最后把响应交还给应用。规则模式下，域名可能先经过 DNS 解析，也可能以域名形式直接参与匹配；具体行为取决于 DNS 模式、嗅探设置和配置文件的写法。因此看到“客户端已运行”并不等于每个应用都已经经过代理。

1.1 配置文件、代理组和节点的区别

节点是一个具体的出站连接定义，包含服务器地址、端口以及协议相关参数；代理组是多个节点或其他策略组的选择器，常见类型包括手动选择、自动选择、故障转移和负载均衡；配置文件则把代理、代理组、规则、DNS 和端口等部分组合起来。一个节点可以被多个代理组引用，一个代理组也可以把另一个代理组作为成员。看到策略组名称却没有可用选项，通常说明节点没有解析成功，或者组内引用的名称与实际代理名称不一致。

“代理端口”与“混合端口”也不应混为一谈。HTTP 端口只接收 HTTP 代理请求，SOCKS 端口接收 SOCKS 请求，混合端口通常同时支持两种常见协议。系统代理设置一般只需要填混合端口或客户端明确标出的 HTTP 端口；如果把控制端口误填到系统代理中，浏览器可能显示连接失败，客户端本身却仍然处于运行状态。控制端口只用于外部 API 或界面通信，不承担普通网页流量。

1.2 先建立可观察的判断顺序

排查时建议沿着“应用是否发出请求、系统是否把请求交给客户端、客户端是否匹配到规则、策略组是否选出有效出站、远端连接是否成功”的顺序进行。不要一开始就修改大量 DNS 或规则。先在客户端的连接、日志或请求列表中观察目标域名；若列表完全没有记录，问题多半在系统代理、TUN 或应用自身的代理支持；若有请求但规则命中 DIRECT，说明配置行为符合当前规则，需要检查规则顺序；若命中代理组但全部连接失败，再转向节点、网络和 TLS 排查。

二、选择客户端：按平台、内核和接管范围安装

客户端选择应先看平台和使用范围，再看界面偏好。Windows、macOS、Linux 通常需要桌面客户端提供系统代理、配置管理和日志查看；Android 需要适配移动系统 VPN 接口；iOS 则通过 App Store 安装 Clash Plus。对于服务器、旁路由或需要长期后台运行的环境，直接使用 mihomo 内核更合适，但它缺少桌面客户端提供的图形化配置入口，维护要求也更高。

本站下载页将 Clash Plus 放在各个平台的首位，原因是它覆盖范围较完整，适合希望使用统一操作方式的用户。Clash Verge Rev、FlClash、Clash Nyanpasu、ClashX Meta 和其他客户端各有平台侧重点。已停止维护的软件仍可能在旧设备上运行，但不应把它作为新安装的第一选择。安装前先确认系统架构和包格式，Windows 常见的是安装程序或压缩包，macOS 要区分 Intel 与 Apple Silicon，Linux 则需区分发行版支持的安装格式。

2.1 安装前的三个确认项

第一项是平台架构。Windows 的 ARM64 设备不能直接使用只面向 AMD64 的程序；macOS 的 Apple Silicon 与 Intel 版本也不应混装。第二项是客户端的运行权限。系统代理、开机启动和 TUN 通常需要额外的系统权限，安装程序本身能打开并不表示这些权限已经授予。第三项是配置来源。只从可信的订阅入口复制地址，避免把一个网页地址、控制面板地址或带有额外说明文字的整段内容粘贴到订阅框。

下载完成后先启动客户端，不要立即同时打开系统代理、TUN 和浏览器扩展。先确认界面能加载，能看到配置文件或空白的配置列表，再进行下一项设置。这样做的好处是每一步只有一个变量，出现错误时可以明确是安装、导入还是系统接管导致。安装路径、日志路径和配置存储位置因客户端而异，若要迁移设备，优先使用客户端提供的导出功能，不要直接复制未知格式的缓存目录。

2.2 图形客户端与内核直跑的取舍

图形客户端适合个人电脑，因为它提供了配置更新、策略组切换、连接日志和系统代理开关。内核直跑适合路由器、服务器或容器环境，配置通过文件和命令维护，可以减少桌面层依赖，但需要自行处理进程守护、文件权限、日志轮转和路由转发。两者使用的配置概念相通，却不能假设每一个桌面按钮都对应一个可直接复制的命令行参数。

三、导入订阅：配置生成、更新和回退

订阅地址本质上是一个返回配置内容的 URL。客户端请求该地址后，可能得到完整 YAML、经过编码的节点集合，或者由服务端按客户端类型生成的配置。导入时应使用客户端的“订阅管理”“配置文件”或相近入口，而不是把地址直接当作普通节点逐个添加。首次导入后，先观察配置名称、代理数量、策略组和规则是否出现，再决定是否启用。

导入订阅之前，建议把当前可用配置保留一份。许多客户端会在更新时覆盖旧文件，如果新内容为空、格式错误或策略组名称变化，回退文件可以帮助恢复工作状态。更新订阅时不要只看更新按钮是否显示成功，还要打开配置详情检查更新时间、解析状态和代理组成员。某些服务端返回 HTTP 成功，但正文是登录页面或错误提示，这种情况下客户端可能只报告解析失败，实际原因要从订阅地址响应内容判断。

3.1 导入后的最小检查

第一步检查代理组是否有成员。常见的主组名称可能是“节点选择”“Proxy”或服务方自定义名称，名称不同不代表功能不同。第二步检查代理组的当前选择是否为一个真实节点或可用的子策略组，不能停留在一个已经删除的名称上。第三步检查规则是否存在。没有规则的配置仍然可以在全局模式下工作，但规则模式下很可能所有请求都落到兜底策略。第四步检查 DNS 部分是否与当前网络环境相容，尤其是开启 fake-ip 后，局域网设备和某些本地服务可能需要额外规则。

订阅更新不是越频繁越好。更新会重新下载配置、重建代理组，并可能触发节点健康检查。日常使用可以按服务提供方的建议更新；如果配置当前稳定，不需要因为客户端界面出现提醒就频繁点击。更新失败时保留旧配置继续使用，记录失败时间和错误文本，再检查网络连通性、订阅权限、地址编码及服务端返回类型。

3.2 配置文件的分层思路

配置可以理解为基础文件、订阅内容和本地覆写三层。基础文件定义端口、日志和 DNS 等通用设置；订阅内容提供节点与策略组；本地覆写用于调整规则、增加局域网直连或改变模式。不同客户端对覆写功能的名称和合并规则不完全一致，因此修改前应先确认最终生成的配置，而不是只看某个编辑框中的片段。若客户端支持配置校验，保存后先执行校验再启用。

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

proxies: []
proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,节点选择

上面的片段展示了配置的骨架：混合端口用于本机 HTTP 与 SOCKS 请求，规则模式按顺序处理请求，局域网访问默认不对外开放，最后一条 MATCH 作为兜底。它不是某个订阅服务的完整配置，不能直接替代服务方提供的节点内容。编辑 YAML 时尤其注意缩进、冒号后的空格和列表层级；一个多余的 Tab 或错误的缩进就可能导致整份文件无法解析。

四、代理模式：规则、全局与直连的验证方法

代理模式决定请求如何进入策略选择。规则模式按配置文件中的 rules 从上到下匹配，匹配到后交给指定策略组；全局模式通常把请求统一交给某个代理组，不再依赖域名规则决定 DIRECT 或代理；直连模式则让请求绕过代理。不同客户端的按钮名称可能略有差异，但判断方式一致：当前模式、当前策略组和单个请求的实际命中结果需要一起看。

规则模式适合日常使用，因为局域网、国内常用服务和需要代理的目标可以分别处理。全局模式适合短时间测试：当规则结果不确定时，把目标统一交给一个已知可用的代理组，可以判断问题来自规则还是连接本身。直连模式适合确认网络原始状态，也适合排查代理是否导致证书、DNS 或登录问题。测试结束后要切回合适模式，否则浏览器表现可能与平时不同。

4.1 从日志确认模式是否生效

选择模式后打开连接日志，访问一个明确的测试网址或刷新一个已有页面。记录中通常能看到请求域名、匹配规则、命中的策略组和最终出站。如果请求命中 DIRECT，先看当前是不是规则模式以及规则是否明确要求直连；如果请求命中代理组但页面无法打开，切换到代理组中的另一个可用节点，观察错误是否改变。若日志没有出现请求，说明流量尚未进入客户端，应检查系统代理、浏览器独立代理设置、TUN 状态或应用是否使用自己的网络通道。

不要用“网页能打开”作为唯一验证标准。浏览器可能使用缓存、IPv6、应用自身的代理设置或之前建立的连接。可以关闭缓存后重新加载，或在客户端连接记录中确认新请求确实产生。命令行验证时，明确指定代理端口比依赖系统环境变量更可靠：

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --socks5-hostname 127.0.0.1:7890 https://example.com/

第一条命令使用 HTTP 代理，第二条使用 SOCKS5 并让域名在代理端解析。若 HTTP 命令失败而 SOCKS5 成功，可能是端口协议或客户端监听设置不匹配；若两条都失败，再查看节点连接和日志。示例中的域名仅用于验证命令格式，实际测试应选择能够正常访问且允许命令行请求的目标。

4.2 系统代理、应用代理和 TUN 的差异

系统代理通常影响遵循系统代理设置的浏览器和桌面应用，优点是改动小、容易关闭；不遵循系统代理的程序仍可能直连。应用代理是程序内部的设置，浏览器扩展、开发工具和终端可能各自使用不同入口。TUN 则在更低的网络层接管流量，覆盖面更大，但会涉及虚拟网卡、系统权限、路由和 DNS，配置错误时影响范围也更大。排查时从系统代理开始，确认目标应用已被覆盖后再考虑 TUN。

五、规则分流：匹配顺序、策略组与自定义规则

规则分流的关键是顺序。内核从第一条规则开始判断，请求一旦匹配就停止继续向下寻找，并交给规则右侧指定的策略组或 DIRECT、REJECT 等动作。因此一条范围过大的规则放在前面，可能覆盖后面更精确的规则。配置自定义规则时，应先描述目标和范围，再选择规则类型，最后把它放在正确的位置，而不是看到某个域名打不开就随意增加一条 MATCH。

常用规则类型包括 DOMAIN 精确匹配一个域名，DOMAIN-SUFFIX 匹配域名及其子域名，DOMAIN-KEYWORD 按关键词匹配，IP-CIDR 匹配 IPv4 网段，IP-CIDR6 匹配 IPv6 网段，GEOIP 按 IP 地理库匹配，PROCESS-NAME 按进程名匹配。不同内核版本和平台对进程名、网络栈及嗅探的支持可能不同，使用前应确认当前客户端的内核能力。规则写得越宽，误匹配概率越高；优先使用精确域名或明确后缀。

5.1 规则组的组织方式

建议把策略组分成“人工选择”和“用途分流”两层。人工选择组包含具体节点或自动选择组，负责决定当前出站；用途分流组负责把不同类别的请求交给人工选择、DIRECT 或其他组。例如广告拦截、局域网、流媒体和兜底请求可以有各自的分组。这样修改节点时只需要调整人工选择组，规则侧的结构保持稳定。若把大量节点直接写进每个业务组，订阅更新后名称变化会造成多处维护。

策略组名称是配置中的引用键，必须完全一致，包括大小写、空格和标点。下面的示例展示了一个小型结构：

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 节点一
      - 节点二

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.org,节点选择
  - GEOIP,LAN,DIRECT
  - MATCH,节点选择

url-test 组会按配置进行可用性测试并选择结果较好的成员，但测试地址的可达性不一定代表所有目标都可达，interval 也不宜设置得过短。select 组则由使用者手动选择。示例中的节点名称必须在 proxies 区域真实存在，不能直接复制到没有这些节点的配置中。

5.2 自定义规则的验证流程

添加一条规则后，不要立刻增加第二条。先保存并重新加载配置，访问一个明确属于目标范围的域名，然后从日志确认规则文本和策略组。如果没有命中，可能是域名实际使用了另一个后缀、请求走了 IP、DNS 结果未被嗅探，或者规则被前面的条目提前处理。如果命中了但仍无法连接，说明规则匹配已经成功，接下来应检查策略组和出站连接，而不是继续修改规则。

规则数量较多时，可以用注释按用途分段，但不要在关键字段中加入无法解析的说明文字。遇到订阅自动生成的规则集，应先确认规则集的更新状态和引用名称，再添加本地规则。若本地规则与订阅规则冲突，应明确哪个优先，并在更新后再次检查最终配置。本站常见问题页面收录了策略组为空、规则不生效和订阅更新异常等高频排查入口。

六、TUN 模式：虚拟网卡、DNS 与系统流量接管

TUN 模式通过虚拟网络接口接收系统层流量，再由内核根据配置转发。它可以覆盖不遵循系统代理的程序，因此适合需要统一接管终端流量的场景；同时它也比普通系统代理更接近系统网络底层，启用后会改变路由和 DNS 行为。TUN 不是“更快的代理模式”，而是一种不同的流量入口。开启前应先确保普通系统代理已经可用，并确认客户端具备创建虚拟接口的权限。

启用 TUN 时，通常要处理三个问题：设备权限、路由接管和 DNS。桌面系统可能弹出管理员授权，Android 则通过系统 VPN 授权建立本地 VPN；Linux 可能需要内核模块、capability 或 root 权限。路由接管决定哪些目标进入 TUN，auto-route、strict-route 等设置的含义依客户端和内核配置而异。DNS 处理不当会导致域名解析走到本地网络，出现规则判断与实际连接不一致，或局域网域名无法解析。

6.1 建议的启用顺序

先关闭不必要的第三方 VPN、网络加速器和浏览器代理扩展，避免多个虚拟接口互相竞争。确认客户端的配置在普通系统代理模式下可以访问测试目标，再打开 TUN 并接受系统权限。启用后先测试局域网网关、普通网页和一个明确需要代理的目标，分别观察是否能解析、是否有连接日志以及规则命中是否变化。若只有局域网失效，优先检查 LAN 规则、路由排除和 DNS；若所有网络都失效，先关闭 TUN 恢复系统代理，再查权限和虚拟接口。

在移动设备上，VPN 图标出现只说明系统 VPN 已建立，不代表当前配置中的节点可用。按应用代理功能可能让部分应用绕过 VPN，也可能因电池优化在后台停止。Android 需要检查电池后台限制、始终开启 VPN 的系统选项和应用分流列表；iOS 的网络接管能力取决于应用自身提供的系统扩展，不应把桌面 TUN 的概念直接套用到移动端。

6.2 DNS 行为与 fake-ip 的判断

fake-ip 模式会为域名分配虚拟地址，让内核可以根据域名继续进行规则处理，适合需要稳定域名识别的场景。但某些局域网域名、本地打印机、企业内网和依赖真实地址的程序可能不兼容。遇到这类问题，可以为局域网后缀、私有地址和特定域名加入 DIRECT 或 fake-ip-filter，具体字段以当前配置和客户端文档为准。不要为了修复一个局域网设备而关闭全部 DNS 处理，先限定问题范围。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

这段配置用于说明常见字段的关系，不能替代平台实际需要的完整 DNS 服务器列表。stack、auto-route 和 enhanced-mode 是否可用，要以当前内核支持范围为准。配置修改后先进行语法检查，再一次只改变一个字段。若 TUN 在某个平台无法启动，可在客户端设置中关闭增强模式，回到系统代理路径完成日常使用。

七、日常维护、故障排查与进阶路线

稳定使用依赖可回退、可观察和少改动三个原则。可回退意味着保留最近一次能正常连接的配置；可观察意味着知道在哪里看日志、规则命中和系统代理状态；少改动意味着每次只调整一个相关设置。把这三个原则落实后，大多数故障都能缩小到配置解析、系统接管、规则判断或远端连接中的一个范围，而不必反复重装客户端。

7.1 一套可重复的排错顺序

第一步确认客户端进程和当前配置。若配置没有成功加载，先恢复上一份可解析文件。第二步确认监听端口，检查端口是否被其他程序占用，并确认应用实际使用的是 HTTP、SOCKS 还是混合端口。第三步确认请求是否进入客户端：查看连接列表或日志，若完全没有记录，就不要先改节点。第四步确认规则命中和策略组选择，区分 DIRECT、REJECT、代理组和空组。第五步再检查节点连接、DNS、TLS 和远端服务状态。

如果浏览器提示代理连接失败，先查看系统代理地址是否仍指向本机和正确端口；如果只有一个应用失败，检查该应用是否使用独立代理、是否启用了自己的 DNS 或是否被防火墙阻止。若所有应用都失败但客户端日志没有请求，问题在接管层；若日志显示连接被拒绝，问题在策略组或节点；若连接建立后出现证书或网页内容错误，才进一步检查 TLS、系统时间、证书链和目标站点响应。

7.2 配置更新与日志管理

订阅更新前记录配置名称和当前策略组，更新后对照检查组名、节点数和规则状态。不要把节点数量当作质量指标，也不要因为某次更新后列表变长就认为配置一定更好。日志级别在排错时可以暂时调高，确认问题后恢复到适中的级别，避免长期产生大量文件。桌面客户端的日志保存位置因项目不同而变化，出现重复错误时复制其中一段包含时间、目标和错误原因的记录即可，不需要上传整份配置或包含账户信息的订阅地址。

配置文件中可能包含订阅生成的敏感内容。分享日志或寻求帮助前，应移除订阅 URL、认证信息、节点地址中不必要的识别字段和本地路径。可以保留字段名称、规则顺序、端口类型和错误文本，让排查者理解结构，但不应公开完整访问地址。若怀疑订阅地址泄露，应在服务端重新生成地址，而不是只删除浏览器历史记录。

7.3 从个人电脑走向进阶配置

完成基础使用后，可以按以下顺序提升：先掌握规则模式和策略组引用，再学习 DNS 与 fake-ip 的边界，之后理解 TUN、路由和局域网排除，最后再考虑路由器、旁路由或服务器部署。每一步都应建立在前一步可验证的基础上。直接把复杂配置复制到本地，往往会同时引入多个未知变量，遇到故障时很难判断是内核能力、平台权限还是配置语法造成的。

路由器部署还需要考虑转发路径、网关位置、DHCP、IPv6、防火墙和设备旁路范围。内核监听地址如果只绑定本机，局域网设备无法访问；如果直接暴露到不可信网络，又会扩大管理和代理入口。服务器运行时要配置进程守护、日志轮转和升级回退，客户端界面中的“系统代理”按钮并不能替代路由器的流量转发规则。对于这部分内容，建议先在隔离环境中验证，再逐步迁移到家庭网络。

7.4 故障记录模板

每次排错可以记录平台、客户端名称、当前模式、是否启用 TUN、配置是否刚更新、目标域名、日志中的错误文本和已经尝试的一个改动。这样的记录比“突然不能用了”更容易定位，也能避免重复尝试同一条路径。若需要进一步查阅，先看常见问题中的分类答案，再回到本文对应章节；Windows UWP 回环限制、HTTPS 证书错误和代理模式区别等具体场景，也可以阅读Windows UWP 应用无法走 Clash 代理与HTTPS 证书错误排查。

Clash 的配置能力来自多个层次的组合，真正可靠的使用方式不是记住一份永远不变的模板，而是建立观察和验证习惯。先让基础连接稳定，再逐步加入规则、DNS 和 TUN；每次修改保留记录，每次更新保留回退点。需要安装包时前往Clash 下载页面按平台选择，首次配置则回到快速上手教程完成主线操作。