Clash 订阅导入与连接教程

开始前：确认客户端与配置来源

本教程从客户端已经安装完成开始。先正常打开程序，进入设置或关于页面，确认客户端名称和内核类型。客户端负责界面、订阅管理以及系统设置；内核负责解析配置、匹配规则和建立连接。程序能够打开，只说明界面启动成功，不代表内核已经加载了有效配置，也不代表其他应用的流量已经进入代理。

准备一条由服务提供方给出的有效订阅链接，或者一份完整的本地 YAML 配置。客户端本身不附带可用的远程代理服务；只有客户端、没有节点和有效配置，无法完成远程代理连接。订阅地址可能包含账户标识，应当只粘贴到可信客户端，不要发布在截图、公开日志或在线转换页面中。

首次操作时，先退出其他正在接管网络的代理或 VPN 工具，保留一条清晰的测试路径。如果此前手动修改过系统代理，记录原设置，便于退出时恢复。随后保持客户端窗口可见，按下面的顺序完成操作，不要同时更改 DNS、TUN、路由和规则，以免出错后难以判断原因。

Clash Meta 与 mihomo 的入口差异

Clash Meta 是这一内核分支的历史名称，项目后来更名为 mihomo，因此部分客户端仍保留 Meta 字样。看到旧名称并不意味着需要另装一个客户端；应以当前程序实际使用的内核和支持字段为准。若订阅包含 VLESS、Hysteria2 等条目，却在导入时提示未知协议，先检查内核兼容性，不要靠反复点击连接解决。具体协议和内核关系可查阅协议参考。

步骤一：导入订阅并启用配置

打开客户端侧栏或底部导航中的“订阅”“配置”或“Profiles”。选择“新增”“导入”或带加号的入口，在来源类型中选择远程链接，再粘贴完整订阅地址。地址通常以 https:// 开头；复制时应保留查询参数，去掉聊天软件附带的说明文字、换行和首尾空格。名称可以写成便于辨认的用途，例如“日常配置”，它只影响本地显示，不改变订阅内容。

点击下载、保存或导入后，等待配置卡片出现成功状态。如果客户端分开提供“保存链接”和“更新配置”两个按钮，需要继续执行一次更新，直到节点和策略组被实际下载。不要仅凭列表里出现了配置名称就进入下一步：有些程序会先保存地址，后台请求失败时仍保留一张空卡片。应打开详情，确认没有解析错误，并且代理页面已出现服务方提供的策略组。

接着点击配置卡片，将其设为当前使用配置。部分客户端用高亮边框、勾选标记或“启用”按钮表示当前配置，另一些客户端会立即重新加载内核。回到代理页面，看到策略组和节点列表后，说明导入与启用两个动作已经衔接完成。如果同时保存多份配置，需要确认高亮的确实是刚导入的一份，避免更新了新订阅却继续运行旧配置。

如果取得的是本地 .yaml 或 .yml 文件，使用“从文件导入”，不要将文件名粘贴到远程链接框。以 ss://、vmess:// 等开头的内容通常是单个节点分享链接，并不等于含有策略组、规则和 DNS 的完整 Clash 配置；只有客户端明确支持该格式时，才能使用相应的节点导入入口。

订阅更新与导入错误

订阅导入成功后，可以在该配置的编辑页面设置自动更新周期。更新时间只决定何时重新获取配置，不保证服务端节点始终可用。手动更新后应检查成功提示，再回到策略组确认原来的选择是否保留。若出现下载失败，先区分是地址失效、账户状态异常、当前网络无法访问订阅地址，还是下载成功后解析失败；这几类问题的处理方向不同。

解析失败时优先查看错误中的字段名、协议名和行号，不要随意删除整段配置。完整订阅一般应由提供方修正，或者按其说明选择适配 mihomo 的格式。订阅中途失效、更新后节点消失等情况，可转到常见问题继续排查；此时先保留上一次可用配置，避免把唯一的工作配置覆盖掉。

步骤二：选择规则模式与出口节点

配置已经启用后，进入“总览”“代理”或“模式”页面，将运行模式设为“规则 / Rule”。规则模式会按配置中的规则顺序决定连接去向：部分目标直连，部分目标进入代理策略组，明确拒绝的目标则被阻止。这个步骤只决定如何处理已经进入内核的连接；流量是否会进入内核，还需要下一步启用系统代理或其他接管方式。

随后打开主要代理策略组。名称由订阅作者决定，可能是“节点选择”“代理”或其他用途名称，不必寻找一个全站统一的名字。展开策略组后，先选一个已知可用的节点；如果客户端提供连通性或延迟测试，可以先测试再选择。测试结果只代表客户端对指定测试地址的探测，显示数值不等于所有网站和应用都能正常使用。

需要留意策略组可能引用另一个策略组。例如主策略组选择了“自动选择”，实际出口由该子组继续决定；选择“手动选择”时，则需要进入对应子组指定节点。如果最终选择的是 DIRECT，该组会使用直连，而不是远程代理。第一次验证建议固定一个明确的节点，减少自动切换带来的变量，确认工作正常后再恢复自动策略。

规则、全局与直连的使用顺序

“全局 / Global”会让进入内核的连接使用全局策略，不会自动接管那些绕过客户端的应用；“直连 / Direct”则让进入内核的连接直接访问目标。日常使用通常先保留规则模式。若某个目标异常，可短暂切到全局进行对照测试：全局正常而规则模式异常，才进一步检查规则命中和策略组选择。完成对照后切回规则模式，避免测试设置被长期遗忘。

自定义规则先确认位置

