Clash 使用教程
订阅导入与连接验证

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

打开客户端，进入“配置”或“订阅”页面。桌面端通常提供订阅地址输入框，也可能需要先点击“新建”或“导入”；手机端一般从页面右上角的加号进入。选择 URL 或远程配置类型，将完整订阅链接粘贴进去，再点击“导入”或“保存”。如果有名称字段，可填写便于区分的本地名称；名称只用于识别配置，不会改变订阅内容。

粘贴时确认链接前后没有多余空格、换行或聊天软件附带的标点。应使用配置提供方明确标注为 Clash 或 mihomo 兼容的地址，而不是账户主页、购买页面或订阅管理网页。有些地址需要在账户页复制专用的订阅入口，浏览器地址栏中的当前页面并不能代替订阅链接。也不要仅凭链接后缀判断格式，订阅响应可以由服务器动态生成。

提交后等待下载与解析完成。成功时，配置列表会新增一项，客户端可能显示更新状态或提供刷新按钮。随后点击这张配置卡片，或使用“启用、设为当前配置”等操作，确认当前标记已经切换过去。部分客户端在导入后会自动选中，另一些只负责保存；如果只完成了导入而没有启用，代理页面仍可能显示旧配置中的策略组。

本地 YAML 文件的导入方式

如果拿到的是文件，改用“从文件导入”入口，选中保存在设备上的 YAML 文件，再将其设为当前配置。手机端可能先打开系统文件选择器，需要找到实际保存目录，而不是选中文件的截图或聊天记录。离线导入的普通本地配置不会自动获得远程订阅地址；后续是否能够更新，取决于文件内的资源引用和客户端提供的管理功能。

若导入时出现解析错误，先核对提供方交付的格式。Base64 节点列表、单条协议链接和完整 Clash 配置并不是同一种内容，不能默认相互替代。优先索取兼容格式，不要为了转换而把含凭据的订阅提交到不明服务。有关格式的进一步区别，可查阅术语手册；本教程先以能够成功载入的配置继续。

第二步：选择规则模式与代理策略

配置启用后，进入“代理”页面，找到“规则、全局、直连”运行模式。初次使用先选“规则”。该模式按照当前配置中的规则决定连接去向：有的请求直接连接，有的请求交给指定策略组。模式名称相同并不表示所有配置的行为完全一致，具体分流结果仍由当前加载的规则和策略组决定。

接着查看页面中的策略组。组名由配置定义，可能按用途或地区组织，不必与教程中的叫法一致。找到承担主要代理出口的选择组，点击展开其选项，再选择配置提供方确认可用的代理。若已有“自动选择”一类策略，也可以选用，但应确认它确实包含候选代理，而不是空组。修改后通常会立即生效，不需要重新导入整份订阅。

需要注意，策略组允许引用其他策略组。外层选择了某个自动策略，并不意味着最终出口已经固定；实际使用哪个代理，要看内层选择或自动测试结果。如果页面显示当前选项为 DIRECT，表示该策略走直连，并不等于代理连接成功。先确认主要策略组的指向，后续再用连接记录验证实际路径，比只看一个延迟数字更可靠。

规则、全局与直连的区别

选择模式只影响已经交给内核的请求，不会自动让所有应用进入代理。尤其是桌面端，选好“规则”后还需要完成下一步的系统代理设置。全局模式也不等于全设备流量接管，未经过客户端的程序仍可能直接连接网络。把“请求是否进入内核”与“进入后采用哪条策略”分开理解，能减少后续排查时的误判。

此时先保留订阅已有的 DNS、规则和端口设置，不要同时添加复杂覆写或切换 Fake-IP。等基本连接验证通过，再按实际需要调整。规则匹配顺序、策略组类型及配置文件写法属于进一步维护内容，可在完整手册中继续查阅。

第三步：开启系统代理或手机端连接

现在配置与策略都已确定，需要把应用请求交给客户端。先回到首页或运行状态页，确认内核已启动，且没有反复退出、配置加载失败或端口占用提示。有的客户端启动应用时就会运行内核，有的需要点击“启动”；应以状态页和日志为准。接下来按设备选择一种接管方式，初次配置不要同时开启多种方案。

Windows 与 macOS：先使用系统代理

进入客户端首页或设置页，开启“系统代理”。这一开关通常把系统代理地址指向本机内核监听端口，使遵循系统代理设置的浏览器和应用转交请求。启用后返回浏览器，重新打开页面；已有长连接可能继续沿用旧路径，因此仅刷新某个正在播放的页面，不一定能反映刚才的设置变化。

若客户端提示端口被占用，先检查是否还有另一个代理客户端运行，或曾经手动设置过系统代理。暂时退出其他同类客户端后再试，不要直接结束不认识的系统进程。需要修改端口时，客户端监听端口与系统代理填写的端口必须一致；本教程不要求把端口改成某个固定数字。应用内单独设置了代理的程序，还需要检查其自身的网络选项。

Android 与 iOS：确认系统连接授权

