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

Clash 客户端首次启动后，界面正常显示并不代表代理链路已经可用。一次完整连接至少涉及配置载入、策略组选择、节点连通、运行模式、系统流量入口和目标访问验证六个环节。任何一环未生效，都可能表现为“节点有延迟但网页打不开”“客户端显示运行中但出口地址没有变化”或“部分应用可以连接、浏览器却无法连接”。

最稳妥的操作方式是沿数据路径逐段确认，而不是连续切换多个开关。先保证配置可以被客户端解析，再选择一个可用节点，然后启用正确的流量入口，最后通过日志与实际访问结果交叉验证。下面的步骤适用于常见桌面 Clash 客户端，也适用于使用 Clash Meta（mihomo）内核的图形客户端；具体按钮名称可能不同，但检查逻辑一致。

PROFILE INPUT

第一步：导入订阅并确认配置已载入

订阅地址不是节点本身，而是客户端获取配置内容的入口。服务端响应通常包含代理节点、策略组、规则、DNS 设置以及远程规则集引用。导入成功的判断标准不只是列表里出现一条订阅记录，还要确认该记录已经被选为当前配置，并且客户端没有报告 YAML 语法、字段类型或远程资源下载错误。

导入订阅的标准顺序

1. 复制完整订阅地址，检查开头是否为 https://，同时避免把地址前后的空格一起复制。
2. 在 Profiles、配置或订阅页面选择“从 URL 导入”，粘贴地址并执行下载。
3. 等待配置记录显示名称、更新时间或配置大小，再点击该记录将其设为当前配置。
4. 打开日志页面，确认没有持续出现解析失败、字段无效、资源下载失败或配置载入失败。
5. 回到代理页面，检查是否出现策略组和节点。只有空白配置名称、没有任何策略组时，不能继续进行节点测试。

部分客户端会同时保存多个配置，但运行时只激活其中一个。导入新订阅后仍看到旧节点，通常是当前配置没有切换，或者新配置被导入后尚未重新载入。可以先记下当前配置名称，再执行一次切换；不要在首次验证阶段同时开启多个覆写脚本，因为覆写结果可能改变代理组、DNS 或端口字段。

如何区分订阅问题与客户端问题

NODE SELECTION

第二步：选择节点并正确理解延迟测试

配置载入后，进入 Proxies 或代理页面。页面通常按策略组组织节点，例如“节点选择”“自动选择”“故障转移”或按地区划分的组。规则最终引用的是策略组，因此只在某个地区分组里点选节点、却没有让上层策略组引用该分组，实际流量仍可能走其他出口。

先看策略组的引用关系

首次测试建议找到规则主要使用的手动选择组，再直接选中一个具体节点。若主选择组当前指向“自动选择”，则由自动测速组决定实际节点；若它指向某个地区组，则还需要进入地区组确认二级选择。可以把关系理解为：

规则命中 → 主策略组 → 地区组或自动组 → 具体代理节点

当客户端提供链路详情时，应确认最末端显示的是具体节点名称，而不是停留在未选择的策略组。修改选择后通常会立即生效，新建连接使用新节点，已经建立的长连接可能继续占用旧链路。验证时可关闭目标网页标签后重新打开，必要时终止旧连接。

延迟数值代表什么

客户端的延迟测试一般会通过指定测试 URL 发起 HTTP 或 HTTPS 请求，并记录建立连接或获得响应所需的时间。它可以快速判断节点是否具备基础连通性，但不等同于 ICMP Ping，也不代表所有目标网站的访问速度。测试服务器位置、TLS 握手、节点拥塞、本地网络抖动和测试超时时间都会影响结果。

• 显示具体毫秒数：说明测试请求在限定时间内完成，节点具备基础可达性。
• 显示超时：可能是节点不可达、测试地址被阻断、协议参数失效或本地网络无法建立连接。
• 数值偶尔很高：先连续测试两到三次，观察是否持续异常，不要仅凭一次结果判断。
• 延迟低但网页失败：继续检查规则、DNS、系统代理和目标站点链路，不能把延迟成功视为完整验证。