首次连接不需要立即增加规则。确实要为某个域名指定路径时，先在客户端中寻找“覆写”“扩展配置”或“规则编辑”入口，弄清修改会作用于当前配置还是所有配置。直接编辑下载下来的订阅文件，可能在下一次更新时被覆盖；优先使用客户端明确支持的持久化修改方式，并在保存后查看最终生成配置。

规则一般从上到下匹配，首次命中后执行对应策略。新增规则必须位于能够兜住该目标的宽泛规则之前，并且策略名称必须真实存在。例如 DOMAIN-SUFFIX,example.com,DIRECT 表示让该域名后缀及其子域走直连；它只是语法示例，不需要加入实际配置。更复杂的规则集和 DNS 关系留到协议与内核参考查阅，先完成下面的基础连接验证。

步骤三：启动内核并接管流量

返回客户端总览，确认状态显示内核运行中，且没有持续出现配置加载失败或端口占用错误。部分客户端打开程序后会自动启动内核，另一些需要点击“启动”或主连接按钮。可以在设置中查看本地代理监听地址与端口；实际值以当前配置为准，不要假定所有客户端都使用同一端口。配置页面显示已启用，但内核启动失败时，继续切换节点不会修复监听问题。

桌面端先使用系统代理

在桌面客户端打开“系统代理”开关，然后使用遵循系统代理设置的浏览器发起新请求。正常情况下，客户端会把系统 HTTP 代理指向本机监听端口。若浏览器安装了单独控制代理的扩展，先暂停扩展接管，避免系统设置被覆盖。保留浏览器原先打开的页面并不能证明连接已经切换，需要刷新页面或打开新的测试页面。

有些命令行程序、游戏或应用不读取系统代理设置，因此浏览器可用而这些程序仍直连，并不一定是节点故障。先确认该程序是否有独立代理入口；如果没有，再考虑 TUN。关于不同应用的流量覆盖范围，可阅读TUN 模式与系统代理区别，不必在首次启动时同时开启所有网络功能。

移动端确认系统连接授权

在移动端点击首页连接开关，首次启动时按系统提示允许创建 VPN 配置或建立 VPN 连接。完成授权后返回客户端，确认状态变为已连接，并检查系统网络状态中的 VPN 标识。这个标识只说明系统隧道已经建立，不能单独证明节点可用。若系统中另一个 VPN 正在运行，应先断开，再回到当前客户端重新连接。

需要覆盖更多应用时再启用 TUN

TUN 通过虚拟网卡和路由接管流量。桌面客户端可能要求先安装服务模式、授予管理员权限或确认系统扩展，按当前客户端的提示完成即可。开启后检查日志是否出现虚拟网卡创建和监听成功的信息；若提示权限不足或网卡创建失败，先关闭 TUN，恢复已验证的系统代理路径，再到故障排查查找对应错误。

不要同时运行两套 TUN 或 VPN 接管方案。首次调试也不建议一边改 DNS、一边调整路由排除列表。系统代理和 TUN 是否需要同时开启，取决于客户端实现与具体应用；以客户端文档为准，验证时先采用一种可解释的接管路径。此时配置、节点和接管方式已经确定，下一步只观察结果，暂时不要继续修改参数。

步骤四：验证访问、规则与实际出口

先打开一个平时能够稳定访问的 HTTPS 页面，确认基础网络没有因接管而中断；再访问一个按当前配置应当使用代理的目标。需要产生新的连接，而不是只查看浏览器已经缓存的内容。若测试期间切换了模式或节点，旧连接可能继续沿用之前的出口；可以关闭该目标页面后重新打开，必要时只清理客户端内对应目标的现有连接。

接着进入客户端“连接 / Connections”页面，按刚访问的目标域名筛选，查看该请求是否出现。若列表完全没有相关记录，优先检查浏览器代理设置、应用独立配置和 TUN 接管范围，而不是马上更换远程节点。若记录已经出现，则继续观察命中规则、策略组链和最终出口；这些信息共同说明流量进入内核后实际走了哪条路径。

对于应该代理的目标，确认它没有意外命中 DIRECT。如果命中的是代理策略组，还要展开策略链，确认最终选择确实是预期节点。目标走直连不一定是错误，可能正是订阅规则的安排；判断标准应当是预期路径与实际记录是否一致，而不是连接列表中所有项目都必须带有代理名称。

出口查询与 DNS 检查分别判断

使用可信的出口查询页面作为辅助验证，将开启代理后的结果与直连基线对照，并同时查看该查询请求在客户端中的记录。出口结果与服务方标注不一致时，需要结合节点实际出口、查询数据库和代理链判断，不能只凭地区名称下结论。也不要把订阅链接或账户信息提交给所谓的一键检测网站。

页面能够打开或出口已经改变，都不能单独证明所有应用的 DNS 请求采用了预期路径。首次上手先确认访问与规则命中；确有 DNS 需求时，再查看Fake-IP 与 DNS 处理方式。遇到只有特定域名异常的情况，应记录目标、命中规则和报错类型，按照常见问题中的排查顺序逐项缩小范围。

完成后保存一套可重复的状态

当页面访问正常、连接记录符合预期后，记下当前配置名称、模式、策略组选择和接管方式即可，不需要公开完整配置。随后测试一次正常退出：先关闭系统代理或断开连接，再退出客户端，确认普通网络仍可访问。如果只结束进程而系统代理仍指向本机端口，浏览器可能因为监听服务已停止而报错；重新打开客户端关闭系统代理，或恢复此前记录的系统设置。

最后按需要启用开机启动和配置自动更新，并在下次重启后复查一次。开机启动只表示程序被打开，不保证订阅已加载、内核已启动或 TUN 权限已经就绪。保留这四步的顺序：配置有效、模式明确、流量进入内核、实际路径可验证。以后发生异常，也从最先不符合预期的一步开始检查，比连续切换多个开关更容易定位问题。