使用指南 / 首次配置
Clash 订阅与连接教程
导入订阅 → 选择代理模式 → 开启连接 → 验证生效
已安装客户端且订阅可用时，可按这条约十分钟的操作路线完成首次连接。先跑通浏览器访问，再处理应用接管、自定义规则和 TUN；每次只改变一项设置，便于判断结果。
01 导入订阅并启用配置
打开客户端，进入“配置”“订阅”或 Profiles 页面。找到“新建”“添加”或“从 URL 导入”入口，选择远程订阅类型，将已有地址完整粘贴到地址栏。若同时提供名称和地址输入框，名称可写成容易辨认的用途，例如“日常配置”；地址栏只放订阅链接，不要混入说明文字、引号或聊天软件附带的标点。
点击下载、导入或保存后，等待配置出现在列表中。正常情况下，配置卡片会显示名称，并能在代理页面读取到代理组或节点。仅出现一张同名卡片，并不等于远程内容已经成功下载；继续查看是否有下载失败、解析失败或内容为空的提示。界面提供刷新按钮时，可手动更新一次，确认订阅地址确实能返回客户端支持的内容。
将导入的配置设为当前配置
有些客户端导入后立即启用，有些需要点击配置卡片，再选择“使用”“激活”或类似操作。检查当前配置标记是否落在刚导入的条目上，随后打开代理页面。若仍显示旧配置的分组名称，先重新选择配置并等待内核载入，不要直接删除其他配置。保留原有可用配置，便于失败时退回。
本地文件则使用“从文件导入”入口，选择实际保存的 .yaml 或 .yml 文件。完整配置一般包含代理、代理组与规则等内容；单独一段节点列表不一定能直接作为完整配置运行。文件扩展名也不能证明内容正确，将网页另存为 YAML 并不会完成格式转换。需要区分这些概念时，先查阅名词解释中的订阅与配置概念。
导入失败时先检查输入与格式
“请求失败”与“解析失败”应分开处理。请求失败通常需要核对地址是否完整、订阅是否有效，以及当前网络能否访问订阅服务器。解析失败则应确认链接输出的是 Clash 或 mihomo 支持的配置，而不是账户登录页、错误提示页或只适配其他客户端的节点文本。若服务方提供格式选项，使用与当前客户端内核匹配的格式重新导入。
不要为了让订阅“看起来能导入”而把完整地址交给不熟悉的转换服务。也不要在此阶段调整 DNS、端口和 TUN：配置内容尚未载入，这些开关不能修复订阅格式。确认代理组已经出现后，再进入下一步；自动更新间隔可在连接成功后设置，首次配置不必立即添加复杂的更新任务。
02 选择规则模式与节点
配置载入后，回到首页、仪表盘或模式菜单，找到“规则”“全局”“直连”三种模式。首次使用先选择规则模式。它让已经进入内核的连接按配置中的规则选择策略：有的目标直连，有的目标交给代理组。这样可以保留订阅原有的分流设计，也方便后面通过日志核对命中结果。
全局模式适合临时对照测试，它会将进入内核的流量交给全局策略选择器；需要在全局组中另选可用节点。直连模式则让进入内核的连接直接访问目标。注意，模式决定流量进入内核之后如何处理，不决定哪些应用会进入内核。切换成全局并不意味着设备上的所有程序都已被接管，系统代理或 VPN 等入口仍须单独开启。
找到规则实际引用的代理组
进入“代理”或 Proxies 页面，先看分组而不是逐个点所有节点。常见的主选择组可能叫 PROXY、节点选择或其他名称，具体以订阅定义为准。展开这个组，查看当前选中的是节点、自动选择组，还是 DIRECT。若组内还有下级组，应继续确认下级组的选择，直到能理解最终连接会走向哪里。
对候选节点执行一次延迟测试，等这一轮测试完成后再选择。手动选择组中，点击节点通常会出现选中标记；自动选择组则可能由内核按测试结果决定，手动点击后的行为取决于组类型。首次验证可先用手动组固定一条可用线路，减少自动切换对排查的干扰。若需要了解 select、url-test 等类型，转到代理组术语说明，不必现在修改配置。
测试可达不等于实际访问成功
延迟测试通常测量节点访问指定测试地址的响应情况，并非本机到所有网站的完整体验。出现数值只能说明这次探测得到了响应，不能据此判断下载速度、目标网站权限或所有协议都可用。超时也应先更换少量候选节点作对照，不要连续高频测试全部节点。若每条线路都失败，先检查设备时间、订阅状态与当前基础网络。
选定节点后保持规则模式不变，记住当前主组和节点名称，下一步再开启流量入口。此时代理页能够测试成功，而浏览器出口仍未改变，可能只是系统代理尚未启用，并不矛盾。节点测试由客户端发起，浏览器访问则取决于浏览器实际采用的网络入口。
03 开启连接与流量入口
先确认客户端没有显示内核启动失败或配置载入错误。部分桌面客户端打开后就会运行内核，另一些需要点击启动或连接按钮。运行内核只是提供本地代理服务；要让浏览器使用它，还需要把系统或应用的网络请求送到相应入口。首次配置先退出其他正在修改系统代理或建立 VPN 通道的软件，避免多个程序互相覆盖设置。
桌面端：开启系统代理
在客户端首页或设置页面找到“系统代理”，将其开启。它通常会把系统的代理地址指向本机监听端口。若浏览器没有独立代理设置，通常会跟随该系统设置。保持客户端运行，然后打开一个新的浏览器标签页访问测试目标。不要只刷新已经缓存完成的页面，因为没有新请求时，连接列表里可能看不到对应记录。
首次配置建议保留客户端默认端口，不必照抄其他教程里的数字。不同客户端可能使用不同的 HTTP、SOCKS 或混合端口。如果之前在浏览器扩展、终端环境变量或应用内手动填写过代理，请先暂时停用这些单独设置，再测试系统代理。确实需要手动填写时，应以当前客户端显示的监听地址和端口为准，详细对应关系见端口设置说明。
部分应用不会读取系统代理，因此浏览器能访问而某个应用没有连接记录，不一定是节点故障。先完成本页验证，再考虑应用内代理或 TUN。涉及 Windows 商店应用的情况，可查阅UWP 回环处理；不要在首次连接阶段同时启用多种接管方式。
移动端：确认系统 VPN 授权
在移动客户端中选择好配置和节点后，点击连接或启动。首次运行通常会出现系统 VPN 配置或连接授权提示，确认应用来源与名称后按系统提示允许。返回客户端，查看是否已进入运行状态，并结合系统的 VPN 状态确认通道已经建立。这里的 VPN 通道是客户端接收设备流量的方式，不代表节点一定可以访问目标网站。
若系统已有其他 VPN 连接，先停止它，再启动当前客户端。Android 的省电策略可能影响后台持续运行，首次测试时先让客户端保持前台或正常驻留，不要边测试边强制清理后台。iOS 的授权流程与 Android 不同，应按系统实际弹窗操作，不需要寻找桌面端的“系统代理”开关。
首次连接暂不叠加 TUN
TUN 可以处理更多不遵循系统代理的流量，但也会涉及虚拟网卡、路由、权限和 DNS。若浏览器验证已经成功，后续确有其他应用接管需求，再参考新手到进阶手册中的 TUN 章节逐项开启。若刚启用 TUN 就出现异常，应先退回刚才已经验证成功的入口，而不是同时修改规则与 DNS。
04 验证代理是否真正生效
保持刚才的节点和模式，先打开客户端的“连接”页面，再在浏览器新标签页访问一个已知目标。回到连接列表，寻找刚发起的目标域名或目标地址，查看匹配规则、所用策略组与最终节点。不同客户端的字段名称不同，重点是把“访问了什么”“命中了什么”“最终走哪里”连起来看，而不是只看首页的运行开关。
用连接记录确认分流路径
在规则模式下，出现 DIRECT 是正常结果之一。例如目标命中直连规则时，它就不应该经过刚选的代理节点。若本来希望代理的目标命中了直连规则，先检查当前配置和模式是否正确，再看规则命中原因。不要直接删除大量规则；如果只是订阅默认策略与需求不一致，连接成功后可按自定义规则说明使用客户端支持的覆写或合并功能调整。
如果访问没有产生任何新记录，先确认连接列表未被筛选，也没有因请求结束而迅速移除记录；可配合日志页查看。仍然找不到请求时，重点回查系统代理、应用独立设置和 VPN 通道，而不是反复更换节点。请求已经进入内核但报错时，再根据日志区分解析失败、连接超时或目标拒绝。分享日志前应移除订阅地址、认证信息和不必要的访问记录。
用出口 IP 辅助验证
在浏览器访问常用的出口 IP 查询页面，记录结果，并与连接页显示的策略对应。规则模式下，查询页面本身可能命中直连，因此显示本地出口不能单独证明代理失效。需要对照时，可临时切换全局模式，在全局选择器中明确选中同一条可用节点，重新发起查询，同时核对连接记录是否实际走了该节点。
完成对照后切回规则模式。出口 IP 的地区显示可能受数据库更新影响，不能单凭地区名称判断节点是否正确；更可靠的是结合最终节点、请求结果与出口变化共同判断。也不必把一次网页加载速度当成长期线路质量结论，先确认路径正确，再观察日常访问表现。
连接失败时按层回退
浏览器完全无法打开网页时，先关闭系统代理，或在移动端停止当前 VPN 通道，确认基础网络本身能否正常访问。如果停止客户端后网络恢复，继续按“配置是否载入、节点是否可达、入口是否正确、规则是否符合预期”的顺序检查。每次只改一项并重新发起请求，这样才能知道哪一步改变了结果。完整排查路线见连接检查手册。
验证成功后，记录当前可用的配置名称、入口方式与主组选择，再设置适当的订阅自动更新。远程订阅更新可能替换原始配置，长期自定义内容应放在客户端支持的持久化位置。平时退出桌面客户端前先关闭系统代理，或确认客户端会自动恢复系统设置，避免代理地址仍指向已经停止的本地服务。