Clash 首次连接实操:选节点、测延迟、确认代理已生效的三步检查

开始前确认：配置已载入，端口没有冲突

首次连接应先把问题拆成三层：配置是否正常载入、节点是否能够建立连接、应用流量是否真正进入 Clash。只看客户端主界面的“已启动”状态并不足够。它通常只代表内核进程正在运行，不代表订阅中的节点可用，也不代表浏览器已经使用本地代理端口。

打开客户端后，先进入「配置」或「Profiles」页面，确认刚导入的订阅处于选中状态。配置旁应能看到更新时间、文件名称或订阅名称。若页面显示解析失败、配置文件为空，或者切换配置后内核立即退出，应先解决导入问题，再进行节点测试。

检查本地监听端口

常见配置使用 HTTP 端口 7890、SOCKS5 端口 7891，也有较新的配置通过 mixed-port: 7890 在同一端口接收 HTTP 与 SOCKS5 流量。具体数值由配置文件和客户端设置决定，不必强行改成某个固定端口，但系统代理填写的端口必须与 Clash 实际监听值一致。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

在图形客户端中，端口通常位于「设置」→「参数设置」→「端口」或「General」→「Port」。若 7890 已被其他代理程序占用，客户端可能提示 bind failed、address already in use 或启动失败。此时可退出占用端口的软件，或者把 Clash 端口改为 7892，再重新开启系统代理。

第一步：在策略组里选择合适节点

订阅导入后，节点通常不会直接出现在首页，而是位于「代理」或「Proxies」页面的策略组中。常见组名包括“节点选择”“代理”“Proxy”“手动选择”。先找到承担主要流量出口的选择型策略组，再从组内选一个节点。不要只在包含 DIRECT、REJECT 等项目的总览页面随意点击。

从手动选择组开始

1. 进入「代理」→「节点选择」，确认当前模式为「规则」或 Rule。
2. 展开主要代理策略组，选择一个地理位置较近、名称信息完整的节点。
3. 若其他策略组引用了“节点选择”，保持它们指向该组即可，不必逐组重复指定。
4. 返回首页，确认内核状态为运行中，再开启「系统代理」。

第一次测试适合手动固定一个节点。这样可以明确后续测速、IP 查询和连接日志对应的是哪一个出口。如果一开始就选择 url-test、自动选择或负载均衡组，客户端可能在测试期间切换节点，容易出现前后结果不一致。

节点名称只能作为筛选线索

节点名称里的地区、倍率、专线等文本由订阅提供方定义，不代表实时质量。实际体验主要受本机到服务器的网络路径、服务器负载、协议参数和目标网站线路影响。距离近的节点通常往返时间较低，但并不保证下载速度最高；低倍率节点也不等于连接更稳定。

如果策略组中只有 DIRECT，或节点列表完全为空，通常不是“没有选中节点”，而是订阅内容没有成功转换为当前内核支持的配置。此时返回「配置」页面更新订阅，查看错误日志，并确认所用客户端的 mihomo 内核版本能够识别配置中的代理协议与字段。

第二步：测延迟并判断节点是否可用

选择节点后，在策略组右侧点击延迟测试按钮。不同客户端可能用测速图标、闪电图标或“Test”表示。测试地址通常是一个体积很小的 HTTP 或 HTTPS 页面，客户端记录建立连接并获得响应所需的时间，结果以毫秒显示。

怎样理解延迟结果

• 50–150 ms：常见于线路较近且状态正常的节点，网页交互通常较顺畅。
• 150–300 ms：仍可用于普通浏览和下载，但实时交互的等待感可能增加。
• 300–800 ms：可能存在绕路、拥塞或节点负载较高，应与同地区其他节点对比。
• Timeout：测试时间内没有获得有效响应，需要区分测试地址不可达、节点失效和本机网络拦截。

这些区间是排查参考，不是固定合格线。一次显示 82 ms、下一次显示 210 ms，说明线路存在波动；连续测试三次分别为 86 ms、91 ms、89 ms，则比只看单次最低值更有意义。首次筛选时可保留两到三个连续成功、波动较小的节点。

