Clash 第一次启动后，界面能够打开并不等于代理已经接管网络。一次完整连接至少包含四个独立环节：配置成功载入、代理组已经选定节点、操作系统或应用把流量交给 Clash、目标连接按照规则通过指定出口。任何一个环节没有完成，都可能出现“节点看起来可用，但网页仍然直连”或“系统代理已打开，但所有请求超时”的情况。

不同客户端的菜单名称可能略有差异。基于 Clash Meta（mihomo）内核的客户端通常会把配置、代理、连接、日志、系统代理和 TUN 分成独立页面；旧版 Clash 客户端也遵循相近逻辑。首次使用时应按数据流顺序操作，不要同时修改 DNS、规则模式、端口和 TUN 参数。先建立一条可验证的基础连接，再处理特定应用兼容问题。

一、连接前确认客户端状态

启动客户端后，先检查内核是否正常运行。界面中常见的状态包括 Running、Started、Core Running 或“服务运行中”。如果页面能够显示，但内核状态为 Stopped、Error 或反复重启，后续订阅导入和节点测试可能无法得到有效结果。此时应先打开日志，确认是否存在配置解析失败、监听端口占用或权限不足。

还要确认系统日期、时间和时区正确。HTTPS 连接依赖证书有效期判断，设备时间偏差过大时，订阅更新和节点握手都可能失败。网络本身也需要能够访问订阅服务：先暂时关闭系统代理，用浏览器确认普通网站可以打开。如果基础网络没有连通，Clash 无法代替本地 Wi-Fi、网线或移动网络建立底层连接。

检查项 正常表现 异常时优先处理
内核状态 持续运行，没有循环退出 查看启动日志与配置错误
本地网络 关闭代理后可访问普通网站 检查网关、认证页面和 DNS
系统时间 日期、时间、时区准确 启用系统时间同步
监听端口 HTTP、SOCKS 或 mixed 端口成功监听 退出占用端口的旧进程

二、导入并启用订阅配置

Clash 使用 YAML 配置描述代理节点、代理组、规则、DNS 和运行参数。订阅链接通常是配置服务提供的更新地址，客户端需要先请求该地址，再把返回内容保存为本地配置。复制链接时应保留完整查询参数，不要手动删除问号后的 token、设备参数或编码内容，也不要把订阅管理网页的地址误当成订阅地址。

  1. 进入“配置”“Profiles”或“订阅”页面。
  2. 选择从 URL 导入，把完整订阅地址粘贴到输入框。
  3. 执行下载或导入，等待客户端报告更新完成。
  4. 在配置列表中选中刚导入的项目，使其成为当前活动配置。
  5. 返回代理页面，确认能够看到代理组及组内节点。

“下载成功”和“配置已启用”是两个状态。有些客户端更新订阅后只把文件加入列表，不会自动切换当前配置。若代理页面仍显示旧节点，应回到配置页检查选中标记、活动状态或最近更新时间。配置启用后，如果客户端提示 YAML 解析错误，应记录具体行号和字段；不要反复点击更新，因为同一份错误内容不会因重复下载而自动修复。

订阅返回空内容、HTML 页面或不受支持的格式时，客户端可能提示 invalid config、unexpected token、proxy group not found 或缺少 proxies 字段。此类问题发生在配置载入阶段，与节点速度无关。可以在浏览器中打开订阅地址确认服务响应，但含有访问凭据的订阅 URL 不应发布到聊天群、截图或公开日志中。

三、选择代理组与节点

配置正常载入后，进入“代理”“Proxies”页面。这里通常不是一张单纯的节点列表，而是多个代理组。常见组类型包括手动选择的 select、自动测速的 url-test、故障切换的 fallback 和负载分配的 load-balance。规则引用的是代理组名称，代理组再决定当前使用哪个节点。因此，只在某个无关分组中点选节点，不一定会改变实际出口。

先找到承担主要流量的组。它可能叫“节点选择”“代理”“PROXY”或由配置提供方自定义。进入该组后选择一个地区明确、状态可测试的节点。如果主组中选中的是另一个代理组，还需要继续进入下一级查看最终节点。链式分组是有效配置方式，但首次排查时必须知道最终落到哪个代理条目。

