一、Clash、Mihomo 与 Clash Verge Rev 有什么区别？

Clash 是这一类代理工具与配置生态中常见的名称；Mihomo 是代理内核；Clash Verge Rev 是使用 Mihomo 的桌面客户端。客户端提供订阅管理、代理选择、系统代理开关和日志界面，内核负责实际连接、DNS 处理与规则匹配。安装客户端，不等于已经获得可用节点。

Mihomo 曾以 Clash.Meta 为人熟悉。搜索旧教程时可能遇到 Clash Meta、Meta 内核等称呼，但不同内核与版本支持的配置字段并不完全相同。遇到配置报错，应先记录客户端版本、内核版本和完整错误信息，再判断是否属于兼容性问题。

  • 客户端：负责把配置与操作呈现在界面中，例如 Clash Verge Rev。
  • 内核：读取运行时配置，建立代理连接并执行分流规则。
  • 订阅：从服务提供方获取的配置或节点来源，不由客户端自动生成。

本文以 Clash Verge Rev 的桌面操作概念为主。Android 的 VPN 授权与桌面的系统代理不是同一种机制，不能把两个平台的开关逐项照搬。选型可先看客户端对比。

二、订阅链接是什么，应该从哪里获取？

订阅链接是用于获取配置的地址，通常包含账户令牌。服务提供方可能同时给出账户管理页面、通用节点订阅、Clash 配置订阅等多个入口。导入 Clash Verge Rev 时，应选择与 Clash 或 Mihomo 配置兼容的入口，而不是复制浏览器地址栏里的账户首页。

导入前检查三项

  1. 确认链接来自自己的服务账户，套餐或授权仍有效。
  2. 确认返回的是受支持的配置内容，而不是登录页面、付款提醒或网页错误。
  3. 确认链接完整。聊天软件断行、复制时多出空格、遗漏查询参数，都可能导致请求失败。

完整配置可能包含 proxies、proxy-groups、rules 等字段；也可能通过 proxy-providers 加载节点，不能仅凭没有 proxies 就认定配置无效。只有节点列表的订阅，则可能需要配合已有配置使用。

三、Clash Verge Rev 怎么导入订阅？

先导入，再激活配置，最后选择节点。这三个动作分别对应获取配置、让内核加载配置、决定代理出口；导入成功只完成了第一步。

  1. 打开左侧「订阅」页面，在订阅链接输入框粘贴地址，执行「导入」。不同版本可能将入口收进新建订阅菜单，以实际界面为准。
  2. 等待订阅卡片出现。检查更新结果、节点数量或流量信息；这些信息是否显示，取决于服务端是否提供相应数据。
  3. 选择该订阅，使其成为当前使用的配置。若提示 YAML 解析或字段错误，先处理错误，不要直接开启全部网络接管开关。
  4. 进入「代理」页面，找到实际被规则引用的策略组，选择一个可用节点。
  5. 首次验证可先使用「规则」模式和「系统代理」，打开浏览器测试，再到「连接」页面检查请求。

如果手动更新失败但旧配置仍能使用，应优先检查订阅地址和更新请求路径。不要先删除唯一可用的配置。服务端返回 401 或 403 时，核对授权、令牌及服务端访问限制；返回 200 也不代表内容一定正确，还要看是否误返回了 HTML 页面。

首次安装与导入的连续步骤见快速上手。更换客户端时，优先重新导入原始订阅，再单独迁移本地设置。

四、规则、全局、直连模式应该选哪个？

日常使用先选规则模式。模式决定内核如何选择出口，但不会自动让所有程序的流量进入内核。系统代理、TUN 与应用自己的代理设置，才决定流量从哪里进入。

模式实际作用适合场景
规则 Rule按配置中的规则顺序匹配，交给对应策略或策略组日常分流，区分直连与代理目标
全局 Global进入内核的请求使用全局策略选择的出口短时对照测试，排查规则选路
直连 Direct进入内核的请求直接连接目标，不经代理节点验证本地网络或临时停用代理出口