延迟正常不等于所有网站都能打开

延迟测试只验证“本机 → 节点 → 测试地址”这一条请求链路。它不测试所有目标网站，也不测大文件吞吐量。某节点延迟为 95 ms，但特定网站仍可能因规则命中 DIRECT、目标站限制、DNS 结果异常或节点出口网络不同而无法访问。

相反，Timeout 也不一定说明节点彻底失效。测试 URL 可能被目标网络限制，或者客户端设置的超时时间过短。可在「设置」→「延迟测试」中检查测试地址与超时值。常见超时值为 5000 ms。更换测试地址后若所有节点恢复结果，问题更可能出在原测试地址，而不是整份订阅。

所有节点同时超时时先查本机

如果十几个节点在同一时间全部 Timeout，逐个更换节点的价值不高。先切换到另一张网络，例如从家庭 Wi-Fi 切换到手机热点，再重新测试。若热点下恢复，问题可能位于路由器、当前宽带或本机网络过滤；若两种网络都失败，再检查订阅更新时间、系统时间、内核日志和节点协议参数。

电脑时间偏差也可能导致 TLS 握手失败。Windows 可进入「设置」→「时间和语言」→「日期和时间」，开启自动设置时间并立即同步；macOS 可进入「系统设置」→「通用」→「日期与时间」，确认自动设置已启用。同步后重启内核，而不是只刷新代理页面。

第三步：确认流量确实经过代理

节点显示延迟后，还要完成流量验证。最可靠的判断由三部分组成：系统代理或 TUN 已启用、出口 IP 与直连状态不同、Clash 连接面板能看到刚才产生的请求。三项同时成立，才能把“节点可用”和“应用已走代理”连接起来。

先记录直连出口 IP

1. 暂时关闭 Clash 的「系统代理」与「TUN 模式」。
2. 在浏览器打开一个可信的 IP 查询页面，记录当前公网 IP 和地区。
3. 关闭该页面，重新开启 Clash，并保持先前选定的节点。
4. 再次打开查询页面，比较公网 IP、网络运营商和地区。

若代理后的出口 IP 与直连 IP 不同，并且地区与节点出口大致一致，说明浏览器请求很可能已经经过代理。但 IP 查询只能确认这一笔访问的出口，不能证明所有应用和所有协议都已被接管。部分浏览器还可能缓存页面，因此测试前可使用无痕窗口，或强制刷新页面。

在连接面板核对请求链路

打开客户端的「连接」或「Connections」页面，然后在浏览器访问一个此前没有打开过的网站。连接列表应出现新的域名、目标地址、规则名称、策略组和实际节点。常见记录类似：

Host: example.com
Network: TCP
Rule: DomainSuffix
Chain: 节点选择 → HK-01
Upload: 3.2 KB
Download: 18.7 KB

其中 Chain 或 Chains 表示策略组最终落到哪个节点。若链路显示“节点选择 → HK-01”，说明请求经过该节点；若显示 DIRECT，则请求按照规则直接连接。规则模式下出现 DIRECT 是正常现象，局域网地址、国内站点或配置指定的域名可能本来就应直连。

连接面板里完全没有新请求，通常说明应用没有使用 Clash。此时检查「设置」→「系统代理」是否开启，并核对系统代理地址是否为 127.0.0.1、端口是否与 Clash 的 HTTP 或 mixed 端口一致。若浏览器安装了代理扩展，确认它没有覆盖系统设置并指向其他端口。

系统代理与 TUN 模式的覆盖范围

系统代理主要影响遵循操作系统代理设置的应用，例如常见浏览器和部分桌面软件。某些游戏、命令行程序、商店应用和 UDP 流量不会自动读取系统代理。需要接管这类流量时，可在客户端的「设置」→「网络」→「TUN 模式」中启用 TUN。

TUN 会创建虚拟网络接口，把更多 IP 层流量交给 mihomo 处理。首次启用时可能需要管理员权限，Windows 还可能安装或启用相关网络组件。启用后再次查看「连接」面板，确认目标进程产生的连接已经出现。不要同时把系统代理错误地指向另一个程序，否则 HTTP 请求与 TUN 流量可能呈现两套不同结果。

