Clash电脑版第一次连接:选择节点、延迟测速与代理生效检查步骤

1. 连接前检查：配置、内核与监听端口

第一次连接按“配置已加载 → 选择出口 → 测试节点 → 接入浏览器 → 查看连接记录”的顺序操作。导入订阅成功只说明客户端取得了配置；节点可用、规则命中和应用接入仍要分别确认。先不要同时开启系统代理、TUN 模式和浏览器代理扩展，否则失败后难以定位是哪一层出了问题。

1. 确认当前配置。进入客户端的「订阅」或「配置」页面，选中刚导入的配置，确认它处于使用状态，而不只是出现在列表中。页面名称随客户端版本变化。
2. 确认内核运行。打开「日志」页面，检查是否有配置解析错误、端口占用或内核退出提示。只有界面打开，不代表内核已成功启动。
3. 记录本地端口。在设置中查找「端口」「混合端口」或 mixed-port。本文以 127.0.0.1:7890 为示例；如果界面显示其他端口，后续命令必须同步替换。
4. 暂时关闭重复入口。先关闭其他代理客户端和浏览器代理扩展，保留一条明确的接入路径。不要为了连接测试关闭防火墙或证书检查。

如果配置页没有节点，先返回导入步骤。检查订阅是否有效、套餐是否到期，以及当前导入的是 Clash YAML 配置还是其他格式的节点列表。此时反复点击延迟测试，不能补齐缺失的配置。

2. 选择策略组：先选模式，再选实际节点

策略组不是节点本身。它可以包含多个节点，也可以继续引用其他策略组。规则模式下，访问不同目标可能命中不同组，因此“选了一个节点”不等于所有流量都会经过它。

第一次连接采用规则模式

进入客户端的「代理」页面，把运行模式设为「规则」（Rule）。找到配置中用于常规代理流量的策略组，展开后选择一个实际节点。组名由配置作者定义，不能只凭名称判断用途；应结合规则目标和连接记录确认。

例如，规则把某个网站交给“媒体”组，而你只修改了“默认代理”组，这个网站的出口可能完全不变。组名只是说明性示例，操作时应以当前配置中的真实名称为准。若组内还有一层“自动选择”，继续展开，记录最终节点。

手动选择后，新请求通常使用新出口；既有长连接可能继续沿用旧出口。测试时重新打开页面或新建浏览器窗口。需要断开连接时，优先关闭对应测试连接，避免直接清空全部连接而中断下载和会议。

3. 延迟测速：看可达性，不把毫秒当下载速度

在「代理」页面点击节点或策略组旁的测试按钮，等待这一轮结束，再比较结果。常见测试是让内核通过节点请求指定的 HTTP 或 HTTPS 地址，并记录耗时；它不是单纯的 ICMP ping，也不是完整的带宽测试。

怎样阅读测试数字

• 返回毫秒数：表示该节点在本轮测试条件下能够完成相应请求。结果受测试地址、握手、网络拥塞和缓存影响。
• 超时或失败：表示本轮没有在期限内得到有效结果。原因可能是节点不可达、测试目标被限制、DNS 异常或测试条件不匹配。
• 数值较低但网页慢：测试目标和真实网站可能走不同的远端路径；带宽不足、丢包和网站响应慢也不会被一个延迟数字完整体现。

举例说明：同一节点连续三轮显示 82 ms、91 ms、87 ms，另一个节点显示 45 ms、超时、310 ms。前者通常更适合继续做首次连接验证。这些是读数示例，不是本站实测，也不能据此推断节点下载速度。

统一测试条件再比较

如果客户端提供测试地址设置，可先使用配置已有的地址，并确认它适合当前网络。常见连通性测试地址如 https://www.gstatic.com/generate_204，预期返回 HTTP 204，但该地址在不同网络中不一定可达；更换地址后，旧结果与新结果不宜直接横向比较。

首次排查可以每轮间隔约 10 秒，测试 3 轮，避免对大量节点连续重复测试。若只有一个节点失败，先换另一个节点验证；若全部失败，优先检查配置有效期、内核日志和本地网络。降低测试超时时间只会更早报告失败，不会让节点变快。

4. 开启系统代理：让浏览器请求进入客户端

节点测试通常由内核直接发起，即使系统代理关闭也可能成功。要让遵循系统代理设置的浏览器经过客户端，还需要在客户端中开启「系统代理」。第一次验证先保持 TUN 模式关闭，减少同时变化的设置。

