入门指南 预计阅读 12 分钟

Clash 第一次连接教程:选节点、测延迟、确认代理已经生效

导入订阅只是开始。本文带你完成首次连接的三件事:在策略组里挑节点、用延迟测试筛掉超时线路、再通过 IP 检测页面确认流量确实从代理出去。

连接前先确认订阅已经载入

第一次使用 Clash，建议先把流程拆成四个独立状态：配置可用、节点可用、策略组已选择、系统流量已接入。客户端显示“运行中”只代表内核进程启动，不等于浏览器已经通过代理访问网络。

检查配置名称与更新时间

以下操作以 Clash Verge Rev 2.4.x 与 mihomo 1.19.x 的常见界面为例。不同客户端的按钮名称可能略有差异，但配置、代理、连接、设置这几个页面的职责基本一致。

  1. 打开「订阅」或「配置」页面，确认刚导入的配置出现在列表中。
  2. 点击配置卡片，使它成为当前启用配置。只下载到本地而未选中，内核不会使用其中的节点与规则。
  3. 查看更新时间。若显示数周前的时间，先执行一次「更新订阅」。
  4. 进入「代理」页面，确认能看到策略组和节点名称，而不是空白列表。

启动内核并观察错误信息

返回「设置」→「Clash 设置」或「设置」→「内核设置」，确认当前内核为 mihomo。启动成功后，日志通常会出现配置载入、监听端口和规则初始化信息。常见本地监听值是 HTTP 端口 7890、SOCKS5 端口 7891，或者统一使用 mixed-port: 7890。

如果日志出现 address already in use，说明端口已被其他程序占用；如果出现 YAML 解析错误，则是配置格式问题。此时不要继续测试节点，应先让内核稳定运行。

在正确的策略组里选择节点

Clash 的「代理」页面往往同时显示节点和策略组。节点是具体线路，策略组决定某类流量最终交给哪条线路。第一次连接时，最容易出现的问题不是节点没选，而是在不参与实际分流的组里选了节点。

先辨认策略组类型

常见名称 典型类型 首次连接时怎么处理
节点选择、PROXY、Proxy select 手动选择一条具体节点，适合首次排查。
自动选择、Auto url-test 按测试结果自动使用较快节点，但初次排障不如手选直观。
故障转移、Fallback fallback 优先使用列表中可用的前置节点，失败后再切换。
负载均衡、Load Balance load-balance 在多条线路间分配连接，不适合用来判断单节点质量。
DIRECT、直连 直连出口 流量直接访问目标，不经过代理节点。

建议先打开名称类似「节点选择」「手动选择」或 PROXY 的组，选一条明确标注地区的节点，例如“日本 01”或“新加坡 02”。之后再检查页面顶部或主策略组是否引用了这个组。若主组仍选中 DIRECT，节点卡片亮起也不会改变出口。

第一次测试先使用规则模式

在「设置」→「系统设置」或客户端首页找到代理模式，选择「规则」。规则模式会按配置中的规则从上到下匹配：本地网络和常见国内地址通常直连，需要代理的目标交给策略组，最后由 MATCH 处理未命中的流量。

  • 规则模式：适合日常使用，也能验证订阅中的分流是否正常。
  • 全局模式：大部分流量交给全局策略组，适合短时间排除规则问题。
  • 直连模式：绕过代理。误选此模式时，IP 检测会一直显示本地出口。

测延迟时要看延迟、超时与波动

客户端里的延迟测试通常不是 ICMP Ping。Clash 会通过指定节点访问测试 URL，并记录建立连接、TLS 协商或收到响应所需的时间。这个结果更接近代理可用性，但它仍不等于下载速度。

执行一次可比较的批量测试

  1. 进入「代理」页面，找到当前使用的策略组。
  2. 点击组右上角的测速按钮，等待所有节点完成，不要连续重复点击。
  3. 记录延迟、超时节点数量，以及同一节点连续三次结果的变化。
  4. 从延迟合理且波动较小的节点中手动选一条，再进行网页测试。
