Clash 使用教程

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

开始前，先确认两件事：客户端能够正常打开，订阅服务仍在有效期内。Clash 客户端负责读取配置和处理流量，安装客户端本身不会生成代理节点。订阅链接通常由服务提供方给出，里面可能带有账户识别信息，应当按私密信息保存。不要把完整链接发到公开讨论区，也不要提交到不熟悉的在线转换页面。

Clash Verge Rev 导入路径

打开 Clash Verge Rev，在侧栏进入“订阅”页面；部分版本可能使用“配置”这一名称。找到订阅链接输入框，粘贴服务提供方标明兼容 Clash 或 mihomo 的地址，再点击“导入”。若弹出新建配置窗口，类型选择远程配置，名称使用便于识别的短文字。名称只用于本地管理，不会改变订阅内容。点击确认后等待下载完成，不要连续重复导入同一条地址。

导入成功后，列表中应出现一张配置卡片或一条配置记录。点击该记录，确认它处于当前使用状态，再进入“代理”页面查看是否出现策略组和可选节点。有的客户端在导入后自动启用，有的只保存文件；因此，“列表里有订阅”和“内核正在使用这份订阅”需要分别确认。若新旧配置内容不同，切换后代理页面也应出现对应变化。

Android 与 iOS 客户端通常从“订阅”“配置”页面的加号进入。选择从链接导入，粘贴地址并保存，然后返回配置列表启用它。系统分享菜单有时也能把订阅链接交给客户端处理，但最终仍要回到客户端检查当前配置。通过二维码导入时，应先确认二维码来自服务提供方；扫描结果如果只是普通网页，并不代表已经获得可用配置。

本地文件与首次更新

如果拿到的是 YAML 文件，使用“导入文件”或“本地配置”入口选择它，不要把文件正文粘贴到订阅地址栏。本地文件是否会更新取决于其内容和客户端机制，不能假定它拥有远程订阅的刷新能力。配置文件中的节点、策略组与规则各有用途，初次使用先保持原样；需要理解它们之间的关系时，可查看名词解释，不必在这一步手工改写文件。

遇到导入失败，先核对地址是否完整，尤其注意聊天软件复制时混入的空格和换行。接着看客户端提示：下载失败说明获取内容这一步未完成；解析失败则表示拿到的内容不能按当前配置格式读取。登录页、错误页以及其他客户端专用格式都可能导致解析失败。应回到服务提供方确认订阅类型，而不是反复更换规则。只有代理页面已能读取策略组，才继续选择模式。

第二步：选择模式与出站节点

配置启用后，找到客户端首页、代理页或设置页里的“出站模式”。通常有“规则”“全局”“直连”三个选项，首次连接选择规则模式。它按照配置中的规则决定每条连接走哪个策略组或直连。这里的模式控制流量进入内核后的处理方式，并不负责把浏览器或其他应用的流量送进内核；后一个问题将在第三步处理。

接着进入“代理”页面，找到主要出站策略组。它的名称由订阅配置决定，可能是“节点选择”“代理”或其他名称，并不一定叫 PROXY。展开策略组后，点击一个当前可用的节点，确认选中标记已经移动。若组内列出的还是其他策略组，就沿着当前选项继续查看，直到能够确认最终使用的是具体节点，还是直连出站。

部分配置还会给视频、代码托管或聊天应用单独设置策略组。在主组里选好节点，并不会强制覆盖这些分组。首次验证只需确认待测试网站对应的组；暂时不知道对应关系也可以先连接，稍后从“连接”记录查找实际链路。不要凭节点名称推断某个网站一定使用它，规则和策略组的引用关系才决定最终出站。

Clash 节点延迟测试

点击策略组旁的测试按钮，或客户端提供的“延迟测试”入口，等待本轮结果结束。测试反映的是客户端通过该出站访问测试地址的情况，具体含义取决于客户端和测试方法。它不是下载带宽，也不能保证所有网站都可访问。出现超时，可先选同组另一个节点重试；不要仅因为某次数字较低，就认定它在全部应用里都更合适。

测试完成后再确认一次选中项。有些按钮只测试连通性，不会自动改变手动选择组的当前节点；自动选择组则由自身配置决定如何切换。初次上手以能持续打开目标页面为准，保持一个可用选择，避免频繁测试打断排查。关于选择组、自动选择与故障转移的差别，留到策略组进阶章节再看。

如果需要用 Clash 全局模式作对照，切换后还要检查全局策略的当前出站。全局模式不等于设备所有流量都会被接管，也不会自动修复失效节点。测试结束后切回规则模式，避免后续验证与原配置的预期路径不一致。三种模式的细节见出站模式说明。

第三步：开启连接与流量接管

现在配置和出站都已确定，需要让实际应用使用客户端。桌面端先走系统代理这一条较容易核对的路径，移动端则按 VPN 连接路径操作。若设备同时运行其他代理工具或 VPN，先断开另一项连接，保留单一测试条件。一次只改变一种接管方式，出问题时才能知道是哪一步带来的变化。

桌面端系统代理设置

