Clash 订阅导入与连接教程

导入订阅并选中当前配置

打开客户端后，先寻找“订阅”“配置”或 Profiles 页面。部分客户端把订阅输入框放在页面顶部，部分客户端需要先点击“新建”“从 URL 导入”或加号。将订阅服务提供方给出的完整地址粘贴到输入框，不要把网页后台地址、套餐名称或单个节点文字当作订阅地址。确认输入框没有多余空格和换行后，点击“导入”“下载”或“添加”。

正常情况下，客户端会请求订阅地址并生成一个新的配置条目。此时先不要急着开启连接，应查看条目名称、更新时间和客户端给出的状态。若页面提示网络错误、格式错误或配置解析失败，说明导入阶段还没有完成；继续切换代理模式不会解决这个问题。可以重新复制订阅地址，在浏览器中确认服务页面可访问，并检查订阅是否仍处于可用状态。涉及授权失效、订阅内容为空或服务端返回异常时，需要由订阅服务提供方处理。

配置条目出现后，点击该条目或使用旁边的启用按钮，将它设为当前配置。很多客户端允许同时保存多份配置，但内核在同一时刻只会按当前选中的配置执行。仅把订阅加入列表、却没有选中它，是常见的“已经导入但代理页面没有策略组”原因。选中后进入“代理”或 Proxies 页面，如果能看到订阅定义的策略组和选项，说明配置已经交给内核读取，可以进入下一步。

导入完成时应该看到什么

最直接的结果不是网页已经可以访问，而是客户端内出现可选择的配置条目，配置详情能够显示策略组，并且没有持续出现解析错误。某些客户端会在导入后自动切换到新配置，另一些仍保留之前的本地配置，因此需要手动确认当前项。若更新订阅后策略名称明显变化，也应重新检查当前选择，避免继续使用旧配置缓存。

这一阶段只解决“配置从哪里来”和“内核读取哪一份配置”。它还没有决定每个请求走哪个出口，也没有把浏览器或系统流量交给客户端。确认配置已选中后，接下来要选择代理模式，让内核知道是逐条判断规则，还是把请求统一交给一个策略。

选择规则模式或全局模式

进入客户端的“模式”“代理模式”或 Mode 设置。常见选项包括规则模式、全局模式和直连模式。第一次完成配置时，建议选择规则模式。规则模式会从配置文件的规则列表顶部开始检查请求，遇到第一条匹配规则后停止继续求值，并把请求送往该规则指定的 DIRECT、REJECT 或策略组。这样可以让不同域名和地址使用不同去向，也是多数订阅配置预期的工作方式。

选择规则模式后，打开“代理”或策略组页面。这里显示的名称由当前配置定义，不同订阅之间可能完全不同。找到用于主要代理选择的策略组，再选择其中一个具体选项或由配置提供的自动选择项。不要把 PROXY 理解成客户端内置且必然存在的固定按钮；在 YAML 示例中，它通常只是策略组名称，必须由配置中的 proxy-groups 定义。实际界面应以当前配置展示的组名为准。

全局模式会把能够被客户端接管的流量统一交给全局策略，适合短时间做对照测试。例如规则模式下某个网站失败，而切换全局模式后可以访问，问题更可能位于规则匹配、策略组选择或 DNS 路径，而不是订阅完全不可用。完成对照后应恢复规则模式，再根据日志查找命中的规则。长期停留在全局模式会绕过配置原本设计的分流逻辑，也无法帮助定位具体是哪条规则产生了结果。

直连模式通常让已接管的请求直接连接目标，可用于确认客户端接管本身是否影响某个应用，但它不是“关闭客户端”的同义词。若系统代理或 TUN 仍保持开启，流量可能依旧先进入内核，再由直连策略送出。需要彻底停止接管时，应在下一步关闭对应的系统代理、VPN 或 TUN 开关，而不是只改变代理模式。

如果策略组为空、所有选项都不可选，或切换模式时立即出现配置错误，应返回第一步检查当前配置，而不是继续开启系统代理。模式与策略都能正常选择后，配置层面的准备已经完成，下一步才是把设备或应用的流量交给客户端。

开启系统代理并建立连接

返回客户端首页或设置页，找到“系统代理”“设置为系统代理”或含义相同的开关并开启。桌面系统中的系统代理会写入操作系统的代理设置，让遵循该设置的浏览器和应用把请求发送到客户端监听端口。开关成功后，客户端通常会显示已启用状态；也可以打开系统网络设置，确认 HTTP、HTTPS 或 SOCKS 代理项已由客户端管理。