1. 在客户端开启「系统代理」，确认开关没有立即回退或出现写入失败提示。
2. Windows 11 打开「设置」→「网络和 Internet」→「代理」，查看「手动设置代理」区域；必要时点击「编辑」核对地址与端口。
3. 本机代理地址通常为 127.0.0.1，端口应与客户端提供的 HTTP 或混合端口一致。不要把订阅 URL 填进代理服务器地址。
4. 使用没有独立代理规则的浏览器窗口访问测试网站，同时打开客户端的「连接」页面观察新请求。

如果使用的是 PAC 接入方式，系统页面可能显示自动配置脚本，而不是手动服务器。不要同时手填另一套代理设置来叠加排查。首次连接先选定一种方式，确认成功后再调整。

TUN 模式适合后续处理不遵循系统代理的应用。它通常需要额外权限，并涉及虚拟网卡、路由和 DNS 配置；是否接管某个应用仍取决于具体配置。系统代理已能完成浏览器验证时，不必为了看到“已连接”而立即开启 TUN。

5. 浏览器与连接日志：确认规则和出口一致

代理生效应同时满足两件事：目标应用的请求确实进入客户端，并且该请求最终使用了预期出口。仅看到浏览器能打开页面，无法区分它是在直连还是走代理；仅看到延迟测试成功，也无法证明浏览器已接入。

在连接页面找同一条请求

1. 打开客户端的「连接」页面，使用域名筛选功能，或留意新出现的记录。
2. 在浏览器访问一个明确的 HTTPS 网站，记录访问时间与域名。测试页面本身可公开访问，不需要登录账号。
3. 查看对应连接的目标域名、匹配规则、策略链及上传下载变化；各客户端显示的字段名称可能不同。
4. 若策略链最终是 DIRECT，说明请求进入了客户端，但被分配到直连；若最终是所选节点，才说明该连接使用了相应代理出口。

部分短连接结束很快，可能在切到界面前就消失。可以先打开连接页再刷新浏览器，或到「日志」页面查找相同时间的规则匹配记录。日志级别为 info 时通常可看到连接信息，但具体内容取决于内核与客户端；不要把缺少某个固定句式当成故障。

需要辅助检查时，可查看可信的公网 IP 查询页面。比较代理前后的出口地址和网络归属即可，不要只凭国家或地区标签判断节点位置：IP 数据库可能更新滞后，网站也可能被规则分配为直连。连接记录应与 IP 查询结果相互印证。

6. 命令行复核：区分本地监听与远端失败

当浏览器行为不明确时，可以用 Windows PowerShell 或终端显式指定 HTTP 代理。这一步绕过浏览器的代理选择逻辑，但不能证明系统代理开关已经生效。先确认示例端口与你的设置一致。

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

-I 请求响应头；--connect-timeout 10 限制连接阶段等待时间为 10 秒，--max-time 20 限制整个请求为 20 秒。若终端设置了 NO_PROXY 环境变量，需检查测试域名是否被列为例外；同时观察客户端是否出现该连接。

• 无法连接本地端口：先检查内核是否运行、端口是否填错，以及该端口是否提供 HTTP 代理。
• 出现 HTTP 200 Connection established：这只表示代理隧道已经建立；还需要继续查看后续 TLS 与目标响应，不能在这一行就判定整个请求成功。
• 收到目标响应头：说明这条显式代理请求完成了相应 HTTP 交互。即使目标返回 403，也要区分网站拒绝访问与连接完全失败。
• 出现证书错误：检查系统时间、证书信任和网络环境，不要用跳过证书检查作为长期处理办法。

需要确认端口监听时，可在 Windows 终端执行：

netstat -ano | findstr ":7890"

查看本地地址列中端口为 7890、状态为 LISTENING 的记录。这个筛选也可能显示其他关联行，需要核对列；PID 可到任务管理器「详细信息」中对应进程。存在监听只证明有程序占用端口，还要确认它属于当前客户端内核。

7. 常见结果对照与首次连接收尾

首次连接完成后，保留一组容易复现的状态：规则模式、已确认可用的节点、实际监听端口，以及一条能在连接页查到的测试请求。临时切换过全局模式的，应恢复规则模式；临时提高过日志级别的，也应恢复常用级别。

退出客户端前先关闭系统代理，避免系统仍指向已经停止监听的本地端口。若退出后浏览器无法联网，返回 Windows 的代理设置核对残留项。后续需要开机启动或 TUN 接管时，一次只调整一个设置，再重复浏览器与连接日志的验证步骤。

判断连接成功的最终依据不是一个绿色状态或某个毫秒数，而是“应用请求进入客户端、规则命中符合预期、最终节点明确、目标响应正常”这一整条链路。更多基础操作可查阅使用指南；遇到具体报错时，可到帮助中心继续按现象排查。