Clash 首次连接教程：选择节点、测试延迟与验证代理状态

首次连接前先分清四个环节

Clash 客户端完成安装，并不等于网络已经经过代理。一次完整连接通常包含四个彼此独立的环节：配置成功载入、策略组已经选择出口、客户端核心处于运行状态、操作系统或应用流量进入 Clash。任何一个环节未完成，都可能出现“客户端已打开但网页没有变化”的情况。

订阅负责提供节点、策略组和规则等配置内容；节点是实际使用的代理出口；规则决定不同请求交给哪个策略组；系统代理或 TUN 模式则负责把流量送入 Clash。首次使用时应按这个顺序检查，而不是反复开关客户端或连续更换节点。

不同客户端的菜单名称可能略有差异，例如“配置”也可能显示为 Profiles，“代理”可能显示为 Proxies，“常规”可能显示为 General。基于 Clash Meta（mihomo）核心的客户端还可能提供更多 DNS、TUN 和规则覆写选项，但首次连接无需立刻修改这些高级项目。先使用订阅原有配置完成最小连接闭环，更容易判断问题位于哪一步。

导入订阅并确认配置已经生效

从服务提供方取得 Clash 或 Clash Meta 兼容的订阅地址后，进入客户端的配置页面，通过 URL 导入功能添加订阅。桌面客户端通常允许粘贴订阅地址并下载配置；移动端可能将该入口称为“从 URL 导入”或“新建配置”。订阅地址属于账户配置资料，不宜发布到公开页面，也不要将它误当成普通节点地址逐个添加。

导入成功后，配置列表中应出现一条新记录。检查它是否显示更新时间、配置名称或节点数量，并主动将该配置设为当前使用项。仅下载到列表而没有选中，客户端可能仍在使用内置空白配置、旧配置或此前导入的其他订阅。

怎样判断订阅导入成功

• 配置页面出现对应记录，手动更新时没有格式解析错误。
• 代理页面能够看到策略组以及组内节点，而不是只有 DIRECT 和 REJECT。
• 规则页面存在域名、IP、进程或兜底规则，配置内容并非空白。
• 客户端日志没有连续出现配置文件不存在、YAML 解析失败或端口占用提示。

如果配置能够下载，但代理页面没有节点，先检查订阅类型是否适用于 Clash。某些服务同时提供通用订阅、单节点链接和 Clash 配置，客户端需要的是其明确标注的 Clash 或 mihomo 配置入口。若更新时返回登录页面、权限错误或到期提示，则应先处理订阅账户状态，重新安装客户端通常不能解决远端订阅失效。

配置更新后，策略组的选择结果可能被保留，也可能按照新配置重建。节点名称和分组发生变化时，应重新进入代理页面确认当前选择，避免继续指向已经从订阅中移除的旧节点。

理解规则模式、全局模式与直连模式

Clash 常见运行模式包括规则模式、全局模式和直连模式。首次连接建议优先使用规则模式，因为它会按照配置中的规则决定请求去向：需要代理的流量交给代理策略组，本地网络或指定站点可以直接连接，最终未命中的请求由末尾兜底规则处理。

全局模式会把进入 Clash 的大部分流量交给全局策略组，适合短时间验证某个节点能否承担出口，但它不等同于操作系统层面的“所有程序必然被接管”。流量是否进入客户端，仍取决于系统代理、TUN 模式以及应用自身的网络行为。

直连模式通常让流量绕过代理出口。它适合临时排除代理节点影响，却不适合作为首次连接的最终状态。若客户端显示运行正常但外部连接结果一直与直连相同，应确认模式没有停留在 DIRECT，也要检查当前策略组是否选中了 DIRECT。

选择策略组与节点

进入代理页面后，通常会看到多个策略组。常见组名可能表示节点选择、自动测速、故障转移、流媒体或最终出口。组名由订阅配置提供，并非所有客户端都完全相同。首次连接应先找到承担主要代理流量的选择组，再查看该组当前指向的是具体节点、另一个策略组还是 DIRECT。