测试结果 一般含义 处理建议
40–120 ms 通常响应较快 可优先用于网页、聊天与轻量请求。
120–250 ms 可用，但交互延迟更明显 再测两次，观察是否稳定。
250–500 ms 链路较远、拥塞或中转较多 与同地区其他节点比较，不只看单次结果。
Timeout 测试时间内未获得有效响应 更新订阅后重测；仍超时则换节点。
80、310、95 ms 连续跳动 抖动明显 实时通信可能不稳定，优先选择波动较小的线路。

例如节点 A 三次结果为 86、91、89 ms，节点 B 为 52、420、77 ms。虽然节点 B 的最低值更小，节点 A 通常更适合作为首次连接测试对象。稳定性比一次偶然的低延迟更有参考价值。

延迟正常但网页仍慢的原因

延迟只反映短请求的响应时间。线路带宽、晚高峰拥塞、目标站点限速、丢包率和设备性能都会影响实际体验。一个 65 ms 的节点可能只有较低吞吐量，另一个 150 ms 的节点反而能稳定传输较大文件。

还要检查测试地址是否可达。mihomo 配置常使用 https://www.gstatic.com/generate_204 作为健康检查地址。如果测试地址本身在当前网络环境中受阻，所有节点都可能显示超时，但这不一定代表每条代理线路同时失效。

开启系统代理，让浏览器流量进入 Clash

节点选好以后，还要把应用流量送到 Clash 的本地监听端口。普通浏览器通常可以通过系统代理接入；游戏、命令行程序、商店应用和部分使用 UDP 的软件，则可能忽略系统代理，需要 TUN 模式或应用自身的代理设置。

Windows 与 macOS 的系统代理检查

在客户端首页打开「系统代理」。Windows 11 可到「设置」→「网络和 Internet」→「代理」查看手动代理状态；常见地址为 127.0.0.1，端口为 7890。如果客户端使用其他 mixed-port，系统设置里的端口必须保持一致。

macOS 可到「系统设置」→「网络」→「Wi-Fi」→「详细信息」→「代理」检查 Web 代理与安全 Web 代理。通常由客户端自动写入，不建议在客户端运行时同时使用另一个代理工具修改这些项目。

先关闭可能冲突的网络工具

  • 退出其他占用 7890、7891 或相同控制端口的代理客户端。
  • 暂停浏览器内单独配置的代理扩展，避免请求被送往另一组地址。
  • 确认系统时间准确。时间偏差过大会导致 HTTPS 证书校验失败。
  • 首次验证时暂时关闭应用内的自定义 DNS 或代理链设置，减少变量。

用出口 IP 确认代理已经生效

能打开网页不代表请求一定经过代理。最直接的验证方式，是在启用 Clash 前后分别查询公网 IP，并比较地址、运营商和地区信息。测试应在同一浏览器、同一网络环境中完成。

浏览器验证步骤

  1. 暂时关闭客户端的「系统代理」，打开 IP 查询页面，记录原始公网 IP 的前两段和所在地区。
  2. 重新开启系统代理，确认模式为「规则」或「全局」，并选中刚才测试通过的节点。
  3. 新建无痕窗口，再打开两个不同的 IP 查询页面。
  4. 如果两个页面都显示代理节点所在地区，且 IP 与原始出口不同，浏览器代理基本已经生效。
  5. 返回 Clash 的「连接」页面，刷新查询页，观察是否出现对应域名、目标地址、策略组和节点名称。

例如关闭代理时出口为 203.0.113.24，开启后变为 198.51.100.76，同时连接记录显示该请求命中 PROXY 并交给“新加坡 02”，说明浏览器流量已经进入 Clash。这里的地址仅用于说明判断方法。

使用命令行对比直连与代理请求

Windows 11、macOS 与常见 Linux 发行版通常都可使用 curl。若本地混合端口为 7890，可以分别执行：

curl https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

第一条命令按当前系统和终端环境访问，第二条明确指定 Clash 的 HTTP 代理。两次返回的 IP 不同，说明本地代理端口能够转发请求。若浏览器仍显示原始 IP，应检查系统代理或浏览器自身设置，而不是反复更换节点。

