Clash 订阅导入与连接教程。

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

在服务提供方的订阅页面找到适用于 Clash 或 mihomo 的订阅入口，使用旁边的复制按钮获取完整链接。复制后不要在公开群聊或截图里展示地址；其中可能包含与账户关联的访问凭据。如果页面同时提供多种客户端格式，优先选择明确标注与你当前客户端兼容的那一种，而不是随意复制另一个格式再尝试导入。

回到客户端，打开侧栏中的“配置”或“订阅”，找到“新建”“添加”或“从 URL 导入”。在地址栏粘贴链接，给配置取一个方便辨认的本地名称，例如“日常连接”，然后点击“导入”或“保存”。部分客户端把输入框直接放在配置页顶部，粘贴后点击下载图标即可；本地名称只是用于区分配置，不会改变服务端的节点内容。

提交后等待下载结束。正常情况下，页面会出现一张配置卡片，或者在列表里新增一行订阅记录。接着点击这份配置，使用“启用”“使用”或选中标记把它设为当前配置。下载完成与启用配置是两件事：列表里已经有文件，并不代表内核正在读取它。切换后如果出现语法或字段错误，应先处理错误提示，再继续下一步。

打开“代理”页面，检查是否能看到策略组及其内部的节点。策略组的名字由订阅决定，可能是“代理选择”、Proxy 或其他名称，不需要与本文相同。若只看到 DIRECT、REJECT 等内置项目，先回到配置页确认当前配置是否选中，再查看订阅更新结果；不要立即开启全局模式，因为模式切换不会补回缺失的节点。

导入失败时，先检查链接是否完整，有没有多出空格、换行或漏掉末尾参数。若提示超时，可能是当前网络访问不到订阅服务器；若提示无法解析，可能返回了登录页面、错误页面或不兼容的配置格式。浏览器能打开一个地址，也不等于它返回的是客户端可读取的配置。具体可按订阅更新失败排查继续定位，不建议把链接交给来源不明的在线转换页面。

如果服务提供方给的是本地 YAML 文件，则选择“从文件导入”，再选中该文件并启用。文件导入不一定具备远程自动更新能力，节点变动后可能需要重新获取配置。无论使用链接还是文件，完成本步的判断标准都是：当前配置已启用，代理页已加载预期策略组，且没有待处理的配置错误。

第二步：选择规则模式与代理节点

确认节点已加载后，进入客户端的主页、代理页或设置页，找到“模式”选项。首次使用建议选择“规则”，英文通常显示为 Rule。该模式按照配置中的规则决定每条连接走直连、代理组还是其他出口，适合把需要代理的请求与普通访问区分开。选中后先保留订阅自带的规则，不要急着添加大批自定义条目。

模式菜单中的“全局”通常把已进入内核的连接交给全局策略处理，便于临时对照规则是否影响了结果；“直连”则通常让进入内核的连接直接访问目标。这里容易混淆的一点是：模式决定流量进入内核之后怎么走，不负责让应用流量进入内核。即使选了全局，尚未设置系统代理或 VPN 接管的应用也可能仍然直接联网。

回到“代理”页面，找到配置中实际供规则引用的主要策略组，展开后选择一个节点。如果组里有“自动选择”或“故障转移”，也可以使用订阅已经定义好的这类组；首次排查时手动固定一个节点，更容易对照前后结果。不要只在某个次要分组里选中节点，就假定所有请求都会使用它，不同规则可能指向不同分组。

随后点击该组的延迟测试或连接测试按钮，等待结果完成。显示超时的节点先不要用于首次验证，可以换一个再测。测试结果只是客户端对指定测试地址的一次探测：较低的延迟不等于所有网站下载都快，测试成功也不等于账户流量、目标网站和整条线路都正常。测试一直失败时，先确认订阅有效期和服务状态，再看节点延迟与超时说明。

日常使用中，如果某个网站没有按预期走代理，先查看连接记录里命中了哪条规则，再决定是否修改分流。临时切换全局可以帮助判断，但测试结束应切回规则模式；全局也不能保证覆盖未被接管的程序，或解决节点本身不可用的问题。规则、策略组与节点的区别可在术语表查阅，本教程先保持“规则模式加一个明确出口”的简单组合。

到这里，客户端已经知道使用哪份配置、按什么模式处理请求，以及主要策略组选择哪个出口。下一步才是让系统或应用把网络请求交给客户端。先记住当前模式和节点，后续测试时不要同时更换节点、切换模式和调整 DNS，否则即使恢复连接，也很难判断真正有效的是哪一项。

第三步：启动服务并接管连接

先回到客户端主页，检查内核或服务状态。某些客户端打开后就会运行内核，另一些需要点击“启动”或连接按钮。这里应看到运行状态，且没有端口占用、配置加载失败等错误。如果内核还没正常启动，先不要开启系统代理，否则应用可能被指向一个没有响应的本地端口，表现为原本能打开的网站也无法访问。

