首次连接结论：先选稳定节点，再核对实际请求

首次连接不必从节点列表中找出绝对最低的毫秒数。先在当前规则使用的策略组里，选择一个连续测试能成功、实际目标网页能打开的节点，再通过连接记录确认它确实承载了请求。最后查询出口 IP，核对外部网站看到的网络出口。三项结果相互对应，才比单看一个绿色延迟数字可靠。

本文适用于采用 Clash 或 Clash Meta（mihomo）内核的常见客户端。不同外壳的中文翻译与页面布局会变化，下面用 Profiles、Proxies、Connections、Logs 等页面名称定位功能，不把某个客户端的开关位置当成通用标准。已有 TUN 或企业网络配置的设备，先记录原状态，不要直接删除路由或关闭安全软件。

一、导入订阅后，先确认配置和策略组生效

订阅导入成功不等于节点正在使用

订阅提供节点与规则等配置，客户端负责加载配置，内核负责处理连接。列表里出现节点，只说明节点信息已被读取；如果仍激活着旧配置、实际规则指向另一个策略组，点击测速也不会改变网页的出口。

  1. 进入 Profiles（配置），确认新导入的配置处于激活状态。检查订阅更新时间，以及是否出现解析失败、下载失败等提示。
  2. 进入 Proxies（代理），将运行模式设为 Rule（规则）。Global（全局）通常将流量交给全局策略，Direct（直连）则不能用来验证节点代理链路。
  3. 找到规则实际引用的选择组。如果有多层策略组，沿选中项向下查看，直到确认最终节点，而不是停留在“自动选择”这一层。
  4. 首次诊断优先用可手动选择的 select 组固定节点。自动组可能因健康检查切换，使前后两次测试无法对应同一出口。

例如，规则最终指向“代理选择”，而“代理选择”当前选中 DIRECT，那么另一个节点显示 80 ms 也不会使这条规则自动走它。如果配置没有手动选择组，不要随意改写整份订阅；先记录自动组当前选中的节点，再结合连接详情判断实际路径。

检查接管入口与本地监听端口

准备验证浏览器时，打开客户端的系统代理开关，并确认浏览器采用系统代理设置。浏览器扩展、独立代理设置或其他 VPN 可能改变路径。终端程序则未必读取系统代理，后文会用显式指定代理的命令单独验证。

本地地址通常为 127.0.0.1，但端口必须以实际配置为准。下面仅是端口含义示例，不是完整可联网配置，不包含任何节点或订阅：

# 配置片段示例：不要覆盖整份订阅
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port: 7890 表示该监听端口可接收 HTTP 与 SOCKS 代理请求；某些配置会分别使用 port 和 socks-port。不要把控制接口端口误当成代理端口，也不要因为看到示例里的 7890，就修改已经正常工作的监听设置。

二、节点延迟测的是什么，怎样比较才有效

客户端里的节点延迟一般来自经该节点访问指定测试 URL 的耗时，不等同于操作系统的 ICMP ping，也不是下载速度。它会受测试地址、DNS、连接复用、节点负载和客户端实现影响；不同客户端之间的数字不能直接当作统一基准。

一些配置使用 https://www.gstatic.com/generate_204 作为连通性测试地址。若该地址在某条线路上受限，节点可能显示超时，但其他网站仍能访问；反过来，测试 URL 成功也不代表目标视频站、工作系统或游戏服务一定可用。

显示结果可以判断什么下一步
连续返回数值测试地址经该节点可达，当前测试链路有响应访问实际目标并核对代理链
数值较低但网页慢短请求快，不代表吞吐量或目标站响应快检查目标站、带宽、丢包与高峰负载
偶尔 timeout测试存在波动，也可能是测试地址受限隔开测试时间，比较另一节点与实际网页
全部 timeout存在共同故障的可能，不能直接判定全部节点失效检查本地联网、订阅状态、DNS 与错误日志

用三轮结果替代一次排名

  1. 先选 2～3 个候选节点，避免对上百个节点同时发起测试，给当前网络造成额外并发。
  2. 保持同一网络、同一测试地址，间隔约 10 秒进行一轮，合计测试三轮。
  3. 记录是否超时以及数值波动，再对同一目标网页进行实际访问。

以下仅为判断方法示例，并非本站实测：节点 A 三轮为 68、240 ms、超时，节点 B 为 105、112、109 ms。首次连接更适合先用 B 建立可复现基线，而不是只看 A 的最低值。若两个节点都稳定，优先选择满足目标服务地区要求、实际访问也顺畅的一个；地理距离近不保证跨运营商路由更短。

三、用浏览器验证：网页打开不等于命中代理

浏览器验证要使用真实网络请求。已经打开的页面可能命中缓存，部分资源也可能由 Service Worker 返回；仅观察页面还在显示，无法证明新配置生效。可以在开发者工具的 Network（网络）面板中临时勾选 Disable cache（停用缓存），保持开发者工具打开后重新加载，并记录测试时间。

  1. 选定一个你确实需要访问的目标域名，先关闭无关标签页，减少后台请求干扰。
  2. 打开浏览器设置，确认使用系统代理；若有代理扩展，记录原状态后暂时停用，避免扩展覆盖设置。
  3. 重新加载目标网页，检查主文档是否真正收到响应，是否出现代理连接失败或证书错误。
  4. 立即切回客户端的 Connections（连接）页面，按域名或时间查找刚才的请求。

