Clash 快速上手：从订阅到连接验证

本页以「已有可用的 Clash 格式订阅链接」为起点。订阅链接由所使用的服务提供方交付，通常对应一份可由客户端下载的配置，而不是单个节点的名称。复制链接时保留完整地址，不要只复制订阅页面的网页地址；如果服务方提供多种格式，选择标注为 Clash 或 Mihomo 的配置格式。订阅可能包含私人连接信息，不要把链接贴到公开讨论区，也不要用不熟悉的在线工具处理。

打开已安装的客户端，先辨认三个位置：「配置」负责导入并启用订阅，「代理」负责查看策略组与选择出口，「概览」或主页负责开启系统代理、查看运行状态。不同客户端把开关放在不同位置，但操作顺序相同。手机端还需准备好系统弹出的 VPN 授权；这项授权由操作系统显示，只有开启连接时才需要确认。如果页面上已有旧配置，先记住当前选中的是哪一份，避免导入后仍沿用旧配置而误判新订阅没有生效。

首次操作建议保持一条清晰的验证路线：先加载一份订阅，用规则模式选择一个可用出口，再开启设备上的代理入口，最后观察实际请求。暂时不要同时改 DNS、TUN、端口与多份覆写文件；一次改变太多设置，出现问题时就很难判断是哪一步造成的。

进入客户端的「配置」或「订阅」页面，找到新增远程配置的入口。部分客户端用加号表示新增，部分客户端提供「从 URL 导入」或「导入订阅」。选择链接导入方式，把完整订阅地址粘贴到 URL 输入框；如果有名称字段，可填一个方便自己识别的名称，例如服务名称。确认后等待客户端下载配置，直到新条目出现在配置列表中。不要在输入框里粘贴订阅网页的标题，也不要把地址当作节点名称填写。

新条目出现后，查看它是否提示下载成功，或能否打开配置内容。随后点击该条目的「使用」「启用」或选中标记，使它成为当前配置。这个动作很关键：有些客户端会保存新订阅，但继续运行之前的本地配置。返回概览，核对当前配置名称是否已变化；再打开「代理」，检查是否出现订阅中的策略组和节点。能看到策略组，说明配置至少已被解析并加载，下一步才有可选择的出口。

如果保存后列表里没有新增条目，先核对链接是否完整、有无多余空格，再检查设备当前能否访问订阅地址。若条目存在却显示解析错误，向服务提供方确认链接是否提供 Clash 格式配置；单节点分享链接或其他格式的节点列表不一定能直接作为完整配置导入。若提示更新失败但旧策略组仍在，看到的可能是上次缓存的内容，不能把它当作本次更新成功。先处理导入问题，不要急着切换代理模式。

完成这一步的判断标准很具体：配置列表里能看到新条目，它处于当前使用状态，「代理」页面有可展开的策略组。以后订阅内容发生变化，可以回到同一页面使用「更新」或刷新操作；更新完成后仍需检查当前配置和策略组是否正常加载。若客户端提供自动更新间隔，先按实际需求设置，不必为了首次连接改动默认值。

确认配置加载后，打开「概览」或「设置」中的代理模式选择器，选择「规则」。有些界面显示英文 Rule。在规则模式下，客户端按当前配置中的规则匹配请求，分别交给指定策略组、直连或拦截处理。它适合作为初次使用的起点，因为可以同时观察需要代理和需要直连的访问是否按配置分开，而不必让所有请求统一经过同一出口。

接着进入「代理」页面。配置里可能有名为「节点选择」「自动选择」或由服务方命名的策略组；点击需要手动选择的策略组，选择一个可用节点，或者选择配置提供的自动选择子组。如果某个策略组指向另一个策略组，还要沿着选择关系检查最终出口，不能仅凭最外层的名称判断当前使用哪个节点。不同订阅的组名没有统一标准，以实际列表为准。选择完成后返回概览，核对模式仍为规则、当前配置仍是刚导入的那一份。

「全局」模式会让符合客户端接管范围的请求统一使用所选出口，适合临时判断问题是否来自规则匹配；「直连」模式则绕过代理出口，可用于对照设备原有网络是否正常。这两种模式都可以辅助排查，但不要因为某个网页打不开就长期停留在全局模式。先记录规则模式下出现的问题，再短暂切换作对照，测试后切回规则模式，才容易定位差异。

