Clash 使用手册：从核心概念到稳定分流

理解 Clash：内核、客户端与代理链路

开始安装前，先把几个容易混用的名称分开。Clash 通常既指一类代理配置格式，也指使用该格式的客户端生态；客户端负责提供图形界面、读取配置、调用系统能力，真正执行 DNS 解析、规则匹配和连接转发的部分称为内核。当前常见的开源内核路线是 Mihomo，它继承并扩展了 Clash Meta 的配置能力。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等属于客户端，不能把客户端名称直接当成内核名称。下载页面会按平台列出这些客户端，选择时应先看系统，再看界面和功能覆盖。

一次访问通常经过四个阶段。应用先产生一个目标域名或 IP 地址，客户端根据当前配置决定是否接管请求；内核随后进行 DNS 处理，并按照规则顺序寻找第一个匹配项；规则把请求交给某个代理组、直连策略或拒绝策略；最后由节点建立到目标服务器的连接。任何一个阶段出现问题，表现都可能是“打不开网页”，但排查方法并不相同。规则命中错误时，切换节点没有意义；DNS 返回了错误地址时，单纯更换代理组也不能解决；系统没有把流量交给客户端时，配置本身可能完全正常。

配置文件和运行状态不是一回事

YAML 配置文件保存端口、代理节点、代理组、规则、DNS 等声明式内容。客户端启动后会把这些内容加载到内存，并根据当前模式、网络接口和运行权限建立状态。修改文件而没有执行重载，界面里可能仍然使用旧配置；反过来，在界面里临时切换节点，也不一定会修改原始订阅。理解这一点有助于判断问题属于“文件没有更新”，还是“运行状态没有应用”。配置重载、订阅更新和客户端重启是三个不同动作，后文会分别说明。

从请求到节点的完整路径

以浏览器访问一个域名为例：浏览器先向操作系统发起连接请求，系统代理设置或 TUN 接口决定流量是否进入 Clash；内核接收后，根据 DNS 模式得到目标地址，再从上到下扫描 rules；若命中 DOMAIN-SUFFIX，就把请求交给指定策略组；策略组再根据手动选择、故障转移或 URL Test 结果选择一个代理节点；节点协议完成握手后，目标请求才会发送出去。链路中的“延迟”可能只代表测试地址的 TCP 建连时间，不等于网页全部内容加载时间。关于测速指标的差异，可参考Clash 延迟测试原理。

还需要区分“代理客户端”和“代理服务”。客户端只负责执行本地配置，订阅服务提供节点信息和流量服务，两者不是同一组织，也不共享账号。订阅地址应只从服务提供方获取；网站中的客户端入口用于下载程序，不会替用户生成节点或提供订阅。完成概念分层后，第二章再根据操作系统和使用目标选择合适的客户端。

选择客户端：按系统能力和使用目标判断

客户端选择不应只看名称或截图，而要看三个条件：系统是否支持所需的接管方式，界面是否能完成订阅和规则操作，内核版本是否覆盖需要的协议与 DNS 功能。普通桌面用户通常需要托盘运行、系统代理、配置重载和日志查看；移动端还要考虑后台限制、电池策略与系统 VPN 权限；服务器或软路由用户则更关注命令行启动、配置文件位置和进程守护。下载页的排序把 Clash Plus 放在各平台首位，适合作为图形界面入口，但不同客户端的菜单名称仍可能不同。

Windows 和 macOS 的选择逻辑

Windows 用户可以优先查看 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu。需要传统桌面控制和较少选项时，选择界面易读的客户端；需要更多 Mihomo 选项、TUN 或规则调试时，选择能够显示内核日志和完整配置区域的客户端。Clash for Windows 已停止维护，不适合作为新安装的默认选择；已有配置可以迁移，但迁移前应保存订阅地址和自定义规则。macOS 的可选项包括 Clash Plus、Clash Verge Rev、FlClash 与 ClashX Meta，其中 ClashX Meta 已停止维护，适合只为读取旧配置而保留，不建议作为新环境的主要入口。

Android 和 iOS 的限制