节点选择不需要单纯追求最低数字。对于首次连通测试，优先选择多次测试均有响应、波动较小的节点。若所有节点同时超时，更可能是订阅参数失效、本地网络入口受限、客户端内核未运行或测试地址不可用，而不是每个节点在同一时间独立故障。

ROUTING MODE

第三步：确认 Rule、Global 与 Direct 模式

Clash 的运行模式决定连接如何选择策略。常见模式包括 Rule、Global 和 Direct。首次使用建议保持 Rule 模式，因为它按照配置中的规则从上到下匹配，通常能实现本地地址直连、指定目标代理以及末尾规则兜底。实际行为取决于当前配置，不是所有 Rule 配置都会采用相同的分流结果。

如果 Rule 模式下某个目标无法访问，而切换 Global 后恢复，问题通常位于规则命中结果、策略组选择或 DNS 分流，而不是系统代理入口。此时应打开连接记录，查看该目标命中了哪条规则、交给哪个策略组以及最终使用哪个节点。测试结束后切回 Rule，避免把临时诊断状态误当作长期设置。

Direct 模式同样具有诊断价值：若 Direct 下本地常用网站也无法打开，应先检查系统代理端口、内核运行状态或防火墙；若 Direct 正常而代理模式失败，则检查节点和代理协议参数。模式切换只是改变进入 Clash 后的处理方式，无法替代系统代理或 TUN 这样的流量接管入口。

TRAFFIC ENTRY

第四步：启用系统代理，让应用流量进入 Clash

节点测试由客户端内核主动发起，即使系统代理没有开启，也可能得到延迟数值。浏览器和桌面应用要使用 Clash，流量还必须进入本地监听端口。桌面客户端通常提供“系统代理”开关，用于把操作系统的 HTTP 与 HTTPS 代理指向 Clash 的本地端口。

系统代理生效所需条件

1. Clash 内核处于运行状态，没有发生端口占用或启动失败。
2. 系统代理开关已开启，操作系统代理地址通常指向本机回环地址。
3. 浏览器或应用遵循系统代理设置，没有使用独立代理配置覆盖系统值。
4. 本地防火墙允许客户端进程监听和访问相应端口。
5. 端口设置与系统代理写入的端口一致，修改端口后已重新应用系统代理。

常见配置会提供 HTTP 端口、SOCKS 端口或 mixed-port。mixed-port 可以在同一端口接受 HTTP 与 SOCKS 连接，但是否启用取决于配置和客户端实现。不要根据其他设备的截图直接填写端口，应以当前客户端的端口页面和运行日志为准。

如果浏览器安装了独立代理管理扩展，它可能绕过或覆盖系统代理。首次检查时应只保留一种入口：要么让浏览器跟随系统设置，要么明确把浏览器指向 Clash 的本地监听端口。两种方式同时改动会让故障来源难以判断。部分应用完全忽略系统代理，这类流量需要应用内单独设置 SOCKS/HTTP 代理，或在确认基础连接正常后使用 TUN 模式。

VERIFY OUTPUT

第五步：用访问结果、连接记录和日志完成验证

验证代理状态不能只看开关颜色。一个可信的结论至少需要三个信号：目标页面能够加载、Clash 连接记录出现对应请求、该请求使用了预期策略和节点。若还需要确认公网出口，可以在启用与停用代理时分别访问可信的 IP 查询服务，对比出口地址是否变化。

推荐的验证顺序

1. 保持 Rule 模式，确认主策略组已经选中刚才测试通过的节点。
2. 开启系统代理，关闭浏览器中原有的目标页面和旧连接。
3. 访问一个本地常用站点，确认基础网络没有因系统代理设置而整体中断。
4. 访问需要走代理的目标，同时观察 Connections 或连接页面是否出现域名。
5. 展开连接详情，核对规则名称、策略组、最终节点、上传下载数据和连接状态。
6. 查看日志中是否存在 DNS 解析失败、连接被拒绝、握手超时或路由失败。

