Clash 首次连接怎么验证：选节点、测延迟与确认代理生效

首次连接的验收标准：接管、命中与出口

订阅导入成功，只能说明客户端已经取得配置，不能证明浏览器、命令行或游戏正在使用代理。节点旁出现延迟数字，也只代表一次指定测试请求取得了结果。完整验证需要把应用入口、规则决策、节点连接和目标响应连起来检查。

客户端负责订阅管理、开关和界面；Clash 或 Clash Meta（mihomo）等内核负责监听端口、匹配规则并建立连接。不同客户端的菜单名称与端口默认值可能不同，下面以界面中的「配置」「代理」「连接」「日志」等功能入口说明操作，不把某一款客户端的布局当成统一标准。

1. 配置已加载：当前配置处于启用状态，内核没有报告解析失败。
2. 流量已进入：新建的测试请求出现在客户端连接列表或内核日志中。
3. 策略符合预期：请求命中的规则指向代理策略组，最终链路包含所选节点。
4. 响应可以核对：目标请求成功，代理出口与对应直连基线能够进行比较。

导入订阅后，先确认当前配置与策略组

检查配置是否真正启用

在「配置」页面找到刚导入的配置，确认它被选中，而不只是出现在列表里。然后查看「日志」页面是否有 YAML 解析错误、策略名称不存在、端口监听失败等信息。订阅更新失败时，有些客户端仍会继续使用上一次成功加载的配置，因此应同时核对更新时间与节点列表。

• 节点数量为零：先检查订阅获取结果，不要把问题归因于系统代理。
• 提示策略名称不存在：检查规则、策略组与节点提供者引用是否一致。
• 提示地址被占用：确认本地代理端口是否被另一个客户端占用。
• 节点能显示但全部失败：继续检查订阅有效期、网络可达性与内核协议支持。

沿策略组展开到具体节点

进入「代理」页面，先选择「规则」模式，再找到规则实际引用的策略组。假设配置中的规则指向「网页代理」，这个组又选中了「手动选择」，就需要继续展开「手动选择」并选定具体节点。只在另一个无关策略组里点击节点，不会改变这条规则的出口。

select 类型用于手动选择；url-test 通常依据健康检查结果自动选择；fallback 按顺序选择可用项；load-balance 则可能为不同连接分配不同出口。首次排查优先使用已有的手动选择组，固定一个节点，减少自动切换带来的干扰。

如果组里当前选中 DIRECT，对应连接会直连；选中 REJECT，对应连接会被拒绝。策略组标题叫“代理”并不意味着内部一定选择了代理节点，必须检查当前选中项。

节点延迟测试：数字代表什么

在「代理」页面执行节点延迟测试，本质上通常是让内核通过待测节点请求一个指定 URL，再记录测试所耗时间。它不是操作系统的 ICMP ping，也不是下载带宽测试。测试 URL、超时阈值、DNS 状态、TLS 握手和连接复用，都可能影响结果。

用固定条件复测，而不是只比较一次排名

1. 固定同一个测试 URL，先串行测试 2 至 3 个候选节点，避免全量并发测试干扰结果。
2. 对候选节点分别测试 3 次，每次间隔约 5 秒，记录成功次数与波动。
3. 保持同一网络环境，不要在测试中途切换 Wi-Fi、蜂窝网络或有线连接。
4. 选定节点后，实际访问需要使用的网站或服务，再看新连接与响应情况。

例如，一组示例记录为 85 / 92 / 88 ms，另一组为 48 ms / Timeout / 410 ms，前者更适合继续验证稳定性。这些数字仅用于说明判断方式，并非本站实测。低延迟节点仍可能受到出口拥塞、目标限制或带宽上限影响，不能据此承诺下载速度。

确认流量入口：系统代理与显式代理测试

浏览器测试先使用系统代理

在客户端开启「系统代理」后，用遵循系统代理设置的浏览器打开一个新页面。暂时停用浏览器里的独立代理扩展，避免扩展覆盖系统设置。打开客户端「连接」页面，再发起一次新请求，观察是否出现对应域名、目标端口和策略链。

系统代理不是全系统流量接管。部分命令行工具、游戏与应用会忽略它。浏览器正常而终端不通，不能直接判定节点失效；应改用工具自己的代理参数，或在确有需求时配置 TUN。

用 curl 显式指定本地端口

以下示例假设当前运行配置的 HTTP 或混合代理端口为 7890。先在客户端端口设置中核对实际值，再执行命令；不要为了照抄示例而覆盖整个订阅。混合端口可接受 HTTP 与 SOCKS 代理连接，单独的 SOCKS 端口则不能直接用于下面的 HTTP 代理写法。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