Android 客户端必须通过系统 VPN 或 VpnService 接管流量，首次运行时会出现系统授权提示。Clash Plus、Clash Meta for Android、FlClash 和 Surfboard 的设置位置不同，但都需要确认 VPN 开关处于运行状态。Android 的省电策略可能暂停后台进程，造成锁屏后连接中断；出现这种情况，应把客户端加入系统的电池优化例外，并检查后台数据权限。Android 使用要点还包括通知权限、始终运行的 VPN 选项以及局域网访问权限，具体可参考Android VpnService 与省电设置。

iOS 的系统代理权限集中在 VPN 配置授权，客户端获取和配置导入都受系统界面控制。下载页提供 Clash Plus 的 App Store 入口，并标注官网 clashplus.io。首次启动时，先完成配置导入，再允许系统添加 VPN 配置，最后在客户端内启动连接。iOS 的后台行为、按需连接和网络切换策略由系统参与管理，遇到蜂窝网络与 Wi-Fi 表现不同，应分别测试。

Linux 与 Mihomo 内核

Linux 桌面用户可以从 Clash Verge Rev 或 FlClash 开始；服务器、路由器和没有桌面环境的设备则更适合直接运行 Mihomo。内核包只提供执行程序或压缩包，不会自动创建 systemd 服务、写入配置或开放端口。安装后需要自行确认架构、文件权限、配置目录和监听地址。将管理面板暴露到公网会扩大风险，通常应只监听本机地址，并通过 SSH 隧道或局域网管理。

选择完成后，不要同时安装多个客户端并让它们都开启系统代理。多个程序竞争同一端口或反复改写系统代理，会制造难以判断的状态。首次配置建议只保留一个正在运行的客户端，确认连接、规则和 DNS 均正常后，再尝试迁移到另一款软件。

安装与初始配置：先建立可回退的工作环境

安装前先记录操作系统版本、CPU 架构和当前是否存在其他 VPN 或代理工具。桌面系统还应确认当前账户有安装权限，移动系统则要准备好系统 VPN 授权。建议从客户端页面进入对应平台，再按照卡片说明选择安装包。首次使用不要急于打开 TUN 或修改 DNS，先让客户端以最小权限完成一次普通系统代理连接，这样后续每增加一个功能，问题范围都比较明确。

桌面端的初始顺序

安装完成后启动客户端，先找到配置、Profiles、订阅或类似名称的区域。没有订阅时，可以先确认程序是否能正常打开、内核是否启动、日志区域是否有启动信息；不要为了测试而填写来源不明的地址。导入配置后，检查代理组是否出现节点，检查规则区是否能加载规则数量或规则文件。然后进入设置，记录混合端口、HTTP 端口、SOCKS 端口和外部控制地址。不同客户端默认端口可能不同，不能直接照搬其他软件的端口。

系统代理通常只影响遵守系统代理设置的应用。浏览器、命令行工具和部分桌面程序可能读取 HTTP、HTTPS 或 SOCKS 设置中的一种，也可能完全忽略系统代理。启用系统代理后，先用浏览器访问一个可确认的站点，再用命令行测试；如果浏览器可用而命令行不可用，优先检查命令行是否需要单独设置环境变量，而不是立即打开 TUN。

移动端的初始顺序

Android 首次启动时，客户端会请求建立 VPN，系统弹窗中的应用名称应与当前安装的客户端一致。授权后回到客户端，确认状态从停止变为运行，并观察通知栏是否出现 VPN 标识。iOS 则需要允许客户端添加 VPN 配置，授权成功后系统设置中的 VPN 状态会发生变化。若系统提示已有 VPN，先关闭其他 VPN，再重新授权，避免两个网络扩展同时工作。

Linux 内核的最小运行方式

在 Linux 上直接运行 Mihomo 时，可先把配置文件放到明确的目录，并以前台方式启动观察日志。确认配置读取成功、端口监听正常后，再交给 systemd 或其他进程管理器。下面的命令只展示通用运行方式，路径需要替换为实际文件位置：

mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/"
mihomo -d "$HOME/.config/mihomo"

启动日志中重点看配置解析、DNS 初始化、代理组加载和端口监听。如果 YAML 缩进错误，内核通常会在启动阶段直接报错；如果配置能加载但节点不可用，错误会出现在实际连接或健康检查阶段。两类日志不要混为一谈。确认前台运行稳定后，再配置服务文件，并为服务指定固定的工作目录和用户权限。

