Clash 订阅导入
与代理配置教程

第一步：导入订阅并选中配置

打开客户端，进入“订阅”或“配置”页面，找到“新增”“导入”或带加号的入口。若入口区分远程地址与本地文件，先按手里的材料选择：复制来的订阅 URL 用远程导入，保存在电脑中的 .yaml 或 .yml 文件用本地导入。不要把文件内容整段粘进网址输入框，也不要把一个网页链接改名后当成 YAML 文件导入。

使用远程订阅时，回到服务提供方的订阅页面，选择明确标注 Clash 或 mihomo 的格式，再复制完整地址。粘贴后检查开头、结尾和中间参数，尤其不要漏掉问号后面的内容。有些页面把多个客户端格式放在一起，普通节点分享链接未必能直接作为 Clash 配置使用；若页面只有二维码，先确认客户端是否支持扫码导入，不必反复尝试不对应的入口。

为配置填写一个便于识别的本地名称，例如“日常连接”，然后执行导入或保存。等待请求完成，查看是否显示更新成功，以及是否出现代理组、规则或节点等配置内容。配置列表多出一个名称，只能说明条目已经创建；还要确认它能被解析，并被选为当前使用的配置。部分客户端用勾选标记表示当前项，另一些需要点击“使用”或“激活”。

使用本地文件时，点击文件导入入口，选择原始 YAML 文件，等客户端完成解析后再选中它。YAML 是一种依靠缩进表达层级的文本配置格式；首次使用不必直接编辑。如果客户端提示语法错误，先重新获取原文件，避免用富文本编辑器保存后引入额外字符。若文件引用了外部规则或代理集合，首次加载仍可能需要网络，因此“文件导入成功”不一定代表所有外部内容也已加载。

导入失败时，先看错误发生在哪一段：请求超时通常需要检查当前网络与订阅地址是否可达；返回网页或解析失败，则要检查复制的是否为订阅接口，而不是登录页、购买页或分享说明页。地址已过期、账户状态变化也可能导致更新失败。先在提供方页面重新复制地址，再重试一次，不要同时修改代理端口、DNS 和规则来碰运气。

订阅地址中的参数可能包含账户访问凭据。分享截图前遮住完整地址，不要把地址发到公开评论区，也不要交给来源不明的在线转换页面。后续需要刷新节点时，使用当前条目的“更新”功能即可；一般不必每次删除后重新创建配置。

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

确认配置已启用后，进入“代理”页面或找到“模式”选择项。首次使用先选“规则”，有些界面显示为 Rule。规则模式会读取当前配置中的匹配条件，再决定某个连接走直连、代理或其他策略。它适合保留日常网络的分流安排，也方便在下一步观察具体连接为什么走某条路径。

不要把“规则模式”和“选中节点”当成同一个动作。模式决定如何分配连接，代理组则决定分配到某个策略后使用哪个出口。打开代理组，查看组内是否提供可手动选择的节点、自动选择组或其他子组。组名由订阅配置决定，不一定叫“节点选择”；应找到配置用于常规代理流量的选择组，再选中一个可用选项。

如果组内有手动测试或延迟测试按钮，可以执行一次，用来检查该测试目标是否能通过对应节点建立连接。测试有结果后，点击节点，使它出现选中标记。不要只点测试按钮就离开：测试完成与实际选中是两个操作。自动选择组通常会按配置里的测试条件挑选出口，首次使用可以保留其默认行为，不必立刻调整测试间隔或容差。

全局模式通常把被客户端接管的连接交给全局策略处理，适合在规则结果不符合预期时做短时对照；它不会自动让所有应用开始使用代理。直连模式则通常让被接管的连接直接访问目标，并不能用来验证代理节点是否正常。如果切到全局做测试，还要检查全局策略实际选中了什么，不能仅凭模式名称判断出口。

先保留配置原有的规则与代理组关系。不要为了让某个网站使用代理，就把所有带 DIRECT 的选项都改掉；DIRECT 表示直连，可能是规则有意保留的路径。若某个应用有单独的策略组，也不必在首次连接时逐一调整。先用一个浏览器目标跑通主路径，之后再处理特定应用的分流需求。

此时回看代理页面，应能确认当前处于规则模式，而且实际被规则引用的选择组已经有选中项。如果节点测试全部失败，先换一个节点再试，并检查订阅服务状态；重复切换模式通常不能修复不可达的节点。规则优先级、嵌套代理组等细节留到 安装大全 查阅，本轮先保持配置结构不变。

第三步：开启流量接管

配置和节点准备好后，再开启接管开关。在 Mac 客户端的首页、设置页或菜单栏中找到“系统代理”，先确认内核没有报错，再将它打开。内核是实际处理连接的后台组件；客户端窗口能打开，不代表内核一定已经正常运行。若页面显示启动失败或端口占用，先处理这条错误，不要继续开启更多网络功能。

