Clash 首次连接怎么选节点:测延迟、切节点、验证代理已生效

先完成连接链路，再比较节点

第一次使用 Clash 或基于 Mihomo 内核的客户端时，先不要盯着节点列表里的延迟数字。一个完整连接至少经过四个环节：配置已载入、策略组已选中节点、系统流量已交给客户端、节点能够访问目标网站。任意一环未完成，都可能表现为“节点有延迟，但网页打不开”。

建议按固定顺序操作：导入订阅，更新配置，选择代理模式，打开系统代理或 TUN 模式，再进入策略组选择节点。图形客户端的名称略有差异，常见路径是「订阅」→「更新」，随后进入「代理」→目标策略组。如果只打开客户端而没有启用系统代理，浏览器通常仍会沿原网络直接连接。

1. 在「订阅」或「配置」页面确认当前 Profile 已启用，并执行一次手动更新。
2. 进入「代理」页面，把运行模式设为「规则」；首次测试不建议直接使用「直连」。
3. 打开「设置」→「系统代理」，确认开关处于启用状态。
4. 回到「代理」→主策略组，选择一个能够完成延迟测试的节点。
5. 查询代理前后的出口 IP，确认地址发生变化，再测试实际网站。

手动选择、自动测速与故障转移的区别

Clash 配置里的“节点选择”实际发生在策略组中。策略组是一组代理节点和选择逻辑的集合。最常见的类型是 select、url-test、fallback 与 load-balance。订阅服务可能把它们显示为“节点选择”“自动选择”“故障转移”或“负载均衡”。

第一次连接优先用手动策略组

手动选择更适合第一次测试，因为变量最少。先在 select 类型的策略组里固定一个节点，完成出口 IP、网页访问和命令行测试。如果连接正常，再切换到自动测速组。这样一旦自动选择结果不理想，可以明确问题来自测速逻辑，而不是系统代理或订阅导入。

节点名称中的地区、倍率和线路标签只提供分类信息，不能代替实测。例如“香港 01”不一定比“日本 02”快，“专线”也不能直接说明本地网络到入口服务器的质量。距离近通常有利于降低往返时间，但运营商互联、晚高峰拥塞和节点负载同样会改变结果。

自动测速看的是测试目标

url-test 会定期请求配置中指定的测试地址，然后比较候选节点的响应时间。一个常见的 Mihomo 配置片段如下：

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港 01
      - 日本 02
      - 新加坡 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval: 300 表示大约每 300 秒重新测试一次；tolerance: 50 表示候选结果差距较小时，允许保留当前节点，减少频繁切换。测试地址返回速度快，只能说明该节点访问这个测试目标的当前表现较好，不能保证访问视频、代码仓库或办公服务时同样最快。

延迟数字应该怎样解读

客户端显示的延迟通常不是传统 ICMP Ping。多数 Clash 图形客户端会通过代理发起 HTTP 请求，记录建立连接并取得响应所需的时间。这个结果同时受到本地网络、代理入口、节点出口、DNS、TLS 握手和测试服务器状态影响。因此，延迟是筛选工具，不是带宽测试。

不要因为一次 65 ms 就认定节点稳定。更可靠的方法是间隔 10 秒测试三到五次。例如同一节点依次为 72、75、79、74 ms，波动较小；另一个节点为 48、210、93、超时，虽然最低值更漂亮，实际使用往往更不稳定。对于视频和下载，还要观察持续吞吐量；对于远程终端和网页交互，则应更重视延迟与抖动。

测速全部超时时先检查什么

• 确认电脑本身可以直连访问普通网站，排除 Wi-Fi 断开或网关故障。
• 在「订阅」→「更新」重新拉取配置，避免使用已过期的节点信息。
• 检查系统时间与时区。时间偏差过大可能导致 TLS 证书验证失败。
• 暂时关闭 TUN，仅启用系统代理测试，避免多个接管方式互相影响。
• 确认本地混合端口没有被其他程序占用，常见值为 7890。
• 查看客户端日志，重点寻找 timeout、connection refused 和 network unreachable。

切换节点后为什么没有立即变化

在策略组中点选新节点后，新建连接通常会使用新选择，但已经建立的连接可能继续复用旧通道。浏览器的 HTTP/2、HTTP/3 长连接，下载工具的分段任务，以及即时通信程序的常驻连接，都可能让旧出口短暂保留。因此，切换后立即刷新同一个页面，不一定能看到出口变化。

按这个顺序让新连接重新建立

1. 进入「代理」→主策略组，确认选中标记已经移动到新节点。
2. 关闭正在测试的网页标签，并等待 5 至 10 秒。
3. 重新打开无痕窗口，避免页面缓存和已有连接影响结果。
4. 再次查询出口 IP，并与切换前的地址比较。
5. 仍未变化时，重启浏览器；必要时在客户端连接页面关闭旧连接。

还要检查规则模式是否把测试网站分配到了预期策略组。规则模式会从上到下匹配域名、IP、进程或规则集合。如果查询出口 IP 的域名命中了 DIRECT，页面显示的仍是本地公网地址，即使主策略组已经选中代理。排查时可在客户端日志或连接列表中找到该域名，核对显示的规则、策略组和实际节点。

可以短暂切换到全局模式做对照测试。全局模式下，流量通常统一交给指定代理节点；如果全局模式能改变出口，而规则模式不能，问题多半位于规则匹配或策略组引用。测试完成后切回规则模式，避免本应直连的局域网或国内服务也经过代理。

用出口 IP 页面验证代理是否生效