配置文件的基本结构

以下片段展示一个可读的最小结构。节点内容和订阅服务提供的字段必须以实际配置为准，示例中的名称只用于说明引用关系：

mixed-port: 7890
mode: rule
allow-lan: false

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

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

这段配置中的密码是示例值，不能直接用于连接。真实配置还可能包含 TLS、UDP、端口复用和特定协议字段。不要把订阅内容、密码或管理密钥发布到公开仓库，也不要在截图中暴露完整订阅地址。完成安装后进入下一章，使用真实订阅替换示例配置。

订阅与节点：更新配置，理解代理组的来源

订阅通常是一个由服务提供方生成的 URL，客户端访问它后取得节点和规则配置。订阅更新不是“测试某个节点”，而是重新下载并解析一份配置；更新成功后，客户端才可能看到新增节点、失效节点或新的代理组。导入订阅时应使用服务提供方给出的原始地址，不要把地址粘贴到不明的转换页面，也不要在公开聊天、截图或工单中暴露完整链接。订阅地址往往包含访问凭据，泄露后应在服务端重置或重新生成。

第一次导入的检查方法

在客户端的订阅管理区域添加地址，填写一个能辨认用途的名称，然后执行更新。更新结束后先看状态提示和更新时间，再打开配置详情，确认节点数量、代理组和规则已经出现。不要只看“更新成功”四个字：有些地址返回的是 HTML 错误页，客户端可能提示下载完成，却无法解析为有效配置。若代理组为空，检查响应格式、订阅是否过期以及客户端是否支持该配置格式。

订阅更新失败时，按以下顺序缩小范围。第一，直接确认地址在当前网络下能否访问；第二，检查系统时间，TLS 证书验证依赖正确时间；第三，确认客户端是否需要通过已有代理更新；第四，查看日志中的 HTTP 状态码和解析错误；第五，删除地址末尾多余空格或换行。若浏览器能打开地址但客户端失败，可能是浏览器使用了代理而客户端尚未建立代理；若客户端在直连失败、切换已有代理后成功，则应在订阅设置中选择正确的更新代理。

节点、代理组和策略的关系

节点是具体的远端连接入口，代理组是把多个节点组织起来的选择器。最简单的 select 组由用户手动选择；URL Test 会按测试结果选择一个节点；fallback 会在当前节点不可用时切换；load-balance 则会按照策略分配请求。测试结果只反映测试 URL 和测试时刻，不能替代真实访问体验。节点所在地区、线路拥塞、目标站位置和协议兼容性都会改变结果。建议先使用 select 组建立可控基线，确认规则无误后再尝试自动选择。

订阅更新与本地修改

很多客户端会把订阅配置和本地覆写分开保存。直接修改订阅生成文件，下一次更新可能覆盖改动；更稳妥的方式是使用客户端提供的覆写、Merge 或 Patch 功能，把自定义代理组、规则和 DNS 放到独立文件中。若客户端不支持覆写，至少在修改前导出备份，并记录改动位置。判断修改是否生效时，要看运行中的配置预览和日志，而不是只看磁盘文件。

节点筛选不应只追求最低延迟。稳定的低丢包线路通常比偶尔出现极低数值的节点更适合长期使用；还要关注流量倍率、出口地区、协议是否支持 UDP，以及目标服务对该出口的限制。可以参考Clash 节点怎么选，建立自己的筛选记录。订阅正常更新后，下一章再选择代理模式，避免在模式未明确时误判规则效果。

代理模式：Direct、Global 与 Rule 应该怎样使用

代理模式决定内核在收到请求后采用哪一类决策方式。Direct 把请求直接连接目标，通常用于验证网络本身和排查规则影响；Global 把大多数请求交给一个代理组，适合快速确认某条线路能否访问目标，但不适合长期作为精细分流方案；Rule 按 rules 从上到下匹配，是日常使用最常见的模式。模式切换不会改变节点本身，也不会自动修复 DNS、系统代理或 TUN 权限问题，因此需要结合日志和连接记录判断。