如果组内有“自动选择”或 URL-Test 类型策略组，它会按照配置指定的测试地址和周期测量可用性，并在候选节点中选择结果较合适的一项。Fallback 类型更重视故障切换，通常使用当前可用的靠前节点。Select 类型则需要用户手动指定。界面里看到延迟数值，并不代表所有策略组都会自动更换节点，Select 组仍以手动选择结果为准。

首次选择节点的实用标准

1. 先看可达性。能够稳定完成延迟测试的节点，优先级高于偶尔出现极低数值但频繁超时的节点。
2. 再看延迟。较低延迟通常有利于网页响应和交互，但它不直接代表下载带宽。
3. 考虑使用目标。部分站点对出口地区、IP 类型或账户地区有要求，应按实际访问目标选择。
4. 避免一次改动过多。首次验证只选择一个明确节点，连接成功后再比较其他线路。

策略组可以互相引用。例如“节点选择”组中可能包含“自动选择”，规则又可能把请求交给“节点选择”。此时实际出口由多层选择共同决定。遇到选择后没有变化，应沿着策略组引用关系逐层查看，直到确认最末端指向某个具体节点，而不是仍停留在 DIRECT 或一个不可用的子组。

正确理解延迟测试结果

客户端中的延迟测试通常不是标准 ICMP Ping。Clash 会通过节点向指定测试 URL 发起 HTTP 或 HTTPS 请求，并记录建立连接及取得响应所需的时间。因此，测试结果同时受到本地网络、代理协议握手、节点负载、测试站点和链路质量影响。操作系统命令行能够 ping 通某台服务器，也不能直接证明代理协议可以建立连接。

点击全部测试后，先等待一轮完成，再观察同一节点多次测试是否稳定。显示几十或几百毫秒属于具体网络环境下的测量值，没有适用于所有地区的固定合格线。比单次数字更重要的是连续结果：如果某节点经常从正常数值跳到超时，实际浏览时也容易出现首屏等待或连接中断。

若所有节点同时超时，应优先怀疑共同条件，而不是断定所有节点一起失效。可检查本地网络是否可访问外部测试地址、系统时间是否准确、订阅是否刚更新、DNS 是否异常，以及防火墙是否阻止客户端核心联网。公司、校园或公共网络还可能限制特定协议或端口，可换用手机热点进行对照测试。

如果只有个别节点超时，则选择同组中能够稳定返回结果的节点继续验证。延迟测试成功仍不等于目标网站必然可用，因为目标站点可能有地区限制，规则也可能将该站点送往另一个策略组。最终判断必须结合连接日志和实际请求。

启动核心并开启系统代理

配置和节点准备完成后，确认 Clash 核心已经启动。部分客户端打开界面时会自动运行核心，另一些客户端需要启用“服务”“运行”或主连接开关。核心未启动时，系统即使写入了代理地址，也可能因为本地监听端口不存在而无法联网。

桌面系统上的“系统代理”一般会把操作系统的 HTTP 和 HTTPS 代理设置指向 Clash 的本地监听地址。遵循系统代理设置的浏览器和应用会把请求交给 Clash。某些程序使用独立代理配置、直接建立连接或自行实现网络栈，因此不会自动遵循系统代理。

首次连接不必同时开启系统代理和 TUN。先用系统代理验证浏览器流量，路径更清晰，权限需求也较少。确认基础代理正常后，如果确实需要接管不遵循系统代理的应用、UDP 流量或更多系统连接，再按客户端说明启用 TUN 模式。

TUN 模式与系统代理的区别

TUN 模式通过虚拟网络接口和系统路由接收流量，覆盖范围通常比系统代理更广。基于 mihomo 核心的客户端可能提供自动路由、DNS 劫持、严格路由等相关设置。启用 TUN 往往需要管理员权限、网络扩展授权或 VPN 权限，也可能与其他 VPN、虚拟网卡、企业安全软件发生冲突。

首次使用时同时打开多种接管方式，会增加判断难度。如果系统代理已经可以让浏览器正常连接，应先记录这一结果，再单独测试 TUN。切换前关闭其他 VPN，并在失败后查看客户端日志，不要仅凭状态栏图标判断是否建立了有效转发。

用三层检查验证代理状态

