Clash 配置教程

开始前需要分清客户端与订阅的作用：客户端负责读取配置、执行规则和建立连接，订阅则提供可用节点、策略组以及可能附带的分流规则。安装完成不等于已经具备可用出口。请先从服务提供方的账户页面取得适用于当前客户端的订阅链接，确认服务仍在有效期内。网页分享地址、账户登录页和订阅地址不是同一种链接，不能互相替代。

打开客户端后，先进入“配置”或“订阅”页面，寻找“新建”“导入”或带加号的入口。如果界面要求选择类型，选择远程订阅或 URL 导入，再把链接完整粘贴到地址栏。名称只用于本地识别，可写成容易区分的用途名称；不要把订阅地址当作名称。检查链接开头和结尾是否混入空格、换行或聊天软件附加的标点，然后点击下载或导入，等待客户端完成请求。

成功后通常会出现一张配置卡片或一条订阅记录。部分客户端会立即启用新配置，另一些需要再点击“使用”“激活”或配置名称。请确认当前配置有选中标记，再进入“代理”页面查看是否出现策略组。仅看到导入记录不代表它已经生效；如果代理页仍是旧内容，先返回检查当前启用的是哪一份配置，不要连续重复导入。

如果服务提供方交付的是本地配置文件，则在同一位置选择文件导入，并使用客户端支持的 Clash 配置格式。文件扩展名相同不代表内容兼容：有些链接返回的是通用节点列表，有些返回完整 YAML，有些是其他客户端的专用格式。出现解析失败、字段不支持或协议无法识别时，优先核对订阅类型和内核要求，不要随意删掉报错字段，以免把有效配置改坏。

导入失败时先看配置页的错误提示，再到“日志”查看同一时刻的请求结果。认证失败通常需要检查账户状态或重新取得链接；请求超时则要区分当前网络问题与订阅服务器问题；解析错误更接近格式或兼容性问题。若更新订阅本身需要走代理，而当前又没有可用配置，会形成启动上的循环，此时应查阅服务提供方的首次导入说明，而不是反复切换不相关的 DNS 选项。

订阅地址常带有账户识别参数，应按敏感信息保存。向他人求助时只提供去除地址、节点凭据后的错误文本，不要直接发送订阅二维码或完整配置。完成本步后，代理页应能看到订阅带来的策略组；先保留原始配置和默认规则，下一步只调整模式与出口，避免同时修改过多变量。

配置加载后，在“代理”页面顶部、首页模式区域或系统托盘菜单中寻找模式选择。首次使用建议选择“规则”，它会按照当前配置从上到下匹配规则，再把连接交给对应策略。这样可以保留订阅原本设计的直连与代理分工。模式选择决定如何分配已经进入内核的流量，并不负责让所有应用自动接入客户端；流量接管要在下一步单独开启。

“全局”会把进入内核的连接统一交给全局策略，适合临时对照排查或明确需要统一出口的任务，但不意味着系统里所有程序都一定经过代理。“直连”则让进入内核的连接直接访问目标，适合暂停代理转发或进行故障对照。日常浏览不必为了省事长期保持全局，也不要把直连模式误认为退出了客户端；后台内核和系统代理设置可能仍然存在。

切到规则模式后，展开订阅中的主策略组。名称由配置作者决定，可能是“代理”“节点选择”或其他名称，并没有全客户端统一的叫法。先找规则实际引用的组，再选择其中一个节点。若选中的是自动选择、故障转移或另一个策略组，继续展开查看它最终会选到哪里；若最终落到 DIRECT，相关连接就是直连，不能仅凭上层组名判断出口。

客户端如果提供连通性测试，可以先运行一次，观察是否有节点能够完成测试。测试结果只代表该节点到测试地址的当时表现，不能当作所有网站、视频或游戏的速度结论；超时也可能来自测试地址不可达。第一次验证最好固定一个明确的节点，等浏览器正常连接后再启用自动选择，这样出现问题时更容易判断是出口变化还是其他设置导致。

不要在此时重写订阅附带的整套规则，也不必把所有分类组都手动改成同一个出口。先调整主策略组，再看具体网站命中了哪个组；只有目标服务的分组确实不符合需求时，才修改对应组的选择。规则更新、订阅更新和手动覆盖可能存在先后关系，进阶修改前应阅读协议手册中的规则与配置兼容性说明，并保留可恢复的原始配置。

本步结束时，界面应显示“规则”模式，且需要走代理的主策略已经指向可用出口。此时浏览器仍可能保持原来的网络路径，这是正常现象：模式已经确定，但系统还没有把请求交给客户端。确认选择后保持配置不动，进入下一步开启接管。

先检查客户端首页或状态栏中的内核状态。如果显示未运行、启动失败或配置加载错误，先处理这一项，再打开系统代理。系统代理的作用是让遵循操作系统代理设置的应用把请求发送给本地内核；若内核没有监听，先打开系统代理反而可能让浏览器暂时无法访问网页。保持客户端处于运行状态，确认没有端口占用或启动错误后再继续。

桌面端：先开启系统代理