Direct 模式用于建立基线

当网页打不开时，可以暂时切换 Direct，观察目标是否能正常连接。如果 Direct 正常而 Rule 失败，问题可能在规则、代理节点或代理组；如果 Direct 也失败，则应检查本地网络、DNS、目标站状态或系统防火墙。Direct 不能证明规则正确，因为它绕过了代理链路。测试结束后应切回原来的模式，否则部分请求会绕过预期的分流策略。

Global 模式用于验证节点

Global 模式把请求集中交给选定的代理组，适合验证“这组节点是否能访问目标”。如果 Global 下能访问、Rule 下不能访问，优先查看规则命中和代理组引用；如果 Global 下仍不能访问，检查当前节点、协议握手、出口地区和远端响应。Global 也可能让本应直连的国内站点、局域网地址或需要本地 IP 的服务经过代理，因此只应作为短时诊断工具，使用完后恢复 Rule。

Rule 模式的判断重点

Rule 模式的核心不是规则数量，而是顺序和覆盖范围。一个域名可能同时符合多个条件，内核通常采用最先匹配的规则。常见配置会先处理局域网、私有 IP、特定域名，再处理广告或地区列表，最后用 MATCH 兜底。没有 MATCH 时，未命中的请求可能采用默认策略，导致行为与预期不同。选择代理组时，要确认组名和规则中引用的名称完全一致。

客户端连接记录通常能显示请求域名、命中的规则和最终策略。出现访问问题时，先清空或筛选连接记录，再只打开一个目标页面，观察请求是否出现、规则字段显示什么、策略组最终选择了哪个节点。浏览器可能同时请求多个域名，页面能打开并不代表所有资源都走了同一路径。对于应用问题，还要确认应用是否使用 QUIC、DoH 或自带代理，这些流量可能不按普通浏览器连接方式出现。

系统代理与 TUN 的边界

系统代理主要接管遵守系统设置的 TCP 应用，TUN 则通过虚拟网络接口接管更广泛的系统流量。启用 TUN 后，某些原本绕过系统代理的程序也会进入内核，但权限、路由和 DNS 处理的复杂度会增加。建议先在系统代理模式下完成订阅、规则和节点验证，只有确定确实需要接管不遵守系统代理的应用时，再进入第七章的 TUN 配置。

规则分流：从匹配顺序到可验证的策略设计

规则分流的目标是让不同请求按照明确条件进入直连、代理或其他策略组。规则不是越多越好，最重要的是边界清楚、顺序稳定、兜底明确。常见规则类型包括按完整域名匹配的 DOMAIN、按后缀匹配的 DOMAIN-SUFFIX、按关键词匹配的 DOMAIN-KEYWORD、按 IP 或网段匹配的 IP-CIDR，以及最后处理未命中请求的 MATCH。规则右侧的策略名称必须在配置的 proxy-groups 或保留策略中存在，否则规则虽然写在文件里，也无法按预期执行。

域名规则的差异

DOMAIN,api.example.com,PROXY 只匹配指定完整域名；DOMAIN-SUFFIX,example.com,PROXY 通常覆盖该域及其子域；DOMAIN-KEYWORD,example,PROXY 会匹配域名中的关键词，范围更宽，也更容易误伤。为一个服务添加规则时，应优先使用完整域名或后缀规则，只有在域名结构复杂且确认影响范围时才使用关键词规则。规则中的域名不应带协议、路径或端口，写入 https://example.com/path 通常不会得到想要的匹配效果。

规则顺序与局域网例外

局域网和本机地址通常应放在靠前位置。这样可以避免打印机、路由器管理页、家庭服务器等请求被送到远端节点。示例顺序如下：

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve 可以避免 IP 规则为了判断域名而额外触发 DNS 解析，适用于已经明确使用 IP 网段判断的场景。它不是所有规则都必须加的开关，使用前要理解当前 DNS 模式和规则引擎行为。GEOIP 依赖 IP 数据库，数据库更新状态会影响结果；如果某个站点的出口和域名策略有明确要求，优先写域名规则，不要完全依赖地区判断。

规则集与本地覆写

