Clash 首次连接排查:节点选择、延迟测试与代理生效验证

1. 先确认配置、内核与流量入口

导入订阅成功，只代表客户端取得并识别了配置，不代表流量已经经过节点。一次代理访问至少经过四步：应用把请求交给本地入口、mihomo 按规则选择策略、策略组选出节点、节点连接目标服务。排查时沿这条链路逐段验证，比反复更新订阅更有效。

本文以使用 mihomo 内核的桌面客户端为主。不同客户端的按钮位置可能变化，先找“配置”“代理”“连接”“日志”这四类页面，再确认系统代理或 TUN 的状态。Android 通常通过 VpnService 接管流量，不需要照搬桌面系统代理步骤。

开始测试前的四项检查

1. 配置已经启用：不仅要看到订阅名称，还要确认它是当前配置。“已下载”与“已激活”不是同一状态。
2. 内核正在运行：日志中没有持续出现配置解析失败、端口占用或进程退出。协议不受支持时，应先核对客户端所用内核。
3. 使用规则模式：首次验证先选“规则”或 rule，记录当前策略组选择，不要同时修改规则和 DNS。
4. 只留一条接管路径：桌面先关闭其他代理软件与 VPN，单独测试系统代理；确实需要接管不遵循系统代理的应用，再测试 TUN。

2. 节点选择：检查实际生效的策略链

“代理”页面里的卡片可能是节点，也可能是策略组。手动选择组 select 使用指定选项；自动测速组 url-test 根据测试结果与容差选择；故障转移组 fallback 通常按配置顺序选择可用项。不能只看一个带地区名称的选项就认定出口已经切换。

例如，规则把目标交给“网页访问”组，该组又选择“自动选择”，最终才落到某个节点。此时更改另一个“手动节点”组，不一定影响这次访问。应在连接详情里追踪策略链，而不是只查看代理页上被高亮的卡片。

首次选择的操作顺序

1. 打开客户端“代理”页，找到访问目标所使用的策略组。暂时不清楚时，先记录主选择组的名称。
2. 在可手动选择的组中，选一个有明确名称且测试成功的节点，避免同时切换多层嵌套组。
3. 重新发起目标访问，再到“连接”页核对规则、策略组与最终节点。
4. 需要换节点时，只更改这一项，再重复同一个测试，保持目标网址和网络环境不变。

地区名称是服务提供者给出的标签，不是物理距离或实际出口的证明。首次测试可以选地理上较近的地区作为候选，但最终应以连接成功率、重复测试波动和实际业务访问为准。订阅到期、流量耗尽或服务端认证失效，也会导致多个节点同时不可用。

3. 延迟测试：毫秒数能说明什么

客户端常见的延迟测试，是让内核经指定节点请求一个测试 URL，再报告耗时或失败。它通常不是 ICMP ping，也不是下载测速；测试是否包含连接建立、是否复用连接以及成功状态判定，会受内核实现和配置影响。不同测试地址、不同客户端显示的数字，不宜直接横向比较。

固定目标，重复三次

可以每隔约 10 秒测试一次，连续记录三次结果。以下是判读示例，不是本站实测：节点 A 为 82、88、85 ms；节点 B 为 48、760 ms、超时。首次使用更适合先选 A 验证稳定性，而不是只按 B 的最低值排序。大文件吞吐、视频缓冲和游戏 UDP 表现，仍需分别测试。

如果全部节点同时超时，先看客户端使用的测试地址。某个探测站不可达，可能让正常节点也显示失败。可以在客户端提供的测速设置中，改用另一个可信且响应轻量的 HTTPS 地址进行对照；不要因为测试失败就立刻覆盖整份订阅。

4. 系统代理验证：先用明确的本地端口测试

桌面系统代理告诉遵循系统设置的应用使用本地代理，但它不会自动覆盖所有程序。命令行工具、独立配置代理的浏览器、部分游戏和 UDP 应用可能另走路径。先核对客户端设置中显示的 HTTP 或混合端口，再做显式代理测试，能把“节点问题”和“系统接管问题”拆开。

核对端口与系统设置

• Windows 11：进入「设置」→「网络和 Internet」→「代理」，核对手动代理地址和端口。若客户端采用自动配置脚本，也要检查对应项。
• macOS：进入「系统设置」→「网络」→ 当前网络连接 →「详细信息」→「代理」，核对网页代理或安全网页代理的设置。
• 客户端：检查本地监听端口。下文用 7890 举例，只有实际 HTTP 或混合端口确为此值时，才能直接运行命令。

