一、先确认配置加载，而不是只看订阅存在
订阅已经出现在列表里，不等于它正在运行。首次连接要分别确认三件事：当前配置确实被选中，代理内核成功启动，配置中的策略组已经加载。Clash 是配置与内核生态的统称，Clash Verge Rev 等客户端提供图形界面，mihomo 负责解析配置、建立代理连接和执行规则。界面按钮的位置会随客户端变化，但这三项检查不变。
- 进入客户端的「订阅」或「配置」页面，选中刚导入的配置，确认有当前使用标记。
- 打开「代理」页面，检查是否能看到策略组及其候选节点，而不只是一个订阅名称。
- 进入「日志」页面，确认没有持续出现配置解析失败、代理类型不支持或监听端口占用的错误。
如果订阅提示更新成功，代理页面却没有节点，应先核对返回内容是否为客户端支持的配置。Clash YAML 完整配置与一串 Base64 节点链接不是同一种输入；一个能下载的地址，也可能返回登录页面或错误提示。不要在配置尚未加载时反复切换系统代理。
二、选择实际参与连接的节点
进入「代理」页面后，先找到规则会使用的主策略组。它可能叫「代理选择」「PROXY」或其他名称，这些名称由配置作者决定，并非软件内置的统一菜单。只在某个嵌套组里点亮节点，不保证最终流量就会使用它：上层组还可能指向另一个自动组，目标网站也可能命中专用策略组。
首次测试用手动选择减少变量
- 在可手动选择的策略组中，选一个明确的实际节点；如果候选项是另一组，继续查看它最终指向哪个节点。
- 先避开
DIRECT与REJECT。前者表示直连，后者表示拒绝连接，都不是远端代理节点。 - 优先选服务商标明仍可用、地理位置合适的线路。节点名称中的地区只是说明，真实出口要在后续验证。
- 初次测试只保留一个代理客户端运行，暂时退出其他 VPN 或代理工具，避免系统代理设置互相覆盖。
对于 url-test 自动组，点击某个节点可能只是临时覆盖选择，也可能受客户端行为和配置影响。要判断最终使用谁，应看连接面板中的实际代理链，而不是仅凭节点旁边的选中图标。
三、延迟数字代表什么
节点列表里的延迟通常来自通过该节点访问指定测试 URL 的耗时，不应直接理解成到服务器的 ICMP ping。测试结果会受到本地网络、代理握手、测试地址、服务器负载以及缓存状态影响。不同客户端或不同测试地址得到的数值，未必可以横向比较。
| 测试现象 | 可以判断 | 不能据此判断 |
|---|---|---|
| 返回 85 ms | 该次测试在约 85 毫秒内完成 | 下载速度一定快、所有网站都能访问 |
| 三次为 82、91、88 ms | 这一小段测试中的波动较小 | 晚间高峰也保持同样表现 |
| 显示 timeout | 规定时间内未完成该项测试 | 节点永久失效，或订阅一定过期 |
| 显示空白或未测试 | 当前没有可用的测试结果 | 已经确认连接失败 |
表中的数值是读数示例，不是线路实测排名。可以连续测 3 次，间隔约 5 秒，优先选择能持续完成测试且波动较小的节点。一次 45 ms、随后两次超时的节点，不一定比三次都在 100 ms 左右的节点更适合日常使用。
测速通过，仍需测试实际网站
测试 URL 可能只是返回很小的响应，例如 HTTP 204。它能验证一条基础请求链路，却不能代替视频吞吐测试、账号地区判断或目标网站访问测试。反过来，测试地址被限制也可能导致延迟测试失败，而部分实际网站仍然能打开。遇到这种情况，要结合日志中的目标地址和错误类型判断，不要只看颜色。
四、开启系统代理，建立最小验证路径
第一次验证建议先使用系统代理，让遵循系统代理设置的浏览器进入 Clash；暂不同时叠加 TUN。TUN 用于通过虚拟网络接口接管流量，涉及路由、DNS 和权限，适合在基础连接确认后再按需要配置。移动端通常通过系统 VPN 接口接管流量，不能照搬桌面端的系统代理开关流程。
- 在桌面客户端主界面找到「系统代理」开关并开启，同时确认内核仍处于运行状态。
- 打开客户端的端口设置，记下 HTTP 或混合端口。本文以
7890为例，实际端口以当前界面为准。 - macOS 可到「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」核对；Windows 11 可到「设置」→「网络和 Internet」→「代理」核对。
- 如果浏览器扩展另行设置了代理，先停用它，或明确让它跟随系统设置，然后新建标签页发起测试。
规则模式适合日常使用：只有命中代理规则的请求才走代理。为了隔离规则影响，可以短暂切到全局模式，并在全局策略组里明确选中测试节点；验证后再恢复规则模式。全局模式只改变进入内核后的选路，不会自动接管所有应用，也不会让原本不经过 Clash 的连接进入内核。
五、用出口 IP 和连接面板交叉验证
出口 IP 检测要有对照条件。仅看到一个陌生地址，并不能证明这次请求经过了所选节点；仅看到原来的地址，也不一定说明代理失效，可能是该检测域名被规则设为直连。可靠做法是同时记录模式、目标域名、命中规则和代理链。
按这个顺序做一次对照
- 在允许直连测试的网络环境下，关闭系统代理，并确认没有 TUN 或其他 VPN 接管，用同一个 IP 查询服务记录基线地址。已有基线时可跳过这一步。
- 开启系统代理，短暂使用全局模式并选定节点，重新查询。可在浏览器地址栏访问
https://api.ipify.org查看公网 IPv4 地址。 - 马上进入客户端「连接」页面，搜索
api.ipify.org，查看记录中的目标、规则、代理链和流量计数。短请求可能很快结束，需要提前打开面板并查看已关闭连接记录。 - 恢复规则模式，再查询一次；如果结果变化，核对该域名是否命中了
DIRECT，或进入了另一个策略组。
确认生效的核心证据是：查询请求出现在连接面板中，代理链包含预期节点，且服务返回的是这条路径对应的公网地址。地址与基线不同是有用信号，但不是唯一条件；不同节点也可能共用一个出口 IP。IP 库给出的国家、城市和运营商可能滞后，不宜单凭城市标签判定线路错误。
还要区分 IPv4 与 IPv6。一次 IPv4 查询不会证明 IPv6 的走向；两个查询网站若使用不同地址族，显示不同地址属于可能现象。需要验证 IPv6 时，应单独测试支持 IPv6 的目标，再对照连接记录、客户端接管范围和 DNS 设置判断。
六、用命令行定位本地端口问题
当浏览器结果不明确时，可以让 curl 显式连接本地 HTTP 或混合代理端口，绕过浏览器扩展和系统代理设置。下面的 127.0.0.1:7890 仅是示例；如果客户端显示混合端口为 7897，就把命令中的端口改成 7897。不要把纯 SOCKS 端口当作 HTTP 代理使用。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.orgWindows PowerShell 中可以使用 curl.exe 运行同样的参数，避免部分旧环境中的命令别名差异。此命令明确指定代理入口，但请求进入内核后仍受当前规则模式控制；要排除规则直连，应配合前面的临时全局测试，并检查连接面板。
Failed to connect：先确认内核启动、本地监听端口及地址正确，重点排查请求是否到达本地代理。- 约 20 秒后超时：说明在本次总时限内未完成，应继续看内核日志里的远端连接、DNS 或 TLS 错误。
- 返回 IP，但浏览器不通：优先检查浏览器独立代理、扩展和旧连接；此时本地代理端口至少能处理这次命令行请求。
不要用关闭证书验证作为常规修复。若出现证书时间错误，先检查操作系统日期、时区和自动校时；若只有某个网站失败，再分析该站证书和线路，而不是直接降低整个浏览器的安全设置。
七、常见结果的排查顺序
| 结果 | 下一步检查 |
|---|---|
| 延迟正常，浏览器打不开 | 核对系统代理、浏览器独立代理，以及请求是否出现在连接面板。 |
| 连接记录显示 DIRECT | 查看命中规则及目标策略组；必要时临时全局测试，验证后恢复。 |
| 代理链正确，目标仍超时 | 换一个实际网站，再换一个节点，区分目标站限制与线路故障。 |
| 浏览器可用，其他应用不可用 | 先查应用代理设置；确需更广接管时，再配置 TUN 并验证 DNS。 |
| 全部节点测试失败 | 依次检查本地网络、订阅有效性、系统时间、内核日志和测试 URL 可达性。 |
| 切换节点后出口不变 | 确认规则指向的策略组，关闭旧连接再重试，并考虑多个节点共用出口。 |
每轮只改一个变量。例如先保持节点不变，只在规则与全局之间切换；再保持模式不变，换另一个节点。一次同时改 DNS、TUN、端口和节点，即使恢复连接，也难以知道问题出在哪一层。
八、首次连接完成后的记录
验证通过后，恢复准备长期使用的规则模式，再访问一个应当直连的网站和一个应当代理的网站，分别检查连接记录。直连请求显示 DIRECT、代理请求显示预期策略链，才说明分流行为与配置意图一致；两个网站都能打开本身不足以证明规则正确。
- 记录客户端名称、内核名称、当前配置名称及本地监听端口。
- 记下测试域名、模式、最终节点、出口 IP 和测试时间，便于后续对比。
- 需要 TUN 时再单独开启，重复目标网站与出口验证，并检查是否与现有 VPN 或虚拟网卡冲突。
- 日后出现异常，先重现这条最小验证路径，再处理应用专属设置。
首次连接的验收重点不是得到最低延迟，而是建立可重复的证据链：配置已加载、节点可连接、请求进入内核、规则指向正确、目标服务返回响应。把这几项分开确认，后续更换订阅或客户端时也能沿用同一套判断方法。