需要注意，代理模式不是设备的总开关。此时即使策略组选对了，浏览器也未必已经把请求交给客户端；桌面系统代理或手机端 VPN 授权还没有开启时，「代理」页的选择通常只是配置好出口。完成模式与策略组选择后，继续下一步，建立设备到客户端的连接入口。规则语法、策略组类型及规则集的维护方式可在进阶配置手册中查阅，首次启动不需要先修改这些内容。

在 Windows 或 macOS 客户端中，返回「概览」，打开「系统代理」开关。客户端会把系统代理指向本机正在监听的端口；遵循系统代理设置的浏览器和应用随后才会把请求交给客户端。开关显示为开启后，保持客户端运行，先不要关闭主窗口之外可能驻留的托盘或菜单栏程序。若客户端另有「启动内核」或「运行」按钮，也要确认内核处于运行状态：系统代理开着而内核没有运行时，请求会被送往一个没有服务响应的本地端口。

在 Android 或 iOS 客户端中，找到主页上的连接按钮并启动。系统通常会弹出创建 VPN 连接的确认框；阅读提示并授权，随后查看系统状态栏是否显示 VPN 状态、客户端是否显示已连接。这里的 VPN 是手机操作系统向客户端提供的网络接入方式，不等于订阅已经正确加载。若授权弹窗没有出现，先看客户端是否提示配置或权限错误；若系统里已有另一个正在使用 VPN 接口的应用，需要先处理接口占用，再重新启动连接。

桌面端并非所有应用都遵循系统代理。浏览器通常适合做第一轮测试，但有些应用单独指定了代理、使用自己的网络栈，或完全忽略系统设置。先用一个遵循系统代理的应用走通基础流程，再决定是否需要 TUN 模式。TUN 会改变设备接管流量的范围，往往还涉及系统权限、路由和 DNS；首次连接时同时开启 TUN 与系统代理，反而不利于判断请求走了哪条路径。需要接管更多应用时，可在进阶配置手册的 TUN 章节按设备情况逐项设置。

如果打开系统代理后网络立即不可用，先回到概览确认内核正在运行、当前配置已选中，再查看客户端显示的监听端口是否与系统代理指向的端口一致。配置中的 mixed-port 常用于同时接收 HTTP 和 SOCKS 连接，但实际端口应以当前客户端设置为准，不要把某个示例端口直接当成所有设备的固定值。完成连接后先保持这些开关不变，进入验证步骤观察真实请求。

保持客户端连接，打开一个平时需要经过代理访问、且你知道应当可以访问的网站。页面加载后，立即切到客户端的「连接」或「日志」页面，寻找刚才请求对应的域名。连接记录通常会显示目标、命中的规则、使用的策略组以及最终出口；不同客户端展示的字段不完全一样，至少要确认这次请求确实到达了客户端，并且没有落到意料之外的直连策略。仅凭主页的「已连接」状态，无法判断浏览器是否真的使用了当前配置。

再打开一个按现有配置预期应当直连的网站，观察新连接是否走向直连。这一步不是测试哪个网站速度更快，而是核对规则模式确实把两类请求分开处理。如果代理网站与直连网站都能打开，但记录里全部指向同一出口，应检查当前模式是否仍为「规则」，以及订阅中的规则是否符合自己的预期。若所用客户端能显示具体命中规则，先记下规则名称，再决定是否要修改配置；不要看到结果不同就立即重写整份 config.yaml。

如果网页打不开且客户端完全没有新增连接记录，问题通常发生在流量进入客户端之前。桌面端先检查系统代理开关，再检查浏览器是否设置了独立代理或使用了不遵循系统设置的连接方式；手机端检查 VPN 授权和客户端连接状态。如果有连接记录，但目标被送到错误的策略组，回到代理页确认组内选择，并核对当前配置是否被旧配置替换。如果记录显示已选中预期出口，仍无法访问，则再考虑节点可用性、订阅更新状态或目标网站自身问题。按「有没有记录 → 命中什么规则 → 最终走哪个出口」的顺序检查，比反复切换所有开关更容易找到原因。

完成验证后，记住当前工作的配置、模式和策略组选择即可。以后遇到订阅更新失败、DNS 解析异常、端口占用或个别应用无法接管，再按症状查看进阶配置手册。如果只是想重走一次流程，可从本页导入订阅开始逐步核对，不需要删除所有现有配置。使用结束后，在客户端关闭系统代理或手机端连接，并确认设备已恢复预期的网络设置。