Clash 首次连接怎么做:选节点、测延迟到验证代理生效
面向第一次使用 Clash 的用户,按顺序讲清如何在节点列表中挑选并切换节点、如何发起延迟测试读懂结果,以及用浏览器与命令行两种方式确认代理已经真正生效。
把订阅导入 Clash 之后,很多人会在节点列表前停下来:一长串名字,后面跟着数字,不知道该点哪一个。这篇文章按照一次完整的"首连"流程来讲,从打开节点列表开始,到最后确认流量确实走了代理,每一步都给出可以照做的具体动作,不假设你已经懂术语。
先认清客户端界面的几个区域
不同平台的 Clash 客户端(Clash Verge、ClashX、Clash for Windows 等)在细节上略有差异,但核心结构基本一致,通常分为四块:
- 代理(Proxies):节点列表所在的页面,按订阅里的分组展示,是本文的重点。
- 规则(Rules):显示当前生效的分流规则,决定哪些流量走代理、哪些直连。
- 连接(Connections):实时展示当前建立的网络连接,是判断代理是否生效的重要入口。
- 设置(Settings/General):系统代理开关、TUN 模式开关、混合端口等基础配置都在这里。
首次使用,建议先确认"系统代理"或"TUN 模式"其中一项已经打开——节点选好但没有开启接管流量的方式,浏览器依然不会走代理。系统代理是通过设置操作系统的 HTTP/HTTPS 代理来生效,配置简单,对大多数网页浏览和应用已经足够;TUN 模式则在网络层接管全部流量,兼容性更好,尤其适合不支持读取系统代理设置的应用,但通常需要额外的权限确认。
如果你还没有导入订阅或者不清楚订阅链接从哪里获取,建议先完成基础配置,再回来看节点挑选与验证的部分。
看懂策略组,再决定点哪个节点
节点列表并不是一份平铺的清单,而是按"策略组"组织的。常见的分组逻辑包括:
- Proxy / 手动选择组:你可以在这里手动点选任意一个具体节点,选中后这个策略组就固定使用该节点,不会自动切换。
- Auto / 自动选优组:客户端会按延迟测试结果自动挑选当前最优的节点,并按订阅设置的周期重新测试和切换。
- Fallback / 故障转移组:优先使用主节点,主节点不可用时自动切到备用节点。
- Select 分类组(例如"海外流媒体""国内服务"等,取决于订阅规则文件的分组设计):把不同用途的流量分别指向不同的策略,你可以为每一类单独选节点。
对第一次使用的人来说,最简单的做法是:找到主策略组(通常命名为 Proxy 或订阅商自定义的名字),点开下拉列表,手动选中一个显示为绿色或延迟数值较低的节点,先确保这一组能正常连通,再考虑要不要切换成自动选优。如果订阅文件按用途拆了多个分组,建议每个分组都检查一遍当前选中的节点是否可用,避免某个分类始终指向一个已经失效的节点。
发起延迟测试,读懂返回的数字
节点名称右侧通常会显示一个延迟数值,单位是毫秒(ms)。点击节点列表页面的"测速"或单个节点右侧的刷新图标,可以手动触发一次延迟测试。理解这个数字需要注意几点:
- 测试对象是延迟探测地址,不是你要访问的具体网站。客户端会向一个预设的测试地址(常见的是某个稳定可达的域名)发起请求,统计往返耗时,这个耗时能大致反映节点到测试地址的网络状况,但不完全等同于访问某个特定网站的实际速度。
- 数值范围的大致参考:200ms 以内通常体验流畅;200~500ms 依然可用,但网页加载、视频缓冲会有轻微延迟感;超过800ms 或显示超时,建议更换节点。
- 显示"超时"或红色标记不代表节点一定不可用,可能是探测请求本身被中间网络丢弃,但也可能是节点确实已经失效,建议直接切换到延迟正常的节点,不必纠结原因。
- 延迟会随时间波动,尤其是使用高峰时段。如果某个节点平时延迟稳定,某次测试突然升高,可以隔几分钟再测一次,排除偶发波动。
建议养成的习惯:切换节点前先测一次延迟,而不是凭节点名称猜测哪个"听起来"更快——名称里的地区、编号和真实网络质量没有必然联系。
切换节点后要做的确认动作
点选了一个新节点之后,不要立刻假设它已经生效,按下面的顺序做一次确认:
- 确认节点列表里该节点确实显示为"已选中"状态(通常有高亮或勾选标记)。
- 回到设置页,确认系统代理开关处于打开状态,或者 TUN 模式已启用。二者选其一即可,没必要同时打开。
- 打开"连接"页面,观察是否有新的连接记录出现,记录里的目标域名和使用的节点名称是否符合预期。
如果切换节点后打开网页明显卡顿或者无法加载,先回到延迟测试确认这个节点当前是否正常,再考虑是不是规则把这类流量分到了别的分组、走的是另一个节点。
用浏览器验证代理是否生效
最直接的方式是访问一个能显示当前出口 IP 和地理位置的页面。具体步骤:
- 在打开代理之前,先访问一次 IP 查询页面,记下显示的地址和地区,这是你的直连出口信息。
- 确认 Clash 里节点已选中、系统代理或 TUN 模式已打开。
- 刷新同一个 IP 查询页面(建议强制刷新,避免读取浏览器缓存),对比新显示的地址和地区是否发生了变化。
如果地区信息变成了节点所在地区,说明代理已经生效;如果显示的还是本地网络的地址,大概率是系统代理没有打开,或者浏览器本身设置了独立的代理配置(部分浏览器允许在系统代理之外单独设置,需要检查一下是否被覆盖)。
另外可以打开客户端的"连接"页面,访问网页的同时观察是否实时出现对应域名的连接记录,并且这条记录标注的节点是你刚才选中的那一个。这一步能确认具体是哪个节点在处理这次请求,比单看 IP 更精确。
用命令行验证代理是否生效
命令行方式适合习惯用终端排查问题的用户,尤其在浏览器缓存、扩展干扰导致结果不直观时更可靠。以 macOS 和 Linux 常见的 curl 命令为例:
curl -x http://127.0.0.1:7890 https://ifconfig.me这条命令通过本机的 HTTP 代理端口发起请求,返回值是出口 IP 地址。端口号需要对照客户端设置页里显示的混合端口或 HTTP 端口,不同客户端默认值可能不同,不要直接照抄示例里的数字,以实际界面显示为准。
如果启用的是 TUN 模式而不是系统代理端口,可以不加 -x 参数直接发起请求,因为 TUN 模式在网络层已经接管了流量:
curl https://ifconfig.me对比这两次(打开代理前后)返回的 IP,如果地址发生变化且与所选节点的地区吻合,说明代理链路是通的。如果命令返回超时或连接被拒绝,先检查端口号是否填对,再检查客户端的代理监听服务是否处于运行状态。
命令行测试只能确认代理端口本身能不能转发请求,不能替代浏览器里的实际使用体验。两种方式建议都做一次,互相印证。
验证不通过时的排查顺序
如果按上面的步骤操作后,代理仍然显示未生效,建议按下面的顺序逐项排除,而不是同时改动多个设置:
- 先看节点本身:延迟测试是否正常,是不是恰好选中了一个失效节点。换一个延迟正常的节点重新测试一次。
- 再看接管方式:系统代理开关和 TUN 模式的状态,确认至少有一项处于打开状态,并且没有被系统设置里的"忽略代理的例外列表"覆盖掉你要测试的域名。
- 然后看规则命中:打开规则页面,确认你测试用的域名被分流到了代理策略组,而不是被规则匹配成了直连(DIRECT)。部分订阅默认把本地网络或特定地区的域名设为直连,这种情况下即使代理正常也不会看到 IP 变化。
- 最后看客户端进程:确认 Clash 核心进程处于运行状态而不是已经退出或崩溃,部分客户端在核心异常退出时界面仍会保留旧的选中状态,容易造成"看起来已经开着"的错觉。
逐项排查完成后,再重复一次前面浏览器或命令行的验证步骤,确认问题已经解决,而不是凭感觉认为"应该好了"。
建立一个简单的日常验证习惯
首次配置成功之后,后续每次切换节点或者重启客户端,建议保留一个简短的确认动作,而不用每次都走完整流程:打开"连接"页面看是否有新连接产生,或者用之前记录的命令行命令快速跑一次,几秒钟就能确认链路是通的。这个习惯在排查"为什么突然连不上了"时特别有用——因为你已经清楚正常状态下应该看到什么,异常状态一眼就能分辨出来。