模式选择也会影响结果：

  • 规则模式（Rule）：按规则从上到下匹配。不同域名可能分别走代理、直连或拒绝策略，适合作为日常默认模式。
  • 全局模式（Global）：大多数被接管的连接统一交给全局组，适合临时确认节点出口，但不代表所有系统流量必然被接管。
  • 直连模式（Direct）：被 Clash 接收的流量直接连接目标，不经过代理节点，不能用于验证远端代理出口。

首次验证可以先使用规则模式。如果无法判断某个测试网站命中了哪条规则，可短暂切换到全局模式比较结果。测试完成后再恢复规则模式。模式决定 Clash 收到连接后的处理方式，系统代理或 TUN 则决定连接是否会到达 Clash；这两个开关不能互相替代。

四、正确理解延迟测试

节点旁的“测速”通常执行 HTTP 探测：内核通过该节点访问配置指定的测试 URL，并记录建立连接及获得响应所需的时间。显示 80 ms、200 ms 或 Timeout，只能说明该次探测结果。它不等同于下载带宽，也不能完整表示视频稳定性、晚高峰拥塞、丢包率或目标网站对出口地址的限制。

测试时可以先对一个代理组执行全部延迟测试，再从同地区的可用节点中选择数值较低且连续结果稳定的项目。不要只根据一次最低数字决定。连续测试中，一个节点在 90 ms、95 ms、100 ms 附近波动，通常比在 40 ms 与 700 ms 之间剧烈变化的节点更容易保持交互稳定。跨地区节点的物理距离更远，基础延迟增加属于正常现象。

Timeout 表示在测试期限内没有获得预期响应，可能由节点离线、线路阻断、测试地址不可达、TLS 握手失败或本地网络波动引起。若所有节点同时超时，应先怀疑本地网络、订阅配置、内核状态或测试 URL，而不是逐个认定节点故障。若只有单个节点持续超时，则切换同组其他节点更有效。

五、启用系统代理或 TUN

节点选定后，需要让应用流量进入 Clash。最常见的方法是打开“系统代理”。客户端会把操作系统的 HTTP 和 HTTPS 代理指向本机监听地址，常见形式为 127.0.0.1 加一个本地端口。遵循系统代理设置的浏览器和桌面应用会把请求发送给 Clash，再由规则决定直连或代理。

系统代理并不覆盖所有程序。有些游戏、命令行工具、后台服务或自行实现网络栈的应用会忽略操作系统代理；UDP 流量也不一定通过普通 HTTP 代理。遇到这类需求时，可以考虑 TUN 模式。TUN 会创建虚拟网络接口，由内核接收更广范围的 IP 流量，通常需要管理员权限，并可能受到防火墙、杀毒软件、其他 VPN 或虚拟网卡的影响。

第一次连接建议先测试系统代理，因为链路更简单，故障点更少。确认浏览器代理成功后，再按需开启 TUN。不要同时运行多个会改写系统代理或路由表的客户端，否则一个程序可能覆盖另一个程序的设置。切换客户端前，应先关闭原客户端的系统代理和 TUN，再退出其后台进程。

使用系统代理时，还可以检查操作系统代理地址是否与客户端当前端口一致。配置中的 mixed-port、port 和 socks-port 用途不同；手动填写时不能把 SOCKS 端口当作 HTTP 端口使用。由客户端自动管理系统代理通常更稳妥，端口变化时也能同步更新。

六、验证代理是否实际生效

验证不能只看开关颜色。应同时检查出口结果、连接记录和规则命中。先保持已知节点处于选中状态，打开系统代理，然后使用新建的浏览器隐私窗口访问一个可以显示公网出口信息的服务。记录当前出口地区或地址，再关闭系统代理刷新比较。如果两次结果发生预期变化，说明浏览器流量已经进入代理链路。

接着打开客户端的“连接”“Connections”页面，再访问一个新网站。正常情况下会出现新的域名、目标地址、连接类型、上传下载量、命中规则和代理链。代理链可能显示“目标策略组 → 选中节点”，也可能显示 DIRECT。看到 DIRECT 不一定是错误：在规则模式下，本地网络、特定地区网站或配置指定域名本来就可能直连。

