Clash 订阅导入与连接教程

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

打开客户端，在侧栏或底部导航找到“配置”“订阅”或“Profiles”。进入后选择“新建”“添加”或“导入”，再选择“从链接导入”。将完整订阅地址粘贴到地址栏，检查首尾是否混入空格、换行或聊天软件附带的说明文字。若有名称栏，可以填写便于辨认的名称，例如“日常订阅”，随后点击“下载”“保存”或“导入”。

这里需要填写的是订阅地址，不是服务商首页、账户管理页面或单个节点的分享文本。有些服务提供方同时提供多种格式，请选择明确标注 Clash 或与当前客户端兼容的配置入口。不要通过改动链接中的参数来猜测格式；不确定时，回到服务提供方的订阅说明确认。

等待下载完成后，配置列表里应出现一张配置卡片或一条订阅记录。部分客户端导入后只保存文件，不会自动切换使用。点击这条记录上的“使用”“启用”或选择按钮，确认它出现选中标记。随后打开“代理”页面，正常情况下会看到策略组以及节点名称；这比仅看到“导入成功”更能说明配置已经被当前内核读取。

已有配置文件时怎么操作

如果拿到的是本地配置文件，在同一个导入入口选择“从文件导入”，找到对应的 .yaml 或 .yml 文件，再将它设为当前配置。文件扩展名本身不能保证内容正确，客户端仍需成功解析。若文件只包含部分配置片段，而非完整配置，直接导入可能无法运行，应先确认文件用途。

链接订阅通常可以在配置列表中手动更新，本地文件则不一定具备远程更新地址。首次连接成功后，再按服务提供方的说明设置更新周期。不要为了等待新节点反复删除、重新添加同一订阅；通常先尝试记录上的“更新”按钮即可。更新失败时也先保留当前仍可用的配置，避免把可用状态一并清掉。

导入失败时先停在哪一步

若提示超时，先确认设备能够访问订阅地址，并检查链接是否过期。若提示解析错误，可能拿到了网页内容、格式不匹配或不受当前内核支持的配置。此时不要急着修改代理模式，因为模式无法修复配置解析问题。订阅地址打不开与节点连接失败是两个不同环节，详细原因可到常见问题继续排查。

本步完成标志：配置已被选中，代理页面能够显示策略组或节点。保持这份配置启用，下一步再决定流量按什么方式转发。

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

回到客户端首页或设置页，找到“代理模式”“运行模式”或“Mode”。首次使用建议选“规则”。这时连接会按当前配置中的规则逐条匹配：有的交给代理策略组，有的直接连接，也可能有规则用于拒绝请求。实际走向取决于配置内容，并不是所有规则配置都采用同一套分流安排。

然后进入“代理”“策略组”或“Proxies”页面。组名由订阅作者定义，可能是英文，也可能是用途名称，不一定都叫“节点选择”。找到配置默认使用的代理选择组，展开后选一个节点。如果组里列出的是另一个策略组，继续查看它的选择，直到确认最终会使用哪个节点，或由哪个自动选择组负责决定。

客户端有“延迟测试”或“测速”按钮时，可以先运行一次，等待结果再选节点。这里的数字通常反映到测试地址的响应时间，不等于下载速度，也不保证所有网站都能访问。超时表示这一次测试没有成功返回，可能与节点、测试地址或当时网络有关。先选一个测试有响应的节点，后面仍要用真实访问验证。

规则、全局、直连分别用于什么

规则模式适合日常使用，按配置决定各个请求的去向。全局模式会让进入内核的连接统一交给全局策略，切换后通常还需要在全局组中选好节点。它不会自动接管所有应用；没有进入内核的流量，仍然不受这个模式控制。直连模式则让进入内核的连接直接连接目标，不使用代理节点转发。

如果某个页面在规则模式下打不开，可以临时切到全局并选定同一个可用节点，重新访问作对照。全局正常而规则异常时，应检查规则匹配和策略组选择，不必马上更换整个订阅。测试结束记得切回规则，避免原本计划直连的流量也走代理。三种模式的更多差异放在常见问题中，本页先保留最短操作路径。

已有浏览器连接不一定会跟随模式切换立即重建，因此调整后最好关闭测试页面再重新打开。如果客户端提供“关闭现有连接”功能，也可以在确认不会打断重要任务后使用。不要只看顶部模式文字改变，就认为此前所有连接都已经改道。

本步完成标志：模式停在“规则”，实际使用的代理策略组已有明确选择。此时只是准备好了转发方案，还需要让系统或应用把流量交给客户端。

第三步：开启连接与系统接入

先看客户端首页是否显示内核已启动或服务正在运行。如果启动失败，先处理客户端给出的端口占用、权限或配置错误提示，再开启系统接入。只启动内核不等于浏览器已经走代理；内核运行和系统把流量交给内核，是需要分别确认的两件事。