本机代理地址通常是 127.0.0.1。如果配置只开放 SOCKS 端口，不要直接使用下面的 HTTP 代理命令；应选择正确协议，或使用客户端提供的混合端口。也不需要为了本机测试打开“允许局域网”。

# macOS / Linux：显式使用本机 HTTP 或混合端口
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output /dev/null https://example.com/

# Windows PowerShell：使用 curl.exe，避免旧环境中的命令别名差异
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output NUL https://example.com/

--connect-timeout 10 限制连接阶段的等待时间，--max-time 20 限制整次请求。示例目标只是连通性检查地址，不能据此判断所有业务网站都可用。使用 --proxy 只指定进入内核的入口，最终是否经远端节点，仍由当前模式和规则决定。

• 连接本地端口被拒绝：先检查内核是否运行、端口是否填错，以及该端口是否支持 HTTP 代理。
• 出现 CONNECT 200：说明代理接受了隧道建立请求；继续观察 TLS 和最终 HTTP 响应，不能把这一行单独当作完整访问成功。
• 显式代理成功，浏览器失败：优先检查系统代理、浏览器扩展、独立代理设置及旧连接，不急于更换订阅。

5. 连接面板：确认请求命中规则与最终出口

浏览器能打开网页，不等于网页走了远端代理。它可能命中 DIRECT，也可能完全没有进入内核。有效验证应同时包含三项证据：连接面板看到新请求、规则匹配符合预期、策略链落到预期节点。

按一次请求核对，而不是观察总流量

1. 打开“连接”页，记录当前时间，在浏览器新开一个窗口访问需要验证的目标。
2. 按目标域名筛选连接。若连接很短暂，提前打开日志辅助观察；部分客户端不保留已结束连接。
3. 展开详情，检查目标域名或 IP、命中规则、策略链与上传下载字节。进程名称是否可见取决于平台和权限，不是必备证据。
4. 若显示 DIRECT，先判断是否符合规则设计。规则模式下直连本地服务或部分网站，本身就是正常分流。
5. 换节点后关闭旧标签页或结束对应旧连接，再发起新请求。已有 TCP 长连接通常不会因切换策略而自动迁移。

出口 IP 查询可以作为补充：使用同一个查询服务，对比直连与预期代理访问结果，并在连接面板中确认该查询确实命中了代理策略。不要只比较两个不同网站显示的地区名称，数据库、IPv4 与 IPv6 差异都可能造成误判。即便出口 IP 改变，也只证明这次查询的路径，不能证明所有应用都已接管。

6. TUN 与常见故障：一次只改一个变量

显式代理已经成功，而某个程序始终不出现在连接面板时，再考虑 TUN。TUN 通过虚拟网络接口和相关路由接管流量，适合不遵循系统代理的应用；它仍然使用内核的规则与策略组，并不意味着所有请求都会走远端节点。启用时可能需要管理员权限、服务模式或驱动支持，具体以客户端提示为准。

短时全局对照，完成后恢复规则模式

如果目标在规则模式下失败，可以短时切到全局模式，并在 GLOBAL 组中明确选择同一个可用节点，再重新建立连接。若全局成功、规则模式失败，重点核对该目标命中的规则与策略；若两者都失败，继续检查节点和目标服务。全局模式只是诊断对照，不会让未进入内核的应用自动进入代理。

排查期间不要同时切换节点、改 DNS、开 TUN 和更新规则，否则结果无法归因。每一步记录“时间、目标、模式、入口端口、节点、错误信息”，更容易复现问题。日志中的 timeout、connection refused 与认证错误指向不同环节，应按具体错误处理，而不是统称为“网络不通”。

7. 首次连接通过的判断标准

• 当前配置已激活，mihomo 内核运行正常，本地代理端口可连接。
• 候选节点对同一测试目标重复测试成功，没有持续超时。
• 实际应用发起的新请求出现在连接面板，且命中预期规则。
• 需要代理的请求最终落到预期节点，直连请求保持预期的 DIRECT 路径。
• 实际业务访问成功；切回规则模式后再次验证，而不是只停留在全局测试结果。

完成这五项，就建立了从本地入口到最终出口的证据链。后续遇到断连，可以沿相同顺序复查，先定位发生变化的环节，再调整设置。有关订阅导入与系统接管的完整步骤，可继续查看入门指南；需要核对配置概念与参数时，查阅完整文档。