全局模式并不等于「全设备接管」，也不保证所有网站更快。若某应用没有使用系统代理，又未被 TUN 接管，即使切到全局，它的请求仍可能绕过客户端。全局策略若选成 DIRECT，同样不会经过远端代理节点。

在规则模式中，规则通常从上到下匹配，命中后采用对应策略。假如目标被前面的直连规则命中，改变列表末尾的兜底规则不会影响该请求。应通过连接记录确认命中的规则，而不是仅凭网站所在地区猜测。

五、系统代理与 TUN 模式有什么区别？

系统代理适合先验证浏览器；TUN 用于接管更多网络流量。系统代理向操作系统登记本地代理入口，但应用可以选择不遵循。TUN 通过虚拟网络接口与路由接管流量，适合不支持显式代理的程序，但需要服务权限，并会与现有网络环境相互影响。

按需要逐级开启

  • 仅浏览器访问：先启用系统代理，暂时关闭浏览器的独立代理扩展，减少相互覆盖。
  • 终端工具：检查工具是否读取系统设置，或为它单独配置 HTTP、SOCKS 代理。
  • 游戏、部分桌面应用：确认协议与节点支持情况后，再考虑 TUN；系统代理通常不能直接解决全部 UDP 流量问题。

在 Clash Verge Rev 中可从「设置」检查「系统代理」与「TUN 模式」相关项目；TUN 不可用时，再检查该版本的服务模式安装与运行状态。不同系统的权限流程有区别，不建议把长期以管理员身份启动作为唯一处理方式。

若同时运行公司 VPN、另一款代理或虚拟网卡工具，先记录当前状态，再只保留一种接管方式测试。TUN 故障常与路由、DNS、网段冲突有关，反复切换节点不一定有效。

六、节点延迟有数字，为什么网页还是打不开？

延迟测试只证明特定测试请求在当时得到了响应。它不等于下载带宽、网站可访问性，也不等于所有策略组都选中了该节点。某个节点显示 80 ms，仍可能无法访问另一个目标网站；这里的数值只是判读示例，不是实测结论。

  1. 查看目标请求使用哪个策略组。更新订阅后，组名或节点选择可能变化。
  2. 检查该组最终指向的出口。选中组名后，还可能继续引用另一个策略组。
  3. 换一个已知可用的 HTTPS 目标测试，区分单站故障与普遍故障。
  4. 在「连接」和「日志」页面核对请求结果，不要只看代理页的延迟颜色。

延迟测试超时也不能直接推出节点一定失效：测试地址可能不可达，服务端可能限制该目标，或测试超时设置偏短。应结合实际网页请求、连接错误以及同一网络下其他节点的表现判断。

如果普通页面能打开，但大文件或视频持续失败，应继续检查节点质量、目标服务限制及协议兼容性。不要把延迟最低当作唯一选择标准。

七、「已连接却打不开网页」应该按什么顺序排查？

先确认请求是否进入客户端，再看规则、节点与 DNS。界面的运行状态通常只说明内核或接管功能已经启动，不代表目标网站的完整访问链路已经成功。

固定一次请求，观察六个位置

  1. 本地网络：临时关闭系统代理与 TUN，验证本来允许直连的网站能否访问。若基础联网失败，先处理 Wi-Fi、网关或网络登录页面。
  2. 当前配置：确认订阅已激活，内核没有报告配置加载失败。
  3. 流量入口：重新加载目标网页，查看「连接」是否出现对应域名或目标 IP。没有记录时，检查浏览器独立代理、系统代理端口、TUN 路由及绕过列表。
  4. 规则结果：查看新连接的匹配规则与策略链，确认不是误选 DIRECT 或命中 REJECT。
  5. 代理出口：在同一策略组内切换一个节点，再发起新请求。旧长连接未必随节点选择立即迁移。
  6. 错误类型：结合日志区分域名解析失败、连接拒绝、连接超时和 TLS 错误，分别处理。

排查结束后恢复规则模式。不要长期关闭系统防火墙，也不要用跳过证书验证来掩盖 TLS 错误；后者应检查系统时间、证书链、目标服务及是否存在 HTTPS 检查软件。

八、怎么判断是 DNS 问题，还是代理端口错误？