系统代理会向 macOS 写入代理设置，让遵守这些设置的应用把请求交给客户端的本地监听端口。首次验证建议使用浏览器，因为它更容易与连接记录对照。开启后不需要再手动把同一地址填进浏览器代理扩展；若扩展已经配置了独立代理，先停用它或切回使用系统设置，以免两套设置互相覆盖。

保持系统代理开启，回到浏览器新建一个页面，发起一次访问。不要只盯着客户端开关判断连接是否建立，也不要急着同时开启 TUN。系统代理只覆盖遵守系统设置的应用，一些终端工具、游戏或自带网络栈的程序可能不会使用它。因此浏览器可用、某个程序仍不可用时，先检查那个程序的代理支持，而不是认定整个配置失效。

如果确实需要接管更多应用流量，再考虑 TUN 模式。TUN 通过虚拟网络接口处理流量，覆盖范围通常比系统代理更广，但实际结果还受路由、排除项和 DNS 设置影响。桌面客户端可能要求先安装辅助服务或服务模式；按照客户端提示操作，核对系统授权窗口显示的程序，再完成授权。不要照搬网上的提权命令，也不必为了首次浏览器连接直接修改系统路由。

测试 TUN 时，先关闭系统代理，再启用 TUN 单独验证，有助于明确是哪一种方式在接管流量。若客户端说明要求两者配合，则以该客户端的当前说明为准。出现持续断网或域名解析失败时，先关闭刚开启的 TUN，恢复到先前可用的系统代理方案；不要在网络异常状态下连续叠加 DNS、路由和防火墙修改。

Windows 用户可以沿用“内核正常 → 开启系统代理 → 浏览器测试”的顺序，遇到特定应用不跟随设置时再查平台专有说明。Android 与 iOS 则通常在点击连接后弹出系统 VPN 授权，批准后再返回客户端确认连接状态。手机状态栏出现 VPN 标记，说明接管通道已建立，但并不能单独证明选中的代理节点可用。

连接期间尽量只保留一个负责接管流量的工具。公司 VPN、安全软件或其他代理客户端可能改变路由与 DNS，导致看似相同的操作得到不同结果；若设备有组织管理策略，应遵守其使用要求。更多辅助服务、权限与平台差异，按需查看 各平台安装配置说明。

第四步：验证代理是否生效

先打开一个在当前网络下已知能正常访问的页面，确认基础网络仍然可用。再打开一个预期由代理处理的目标页面，观察是否能完成加载。如果页面此前已经打开过，使用新的标签页或刷新后重试，避免把缓存内容误当成新的网络请求。无需一开始就做速度测试，先确认请求确实经过了预期路径。

同时进入客户端的“连接”“活动”或“日志”页面，找到刚才访问产生的新记录。能看到哪些字段取决于客户端和当前日志级别，通常可以对照目标域名、匹配规则与使用的代理链。预期走代理的请求若显示 DIRECT，应先检查命中的规则和代理组；若显示已选代理，但请求仍超时，再检查节点、目标站点和上游网络，而不是反复切系统代理开关。

连接记录比单独查看出口 IP 更适合解释规则模式下的结果。不同网站可能命中不同规则，IP 查询页面本身也可能被设置为直连，所以一次查询显示本地出口并不必然表示代理失效。若确需比较出口，应对同一个目标、同一种接管方式进行测试，并确认这条请求实际命中了代理策略。分享记录时遮住订阅地址、认证信息与不必要的访问记录。

若浏览器无法加载目标，按固定顺序逐项排查：先确认当前配置仍被选中，再确认代理组的选中项，接着确认内核运行与系统代理或 TUN 状态。随后换一个节点，重新发起访问并查看新记录。每次只改一项，记录改动后的结果；同时更换配置、模式、节点与 DNS，反而无法判断是哪一项造成变化。

若浏览器成功而终端或某个应用失败，先把问题限定到该应用。检查它是否支持系统代理、是否配置了独立代理，以及是否需要重启才能读取新设置。旧的长连接可能继续沿用原路径，因此切换节点后也应重新建立连接再观察。需要处理终端代理、应用排除或 TUN 的 DNS 问题时，转到 故障排查说明，不必把首次配置重新做一遍。

最后做一次退出检查。结束使用前，先关闭系统代理或 TUN，再退出客户端，然后打开普通网页确认网络恢复正常。多数客户端会在正常退出时清理设置，但异常退出后仍可能留下指向本地端口的代理项。若退出后无法联网，先重新打开客户端关闭接管；仍未恢复时，到 macOS“系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理”中检查相关设置，具体路径可能随系统版本变化。

首次配置完成后，保留这份已验证的配置，后续通过订阅条目的更新按钮获取变更。更新后若只有某个应用异常，先看对应的新连接记录，再决定是否调整分流。日常操作到这里即可；更换设备、部署 Linux 内核或深入理解规则时，再使用 安装大全 按章节查阅。