Clash 导入订阅、连接与验证

从订阅地址导入

打开客户端后，先寻找“订阅”“配置”或“Profiles”页面。桌面客户端通常会在页面顶部提供输入框和导入按钮，移动端则可能把入口放在右上角的加号菜单中。将完整订阅地址粘贴到输入框，必要时填写一个便于识别的名称，例如“日常配置”，然后点击“导入”“添加”或“下载”。客户端会请求远程内容并生成一条新的配置记录。

导入完成后，不要立刻打开系统代理。先查看配置记录是否显示名称、更新时间或代理数量，再进入代理页面确认至少出现一个策略组。如果配置页只新增了一条记录，但代理页仍为空，可能是订阅内容没有成功解析；如果客户端直接提示格式错误，则需要重新确认复制的地址是否完整。某些服务会同时提供通用订阅、Clash 订阅和其他客户端格式，此时应优先选择明确标注适用于 Clash 或 mihomo 的格式。

当配置列表中存在多份内容时，需要点击目标配置，并执行“启用”“设为当前”或类似操作。仅完成下载不代表客户端正在使用它。可以观察配置条目是否带有当前状态标记，也可以返回首页查看当前配置名称是否发生变化。确认当前项后再进入下一步，这样后续看到的策略组和规则才属于刚刚导入的配置。

从本地 YAML 文件导入

使用本地文件时，在配置页选择“从文件导入”或把 YAML 文件拖入客户端指定区域。Android 通常会打开系统文件选择器，需要授予客户端读取所选文件的权限；macOS 可能要求允许访问下载目录或文稿目录。导入成功后，同样要把该文件设为当前配置。若客户端提示 YAML 解析失败，应优先检查缩进层级、冒号后的空格和列表项格式，而不是反复切换代理模式。

本地配置适合需要固定规则或自行维护参数的场景，但首次使用不建议同时启用覆写脚本、全局扩展配置和多个规则提供器。配置层叠越多，出现问题时越难判断实际生效值。先使用原始配置完成一次连接，之后再逐项增加自定义内容。关于协议字段、订阅兼容性和配置迁移的详细差异，可查阅协议手册中的订阅格式章节。

首次使用优先选择规则模式

配置就绪后，进入客户端的“模式”“Mode”或代理设置区域。常见选项包括规则模式、全局模式和直连模式。首次配置建议选择规则模式，也就是常见的 Rule。在这个模式下，每个请求会按照配置中的规则顺序匹配：某些域名或网络可以直连，另一些请求交给指定策略组，未命中的请求则由末尾规则承接。这样既能验证订阅中的规则是否正常加载，也更符合多数配置的默认设计。

全局模式通常会把大部分请求交给同一个全局策略，适合短时间排查规则是否导致连接差异，但不宜把它当作所有问题的解决方式。直连模式会绕过代理，主要用于临时恢复网络或对照测试。如果规则模式下某个网站无法访问，而全局模式可以打开，应进一步检查规则命中和策略组选择；如果两种模式都失败，则应回到配置、代理可用性或系统接入状态进行检查。

为主要策略组指定代理

进入“代理”或“Proxies”页面后，会看到由配置定义的多个策略组。名称可能是“节点选择”“自动选择”“故障转移”“媒体服务”或其他自定义文字。先找到承担默认流量的主要策略组，点击后选择一个明确的代理条目。若组内包含 DIRECT、自动测试组和多个代理，首次验证可以先手动选择一个状态正常的代理，减少自动切换带来的变量。

客户端提供的延迟测试只能说明测试地址在当时是否可达，以及建立请求所需的大致时间，并不能单独证明所有网站和应用都能正常使用。某个条目显示较低延迟，也可能因为协议参数、网络路径或目标服务差异而无法完成实际请求。因此，测速用于缩小选择范围，最终仍要以第四步的真实连接记录和页面访问结果为准。

若策略组采用 url-test、fallback 或 load-balance，客户端可能显示为“自动选择”“故障转移”或“负载均衡”。这些组的选择逻辑不同：自动测试通常偏向测试结果较优的代理，故障转移更关注当前代理失效后的切换顺序，负载均衡则会把连接分配到多个代理。首次上手只需确认主要策略组有可用选择，不必立即调整测试间隔、容差或哈希策略。详细差异可转到协议手册继续查阅。

先确认内核处于运行状态

返回客户端首页或设置页，检查内核状态。采用 mihomo 的客户端通常会显示“运行中”“Service Running”或可操作的启动按钮。部分桌面客户端打开后会自动启动内核，另一些客户端需要手动点击启动；如果涉及服务模式，Windows 可能弹出管理员权限确认，macOS 可能要求输入系统密码安装辅助服务。完成授权后等待状态稳定，再继续打开系统代理。