Android 和 iOS 客户端通常通过系统 VPN 接口接管流量。第一次启动时，系统会弹出 VPN 配置或连接授权，确认后状态栏可能出现系统级 VPN 标识。这个授权表示允许客户端创建本地网络通道，并不代表订阅服务与客户端属于同一提供方。若拒绝授权，配置和策略仍可能在客户端内正常显示，但其他应用的流量不会进入内核。

macOS 上不同客户端可能使用系统代理、VPN 配置或网络扩展；Windows 客户端也可能在开启 TUN 时请求管理员权限。只打算先验证浏览器时，优先使用系统代理即可。系统代理影响范围更容易观察，也便于在出现问题时关闭。终端程序、部分游戏、虚拟机以及自行实现网络栈的应用可能忽略系统代理，这些场景再考虑 TUN，而不是在首次配置时同时打开所有接管方式。

开启接管前还要确认策略组中已经选定一个可用选项。如果客户端支持策略测试，可以执行一次由客户端提供的可用性检查，但结果只能说明测试目标的请求情况，不能替代真实应用验证。随后保持客户端运行，打开一个新的浏览器窗口进入下一步。不要在连接前后同时修改订阅、模式、DNS 和 TUN；一次只改变一个环节，出现问题时才能判断是哪项设置造成差异。

到这里，连接链路应是：应用读取系统代理或进入 VPN/TUN，流量到达客户端监听入口，内核读取当前配置并按选定模式处理，最终送往直连、拒绝或代理策略。下一步需要从应用表现和客户端日志两侧验证这条链路，不能只看首页开关是否亮起。

验证代理与规则是否生效

先选择一个此前没有打开的网页，在新标签页中访问。使用新请求可以减少浏览器缓存、已有连接和 DNS 缓存对判断的干扰。页面加载的同时打开客户端日志或连接记录，搜索刚访问的域名。能够看到该域名、命中的规则和最终策略，才说明请求确实进入了内核。只看到系统代理开关处于开启状态，不能证明具体应用已经采用该设置。

日志中的结果应与规则预期一致。例如目标命中直连规则时会显示 DIRECT，命中拒绝规则时会显示 REJECT，命中策略组时会显示该组及其最终选择。规则模式采用从上到下、首次匹配即停止的逻辑，因此后面的规则即使看起来更具体，也不会覆盖已经命中的前一条。发现去向不符合预期时，先记录命中规则，再处理规则顺序或策略组，不要用反复切换节点掩盖规则问题。

浏览器验证完成后，再测试真正需要使用的应用。若浏览器正常而终端命令失败，通常说明两者读取了不同的代理入口。终端可能需要单独设置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 环境变量，也可能需要由 TUN 接管。若某个应用提供自己的代理设置，它可能覆盖系统代理；应检查应用设置中是否选择了“不使用代理”、固定端口或旧地址。详细的浏览器与终端分层方法可查看帮助中心，避免在基础流程中同时修改过多参数。

若日志完全没有出现测试域名，应从流量入口检查：桌面端确认系统代理仍开启并且端口与客户端监听一致，移动端确认系统 VPN 连接没有被其他 VPN 应用替换，TUN 场景确认权限和路由创建成功。若日志出现域名但请求失败，则继续查看最终策略、连接错误和 DNS 结果。前者属于“应用没有进入客户端”，后者属于“已经进入客户端，但出口或解析阶段失败”，两类问题的处理方向不同。

还可以做一次模式对照：保持同一个配置和同一个测试地址不变，从规则模式临时切换到全局模式，并选择同一可用策略。如果全局模式成功而规则模式失败，重点检查规则命中和 DNS；如果两种模式都失败，重点检查策略可用性、订阅状态和本地网络；如果浏览器成功但其他应用失败，重点检查应用代理设置和接管范围。完成测试后恢复规则模式，避免测试状态成为长期设置。

验证失败时按层次回退

排查时按本教程顺序向前回退即可：日志没有请求，回到连接步骤检查系统代理、VPN 或 TUN；日志有请求但没有合适策略，回到模式步骤检查策略组和规则；代理页面没有策略组，回到导入步骤确认当前配置及解析状态。这样每次只处理一个层次，比删除客户端后重新安装更容易保留有效线索。