浏览器能打开网页，是功能验证的一部分；浏览器不能打开网页，也不一定是节点故障。如果命中了代理链且其他站点正常，目标站自身故障、地区限制、账号状态与 DNS 结果都需要分别检查。

四、用连接记录与日志确认规则、策略组和节点

Connections 与 Logs 的作用不同：前者适合查看请求路径，后者适合找握手失败、解析失败、连接被拒绝等原因。不同客户端显示字段可能不同，至少应寻找目标域名或 IP、匹配规则，以及最终代理链这三项信息。

如果连接页面只显示活跃连接，短请求可能一闪而过。可以先打开连接页面再刷新网页，或使用客户端支持的连接历史。Logs 页面可临时切换到 info 级别观察路径；若仍不足，再短时间启用 debug，并在排查后恢复，避免持续积累大量记录。

按结果分支，不要一次改多项

分享截图或日志前，遮盖订阅链接、令牌、节点服务器地址和个人网络信息。订阅 URL 常包含访问凭据，不适合直接贴到公开讨论区。

五、用出口 IP 与显式代理命令交叉验证

出口 IP 表示查询服务看到的请求来源。它可以帮助区分本地宽带出口与节点出口，但 IP 地理数据库可能滞后，同一节点也可能使用多个出口。判断时应结合连接记录，不要只凭城市名称认定线路有问题。

先建立直连与代理的对照条件

在条件允许的个人网络中，可先记录关闭代理、关闭 TUN 且没有其他 VPN 接管时的出口，再开启代理查询同一个服务。若 TUN 或其他系统级隧道仍在运行，“没有使用 HTTP 代理”的请求也可能继续被接管，不能作为直连基线。

下面以支持 HTTP 代理的本地 127.0.0.1:7890 为例。只有实际端口一致时才能直接运行；这些命令不会修改系统设置。Windows PowerShell 中请将 curl 写成 curl.exe，避免某些环境把名称解析为其他命令。

# 不使用 curl 的显式代理设置；不代表能够绕过 TUN
curl --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

# 强制通过指定的 HTTP 代理端口访问同一查询服务
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "" 用于清空本次请求的代理绕过列表，避免现有 NO_PROXY 设置干扰。如果查询服务本身不可用，可换一个可信的出口查询服务；不应根据一个服务超时就认定整条线路失败。公开 IP 查询会向该服务暴露此次连接的出口地址。

再验证实际 HTTPS 请求与耗时

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --output /dev/null --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://example.com/

macOS、Linux 可使用上面的 /dev/null；Windows 请改为 NUL，并使用 curl.exe。示例域名用于演示命令结构，排查业务时应替换成实际目标地址。HTTP 200 表示该次请求获得了成功响应，不能代表所有网站都可访问；403、429 也可能说明代理链路已经到达站点，只是被站点策略拒绝。

time_total 是整次请求耗时，包含响应传输，不能与客户端节点测速直接等同。如果显式代理命令成功、浏览器失败，优先查浏览器接管和规则差异；如果命令提示无法连接 127.0.0.1:7890，先确认内核运行状态和端口，不要急着换远端节点。

六、首次连接常见结果与处理顺序

延迟有数值，目标网页仍打不开

先核对该网页是否走了被测节点，再区分 DNS 错误、连接超时与 HTTP 拒绝。测速域名和实际目标不同，通向测试服务器的路径正常，并不能覆盖所有目的地。如果只有一个域名异常，用另一节点对照，并保留相同的浏览器、规则和测试时间范围。

浏览器已代理，终端出口没变化

系统代理通常不是全设备强制接管，很多命令行工具需要环境变量或自己的代理参数。先用上面的 --proxy 完成显式验证。只有明确需要覆盖不遵循系统代理的程序时，再评估 TUN；TUN 涉及路由、DNS、权限和其他 VPN 的兼容，不宜作为第一次测速的同时变量。

出口 IP 改变了，但不是预期地区

确认查询请求的代理链，检查是否误选自动组、是否复用了旧连接，再看 IPv4 与 IPv6 是否走了不同路径。双栈网络下，可对支持相应地址族的查询服务分别测试；单看一次查询的地区标签，不足以判断全部流量的出口。

全部节点都超时

按“本地能否正常联网 → 内核是否运行 → 订阅是否有效 → 测试地址是否可达 → 日志是否报告 DNS 或认证错误”的顺序排查。若其他设备在同一网络也出现相同问题，应优先找共同条件，而不是反复重装客户端。

首次连接的验收标准可以很具体：目标网页获得正常响应，连接详情显示预期规则与节点，出口查询与这条代理链一致。达到这三个条件后，再考虑自动选路、应用分流或 TUN 覆盖范围，比持续追求最低延迟数字更有利于后续排查。