Clash 第一次连接：选节点、测延迟到验证代理生效三步走

连接前先确认配置已经进入工作状态

订阅导入成功，只代表客户端已经取得配置文件，不等于代理连接已经建立。第一次操作时，应先确认配置、内核、策略模式和系统接管方式处于一致状态。不同客户端的菜单文字略有差异，常见路径是「配置」→「订阅」选择刚导入的配置，再到「设置」→「参数设置」确认内核已启动。

使用 mihomo 内核的客户端通常会显示运行状态、内核版本和控制端口。若主界面仍提示“未启动”或日志没有任何新记录，应先启动内核，不要直接反复测试节点。节点延迟按钮调用的是内核能力，内核没有运行时，所有节点可能同时显示超时。

第一次连接的四项检查

1. 配置已选中：配置列表中只有被设为当前配置的文件会参与规则匹配。刚更新订阅后，还要确认客户端没有继续使用旧的本地配置。
2. 运行模式明确：初次使用建议选择「规则」模式。该模式按照配置中的规则决定直连或代理，便于在连接页查看实际命中过程。
3. 代理接管已开启：桌面浏览器通常需要开启「系统代理」。需要接管不读取系统代理的应用时，再使用 TUN 模式。
4. 端口没有冲突：常见配置使用 HTTP 或 mixed-port 7890，SOCKS 端口常见为 7891。最终数值以当前配置和客户端设置页为准。

如果同时开启系统代理和 TUN，测试结果可能混入两种接管路径。首次排查建议只开启一种：先用系统代理验证浏览器，再根据需要测试 TUN。这样可以避免把 TUN 路由正常误认为系统代理正常，或者把浏览器自己的代理设置问题误判为节点故障。

第一步：在策略组中选对节点

Clash 配置通常不会让规则直接引用某个具体节点，而是先引用策略组。策略组再决定使用哪个节点或下一级策略组。常见名称包括「节点选择」「代理」「手动选择」「自动选择」和「故障转移」。名称由订阅提供方定义，并非所有配置都相同。

先找到规则最终引用的策略组

打开「代理」页面后，可以看到多个组。标记为 select 的组需要手动选择；url-test 会按测试结果自动挑选；fallback 优先使用可用节点；load-balance 则会按策略把连接分配给多个节点。第一次连接最适合从手动选择组开始，因为结果更可控。

不要只在某个地区组里点选节点，还要检查上一级组是否真的引用了这个地区组。例如「节点选择」当前选中「自动选择」，而用户只在「香港节点」中切换了具体线路，那么最终出口仍可能由「自动选择」决定。策略组可以嵌套，页面上的选中标记要从顶层一路向下核对。

第一次应该选什么样的节点

• 先选地理距离较近、延迟结果稳定的节点，不必只追求列表中的最小数字。
• 连续测试三次。若结果分别为 68 ms、71 ms、74 ms，稳定性通常好于 42 ms、190 ms、超时这样的波动。
• 暂时避开名称中明确标注倍率、实验或限速的线路，先建立一个可重复的基础结果。
• 若同一地区有多个协议节点，先选择订阅默认推荐的常规线路，再根据实际吞吐和稳定性比较。

节点名称只是配置提供者写入的标签，不能独立证明物理位置或链路质量。最终仍要结合延迟、连接日志、出口地址和实际访问表现判断。对于需要固定会话的登录服务，短时间内频繁切换节点还可能改变出口地址，因此每次切换后应重新建立连接再验证。

第二步：测试延迟并正确读取结果

客户端中的延迟测试并不是传统意义上的 ICMP Ping。Clash 或 mihomo 通常会让指定节点请求一个测试 URL，并记录建立代理连接和取得响应所需的时间。常见测试地址会返回 HTTP 204，例如 https://www.gstatic.com/generate_204 或 https://cp.cloudflare.com/generate_204。具体地址由配置或客户端设置决定。

延迟数字分别意味着什么

这些区间只用于初筛。一个 55 ms 的节点可能因带宽拥塞而下载缓慢，一个 180 ms 的节点也可能在持续传输时保持稳定。延迟主要反映短连接响应，无法直接等同于下载速度、丢包率或晚高峰容量。

批量测试时不宜连续快速点击。一次同时测试几十个节点，会瞬间建立大量连接，路由器、DNS 服务或远端服务器都可能限流。建议等待本轮结果完整返回，间隔 10 至 20 秒再做第二轮。三轮数据比单次最小值更有参考意义。

所有节点一起超时时先查测试链路

1. 打开「日志」，确认点击测速后是否出现连接尝试。完全没有日志，通常是内核未运行或界面没有连接到控制端口。
2. 检查本机是否能直接解析测试地址。DNS 失败会让一批正常节点同时显示超时。
3. 把测试 URL 换成另一个稳定的 204 地址，再测试一次。某个测试站点不可达，不代表所有节点同时失效。
4. 确认本地时间准确。涉及 TLS 的连接在系统时间偏差较大时可能握手失败。
5. 查看日志中的 timeout、connection refused、network is unreachable 等信息，分别处理超时、端口拒绝和路由不可达。

第三步：验证流量确实经过代理

验证代理不能只看系统代理开关变色，也不能只看节点旁边出现延迟数字。可靠的方法是同时观察出口地址、Clash 连接记录和规则命中结果。三项能够对应起来，才能确认请求经过了预期节点。

方法一：对比直连与代理出口地址

1. 关闭系统代理和 TUN，访问一个显示公网 IP 的服务，记录直连出口。
2. 重新开启系统代理，固定选择刚测试过的节点。
3. 使用新的无痕窗口再次查询公网 IP，避免页面缓存影响结果。
4. 比较两次地址，并在 Clash「连接」页面找到对应域名的请求。