连接验证不应只看客户端按钮是否变色。较可靠的方法是依次检查客户端日志、实际网页访问和出口信息。三层结果互相印证，能够区分“核心已启动”“请求已进入 Clash”和“请求已通过目标节点完成”这几个状态。

第一层：查看连接记录

打开客户端的连接或日志页面，然后在浏览器刷新一个网页。正常情况下应出现新的域名、目标地址、命中规则和策略链记录。日志可能显示请求命中了某条规则，并通过某个策略组走向具体节点；若记录显示 DIRECT，则说明该请求按照当前规则直连，并不一定是故障。

浏览器刷新后完全没有新连接记录，通常说明流量尚未进入 Clash。此时检查系统代理是否开启、浏览器是否使用独立代理、客户端监听端口是否正常，以及操作系统代理设置是否被其他程序改写。

第二层：访问普通网页

选择一个在当前网络环境中结果明确的网页进行测试。先确认页面能够打开，再观察图片、脚本和接口请求是否完整。只打开首页并不能覆盖所有连接，因为页面资源可能分布在多个域名，并由不同规则处理。若正文出现但图片或视频失败，应在连接记录中查找对应资源域名的策略去向。

第三层：核对出口信息

通过可信的 IP 信息页面查看当前出口地址和地区，再与关闭系统代理时的结果进行对照。出口发生变化，且日志显示请求通过所选节点，才能说明该次浏览器请求完成了代理转发。出口没有变化时，应检查当前策略是否选择 DIRECT、目标查询站点是否被直连规则命中，以及浏览器是否启用了绕过系统代理的功能。

1. 保持当前节点不变，打开系统代理并刷新测试页面。
2. 在连接列表中定位测试页面对应的域名请求。
3. 确认策略链最终落到预期节点，而不是 DIRECT。
4. 记录出口信息，再关闭系统代理进行一次对照。
5. 测试完成后重新开启所需接管方式，并确认客户端状态。

首次连接失败时的固定排查顺序

排障时每次只改变一个条件，并从配置层逐步走向系统层。连续重装、同时更换订阅和修改 DNS，会让原本简单的问题失去可比结果。下面的顺序适用于多数桌面与移动客户端。

遇到“开启系统代理后全部网页无法访问”，先关闭系统代理恢复本地网络，再检查核心是否运行和本地端口是否被占用。如果日志出现监听失败，可能有另一个代理客户端正在使用相同端口。完全退出其他代理或 VPN 程序后重启 Clash，比随意修改多个端口更容易确认原因。

遇到“延迟测试正常但网页打不开”，重点查看实际请求日志。测试 URL 与目标网页不是同一站点，两者可能命中不同规则或使用不同 DNS 结果。还应检查浏览器是否启用了 HTTP/3、独立 DNS 或扩展代理设置。可暂时换用另一个遵循系统代理的浏览器进行对照，但不要同时改动节点和运行模式。

遇到“部分网站正常、部分网站失败”，通常说明基础连接已经成立，问题更可能位于规则、策略组、DNS 或目标站点限制。找到失败域名对应的连接记录，确认它命中了哪条规则、交给哪个策略组，再检查该组的实际出口。规则模式从上到下匹配，较早命中的规则会决定处理方式，末尾的 MATCH 通常承担兜底。

连接成功后的基础设置

首次验证完成后，可以再处理自动更新、开机启动和策略保存。订阅更新频率不宜设置得过密，按照服务提供方和客户端的默认周期即可。更新配置后应留意节点名称、策略组结构和规则是否变化，并重新确认重要策略组的选择。

如果启用开机启动，还要区分“客户端自动打开”“核心自动运行”和“系统代理自动开启”。三者可能是独立选项。共享电脑或经常切换网络的设备，更适合保留手动开启系统代理的习惯，避免在客户端核心未就绪时留下失效的系统代理设置。

日常使用中可保留一个稳定节点作为基准。当网络异常时，先测试基准节点，再比较其他节点；这样能够判断是单条线路波动，还是本地网络、订阅或客户端整体出现问题。需要更广泛流量接管时，再逐项配置 TUN、DNS 和路由选项，并在每次改动后重复“连接记录—网页访问—出口信息”三层验证。