DNS 负责把域名转换成地址；代理端口负责接收应用请求。两者处于不同环节。日志出现 lookup、no such host 等信息时优先检查解析；连接本机代理地址就被拒绝时，则先检查端口与内核监听状态。

以下命令是显式指定 HTTP 代理入口的测试示例。7897 仅为示例端口，必须替换成客户端当前运行时配置中的 HTTP 或混合端口，不能把旧教程里的 7890 当成固定默认值。

curl --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShell 中可使用 curl.exe，避免部分环境下 curl 被映射为其他命令。示例中的连接超时为 10 秒，总超时为 20 秒；目标仅用于说明测试方法，实际排查应换成出现问题的地址。收到 HTTP 响应说明请求已推进到应用层，但不代表该网站所有功能都可用。

  • 本机连接被拒绝：核对端口、监听地址、内核是否运行，以及端口是否被其他进程占用。
  • 请求进入客户端后解析失败：核对运行时 DNS 配置与上游解析服务的可达性。
  • 只有浏览器异常：继续检查浏览器代理扩展、安全 DNS、缓存和应用自身设置。

Fake-IP 是一种域名映射机制，并不是实际远端服务器的地址。开启后，解析结果出现合成地址不一定是故障。修改 DNS 前应查看实际生效配置；系统命令 nslookup 的结果也不一定代表内核采用了相同的解析路径。

九、订阅更新会覆盖节点选择和本地规则吗？

远程订阅内容会随更新变化，本地定制应放到覆写层。直接修改下载下来的远程 YAML，后续更新可能将修改替换。节点选择能否保留，还取决于客户端的保存机制，以及更新后策略组名和节点名是否保持一致。

需要区分三层设置

  • 远程配置：服务提供方交付的节点、策略组、规则及相关设置。
  • 本地覆写：在订阅基础上合并或调整字段，用来保存自己的分流与参数。
  • 运行时配置：经过客户端处理后，最终交给 Mihomo 加载的配置。

使用 Merge 覆写时，不能假设所有列表都会自动追加。规则列表的合并方式、脚本处理顺序和客户端增强设置都可能影响最终结果。保存后应核对运行时配置，再用一条真实请求验证规则是否命中。

例如希望某个域名直连，重点不只是写出 DOMAIN,example.com,DIRECT，还要确认它在有效规则中的顺序，以及是否被前面的规则先匹配。初次配置可先保留订阅原有规则，稳定后再参照高级用法逐项加入本地覆写。

十、退出客户端后无法联网，怎样恢复并提供有效反馈？

先检查是否残留指向本机的代理设置。若系统仍指向 127.0.0.1 的代理端口，而客户端内核已停止，遵循该代理设置的应用就无法建立连接。

  1. 重新打开客户端，关闭「系统代理」和「TUN 模式」，再正常退出，观察网络是否恢复。
  2. Windows 11 可检查「设置」→「网络和 Internet」→「代理」→「手动设置代理」。只清理自己配置的本地代理，不要随意删除单位管理的设置。
  3. macOS 可检查「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」，核对 HTTP、HTTPS 和 SOCKS 项目。
  4. 若仍有异常，检查其他 VPN、浏览器独立代理，以及终端中的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 环境变量。

TUN 异常退出后的情况与系统代理残留不同，还可能涉及虚拟网卡、路由或 DNS 状态。优先通过客户端正常关闭接管与服务，必要时重连网络；不建议在不了解用途时批量删除路由或虚拟网卡。

求助时附上最小诊断信息

  • 操作系统版本、客户端版本、Mihomo 内核版本。
  • 当前模式、系统代理和 TUN 是否开启、使用的本地端口。
  • 问题发生时间、目标域名，以及「连接」中看到的匹配规则和策略链。
  • 同一时间附近的错误日志、已尝试的步骤，以及每一步的结果。

分享前删除订阅令牌与其他凭据。清晰的复现路径，比整屏节点截图更有助于定位问题。新手排查的基本顺序可以固定为：订阅有效、配置生效、请求进入、规则正确、出口可用，最后再调整 DNS 与更复杂的网络接管参数。