如果使用的是负载均衡策略组，不同连接可能出现不同出口，不能要求每次查询都完全一致。若使用手动选择的单节点，出口通常应保持相对稳定。公网 IP 没有变化时，也不要立刻判定失败：当前规则可能把查询服务设为 DIRECT，应先看连接记录中的出站策略。

方法二：在终端中明确指定代理端口

终端程序通常不会自动读取桌面系统代理。可以使用 curl 显式指定本地代理，从而把“终端是否继承系统设置”与“Clash 端口是否工作”分开测试。以下命令假设 HTTP 或 mixed-port 为 7890：

curl --proxy http://127.0.0.1:7890 https://api.ipify.org

Windows PowerShell 中建议调用 curl.exe，避免旧版环境把 curl 解析为其他命令：

curl.exe --proxy http://127.0.0.1:7890 https://api.ipify.org

若配置单独开放 SOCKS5 端口 7891，可以让域名解析也通过代理端完成：

curl --proxy socks5h://127.0.0.1:7891 https://api.ipify.org

socks5h 中的字母 h 表示把主机名交给 SOCKS 代理解析。若命令返回连接被拒绝，应先核对实际监听端口，而不是直接更换节点。部分新配置只启用 mixed-port，此时未必存在独立的 socks-port。

方法三：查看连接详情和规则链

打开客户端的「连接」页面，再刷新目标网页。请求详情通常会显示目标主机、源地址、上传下载流量、命中的规则和最终策略链。例如一条记录可能显示：

example.com
规则：DomainSuffix
策略链：节点选择 → 香港节点 → HK-01
网络：TCP
状态：Active

看到 DIRECT 表示该请求按规则直连；看到具体节点名称表示代理出站；看到 REJECT 表示规则主动拒绝。若连接列表没有出现目标请求，流量可能没有进入 Clash，排查重点应转向浏览器代理、应用内代理、TUN 路由或本机防火墙。

识别“能测速但没代理”的假连通

假连通最常见的表现是节点延迟正常、客户端显示运行中，但目标应用仍使用直连网络。原因通常不在节点本身，而在策略组选择、规则命中或应用接管范围。按下面顺序检查，比重复更新订阅更有效。

顶层策略组没有选中刚测试的节点

用户可能在「香港节点」组中选了 HK-01，但规则实际引用的是「节点选择」，而「节点选择」仍指向「自动选择」。此时 HK-01 能正常测速，却没有承担业务流量。回到顶层组，沿当前选项逐层查看，直到最终节点名称与预期一致。

目标域名被规则设为直连

规则模式会按顺序匹配。诸如 DOMAIN-SUFFIX、GEOSITE、GEOIP 和兜底 MATCH 都可能改变出口。连接记录若显示 DIRECT，说明系统代理本身可能已经工作，只是规则决定直连。可以短时切到全局模式做对照，验证完成后再回到规则模式检查规则顺序。

浏览器或应用绕过系统代理

部分浏览器允许扩展或企业策略单独设置代理，开发工具、游戏启动器、容器和终端程序也可能直接建立连接。系统代理通常只影响主动读取操作系统代理设置的程序。此类应用可以配置本地 HTTP/SOCKS 地址，或在确认系统兼容后启用 TUN 模式。

TUN 已开启但路由或权限未就绪

TUN 模式通过虚拟网络接口接管更广范围的流量。Windows、macOS 和 Linux 都可能要求管理员权限或安装系统扩展。开启后应检查 TUN 状态、虚拟接口和日志；仅看到开关处于开启位置，不代表路由已成功写入。若日志提示接口创建失败或权限不足，先修复权限，再测试节点。

旧连接没有随节点切换重建

切换节点不会强制所有既有 TCP、QUIC 或长连接立即迁移。浏览器标签页、视频客户端和即时通信程序可能继续使用旧连接。切换后可关闭对应连接、重新载入页面，必要时退出并重开应用。测试网页时使用新无痕窗口，能减少缓存、Service Worker 和持久连接造成的干扰。

IPv4 与 IPv6 走了不同路径

目标域名可能同时返回 A 与 AAAA 记录。应用选择 IPv6，而当前代理或 TUN 路由只覆盖了 IPv4 时，会出现部分请求直连、部分请求代理的混合结果。连接页面和日志可以确认请求使用的地址族。不要仅凭一个公网 IP 页面推断全部流量路径。

建立可重复的第一次连接检查流程

完成一次成功连接后，可以把排查步骤固定下来。以后更新订阅、更换网络或切换客户端时，沿相同顺序检查，能快速区分配置问题、节点问题和应用接管问题。

1. 选择当前订阅配置，确认 mihomo 或其他兼容内核正在运行。
2. 保持规则模式，先只开启系统代理，不同时叠加 TUN。
3. 在顶层手动策略组中选择一个具体节点。
4. 间隔 10 至 20 秒测试三次，记录延迟和是否出现超时。
5. 访问目标页面，同时观察「连接」与「日志」是否出现对应请求。
6. 核对规则命中、策略链和最终节点名称。
7. 对比直连与代理出口地址，再用终端显式指定 127.0.0.1:7890 做独立验证。
8. 确认基础链路正常后，再启用自动选择、故障转移或 TUN。

选节点、测延迟和验证代理是三个独立环节。选中节点解决“准备使用谁”，延迟测试解决“探测请求能否通过”，出口与连接记录则解决“实际流量去了哪里”。把三步分开判断，才能避免把一个绿色延迟数字当作完整的连接结论。