在 Windows、macOS 和 Linux 桌面端，首次测试可以先开启“系统代理”。这一开关会修改系统代理设置，让遵循该设置的浏览器和应用把请求交给本地客户端。开启后新开一个浏览器标签页进行测试。若系统要求确认修改网络设置，核对请求来自正在使用的客户端，再按提示授权；不要把关闭系统防护作为固定安装步骤。

系统代理不能覆盖所有软件。部分游戏、命令行工具以及自行指定代理的应用可能忽略系统设置，所以浏览器已经生效，而另一个程序没有变化，并不一定是节点失效。先完成浏览器验证，再考虑该程序是否需要单独设置代理，或改用 TUN。命令行的代理环境变量与系统代理不是同一项设置，不要为了这次浏览器测试额外修改它们。

Android 和 iOS 通常在点击“连接”后弹出系统 VPN 授权提示。确认应用身份后允许建立连接，再回到客户端观察状态。系统的 VPN 标记可以说明通道已建立，但不能单独证明节点能访问目标网站。若设备已经连接其他 VPN，应先断开再测试；工作资料、设备管理策略或系统的始终开启 VPN 设置，也可能限制新的连接。

当桌面应用确实不遵循系统代理时，可以在客户端中查找“TUN”“虚拟网卡”或类似入口。TUN 通过虚拟网络接口接管流量，通常涉及服务安装、路由和额外权限。按当前客户端说明完成授权即可，不要把其他教程里的网卡名称、路由命令或 DNS 参数直接照搬到本机。Linux 上的权限要求、macOS 的网络授权以及 Windows 的服务状态，应结合平台分别检查。

如果开启 TUN 后整个网络异常，先关闭 TUN，检查普通直连能否恢复，不要继续叠加新的 DNS 或路由配置。需要深入处理虚拟网卡、权限和解析接管时，转到完整文档的对应平台章节。本步完成时，应只留下清楚可辨的连接方式：桌面端系统代理，或已经正确授权的 VPN／TUN 接管。

第四步：验证流量路径与退出恢复

连接按钮显示已开启后，不要只看图标颜色就结束。先在浏览器中新开标签页，访问一个你明确希望通过代理访问、且本身服务正常的网站。尽量使用新请求，避免把已经加载的页面、离线缓存或旧连接当成测试结果。随后回到客户端打开“连接”或 Connections 页面，找到刚才访问的域名。

展开这条连接，核对目标域名、命中规则、策略组与最终出口。不同客户端展示的字段多少不同，有的会显示完整策略链，有的只显示最终节点。若记录最终指向所选代理节点，且网页能正常加载，说明这条请求的接管与代理链路基本正常；若显示 DIRECT，则需要结合你的规则判断，这可能是预期直连，也可能是分流与预期不符。

如果网页能打开，但连接列表里始终找不到对应请求，先确认列表没有开启过滤、暂停刷新或只显示特定进程，再重新访问页面。仍然没有记录时，应回到第三步检查应用是否遵循系统代理，或 VPN／TUN 是否真正建立。不要仅凭页面可访问就认定代理生效，因为目标网站也可能原本就可以直接连接。

接着访问一个预期直连的常用网站，同样观察记录。在规则模式下，两个网站走不同出口是正常现象。若使用出口 IP 查询页面做辅助对照，应先确认该查询请求本身走的是代理还是直连；查询结果只能代表那次请求，不能证明整台设备的所有应用都经过同一出口。分享结果截图时，也应遮住自己的地址、订阅信息和账户内容。

出现“记录走了代理但网页失败”的情况时，先换一个目标网站，再换一个节点，每次只改一项。多个网站都失败而节点测试也超时，优先检查节点和服务状态；只有单个网站失败，则可能与该网站限制、节点出口或规则有关。页面能加载但某些资源失败时，查看失败资源的连接记录比反复切换全局更有帮助，进一步原因可到常见问题按现象查找。

完成访问测试后，再做一次退出检查。桌面端先关闭系统代理或 TUN，移动端点击断开连接，然后确认普通网站仍能访问。桌面端不要在系统代理尚未恢复时直接强制结束进程；如果退出后浏览器仍连不上，检查系统网络设置中是否残留指向本地客户端的手动代理。恢复时只修改本次客户端设置的项目，不要误删单位或学校要求保留的代理配置。

最后记下可用的配置名称、接管方式和当前策略组选择，后续遇到问题就能回到这组已验证的设置。订阅更新后如果表现发生变化，也先核对当前配置和组内选择是否被重置。需要配置自动更新、DNS、规则集或各平台后台权限时，继续阅读完整文档的配置常见问题，不必在首次连接阶段一次改完所有高级选项。