桌面端：先开启系统代理

在 Windows、macOS 等桌面客户端中，找到“系统代理”“设置为系统代理”或相近开关并打开。常见浏览器会读取系统代理设置，无需首次使用就手动填写端口。若系统弹出网络设置或辅助服务授权，核对申请来自正在使用的客户端后再确认。不同客户端的启动按钮可能会合并开启内核与设置代理，仍应查看两项状态。

Linux 桌面环境和部分应用对系统代理的支持不同；某些客户端需要手动设置桌面环境代理，浏览器也可能有独立代理配置。如果浏览器安装过代理扩展，先停用扩展或改为跟随系统，避免它覆盖刚刚启用的设置。终端、游戏和部分商店应用也可能不遵循系统代理，浏览器能访问并不代表这些应用会自动采用同一路径。

首次设置先不要同时开启 TUN。系统代理更容易观察和恢复，适合先确认订阅与节点可用。只有明确需要接管不读取系统代理的应用时，再按配置进阶了解 TUN 的权限、路由和 DNS 条件。TUN 与全局模式不是同一个选项：前者涉及流量怎样进入内核，后者决定进入后怎样转发。

手机端：确认 VPN 连接授权

在 Android 或 iOS 客户端中，点击首页的“连接”“启动”或电源形按钮。首次运行时，系统通常会要求允许建立 VPN 连接或添加 VPN 配置。确认授权后返回客户端，等待状态变为已连接，并查看系统状态栏或系统 VPN 设置中的连接状态。系统使用 VPN 通道把流量交给客户端，不代表订阅节点一定可用，仍需执行最后的访问验证。

如果手机已经运行其他 VPN、代理或使用 VPN 通道的网络工具，先断开再连接当前客户端；能否并存取决于系统和应用实现。Android 若很快在后台断连，可先保持客户端在前台完成测试，确认基础功能正常后再排查电池优化与后台限制。不要一开始同时修改省电、DNS 和节点参数，否则很难判断哪一项起了作用。

本步完成标志：桌面端内核运行且系统代理已开启，或手机端已经完成 VPN 授权并显示连接。保持客户端运行，接下来用页面访问与连接记录共同确认结果。

第四步：验证访问与实际流量走向

重新打开浏览器，先访问一个平时能够直接打开的网站，确认基础网络没有被打断；再访问一个预期需要代理的目标，例如在当前网络条件下需要代理才能稳定访问的 GitHub 页面。不要把某个站点当作所有环境都通用的测试标准，目标本身的可用性、账户限制和地区服务策略也会影响结果。

测试时，同时打开客户端的“连接”“Connections”或日志页面。新建连接通常能看到目标域名或地址、匹配规则与策略链。找到刚访问的目标，确认它究竟走了节点还是直连。部分客户端需要进入连接详情才能看到完整策略链；如果页面已加载但列表没有新记录，先重新发起请求，并确认列表没有被筛选条件隐藏。

判断时把现象连起来看：页面能够打开，连接详情也显示使用了预期策略，才是比较明确的生效证据。仅看到流量数字增加不够，因为后台应用也会产生请求；仅看到页面能打开也不够，它可能本来就可以直连，或者读取了缓存。必要时换一个新的页面路径，再观察对应的新连接。

结果不符合预期时怎么回查

如果完全看不到浏览器的新连接，先回到第三步检查系统代理、浏览器扩展或手机 VPN 状态。若有连接记录但显示直连，而目标本应使用代理，就回到第二步检查规则模式与策略组；这通常属于分流方向问题。若记录显示使用了节点，却持续连接超时，先换一个节点再测试，不要立刻改动 DNS 和 TUN。

如果所有节点都失败，检查订阅账户是否仍有效、当前网络能否正常联网，并留意客户端日志中反复出现的具体错误。日志可能包含访问域名、节点地址或订阅信息，向他人求助前先遮盖敏感内容。进一步排查请看常见问题；需要调整 DNS、Fake-IP、规则集和外部控制面板时，再进入配置进阶逐项查阅。

确认正常后的日常操作

连接验证通过后，保留规则模式和当前可用的策略组选择，再按需要设置订阅更新。以后更换网络、更新配置或切换节点后，可以重复“打开页面、查看新连接”这组检查，不必每次重新走完整安装流程。遇到问题时一次只改一个设置，记下改动前的值，结果不好就恢复，排查会更清楚。

需要结束使用时，桌面端先关闭系统代理，再退出客户端；手机端先点击断开，确认系统 VPN 已停止。若异常退出后普通网页打不开，优先检查系统是否还保留着指向本机的代理设置。自动恢复行为因客户端而异，主动确认一次比反复重启浏览器更直接。

本步完成标志：基础网页正常，测试目标可以访问，连接记录与预期策略一致。到这里，订阅、模式、系统接入和连接验证四个环节已经闭合，后续只在遇到具体需求时增加进阶设置。