三类常见误区：看起来已连接，实际问题仍在

误区一：只看首页开关

首页显示“运行中”只说明内核启动成功。完整状态至少包括：配置载入成功、节点延迟测试有结果、系统代理或 TUN 已开启、连接面板出现请求。缺少任何一项，都可能出现客户端在运行但网页仍然直连或无法访问的情况。

误区二：把延迟最低当作速度最快

延迟测试传输的数据很少，主要反映响应时间。下载速度还受到服务器带宽、线路拥塞、节点负载、单连接限速和目标站点性能影响。两个节点分别为 70 ms 和 110 ms 时，后者仍可能拥有更稳定的下载吞吐量。日常使用应同时观察网页响应、连续连接稳定性和实际传输速度。

误区三：出口 IP 没变化就认定节点失效

在规则模式下，IP 查询网站可能被配置为 DIRECT，因此显示的仍是本地出口。先到「连接」页面查看该域名命中了哪条规则。如果记录显示 DIRECT，可暂时将模式切换为全局并重新测试；若全局模式下出口变化，说明节点本身可用，需要调整规则或选择正确的代理策略组。

另一种情况是浏览器启用了安全 DNS、独立代理扩展或企业策略。它们可能改变域名解析或代理路径。排查时先关闭额外扩展，保留系统代理一种入口，再观察连接面板。DNS 查询结果与网页 TCP 连接是两个环节，不应只根据 DNS 服务器位置判断全部流量是否代理。

首次连接失败时的固定排查顺序

遇到网页打不开、测速全超时或出口 IP 不变时，按固定顺序检查比随机切换设置更快。每次只改一个变量，并在修改后重新发起请求。

1. 配置：确认订阅处于选中状态，更新时没有解析错误，节点列表不是空白。
2. 内核：确认状态为运行中，日志中没有端口占用、字段错误或权限错误。
3. 节点：固定一个节点测试三次，再换同地区另一个节点对比。
4. 端口：核对 mixed、HTTP、SOCKS5 端口与系统代理设置一致。
5. 应用入口：浏览器先用系统代理测试，不读取系统代理的应用再考虑 TUN。
6. 规则：在连接面板查看命中 DIRECT、REJECT 还是代理策略组。
7. 网络：切换手机热点复测，区分客户端配置与当前局域网问题。
8. 日志：根据 timeout、connection refused、TLS handshake 等具体信息定位环节。

例如，节点延迟正常、IP 查询仍显示直连、连接面板没有记录，这组现象优先指向系统代理未生效，而不是节点问题。若连接面板已有记录，链路指向所选节点，但请求显示 timeout，则应继续检查节点和目标网络。若记录明确显示 REJECT，则需要检查规则，而不是修改端口。

完成检查后的推荐日常设置

确认连接成功后，可把模式保持为 Rule，让配置按域名、IP 和规则集决定 DIRECT 或代理。主要策略组可以继续固定到稳定节点，也可以切换到 url-test 自动选择组。使用自动组前，应先确认组内节点都能独立连接，否则自动测试只能在可用范围内选择，无法修复失效配置。

• 系统代理用户保持本地监听地址为 127.0.0.1，不需要局域网共享时关闭 Allow LAN。
• 需要游戏、命令行或不读取系统代理的软件时，再启用 TUN，并确认连接面板能识别其流量。
• 订阅更新后若节点名称变化，重新检查手动策略组是否仍指向有效节点。
• 网页异常时先查看连接记录和规则命中，不要直接删除整份配置。
• 保留一个经过三次延迟测试和实际访问验证的备用节点，便于快速对照。

首次连接的核心不是把所有开关全部打开，而是建立清晰的验证链：先选定一个具体节点，再用延迟测试确认基本连通，最后通过出口 IP 与连接面板确认请求路径。完成这三步后，后续遇到速度下降、单个网站打不开或特定应用不走代理时，就能明确问题发生在节点、规则还是流量入口。