在客户端首页点击“启动”或“连接”。首次使用通常会出现系统 VPN 连接或添加 VPN 配置的确认框，阅读授权内容后允许；某些设备还需要输入设备解锁信息。完成后回到客户端，确认连接状态已开启，并检查系统网络状态中的 VPN 标识。这里的系统授权用于建立本机流量接管通道，不能单凭标识判断远端代理是否可用。

如果设备已经连接其他 VPN，先断开已有连接，再启动当前客户端。Android 的应用分流设置可能只允许部分应用经过通道，测试浏览器也必须包含在接管范围中。手机端若出现启动后立即断开，应先看授权是否完成、配置是否能加载，再检查系统后台限制；不宜一开始就把所有电池管理和网络设置全部修改。

Linux 与 TUN 的处理边界

Linux 桌面环境对系统代理的支持存在差异。如果客户端没有自动写入桌面设置，需要在桌面网络设置中按客户端实际监听地址与端口配置代理；终端程序还可能要求单独设置代理环境变量。不要把浏览器能够访问视为整个系统都已接管，先用本次准备测试的应用完成基础验证。

TUN 是另一种接管方式，可能涉及服务安装、管理员权限、路由和 DNS。第一次操作建议先完成系统代理路径；只有需要覆盖不遵循系统代理的应用时，再了解 TUN 的设置。不要因某个程序没有变化就立即同时开启 TUN、全局模式和 DNS 覆写，否则很难判断到底哪项改动起作用。相关区别可在疑难解答中查询。

第四步：用连接记录验证是否生效

保持客户端运行，在浏览器打开一个准备通过代理访问的网站，同时打开客户端“连接”页面。建议新建标签页并重新发起请求，避免把缓存内容误认为新的网络访问。找到与测试网站对应的域名或目标地址，查看连接详情中的匹配规则、策略组和实际代理链；不同客户端显示字段略有差异，但核心是确认请求进入了内核，以及最终被交给哪个出口。

如果记录显示请求命中了预期规则，并使用了刚才选择的代理，且网页能够完成加载，便完成了一次基本代理验证。随后访问一个按照配置应当直连的网站，再看是否走向 DIRECT。规则模式下出现直连记录是正常结果，不能把它视为“代理没有开”。这里同时检查代理与直连，是为了确认配置分流，而不只是证明某一个网页可以打开。

也可以使用可信的公网出口查询页面作辅助对照，分别记录开启与关闭接管时的出口变化。但浏览器出口变化只能说明该次请求的路径，不代表所有应用都经过相同代理，更不能单独证明 DNS 行为符合预期。有关 DNS 接管与泄漏的详细验证，另见完整手册的 DNS 章节，本次先完成连接链路检查。

没有达到预期时的检查顺序

若网页打不开，先看连接列表有没有出现该请求。完全没有记录时，优先检查系统代理是否开启、手机端连接是否保持，以及浏览器是否被应用分流排除。能看到请求但走向直连时，再检查当前模式、命中规则和策略组选择。已经选到代理却报连接错误时，再核对代理可用性、订阅状态和本地网络。按这个顺序可以把接管、分流与出口故障分开。

某些客户端提供“延迟测试”或“连通性测试”，可以用来筛选候选代理，但测试目标与网页的实际目标不同。测试成功不保证所有网站都能访问，测试失败也应结合日志中的错误判断。若需要比较不同代理，保持同一测试网站和相同模式，每次只切换一个选项。关于测试结果的解释，参见节点延迟相关问题。

最后检查退出行为。完成测试后，可以先关闭系统代理或手机端连接，再正常退出客户端，确认原本能够直连的网站仍可打开。若桌面端关闭客户端后网络异常，检查系统设置中是否残留了指向本机的代理地址；手机端则确认 VPN 已断开。不要在内核已经停止的情况下继续让应用连接本机代理端口。

后续更新：订阅、规则与客户端分别维护

基础连接完成后，回到“配置”或“订阅”页面，对当前远程配置执行一次手动更新，确认地址仍然有效。若客户端支持自动更新，可在该配置的编辑入口设置合理间隔，并核对单位：界面可能使用分钟，配置资源字段则可能使用秒，不能把同一个数字直接照搬。关闭应用期间是否能定时更新，也取决于客户端是否仍在后台运行。

远程订阅刷新可能替换直接编辑的配置内容。需要长期保留的规则或设置，应先了解客户端支持的覆写、合并或扩展机制，而不是每次更新后重复修改下载文件。规则资源也可能有独立更新周期，刷新订阅不一定意味着所有资源都已重新拉取。内核与客户端升级则负责程序能力和兼容性，属于另一条更新链路。

后续调整时保留一个已验证可用的状态，每次只修改一项，出现异常便回到连接记录确认变化。接下来需要学习规则顺序、TUN、DNS 或持续覆写，可继续阅读从零到精通完整手册；遇到具体报错时按疑难解答定位；不熟悉的字段与术语可查术语手册，不必在初次配置阶段一次性修改全部设置。