Windows PowerShell 中可使用 curl.exe，避免旧环境中的同名别名改变参数含义。看到 200 Connection established 只代表本地代理已接受 HTTPS 隧道请求，还要继续看目标站响应或最终错误；目标站返回 301、403 等状态，也不等于代理连接失败。

如果本地端口支持 SOCKS5，可用下面的方式让目标域名通过 SOCKS 请求交给代理端处理，而不是由 curl 先在本地解析目标域名：

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

通过规则命中与出口 IP 确认代理生效

连接详情比模式开关更可靠

在「连接」页面筛选测试域名，检查目标地址、命中规则与链路。不同客户端显示字段不完全相同，但判断重点一致：请求是否进入内核、哪条规则决定了策略、策略组最终落在哪个出站。只看到流量计数增长，可能只是后台更新或其他应用连接，不能替代目标请求核对。

• 命中域名规则：确认规则目标就是预期的策略组。
• 落到兜底规则：检查末尾 MATCH 指向代理还是直连。
• 策略链含 DIRECT：这是直连结果，不因系统代理已开启而改变。
• 切换后仍是旧节点：旧连接可能继续复用原链路，需重建连接后再观察。

规则通常按顺序匹配，先命中的规则决定处理方式。排查时不要只检查最末尾的兜底项，前面的域名规则、IP 规则或规则集可能已经接管请求。关于自定义规则与订阅更新后的保留方式，可参照使用文档中的自定义规则说明。

建立直连基线，再查询代理出口

可先关闭 TUN 和系统代理，暂停其他 VPN 或代理工具，然后用以下命令查询当前网络的公网 IPv4。该查询会向第三方 IP 查询服务发起请求，服务端能够看到请求来源；只在接受这一点时使用。

curl -4 --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

随后保持 TUN 关闭，启动本地代理，用显式代理参数再次查询。确认该查询域名按规则走向所选节点：

curl -4 --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "*" 只让 curl 跳过应用层代理设置，无法绕过仍在运行的 TUN 或其他透明接管。因此，基线测试前关闭这些接管很重要。两次地址不同且第二次连接链路包含所选节点，通常是代理出口生效的有力证据；地址相同则要继续检查规则直连、查询缓存或代理与本地共享出口等情况。

IP 所属地区只是数据库判断，可能过时。IPv4 查询结果也不能代表 IPv6 与所有 UDP 流量的路径，更不能单独证明 DNS 没有泄漏。验收应限定到具体应用、地址族和协议，避免把一次成功扩大为“全部网络都已代理”。

TUN 与常见失败现象：按层定位

需要接管不遵循系统代理的应用时，再考虑 TUN。它通过虚拟网卡与路由接管流量，通常涉及服务权限、路由设置和 DNS 处理。开启开关只代表发起启用操作，还需核对虚拟网卡、路由建立情况及目标应用的新连接。基于 mihomo 的客户端也可能提供不同的默认配置，不能只凭界面相似就假定行为一致。

日志只临时提高详细程度

先用常规日志级别复现一次问题。信息不足时，再临时提高到 debug，记录失败时间与目标域名，完成后恢复原级别。不同错误对应不同阶段：连接被拒绝偏向本地监听；域名解析失败偏向 DNS；握手失败可能涉及节点参数、证书或服务端；超时则需要结合发生位置继续判断。

分享截图或日志前，隐藏订阅链接、认证信息、控制接口密钥与个人访问记录。订阅链接经常包含访问凭据，不应为了排障直接贴到公开评论区。常见系统问题也可以继续查阅Clash 常见问题。

首次连接完成后的复核清单

完成上述流程后，保留一条可重复的测试方法，比记住一次延迟排名更有用。网络、节点和规则更新后，可以用同一目标重新验证，不必每次都从重装客户端开始。

1. 记录当前启用配置、内核名称与实际本地代理端口。
2. 固定一个可用节点，完成至少 3 次同条件延迟检查。
3. 用显式代理请求确认本地入口可用，并看到目标响应。
4. 在连接详情核对规则、策略组和最终节点，而不只看总流量。
5. 对比直连基线与代理出口，注明测试的是 IPv4 还是 IPv6。
6. 按需恢复自动选择或开启 TUN，再对实际应用重新验证。

判断代理是否生效，应以“目标请求进入内核、规则指向正确策略、最终出站符合预期”为主线。延迟数字帮助挑选候选节点，出口查询帮助核对路径，连接日志负责把两者关联起来；三类证据不能互相替代。