较大的域名清单通常以 rule-provider 或规则集形式加载。规则集适合集中维护，但调试时要知道实际命中的来源。修改本地规则后，应先保存配置，再执行重载；如果规则集是远程地址，还要确认它是否更新成功。为了降低排错难度，可以把少量个人例外规则放在独立文件的顶部，把通用规则集放在其后，最后保留一条明确的 MATCH。这样既能快速覆盖个人例外，也不会直接改动上游订阅。

如何验证一条规则

验证时只选一个目标域名。清理连接记录，访问目标，查看连接详情中的域名、解析地址、命中规则和最终策略。若没有记录，先检查应用是否经过系统代理或 TUN；若有记录但命中 MATCH，检查规则文件是否加载、规则顺序是否正确；若命中目标规则却仍然失败，问题已经从规则层转移到策略组、节点或远端响应。不要同时改三处配置，否则无法知道是哪项修改产生了结果。

规则分流还会受到缓存影响。浏览器可能缓存 DNS、连接或重定向结果，客户端也可能保留连接状态。修改规则后关闭目标页面，执行一次配置重载，必要时重新建立连接，再观察新的请求。对于长期维护，建议把个人规则写成带日期和用途说明的独立片段，并定期删除已经不再需要的例外，避免规则表逐渐变成无法解释的黑箱。

TUN 与 DNS：处理系统代理覆盖不到的流量

TUN 是一种虚拟网络接口。系统把流量送入该接口后，Clash 内核可以在更接近网络层的位置接收请求，因此不遵守系统代理的程序也有机会被纳入分流。TUN 不是“更快的代理模式”，也不是打开后所有网络问题都会消失。它需要系统权限、路由设置和正确的 DNS 配合；与其他 VPN、虚拟网卡、企业安全软件同时运行时，还可能产生路由冲突。只有在普通系统代理无法覆盖目标应用时，才建议启用。

启用前的准备

先关闭其他 VPN，记录当前网络是否能正常使用。桌面客户端中找到 TUN、增强模式或虚拟网卡设置，确认内核具备对应能力。Windows 可能弹出驱动或管理员权限请求，macOS 可能要求允许网络扩展，Linux 则可能需要 CAP_NET_ADMIN 或 root 权限。移动端的 VPN 接管由系统应用层控制，通常不使用桌面端相同的 TUN 开关。启用前保留一个关闭 TUN 的回退路径，避免重启后网络无法恢复。

DNS 模式的作用

DNS 不只是把域名翻译成 IP。规则通常需要先看到域名，DNS 处理方式会影响规则匹配、Fake-IP 映射、局域网访问和污染规避。常见思路包括 redir-host 与 fake-ip。redir-host 返回真实解析地址，兼容性直观，但某些域名解析结果可能受到当前网络影响；fake-ip 为域名分配虚拟地址，内核通过映射表保留域名信息，便于在连接阶段继续按域名匹配，但部分局域网设备、硬编码 IP 的应用和特殊认证流程可能不兼容。

示例配置如下，实际 DNS 服务器应根据网络环境和客户端支持情况调整：

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.local"

Fake-IP 地址段不能与实际局域网网段冲突，过滤列表也不能随意照抄。需要访问局域网主机名、智能家居或公司内网时，应把相应域名加入过滤范围，并确认局域网 DNS 仍然可达。若某个应用显示 IP 地址而不是域名，Fake-IP 可能无法恢复原始域名；这类应用要么加入过滤，要么使用更适合它的接管方式。

TUN 开启后的排错顺序

启用后先测试局域网网关，再测试普通域名，最后测试需要代理的目标。局域网失败时检查路由、Fake-IP 过滤与允许局域网设置；普通域名失败时检查 DNS 日志、虚拟网卡和系统 DNS；只有前两者正常而代理目标失败，才转向规则、代理组和节点。若所有网络都断开，立即关闭 TUN 或退出客户端，恢复基础网络后再检查权限和路由日志，不要继续叠加配置。

DNS 缓存也会让修改看起来没有效果。完成配置修改后，执行客户端配置重载，重新连接网络，并按操作系统需要刷新 DNS 缓存。浏览器自带的安全 DNS 可能绕过系统 DNS，应用自带解析器也可能绕过内核；排错时应明确测试工具使用的解析路径。完成 TUN 与 DNS 验证后，不要为了追求复杂配置继续增加选项，稳定、可解释的配置比堆叠功能更容易长期维护。