同时查看连接记录

打开客户端的「连接」页面，正常请求通常会显示主机名、源地址、上传下载量、命中规则、策略链和最终节点。点击一条连接后，可以确认它究竟走了 DIRECT、REJECT，还是某个代理节点。

如果 IP 查询页面命中 DIRECT，先切到全局模式做对照。全局模式下出口改变，说明节点和系统代理均可用，问题位于规则或策略组；全局模式下仍没有连接记录，则说明流量根本没有进入当前 Clash 实例。

系统代理无效时再启用 TUN 模式

TUN 模式由 mihomo 创建虚拟网络接口，在网络层接收流量。它适合不读取系统代理的程序，也能处理更多 UDP 场景。第一次连接不必同时开启所有功能：先验证普通系统代理，再按应用需要开启 TUN，排障会更清晰。

TUN 的启用顺序

  1. 进入「设置」→「Clash 设置」→「TUN 模式」。
  2. 按客户端提示安装或启用服务模式。Windows 通常需要管理员权限完成首次安装。
  3. 打开 TUN 后等待虚拟接口建立，再访问 IP 查询页面。
  4. 查看「连接」与「日志」，确认目标应用的请求被记录。
  5. 若网络异常，先关闭 TUN，确认系统网络恢复，再检查 DNS 与路由设置。

mihomo 的 TUN 常与 DNS 劫持、自动路由和严格路由配合。不同客户端会把这些参数封装成开关。对于第一次使用者，不建议在不了解配置来源时同时改动接口名、MTU、路由表和 DNS 监听端口。

如何判断是 DNS 问题

如果能访问具体 IP，却无法通过域名打开网站，或者日志持续出现域名解析失败，问题可能在 DNS。使用 Fake-IP 模式时，DNS 模块会先返回映射地址，再由内核根据原始域名匹配规则。看到 198.18.0.0/16 范围的映射地址并不等于目标网站真的位于该网段。

可先执行一次客户端提供的 DNS 清理功能，或重启内核，再重新测试。Windows 也可在终端运行 ipconfig /flushdns 清理系统缓存。若只有某个域名失败，应在连接日志中查看它命中的规则和 DNS 返回结果，而不是直接把所有流量改为全局。

第一次连接失败的快速定位表

现象 优先检查 下一步
代理页面没有节点 订阅是否成功更新、配置是否被选中 重新载入配置并查看解析日志。
全部节点显示超时 测试 URL、系统时间、当前网络 切换网络后重测，并向订阅提供方确认线路状态。
节点延迟正常，浏览器打不开网页 系统代理地址与端口 检查是否为 127.0.0.1:7890，再看连接记录。
网页能打开，但出口 IP 没变化 直连模式、规则命中、浏览器代理 临时切到全局模式进行对照。
浏览器可用，游戏或终端不可用 应用是否支持系统代理 配置应用代理，或按需启用 TUN。
开启 TUN 后无法解析域名 DNS 设置与虚拟接口状态 关闭 TUN 恢复网络，再检查 DNS 日志。
启动时报端口占用 7890、7891 的占用进程 退出冲突程序，或统一修改监听与系统代理端口。

完成连接的最低验证标准

  • 当前配置已选中，更新操作没有返回格式错误。
  • mihomo 内核运行稳定，本地监听端口已建立。
  • 至少一条节点连续三次测试没有超时，延迟波动处于可接受范围。
  • 实际参与分流的策略组选中了该节点，而不是 DIRECT。
  • 浏览器请求出现在「连接」页面，并显示最终使用的节点。
  • 两个独立 IP 查询结果与关闭代理时不同。

达到这六项后，首次连接就已经完成。之后再处理自动测速、策略组细分、规则调整、订阅自动更新和 TUN 常驻等进阶设置。每次只改一个变量，并用连接记录和出口 IP 复核结果，定位问题会更快。

下载 Clash 客户端 Windows、macOS、Android、iOS、Linux