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

先完成一条可验证的连接

首次使用先做最小验证：启用配置、切换到规则模式、手动选择节点、开启系统代理，再发起一次网页请求。不要同时开启多个代理客户端，也不要一开始就改 DNS、TUN 和规则。一次只改变一个条件，才能知道问题出在哪一层。

在「配置」或「Profiles」页面导入订阅，选中该配置。导入成功不等于已经启用，返回代理页面确认策略组已经出现。
把运行模式切换为「规则 / Rule」。首次验证保留订阅自带规则，不先增加自定义分流。
在目标策略组内选择一个具体节点，执行延迟测试，确认不是 DIRECT 或 REJECT。
桌面端开启「系统代理」，随后用浏览器访问目标网站，并到「连接 / Connections」页面核对这条请求。

在策略组里选择实际出口

打开「代理 / Proxies」后，先找规则实际使用的策略组，而不是看到一个节点就点击。订阅可能包含「节点选择」「自动选择」「海外服务」等多个分组；这些名称由配置作者定义，并非客户端固定菜单。一个组还可能指向另一个组，需要沿着选择关系确认最终节点。

三类常见分组的选择方式

组类型	运行行为	首次连接建议
`select`	使用手动选定的节点或下级组。	先固定一个具体节点，方便复测。
`url-test`	按探测结果自动选择出口，切换还受容差等配置影响。	查看当前实际选中节点，不只看组名。
`fallback`	通常按配置顺序选择健康检查可用的出口。	不要把它当成最低延迟排序。

例如，目标网站命中「海外服务」，该组选择「节点选择」，而「节点选择」选择了「新加坡 A」，最终出口才是「新加坡 A」。如果只改了另一个无关分组，目标网站的路径不会变化。节点名字中的地区也只是标签，实际出口地址应通过请求验证。

DIRECT 表示直连，不经过代理节点。它适合本地与直连规则，不是代理连通性的证明。
REJECT 表示拒绝请求。误选后出现连接失败属于预期行为。
节点很多时，优先选择服务提供方标记正常、距离较近的两个候选项；首次排查不要在十几个节点之间连续切换。

延迟测试能证明什么

点击策略组旁的测速或延迟按钮，等待一轮结束。常见 URL 延迟测试会经由节点访问指定 HTTP 或 HTTPS 地址，记录完成探测所需时间。它不是普通的 ICMP Ping，也不是下载带宽测试；测试 URL、连接复用、DNS、节点负载都会影响数字。

用三次结果判断稳定性

手动选择一个候选节点，在相同测试地址下执行三轮测试，每轮间隔约 5 秒。记录结果后再换另一个节点。下面是判断方法的示例，不是本站对某个节点的实测或速度承诺。

候选节点	三轮示例结果	如何处理
节点 A	82 / 91 / 87 ms	结果集中，适合先用于网页验证。
节点 B	45 / 680 ms / 超时	最低值较低，但稳定性存疑。
节点 C	三轮均超时	换节点和测试目标交叉检查。

自动探测常用返回 204 的地址，例如 https://www.gstatic.com/generate_204。但该地址可达，不代表视频、登录或文件下载都正常；反过来，探测地址被特定网络阻断，也可能导致可用节点显示超时。应结合真实网站访问，不凭一个数字下结论。

开启系统代理，确认请求进入内核

在 Windows 或 macOS 上，先使用客户端的「系统代理」开关验证浏览器流量。它通常把系统代理地址指向本机监听端口，但并不强制接管所有应用。浏览器扩展、应用自己的代理设置以及部分命令行程序，可能不遵循系统代理。

先核对端口，再执行显式代理请求

在「设置」页面查找「端口」「混合端口」或「Mixed Port」。7890 是常见示例值，不是所有客户端的固定值。下面展示配置字段含义，仅用于对照当前运行配置，不要直接覆盖订阅文件：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

确认当前混合端口确实是 7890 后，可在 Windows PowerShell 中运行以下命令。macOS 或 Linux 把 curl.exe 换成 curl；若端口不同，替换命令中的数字。

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

