第一步：导入订阅并启用配置
打开 Clash Verge Rev，在左侧进入「订阅」页。先从服务提供方的管理页面复制明确标注适用于 Clash 或 Mihomo 的订阅地址。它通常是一条完整链接，而不是登录页面地址、网页分享地址或某个单独的代理协议链接。订阅地址可能包含访问凭据，应只粘贴到准备使用的客户端，不要发到公开聊天、截图或问题反馈中。
粘贴地址，等待导入完成
找到订阅链接输入框；若当前界面只显示新增按钮，先点击加号，再选择通过链接导入。粘贴完整地址后检查开头与结尾，删除复制时多出的空格、换行和引号，然后执行「导入」。等待客户端完成下载与解析。成功后，订阅页应新增一张配置卡片，可以看到名称以及更新、编辑等操作入口。界面中的具体名称由订阅内容或客户端生成，不必与本文示例相同。
导入后还要确认这张配置已经成为当前使用的配置。点击卡片或其启用入口，观察选中标记是否出现；随后进入「代理」页，检查是否能看到策略组。仅在订阅页看到了卡片，不足以说明内核已经使用它。如果代理页仍为空，先返回订阅页核对选中状态，再到日志页查看是否存在解析失败或配置加载失败的信息，不要直接开始切换系统代理。
本地文件与订阅更新的区别
如果拿到的是本地 .yaml 或 .yml 文件，使用新增菜单中的文件导入入口，选择文件并设为当前配置。文件需要是可运行的完整配置，只有几行规则或一段 DNS 设置的片段，不能当作完整订阅使用。本地文件通常不会自动跟随服务提供方更新；后续拿到新文件时，需要重新导入或按客户端支持的方式替换。
如果链接导入失败，先确认订阅是否仍有效、账户是否到期，以及当前网络能否访问订阅服务器。打开日志，区分连接超时、服务器拒绝与 YAML 解析错误：前两类先检查地址和网络，解析错误则应确认拿到的是正确格式，而不是登录提示页。不要把完整订阅地址提交给不明转换网站。若提供方要求先通过代理更新，应使用已有可用连接处理，不能假定尚未配置好的新订阅会自行建立连接。
首次跑通后，后续使用卡片上的「更新」获取远端变更即可。直接编辑远端订阅内容可能在更新时被覆盖，所以此时先保留默认配置，不急着改端口、DNS 或规则。需要长期保留自定义设置时，再阅读高级用法中的本地覆写与多订阅合并。完成本步的检查标准是：配置卡片已选中，代理页能显示预期策略组，日志没有阻止配置加载的错误。
第二步：选择规则模式与代理出口
配置生效后，找到客户端的运行模式切换入口，将模式设为「规则」。部分版本将入口放在首页或代理页，也可能显示为 Rule。规则模式按配置中的规则决定请求直连、代理或拒绝，适合首次使用时保留订阅原有的分流安排。它并不是自动判断所有网站是否需要代理，实际结果仍取决于当前配置及策略组的选择。
先选模式，再选策略组内的出口
进入「代理」页，找到订阅配置中承担主要流量的策略组。名称可能是「代理选择」「节点选择」或服务提供方自定义的文字，不能仅凭名称推断用途。展开该组，查看其中是具体出口，还是另一个自动选择、故障转移策略组。手动选择组需要点击一个候选项并确认选中标记；如果选中的是嵌套策略组，还要展开下一层，确认最终能落到实际可用的出口。
客户端若提供连接测试，可以对当前组执行一次测试，把结果作为辅助线索。测试成功仅说明测试目标在当时可达，不能保证所有网站都能正常访问；测试失败也可能与测试地址被限制有关。首次验证时，优先选一个已知可用的出口，避免同时修改多组选择。若整个代理页只有直连选项，或完全没有候选项，应回到上一步核对订阅内容，而不是继续开启 TUN。
区分规则、全局与直连
「全局」通常将流量交给全局策略组，但组内仍然需要正确选择出口；切到全局并不等于自动找到可用线路。「直连」则让请求不经过代理出口，主要用于恢复或对照检查。首次使用建议停留在规则模式，只有在已经确认出口可用、需要区分是否为规则匹配问题时，才短暂切换全局进行比较，测试后再恢复规则模式。
这里的代理模式与下一步的流量接管方式是两件事。规则模式回答「进入内核的请求如何处理」，系统代理和 TUN 回答「哪些请求进入内核」。因此，选好规则模式却没有开启任何接管方式时，浏览器仍可能沿用原有网络。反过来，开启 TUN 也不会替代策略组选择，更不会修复失效订阅。离开本步前，确认模式为规则、主策略组已选择有效出口，再继续建立连接。
若希望了解自动选择、负载均衡、规则顺序或规则集订阅化管理，不必在首次连接时逐项研究。先记住当前选中的组和出口，后续到进阶配置手册查看对应章节，避免在验证前一次改变太多变量。
第三步：开启系统代理并发起请求
现在回到首页或「设置」页，先确认 Mihomo 内核没有处于停止或反复报错的状态，再找到「系统代理」开关并开启。系统代理会把支持系统代理设置的应用引向客户端的本地监听端口；客户端窗口保持打开，并不表示这个开关已经启用。开启后，用常用浏览器新开一个页面，给客户端产生一条可以观察的请求。
首次连接先保留默认端口
端口设置中可能显示 Mixed Port，例如 7897，请以当前客户端实际值为准，不必为了与教程一致而修改。系统代理指向的本地地址与端口，需要和正在运行的内核监听项一致。若此前用过其他代理工具，系统中可能残留旧端口；可先关闭 Clash Verge Rev 的系统代理，再重新开启，让客户端重新写入设置。不要同时打开另一款工具的系统代理开关。
若开启后浏览器立即无法访问任何页面，先关闭系统代理，确认原有网络能恢复。然后查看日志是否出现端口占用、内核启动失败或连接被拒绝。端口占用应先确认是其他程序仍在运行，还是同一客户端开了多个实例。不要反复随机改端口，因为改动后还需要同步手动代理应用中的地址，反而会增加排查范围。订阅可用、内核运行、端口监听正常后，再开启系统代理重试。
应用不跟随系统代理时，再考虑 TUN
部分应用有独立代理设置，也有应用不遵循系统代理。如果浏览器已经正常，而某个应用仍走原来的网络，先检查该应用是否支持单独设置 HTTP 或 SOCKS 代理。需要更广的流量接管范围时，再考虑 Clash TUN 模式。它通过虚拟网络接口与路由接管流量，可能要求安装服务、授予管理权限或批准网络扩展，具体提示取决于系统和客户端版本。
开启 TUN 前先保留一份已经验证可用的系统代理状态，按客户端提示完成服务与权限步骤，再开启 TUN 并检查日志。首次比较时一次只改变一个接管开关，避免同时叠加多个工具、多个虚拟网卡与手工路由。若 TUN 导致基础网络异常，先关掉 TUN 并恢复此前状态；不要把它当成任何网络故障都适用的修复开关。有关 Fake-IP、路由与 DNS 的细节，留到高级用法再配置。
在移动端，导入并选择配置后，通常通过「启动」或连接按钮发起接管。Android 首次会出现系统 VPN 连接请求，阅读提示后授权，并确认系统显示相应连接状态；iOS 按所用客户端的提示添加 VPN 配置并授权。已有其他 VPN 连接时要先处理冲突。系统显示连接状态只代表接管已启动，出口是否可达仍需要下一步验证。
第四步：验证请求路径与实际访问
不要只凭开关颜色或「运行中」文字判断配置成功。先打开一个按当前规则预期走代理的页面，再打开一个预期直连的页面。测试时使用新标签页并刷新，避免只看到浏览器缓存。随后进入「连接」页，找到刚才请求对应的域名或目标地址，查看它命中了哪条规则、进入哪个策略组，以及最终选择了什么出口。
把访问结果与连接记录对应起来
如果页面正常打开，连接页也显示了预期的规则与策略链，就完成了一次有依据的验证。请求显示 DIRECT 时，表示它按当前规则直连，并不必然是故障；需要结合该网站原本应走的路径判断。某些版本会在连接结束后很快移除记录，可在刷新页面时同步观察连接页，或查看客户端提供的连接历史。不要因为列表暂时为空就立即重装客户端。
如果浏览器一直加载，而连接页完全没有对应请求，先检查系统代理是否开启、浏览器是否使用自己的代理扩展，以及该请求是否确实发出。若已有对应连接，但最终出口与预期不同，回到第二步核对规则模式与策略组选择；若出口正确却连接失败，再查看日志中的超时、拒绝或解析错误。按「请求是否进入 → 路径是否正确 → 目标是否可达」的顺序检查，比同时调整 DNS、端口和 TUN 更容易定位问题。
公网出口与 DNS 需要分别判断
需要确认公网出口时，可以使用可信的公网 IP 查询服务，对比关闭接管与开启接管后的结果。但查询页面本身也受分流规则影响：它若命中直连，看到本地网络出口就是正常结果；使用浏览器代理只能说明这个浏览器的请求路径，不能代表所有应用。不要单凭一个查询页面的位置文字，断言整台设备的流量都已按同一种方式处理。
网页能访问也不等于已经完成 DNS 泄漏检查。浏览器安全 DNS、系统解析、客户端 DNS 与 TUN 的接管范围可能不同。首次上手阶段，先确认日常目标页面正常、连接记录可解释即可；如果有明确的 DNS 隔离需求，再按进阶配置手册的 DNS 与 TUN 章节做单独测试，不要照抄来源不明的整段 DNS 配置覆盖现有订阅。
结束使用时，确认网络能够恢复
验证成功后，记下当前配置名称、模式、主策略组与接管方式，后续故障时便有一个可返回的基准。需要停止使用时，先关闭系统代理或 TUN，再按需要退出客户端；直接强制结束进程可能留下指向本地端口的系统代理设置。关闭后重新访问常用页面，确认原有网络恢复。如果仍无法访问，检查系统网络设置是否残留手动代理，而不是连续重装软件。
开机自启与启动后自动开启系统代理是不同设置。首次验证完成后，才按日常需求启用，并在下一次登录系统时再做一次简短检查。订阅更新后若出现变化，也先核对当前配置和策略组，不急着重做全部步骤。至此，订阅已加载、出口已选择、请求已进入内核，且实际路径得到验证，首次配置流程完成。