连接记录是判断流量是否进入 Clash 的直接证据。浏览器正在访问目标，但连接列表完全没有对应域名或 IP，说明问题多半发生在 Clash 之前：系统代理未写入、浏览器绕过代理、应用使用了自己的网络栈，或者内核监听端口与系统设置不一致。若连接记录存在却停留在超时，则继续检查节点、DNS、规则和远端链路。

出口地址没有变化时怎么判断

先确认测试目标确实命中了代理策略。Rule 模式可能将某些 IP 查询站点设为直连，因此出口不变并不必然代表系统代理失效。可以从连接详情确认匹配结果，或短时切换 Global 模式进行对照。如果 Global 模式下出口变化，说明代理链路工作正常，需要调整的是规则或策略组；如果 Global 下仍没有对应连接记录，则回到流量入口检查。

还要注意浏览器缓存、连接复用和 QUIC。已建立的连接可能不会在节点切换后立即重建，某些浏览器的 UDP/QUIC 流量也可能与普通 HTTP 代理表现不同。最简单的处理是关闭相关标签页、等待旧连接结束后重新访问。不要一边测速、一边连续切换多个节点和模式，否则日志很难对应到具体操作。

FAULT ISOLATION

首次连接失败的分层排查表

首次连接失败时，按照“配置—内核—节点—入口—规则—DNS”的顺序逐层检查。每次只改变一个设置，并在修改后重新发起连接。这样可以确定是哪一层恢复，而不是偶然得到一个暂时可用的组合。

DNS 问题应如何确认

Clash Meta（mihomo）配置可能使用 fake-ip 或 redir-host 等 DNS 增强模式。它们的解析路径和缓存行为不同，但首次排查的核心相同：确认域名查询进入了预期 DNS 模块、上游服务器可以访问、规则判断所需的域名信息没有丢失。不要在尚未确认系统代理可用时同时替换多个 DNS 上游。

若日志明确显示域名解析超时，可以先测试其他域名，判断是单一域名异常还是所有查询都失败。若只有特定域名失败，检查规则、hosts 覆写和 fake-IP 过滤项；若所有域名都失败，检查 DNS 监听端口、上游协议、网络可达性以及 TUN 下的 DNS 劫持设置。配置更新后还应清理客户端 DNS 缓存或重启内核，避免旧记录影响结论。

什么时候再启用 TUN 模式

当系统代理下的浏览器访问、策略命中和节点出口都已验证正常，但游戏、命令行程序或不遵循系统代理的应用仍无法被接管时，再考虑 TUN。启用前应记录当前可用配置和端口，以便快速回退。TUN 通常涉及虚拟网卡、路由表、DNS 接管、管理员权限及严格路由设置，故障范围比系统代理更广。

启用 TUN 后，先检查虚拟接口是否创建、默认路由是否按客户端预期调整，再查看应用连接是否出现在 Clash 连接记录中。如果开启后整机网络中断，应立即停用 TUN 并恢复基础链路，不要同时修改 MTU、DNS、路由和防火墙。基础代理已经可用时，TUN 问题通常可以独立定位。

FINAL CHECKLIST

首次连接完成检查清单

以下项目全部满足，才能视为首次连接主线完成。后续再根据设备用途调整自动选择、故障转移、规则集、DNS 和 TUN，不必在第一轮配置中一次完成所有高级功能。

• 订阅已成功更新，并被设置为当前运行配置。
• 代理页面可以看到策略组和具体节点。
• 至少一个节点经过多次测试均能返回稳定结果。
• 主策略组最终指向该节点，而不是未配置的二级组。
• 运行模式为 Rule，临时诊断模式已经恢复。
• Clash 内核正常运行，本地监听端口没有冲突。
• 系统代理已启用，浏览器流量出现在连接记录中。
• 连接详情显示预期规则、策略组和最终节点。
• 目标页面能够重新建立连接并正常加载。
• 日志中没有持续出现解析、DNS 或握手错误。

完成以上检查后，可以保存当前配置状态，并记录客户端版本、内核类型、配置名称和可用节点。以后出现连接异常时，先回到这组基线重新验证：配置能否载入、节点是否可达、流量是否进入内核、规则是否选中正确出口。相较于反复重装客户端，这种沿链路检查的方法更容易定位实际故障点。