命令显式指定本机 HTTP 代理，适合排除应用是否读取系统代理这一变量。混合端口支持 HTTP 代理请求。
出现 Failed to connect 且指向 127.0.0.1 时，先检查内核是否运行、端口是否填写正确。
收到目标服务器的 HTTP 响应，说明请求链路至少已完成相应通信；即使是 403，也不应直接归类为本机端口故障。
显式代理请求成功但浏览器失败时，重点检查系统代理开关、浏览器独立代理配置和扩展，而不是立即更换订阅。

上述请求进入内核后仍会遵循当前规则，命中直连规则时也可能走 DIRECT。因此，命令成功只说明入口可用，是否真的经过所选节点，还要看连接记录。关于监听入口的说明可对照安装大全中的端口配置。

用连接记录核对规则与节点

打开「连接 / Connections」，按域名筛选，然后刷新一个目标网页。首次确认最好选择自己知道应当走代理的普通网页，不要只检查已有长连接的聊天应用。若连接记录很快消失，可同时打开「日志 / Logs」，以 info 级别观察新请求。

一条请求至少核对四项

目标域名或地址：确认记录属于刚刚打开的网站，而不是后台更新或其他标签页。
匹配规则：查看是域名规则、地址规则还是末尾兜底规则生效。规则通常从上往下匹配，先匹配的项决定后续处理。
策略链：沿组名找到最终节点。如果结果是 DIRECT，该条请求没有通过代理节点。
传输变化：刷新后上传、下载计数应有变化。只有一条建立记录，没有响应流量，还不能证明页面完整可用。

若页面显示的出口 IP 与预期不同，可以在同一浏览器中访问可信的 IP 查询服务，并同步观察这次查询的策略链。IP 查询网站本身也受规则影响，可能被直连；它显示的结果只能证明这次请求的出口，不代表所有应用都走同一路径。

切换节点后，应新建请求再验证。已有 TCP 连接或浏览器连接池可能继续使用旧路径，部分客户端提供「关闭连接」功能；关闭连接会中断当前传输，下载文件或会议通话进行中不要随意操作。更多匹配逻辑可查看规则分流使用说明。

系统代理与 TUN 怎样选择

浏览器通过系统代理验证成功后，再考虑是否需要 TUN 模式。TUN 通过虚拟网络接口接管符合路由条件的流量，适合不读取系统代理的应用，但需要客户端完成权限、路由和 DNS 相关设置。它不是节点加速开关，也不能让失效订阅恢复可用。

桌面浏览器访问：先用系统代理，减少权限和路由变量。
游戏、独立网络程序：先确认其代理支持；确有接管需求时再启用 TUN，并检查服务模式或管理员权限提示。
Android 客户端：通常通过系统 VPN 授权建立接管入口，不照搬桌面端的系统代理步骤。其他 VPN 应用可能与它争用同一入口。

启用 TUN 后仍需重新核对连接记录。某些故障只影响 UDP 或域名解析，不能因为网页能打开就认定全部协议都正常。首次排查不建议同时运行另一个 VPN；如果工作环境依赖企业 VPN，应先确认组织的网络要求与分流方式。

按现象定位首次连接失败

现象	优先检查	下一步操作
代理页面没有节点	配置是否已启用，订阅是否解析成功。	回到配置页选择条目，查看更新或加载错误。
所有节点测速超时	本地网络、订阅状态、探测地址可达性。	先确认直连网络，再选两个节点测试真实网页。
延迟正常，网页失败	系统代理入口、规则、目标服务限制。	用显式代理命令测试，并查看连接策略链。
浏览器请求未出现在连接页	浏览器是否绕过代理，是否使用其他本地代理。	检查浏览器独立设置，并核对系统代理端口。
请求出现但显示直连	命中规则与组内选择。	检查实际命中组，不只切换默认节点组。
只有一个网站访问失败	网站状态、账号地区、节点出口限制。	固定其他条件，仅换一个节点做对照。

遇到错误时，先记下发生时间、目标域名、当前模式、节点名称和错误原文。分享日志前删除订阅 URL、令牌、密码与个人访问记录。订阅地址通常含有访问凭据，不应贴到公开讨论区，也不应随意交给在线转换服务。

首次连接的完成标准

配置已启用，候选节点能完成探测，实际请求进入内核，规则命中预期策略组，最终策略链包含选定节点，目标页面正常返回。满足这几项，比首页显示「已连接」更有判断价值。之后再按需要设置自动选择、订阅更新和应用分流，后续改动也沿用同样的验证顺序。