Clash 首次连接检查清单：节点选择、延迟测试与代理生效验证

1. 连接前检查：配置、内核与流量入口

订阅导入成功，只能说明客户端取得了配置，不代表流量已经进入 mihomo 内核。首次验证应拆成四步：确认配置被加载、确定流量入口、选择策略组节点，再检查目标连接的实际出站。不要同时改 DNS、TUN 与规则，否则出现问题时很难判断是哪一项产生了影响。

1. 确认当前配置。进入客户端的「配置」或「Profiles」页面，检查当前选中项是否为刚导入的订阅。下载成功但没有激活的配置，不会替换正在运行的规则与节点。
2. 确认内核运行。查看启动日志是否有配置解析错误、监听端口占用或进程退出记录。出现 YAML 解析错误时，应先修复配置，而不是继续切换节点。
3. 选择规则模式。首次连接通常从 Rule／规则模式开始。Global／全局模式用于临时对照；Direct／直连模式不适合作为节点代理验证的起点。
4. 记录实际端口。在客户端设置或有效配置中查看 HTTP／混合端口。例如 mixed-port: 7890 表示该入口可接受 HTTP 与 SOCKS 代理连接；具体数值以当前配置为准。

系统代理与 TUN 的选择

桌面端先用系统代理验证浏览器请求，通常更容易定位问题。开启系统代理后，遵循系统代理设置的程序才会使用对应入口；部分命令行工具、游戏和自行管理网络的应用不会跟随。TUN 模式通过虚拟网络接口接收被路由进来的 IP 流量，覆盖范围还取决于路由、排除项和平台权限，并非打开开关就能保证所有连接进入内核。

首次测试不要同时运行两个接管系统代理或创建代理路由的客户端。Android 与 iOS 上常见的是系统 VPN 授权入口，需要确认授权已完成且连接保持启用；不能直接套用桌面端浏览器的系统代理操作。

2. 策略组选择：找到真正决定出站的节点

在「代理」→「策略组」页面，看到的卡片可能是单个节点，也可能是另一个策略组。规则先决定使用哪个策略组，该组再决定最终节点。仅在一个没有被目标规则引用的组里更换节点，对该网站不会产生影响。

首次验证用固定节点

1. 找到目标网站规则引用的策略组。尚不清楚规则指向时，可先发起一次访问，再到连接记录中反查。
2. 若该组允许手动选择，选定一个具体节点，避免测试过程中自动切换导致结果难以对照。
3. 若组内选中的是「自动选择」等子组，继续展开，确认最终使用的节点，而不是只记住外层组名。
4. 切换后重新建立测试连接。已有的 TCP 长连接、HTTP/2 连接或 QUIC 会话不一定立即迁移到新节点。

DIRECT 表示直连，不是名称特殊的代理节点。REJECT 表示拒绝连接。如果节点显示正常但目标规则最终指向这两类出站，延迟测试再低也不会让该请求按预期经过代理。

3. 延迟测试：数值、超时与吞吐的区别

客户端里常见的节点延迟不是单纯的 ICMP ping。mihomo 的 URL 探测会经节点访问配置的测试地址，结果会受到节点连接建立、协议握手、测试站点响应和本地网络状况影响。客户端展示的具体计时口径还取决于调用方式，因此只适合在同一测试条件下比较。

统一测试条件后再排序

• 同一个 URL：检查有效配置中的 url。常见探测地址为 https://www.gstatic.com/generate_204；测试目标不同，数值不宜直接比较。
• 同一网络：在同一 Wi-Fi 或有线网络上完成一轮测试，不要把蜂窝网络结果混在一起。
• 重复观察：连续测试 3 次，保留每次结果。若一组示例值为 82、91、86 ms，而另一组为 65、460、超时，前者更适合优先验证稳定性。这是读数示例，不是本站实测结果。
• 区分单次与周期探测：手动点击测试得到一次结果；策略组的健康检查则按自身配置运行，两者更新时机可能不同。

下面是策略组配置片段，仅用于识别字段；它引用了已有的 PROXY 组，不能作为完整配置直接运行。interval: 300 的单位是秒，tolerance: 50 的单位是毫秒，后者用于减少小幅延迟变化引起的切换，不是请求超时。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - PROXY
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