在 Windows、macOS 或 Linux 桌面客户端中寻找“系统代理”开关，常见位置是首页、设置页或托盘菜单。将它开启后，新建浏览器页面进行后续验证。不同桌面环境与应用对系统代理的支持程度不同，浏览器扩展、企业策略或应用自己的代理设置也可能覆盖系统设置。如果浏览器装有代理切换扩展，先暂停其接管，避免两个入口互相覆盖。

首次操作只开系统代理即可，暂时保持 TUN 关闭，也不需要开启“允许局域网连接”。后者是让其他设备访问本机代理监听，与本机浏览器能否使用代理不是同一个问题。不要为了尝试联网而把监听范围扩大。若当前还运行着其他代理或 VPN 工具，先保存其设置并退出连接，减少系统代理、路由和 DNS 设置相互争用的机会。

移动端：确认系统 VPN 权限

Android 或 iOS 客户端一般使用首页的连接按钮。首次连接时系统会弹出添加或建立 VPN 连接的授权提示，确认应用身份后按系统流程允许；成功后可在系统状态区域或 VPN 设置页看到活动连接。这里的 VPN 标记表示应用获得了系统网络接管通道，不保证所有连接都走远端节点，实际去向仍由规则、策略和应用排除设置决定。

如果点击连接后立即断开，先回到客户端查看日志，确认是否存在配置错误、授权未完成或另一个 VPN 正在占用连接。Android 的按应用代理列表可能排除了浏览器，iOS 的按需连接设置也会影响自动重连行为。首次测试先采用默认接管范围，并在客户端前台完成验证；后台断开、电池优化和自动连接等细节，等基础连接正常后再到FAQ逐项处理。

TUN 模式留给实际需要

如果浏览器通过系统代理工作正常，而某个桌面应用仍未进入代理，可以再考虑 TUN。它通过虚拟网络接口接管流量，通常需要服务组件或更高权限，并可能影响路由与 DNS。开启前应看清客户端的安装服务或授权提示，记录当前开关状态。TUN 不是速度增强按钮，也不是每个人的必选项；首次配置不要同时改动系统代理、TUN 和 DNS，具体机制可查阅协议手册。

现在应能看到内核运行，以及桌面的系统代理开启或移动端的 VPN 连接状态。先不要用“已连接”三个字作最终判断，接下来用真实访问请求确认流量进入了哪里。

新开一个浏览器标签页，访问你明确预期应走代理的正常网站，并同时打开客户端的“连接”页面。尽量使用新请求，而不是只看已经打开很久的页面：旧页面可能来自缓存，已有连接也可能继续沿用切换前的路径。若连接记录较多，可按目标域名或进程筛选；部分客户端只在连接存续时展示记录，页面加载完后记录消失并不一定是异常。

找到刚才的目标后，查看命中的规则与策略链。理想结果是目标域名符合预期规则，策略链最终指向第二步选定的节点或代理出口。仅看到请求出现在列表里，只能说明流量进入了内核；如果最终策略是 DIRECT，它仍然是直连。如果客户端不显示完整链路，可结合“规则”页与适当级别的日志确认，不必为首次验证长期打开大量调试日志。

再访问一个预期应直连的常用服务，按同样方式查看记录。这一步是检查分流，而不是比较两个网站的打开速度。规则配置可能让部分直连流量也经过内核，因此“出现在连接列表中”与“经过远端代理”不能画等号。反过来，浏览器能打开网站也不能单独证明代理生效，因为目标本来就可能可以直连访问。

需要进一步确认出口时，可以访问可信的公网地址查询服务，并在相同网络条件下对照连接前后的结果；但应先核对该查询域名本身是否被规则分配给代理。它显示的是这一次请求的出口，不代表其他应用、所有域名或所有地址族都采用相同路径。看到结果不同可作为辅助证据，真正定位分流仍以对应请求的规则和策略为准。

如果页面打不开，按前面四步逆向检查：连接页完全没有对应请求，优先检查应用是否遵循系统代理、是否被排除或是否被其他工具接管；能看到请求但最终是直连，回到策略组和规则核对；命中代理但连接失败，再检查节点状态和服务有效性。出现证书错误时不要绕过浏览器警告，也不要安装来源不明的根证书，应按故障排查 FAQ检查系统时间、网络环境与错误信息。

确认可用后，只做一次小范围稳定性检查：关闭并重新打开浏览器页面，观察是否仍命中同一预期策略；移动端可在正常使用后检查后台连接是否保持。若从 Wi-Fi 切到移动网络，要把它当作新的网络环境重新验证，因为 UDP 可用性、DNS 与系统连接状态可能变化。单次测速或某个网页打开成功，都不能替代实际使用场景的检查。

最后熟悉退出流程。桌面端若只想暂时停用代理，可先关闭系统代理，再按需要退出客户端；使用 TUN 时也应确认它已停止。移动端点击断开，并在系统 VPN 页面确认状态。若退出后浏览器无法联网，先检查系统是否残留指向本地端口的手动代理设置，不要直接删除全部配置。记住当前有效配置和主策略选择，下次启动就不必从头导入。