日常维护与进阶路线：让配置保持可解释

稳定使用 Clash 的关键不是频繁调整，而是建立固定检查周期。每次订阅更新后，确认更新时间、节点是否仍存在、代理组引用是否完整；每次客户端升级后，查看内核日志和系统代理状态；每次修改规则或 DNS 后，只改变一个变量并做一次目标测试。把配置当作需要维护的运行文件，而不是一次导入后永远不变的设置，可以明显减少“昨天还正常、今天突然失效”时的无从下手。

建议保留的记录

至少保留当前使用的客户端名称、配置来源、代理模式、混合端口、是否启用 TUN、DNS 模式以及自定义规则文件。订阅地址不要直接写入公开文档，可以只记录它的用途和服务端管理位置。出现问题时，记录发生时间、网络类型、目标域名、连接日志中的命中规则和错误信息。比起一句“不能上网”，这些上下文更能帮助定位是订阅、规则、DNS、节点还是系统权限出现变化。

更新客户端和内核时的迁移流程

升级前导出当前配置或复制本地覆写文件，记下自定义规则和代理组名称。安装新客户端后先不要启用 TUN，导入配置并检查代理组；再启用系统代理测试浏览器；最后才恢复 TUN、DNS 和开机启动。不同客户端对字段、外部控制接口和覆写语法的支持并不完全一致，旧配置能导入不代表每个选项都被采用。发现启动错误时，应回退到最小配置，逐段恢复，而不是把旧目录整体覆盖到新客户端。

常见故障的判断树

如果客户端打不开，先检查安装包、权限和系统日志；如果客户端能开但没有节点，检查订阅更新与配置解析；如果节点存在但所有请求失败，检查代理组选择、节点握手和系统时间；如果只有部分域名失败，检查规则命中、DNS 和目标站限制；如果浏览器能用而某个应用不能用，检查应用是否遵守系统代理；如果开启 TUN 后全局断网，关闭 TUN 并检查路由、权限和其他 VPN。这个顺序从本地程序逐步向远端服务扩展，能避免把所有问题都归因于节点。

FAQ 页面整理了订阅更新失败、系统代理和配置导入等短问题；需要查某个术语时，可从站内的客户端和配置说明进入对应章节。博客文章适合阅读一个具体主题，例如 Fake-IP 原理和 iOS 配置导入，而本页适合在配置过程中反复定位章节。三类内容的用途不同，遇到问题时不必从头重读全部文档。

进一步学习 Mihomo 配置

完成基础分流后，可以依次学习代理组策略、rule-provider、脚本规则、外部控制接口和服务化运行。进阶配置应遵循两个原则：每个新增功能都能说明解决什么问题，每个远程来源都能说明由谁维护。不要为了复制别人的完整配置而一次启用大量 DNS、脚本和规则集；复杂配置的故障边界更宽，且上游变更可能让旧字段失效。阅读配置时，先看端口和模式，再看 DNS，之后看代理组和规则，最后看高级实验选项。

对于服务器或路由器，建议把 Mihomo 进程权限、配置目录和管理接口分开规划。管理接口只绑定到可信地址，配置文件限制读取权限，服务重启后检查日志，升级时保留上一个可工作的内核文件。对于桌面和移动设备，重点是控制后台权限、避免多个 VPN 竞争、及时清理失效订阅和过期规则。无论平台如何变化，核心排错方法都相同：确认流量是否进入内核，确认 DNS 和规则如何处理，再确认策略组和节点是否完成连接。

至此，可以把 Clash 的使用过程归纳为一条稳定路线：选择与系统匹配的客户端，完成最小权限安装；导入并验证订阅；使用 Rule 模式建立分流基线；通过连接记录验证规则；确有需要时再启用 TUN 与 Fake-IP；按周期更新订阅、检查日志并备份自定义配置。遇到具体操作问题，回到快速上手按主线执行；需要完整客户端包清单时，前往Clash 下载页面选择对应平台。