延迟低不等于下载快

短请求完成时间和持续传输吞吐是两个指标。一个显示 70 ms 的节点可能受出口带宽、拥塞或服务端限速影响，下载速度仍低；显示 160 ms 的节点也可能提供更稳定的长时间传输。首次连接应先确认网页可正常访问，再按实际用途测试视频、文件传输或交互响应，不宜仅凭列表中的最小数值决定长期使用项。

4. 代理生效验证：入口、规则与出口三项证据

最可靠的验证不是只看连接开关，而是为同一次请求建立证据链：流量进入内核，命中预期规则，最终由预期节点出站。浏览器能打开一个网站，只能说明存在可用路径；如果该网站本来就能直连，这个结果无法单独证明代理生效。

用显式代理验证本地入口

假设已确认混合端口为 7890，可用以下命令绕过“应用是否跟随系统代理”这一变量。Windows PowerShell 使用 curl.exe，避免部分环境中的同名别名影响参数解析；macOS 与 Linux 可将命令名改成 curl。

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

--noproxy "" 用于清空此命令的代理绕过列表。该命令只证明显式指定的入口可用，不代表系统代理已经配置正确，也不会强制规则选择代理节点。如果规则把这个 IP 查询服务分到直连，返回的仍可能是本地网络出口。

在连接记录中追踪同一次访问

1. 打开客户端「连接」页面，按目标域名筛选，例如 api.ipify.org。
2. 发起新请求，查看目标域名或目标 IP、命中规则、策略链与最终节点。短连接可能很快消失，可结合历史记录或日志查看。
3. 确认链路不是 DIRECT，且最终节点与手动选择一致。若显示子组名称，继续查看其实际成员。
4. 若完全没有记录，先检查端口、应用代理设置及 TUN 路由，不要直接归因于远端节点。

日志中的 info 级别通常足以查看常规连接与规则信息。需要进一步排查时可临时启用 debug，完成后恢复原级别。不同客户端可能对日志重新排版，重点是目标、规则与出站，不必要求文字格式完全一致。

对照出口 IP

先在允许直连的测试环境下记录同一 IP 查询服务的直连结果，再通过已确认的代理规则重复查询。两次结果不同，且代理请求的连接记录指向预期节点，才能形成更完整的判断。IP 地理位置数据库可能滞后，节点名称中的城市也不一定等于数据库显示的城市。

如果两次结果相同，先确认查询请求是否命中直连规则，随后检查代理出口是否恰好与当前网络共享公网地址。双栈网络还要区分 IPv4 与 IPv6；一次 IPv4 查询不能证明 IPv6 流量也被接管。不要为了让检测页面显示某种结论就盲目关闭 IPv6，应先核对客户端的 IPv6、DNS 与路由配置。

5. 常见异常：按现象缩小检查范围

若只在启用 TUN 后出现异常，应重点检查管理员或系统扩展权限、虚拟网卡、路由以及 DNS 接管。不要直接复制包含 auto-route、dns-hijack 的片段覆盖整个订阅：这些设置与平台、内核版本和客户端管理方式相关，错误覆盖还可能在下一次订阅更新时被替换。

如需向维护者反馈，提供操作系统、客户端版本、mihomo 内核版本、当前模式、入口端口、目标域名与脱敏错误信息。隐藏订阅链接、认证参数和控制接口密钥；连接日志也可能包含访问记录，不应原样公开整份文件。

6. 首次连接通过标准

• 当前 Profile 已激活，内核持续运行，日志没有配置加载错误。
• 用于测试的应用流量能够进入内核，连接页面能找到对应目标。
• 目标命中预期规则，策略链的最终出站与选择一致。
• 同一测试条件下完成多次延迟探测，并用实际目标确认可用性。
• 出口查询与连接记录互相印证，IPv4、IPv6 的验证范围有明确区分。

完成这些检查后，再恢复自动选择组或扩展到 TUN 使用场景。每次只改变一项设置，并重新建立测试连接，通常比反复刷新订阅、更换节点或重装客户端更容易找到问题所在。基础操作可继续查阅使用指南，概念区别可在概念速查中核对。