最直观的方法是先关闭系统代理，访问一个公网 IP 查询服务，记录当前出口地址；再开启系统代理并刷新查询。两次结果不同，而且代理后的地区与所选节点大致一致，说明浏览器流量已经经过代理。不要只看页面显示的国家或城市，IP 地址本身更适合作为对比依据。

1. 关闭 Clash 的「系统代理」开关，打开 IP 查询页面，记录一组 IPv4 或 IPv6 地址。
2. 重新打开「系统代理」，在策略组中固定一个节点。
3. 新建浏览器无痕窗口，再次查询出口 IP。
4. 切换到另一个地区的节点，关闭查询标签并重新打开，确认地址再次改变。
5. 回到客户端「连接」页面，查看查询域名是否经过目标策略组。

如果 IPv4 已变化但 IPv6 仍显示本地运营商地址，需要检查客户端是否接管 IPv6，以及浏览器访问的查询服务是否优先返回 IPv6。不同系统、TUN 配置和网络环境对 IPv6 的处理不同。只测试 IPv4 不能推断所有 IPv6 流量也经过相同路径。

用命令行分别测试直连与代理

命令行测试能绕过浏览器扩展、缓存和长连接，更容易确认本地代理端口是否工作。以下示例假设 Mihomo 的混合端口为 127.0.0.1:7890。混合端口同时接受 HTTP 与 SOCKS 连接；如果客户端使用其他端口，应以「设置」→「端口设置」中显示的数值为准。

Windows PowerShell

Windows 10 或 Windows 11 可先确认 curl.exe 的真实程序，避免 PowerShell 旧版本把 curl 解释为其他命令。直连和代理请求分别执行：

curl.exe --noproxy "*" https://api.ipify.org
curl.exe -x http://127.0.0.1:7890 https://api.ipify.org

macOS 与 Linux

curl --noproxy "*" https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

第一条命令强制跳过代理，返回本地网络的公网出口；第二条明确把请求发送到 Clash 混合端口。如果两条命令返回不同地址，且第二条请求同时出现在客户端连接记录中，HTTP 代理链路已经生效。若第二条提示无法连接到 127.0.0.1:7890，应检查客户端是否正在运行、端口是否填写正确，以及监听地址是否允许本机访问。

也可以测试 SOCKS5，并让域名解析通过代理端完成：

curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org

--socks5-hostname 与单纯的 --socks5 有一处重要区别：前者把域名交给 SOCKS 代理解析，适合排除本地 DNS 解析结果对测试的影响。如果 HTTP 代理可用而 SOCKS 请求失败，应检查当前端口究竟是混合端口、HTTP 端口还是单独的 SOCKS 端口。

检查本地端口是否正在监听

Windows 可以执行：

netstat -ano | findstr :7890

macOS 可以执行：

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux 可以执行：

ss -lntp | grep 7890

看到 127.0.0.1:7890 或 0.0.0.0:7890 处于监听状态，表示有程序接收该端口连接，但还不能单独证明节点可用。仍需结合代理请求结果和客户端日志判断。若监听进程不是当前 Clash 客户端，可能存在端口冲突，应关闭冲突程序或同步修改客户端端口与系统代理设置。

浏览器可用但其他应用不通的处理方法

浏览器能够访问并不代表所有程序都读取了系统代理。部分游戏、命令行工具、商店应用和自带网络栈的软件会忽略 HTTP 代理设置。此时先查看应用自身是否提供代理选项；如果支持，可填写 HTTP 代理 127.0.0.1:7890，或 SOCKS5 代理使用同一混合端口。

应用没有代理设置时，可以考虑 TUN 模式。常见操作路径是「设置」→「Mihomo」或「内核设置」→「TUN 模式」。首次启用可能需要管理员权限，并创建虚拟网络适配器。开启后应重新测试出口 IP和目标应用，同时检查局域网设备、打印机与公司内网是否仍能按规则直连。

TUN 模式验证重点

• 客户端日志中能够看到目标应用产生的新连接。
• 连接记录显示正确的规则与策略组，不是意外命中 DIRECT。
• DNS 请求能够正常完成，没有连续出现解析超时。
• 关闭系统代理后，目标应用在 TUN 模式下仍能按规则连接。
• 退出客户端后网络可以恢复，默认路由和 DNS 没有残留异常。

不要同时反复切换系统代理、TUN、全局模式和多个节点。一次只改变一个变量，并记录结果。例如先固定“日本 02”，仅开启系统代理；确认命令行代理可用后，再启用 TUN；最后恢复规则模式。这样的排查顺序能快速定位问题位于节点、端口、规则还是流量接管层。

首次连接的稳定检查清单

选到一个延迟较低的节点后，再做一轮连续测试。打开三个不同类型的网站，保持 5 分钟；下载一个 50 MB 左右的公开测试文件，观察速度是否持续；切换两次页面并查看客户端连接记录。短暂测速成功但几分钟后大量超时，往往说明节点负载、线路抖动或本地网络不稳定。

• Profile 已更新，客户端显示的配置更新时间符合预期。
• 主策略组明确选中一个节点，而不是误选 DIRECT。
• 连续三次延迟测试没有大幅跳动或频繁超时。
• 系统代理或 TUN 至少启用一种，并与测试目标相匹配。
• 代理前后出口 IP 不同，连接日志显示目标节点名称。
• 规则模式下常用网站命中预期策略组。
• 关闭客户端后系统网络能够正常恢复。

最终选择不必追求列表中的最低数字。一个稳定在 110 ms、连续使用正常的节点，通常比在 45 ms 到 400 ms 之间跳动的节点更适合日常工作。先保证可用和稳定，再根据视频速度、网页响应或特定地区需求调整策略组。