在 Clash Verge Rev 的设置页找到“系统代理”并开启，随后打开操作系统网络设置中的代理页面，确认代理状态随之改变。客户端一般会把系统代理指向本机监听地址和当前端口。以客户端显示的值为准，不能因为教程示例常见 7890，就强行把设备改成这个端口；自定义配置和其他软件可能使用不同端口。

浏览器若采用系统代理设置，通常会在新连接中使用这条路径。检查浏览器是否安装了独立代理扩展，或者是否在自身设置中指定了另一套代理。Firefox 等浏览器可能保留单独的网络设置，应明确选择使用系统代理，或按客户端实际监听信息配置。更改后新建窗口再访问，避免沿用原有连接。命令行和部分应用不一定读取系统代理，暂时不要把它们作为首次成功与否的唯一依据。

macOS 修改系统网络配置时可能弹出权限提示；需要安装服务或辅助组件的客户端，还可能请求额外授权。核对提示对应的应用名称后再确认，并返回客户端查看开关是否保持开启。Linux 下若桌面网络设置没有同步改变，可在应用里显式设置代理进行验证。不要在没有记录原值的情况下反复修改系统网络选项。

移动端连接与 VPN 授权

Android 和 iOS 上，回到客户端主页点击连接开关。首次连接通常弹出系统 VPN 配置或连接授权，确认后等待客户端显示已连接，再查看系统是否有相应 VPN 状态。这个状态说明系统已建立客户端所需的接管通道，不代表远程节点已经通过访问测试，因此仍需完成第四步。

如果开关打开后立即关闭，先看系统是否拒绝授权，以及另一款 VPN 是否仍然连接。Android 还应检查系统的始终开启 VPN、应用分流和电池管理选项，避免其他应用限制当前连接。iOS 可在系统设置里查看当前 VPN 配置是否属于正在使用的客户端。连接提示没有完成前，不要连续快速点击开关，以免多次启停让状态难以判断。

什么时候改用 TUN

浏览器已经能按规则访问，但某个不遵从系统代理的应用仍然直连时，再考虑 TUN。进入设置开启 TUN 模式，并按客户端要求安装服务或授予管理员权限。首次使用保留客户端默认 stack，先验证功能，不要同时改动 DNS、路由和协议栈。虚拟网卡能否建立、路由是否正确以及应用是否被排除，都会影响结果，单看开关颜色不足以确认接管成功。

若开启 TUN 后出现整个设备无法联网，先关闭 TUN，回到刚才已经验证过的系统代理路径。恢复可用状态后再查日志，不要立即重置全部配置。TUN、Fake-IP 与 DNS 的组合属于后续优化，本文不要求首次连接就完成这些设置；相关机制可先从网络接管与 DNS 术语查起。

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

打开客户端“连接”页面，保留窗口，再用浏览器新建窗口访问一个平时常用、内容稳定的 HTTPS 页面。观察客户端是否出现对应域名或目标地址的连接记录，然后查看这条连接的命中规则和出站链路。部分客户端需要展开记录详情才能看到这些字段。短连接可能很快结束，可以先打开记录页再刷新目标页面。

如果页面正常显示，同时记录中能看到预期策略组及其节点，说明这次请求已进入内核，并按该路径处理。再访问一个预期应当直连的页面，检查记录是否显示 DIRECT。规则模式下有些请求直连是正常结果，并不是代理失效。若配置使用绕过机制，部分直连流量也可能不出现在内核记录中，应结合实际接管设置判断。

还可以用可信的出口地址查询页面辅助检查，但应先确认查询页面自身走的是哪条规则。它显示的是该次请求观察到的出口，不代表所有应用、所有域名都使用相同路径。浏览器缓存、复用连接和不同地址族也可能造成结果差异。优先把页面访问结果与连接记录对应起来，不要只看任务栏图标或 VPN 标志下结论。

失败时按同一顺序回查

客户端完全没有出现测试请求时，先回到第三步检查系统代理、浏览器独立代理设置或移动端 VPN 状态。有记录但目标走了 DIRECT，而你预期走代理时，检查规则和策略组选择，不要先换节点。记录确实经过代理节点却连接超时，再换同一策略组中的另一个节点作对照。这三个分支对应接管、分流和出站连通性，分开处理比同时修改多个开关更容易定位。

日志出现解析相关错误时，先保留原配置，确认直连网络能否正常解析和访问常用页面，再检查问题是否只影响特定域名。不要从网上复制整段 DNS 配置直接覆盖订阅，也不要把系统 DNS、客户端 DNS 和浏览器加密 DNS 同时改掉。需要提交问题时，记录客户端名称、操作系统、复现操作和错误文字；分享日志前去掉订阅地址、账户标识及其他敏感信息。

验证成功后，记住当前使用的配置、模式和策略组选择。日后刷新订阅后若出现变化，先检查当前配置是否仍为原来的那一份，以及策略组是否保留了选择。结束使用时，从客户端关闭系统代理或 VPN 连接，再退出应用；如果直接退出后浏览器断网，到系统网络设置检查是否还残留指向本机的手动代理。