如果内核无法启动，先查看端口占用和错误日志。常见情况是另一款代理客户端仍在后台运行，或者旧进程占用了配置中的 mixed-port、HTTP 端口或 SOCKS 端口。关闭其他客户端后重新启动，比同时修改多个端口更容易确认原因。若日志直接指出配置字段无法识别，则可能是当前内核与配置能力不匹配，此时应更新客户端或选择兼容的配置格式。

桌面端启用系统代理

Windows 和 macOS 用户在内核运行后，打开“系统代理”“System Proxy”或“设为系统代理”开关。这个操作会把代理地址写入操作系统的网络设置，浏览器以及遵循系统代理的应用随后会把请求发送给 Clash。开关启用后不要立即退出客户端，因为系统代理只负责把流量指向本地监听端口，真正处理连接的仍是正在运行的内核。

有些浏览器使用独立代理设置，部分命令行工具也不会自动读取系统代理。首次验证建议先使用系统自带浏览器或常见桌面浏览器，避免一开始就用行为特殊的应用测试。等浏览器确认可用后，再根据目标应用的网络设置决定是否需要单独填写 HTTP 或 SOCKS 地址，或者改用覆盖范围更广的 TUN 模式。

移动端允许建立系统连接

Android 与 iOS 客户端通常通过系统 VPN 接口接管流量。点击连接按钮后，系统会弹出网络连接授权提示，确认后状态栏会显示相应的连接标识。这个授权表示允许客户端创建本地网络通道，不等于已经选对代理，因此仍需保持第二步中的策略组选择。若系统提示已有其他 VPN 正在运行，应先断开原有连接，再重新启动 Clash 客户端。

何时考虑 TUN 模式

系统代理适合浏览器和遵循系统设置的桌面应用，配置路径短，首次排错也更清晰。TUN 模式会通过虚拟网络接口覆盖更多流量，适合不读取系统代理的应用、部分命令行程序或需要统一处理 DNS 的场景。启用 TUN 可能需要管理员权限、辅助服务或额外网络组件，因此本教程建议先用系统代理完成浏览器验证，再根据实际需求开启。

切换到 TUN 后，应避免同时让其他网络工具修改路由或 DNS。若连接出现变化，可以先关闭 TUN，确认系统代理路径仍然正常，再检查 TUN 堆栈、DNS 劫持和路由排除项。关于系统代理、TUN、DNS 模式及不同系统权限的完整说明，请参考协议手册的网络与系统章节。

先用浏览器发起一个新请求

保持客户端在前台或后台运行，关闭浏览器中已经打开的测试页面，再新建标签页访问一个稳定的网站。重新打开页面比刷新旧页面更可靠，因为浏览器缓存、已有连接和 DNS 缓存可能让旧标签页没有产生完整的新请求。页面能够加载只是第一层结果，还需要回到客户端观察连接列表是否出现对应域名。

打开“连接”“Connections”或“日志”页面，查找刚才访问的域名。正常情况下可以看到请求目标、命中的规则、所用策略组以及最终选择的代理或 DIRECT。如果目标网站按配置预期走代理，记录中应显示相应策略链；如果本应直连的站点显示为 DIRECT，也说明规则模式正在工作。验证重点不是所有请求都显示同一种路径，而是实际结果与规则设计一致。

区分浏览器成功与全系统成功

浏览器能够访问后，再打开一个实际需要使用的应用进行测试，并同步观察连接列表。如果浏览器有记录而目标应用完全没有新连接，该应用可能不读取系统代理，或者使用了独立网络栈。此时可以检查应用自身的代理选项，桌面端也可以在理解权限要求后测试 TUN 模式。若连接列表出现请求但状态为超时，则说明流量已经进入 Clash，问题更可能位于代理条目、协议参数、DNS 或目标网络路径。

命令行工具需要单独判断。部分工具会读取系统环境变量，部分工具使用自己的代理参数，还有一些程序只有在 TUN 模式下才会被接管。因此，不要用单个命令行请求直接否定系统代理状态。先以浏览器和客户端连接记录建立基准，再针对具体工具设置代理地址，这样可以把系统接入问题与应用配置问题分开。

检查模式切换是否符合预期

为了确认规则影响，可以选择同一网站进行一次对照：保持代理条目不变，短暂切换到全局模式并重新打开页面，然后再切回规则模式。若全局模式成功而规则模式失败，应查看规则命中到哪个策略组，以及该组是否误选了直连或不可用条目。若两种模式都失败，则检查当前配置、主要策略组和代理本身。完成对照后应恢复规则模式，避免后续所有请求继续使用全局策略。

还可以进行一次恢复测试：关闭系统代理或断开移动端连接，确认客户端状态与系统连接标识同步变化，然后重新连接。这个动作能够验证权限和开关是否可重复工作。桌面端若关闭系统代理后浏览器仍指向本地端口，应进入系统网络设置检查代理项是否残留；移动端若断开后系统图标仍在，则检查是否有其他 VPN 应用接管了连接。