日志可以补充判断，但应按时间顺序阅读。一次浏览器请求通常会经过 DNS 查询、规则匹配、建立 TCP 或 UDP 连接、连接节点、访问目标等阶段。日志出现 match、proxy、DIRECT 或具体组名时，重点核对它是否对应刚刚访问的域名。旧日志中的 timeout 不能证明当前请求仍然失败，排查前可以清空日志或记住测试开始时间。

还应分别测试域名和直接 IP 连接。网页打不开但连接记录中没有任何新条目，说明流量可能未进入 Clash；有连接条目但显示 DNS 失败，应检查 DNS 模块、网络可达性和模式设置；连接命中正确节点后仍超时，则更接近节点线路或目标服务问题。按阶段定位比连续切换十几个节点更快。

一个可重复的验证流程

  1. 选择一个延迟测试可响应的节点。
  2. 确认当前模式为规则或全局，而不是直连。
  3. 开启系统代理，暂时保持 TUN 关闭。
  4. 清空或标记连接记录与日志的当前时间。
  5. 使用浏览器新窗口访问出口检测页面和普通 HTTPS 网站。
  6. 核对连接记录中的域名、规则、策略组和最终节点。
  7. 关闭系统代理再次测试，确认出口与连接记录发生变化。

七、识别状态提示与常见故障

Connected 或 Running：一般只表示内核、服务或某条连接处于运行状态，不保证目标网站可访问，也不保证当前出口经过代理。仍需结合连接记录验证。

Timeout：表示在限定时间内没有完成探测或连接。先判断是全部节点还是单个节点，再区分 DNS、节点握手和目标响应阶段。全部节点同时超时通常需要检查本地网络与内核。

Connection refused：目标地址主动拒绝连接。若被拒绝的是 127.0.0.1 上的本地端口，常见原因是内核未监听或系统代理端口填写错误；若发生在远端节点，则可能是节点服务没有在对应端口工作。

DNS lookup failed：域名解析没有得到可用结果。检查设备是否存在其他 DNS 工具、TUN DNS 劫持是否正常、配置中的 nameserver 是否可达。不要在基础连接尚未确认时同时叠加多个加密 DNS 和自定义 hosts 规则。

TLS handshake failed：可能涉及设备时间、证书验证、SNI、链路中断或远端服务状态。先校准时间，再换同组节点比较。如果所有节点仅对一个目标失败，也要考虑目标服务限制，而非直接修改整个配置。

网页能打开但应用不能连接：浏览器通常遵循系统代理，而目标应用可能忽略该设置或使用 UDP。先在连接页面确认应用请求是否出现；完全没有记录时，再考虑 TUN、应用内代理或进程路由设置。

八、首次连接检查清单

  • 客户端内核持续运行，日志没有配置解析失败。
  • 订阅已经下载，并被设为当前活动配置。
  • 代理页面能够看到策略组和节点。
  • 主要策略组已选中一个实际节点，而非失效条目。
  • 节点延迟测试有响应，连续结果没有异常波动。
  • 当前模式不是 Direct，规则模式下能够查看命中策略。
  • 系统代理已打开，操作系统代理端口与客户端监听端口一致。
  • 浏览器访问时，连接页面出现对应的新记录。
  • 记录中显示预期规则、策略组和最终节点。
  • 出口检测结果与关闭系统代理时存在预期差异。

完成以上项目后，首次连接的基础链路已经建立。后续如果只有特定程序无法联网，应把排查范围缩小到应用是否遵循系统代理、是否使用 UDP、是否需要 TUN，以及对应域名命中了哪条规则。若所有应用同时失效，则回到配置、内核、监听端口和本地网络四个基础环节重新检查。

稳定使用的关键不是持续追求最低延迟，而是保持配置有效、节点可达、流量入口明确、规则结果可观察。只要能够从连接记录中回答“请求是否进入 Clash、命中了什么规则、最终走了哪个节点”，大多数首次连接问题都能被定位到具体阶段。