安装前：确认系统架构与配置来源

Windows 上安装 Clash Verge Rev，建议按“客户端启动 → 导入订阅 → 系统代理验证 → 服务模式 → TUN”的顺序操作。不要第一次启动就把所有开关打开。先建立一条能够正常访问的代理连接，再处理不遵循系统代理的应用，故障范围会小很多。

Clash Verge Rev 是桌面管理界面，实际处理连接与规则的是 mihomo 内核，也常被称为 Clash Meta。安装成功只代表程序已经就位，不代表已经有可用节点。还需要一份与内核兼容的配置，或者由服务提供方交付的 Clash 格式订阅。

安装包按处理器架构选择

  1. 按 Win + I 打开 Windows 设置，进入「系统」→「系统信息」，查看「系统类型」。部分 Windows 版本将该页面命名为「关于」。
  2. Intel、AMD 的常见 64 位电脑选择 Windows x64 安装包；标注 ARM 处理器的设备选择发行页面提供的 ARM64 包。
  3. 确认所选发行版支持当前 Windows 版本。不要仅凭文件名带有 Windows 就判断它支持旧系统，也不要将 x64 与 32 位系统混用。
  4. 运行安装程序，按向导完成安装。已有旧客户端时，先退出旧程序，避免两个客户端争抢系统代理设置。

首次启动：防火墙提示该怎样放行

首次启动内核时，Windows 可能询问是否允许应用通过防火墙。提示对象可能是客户端，也可能是实际监听端口的内核程序。先核对程序路径是否位于刚安装的目录，再决定允许的网络范围；名称相近并不能替代路径确认。

本机代理和局域网共享不是一回事

  • 只给本机使用：保持「允许局域网连接」关闭，代理入口优先绑定回环地址。正常的本机回环连接通常不需要向局域网开放入站端口。
  • 给手机或其他电脑共享：需要主动启用局域网访问，并针对可信专用网络配置入站规则。公共网络不应顺手勾选。
  • 设备受组织管理：管理员策略可能限制内核联网、服务安装或虚拟网卡创建，应联系管理员确认，而不是关闭整套防火墙。

误点取消后，可以进入「Windows 安全中心」→「防火墙和网络保护」→「允许应用通过防火墙」检查记录。若需要按程序路径、端口或远端地址细分，在开始菜单搜索「高级安全 Windows Defender 防火墙」，检查对应规则的作用范围。应用列表中的允许项主要涉及入站访问，不能单凭一个勾选状态判断出站连接一定可用。

安装目录或内核路径在升级后发生变化时，旧规则可能不再命中。只调整确认有问题的规则，不要为了排查一次连接失败而停用所有网络配置文件的防火墙。

导入订阅：先用系统代理验证一条连接

  1. 打开客户端的「订阅」页面，使用新建或导入入口粘贴完整订阅地址，下载配置后选中该配置。具体按钮名称可能随版本调整。
  2. 查看策略组是否出现节点。选择一个已知可用节点，再确认客户端处于规则模式，而不是直连模式。
  3. 在「设置」中的 Clash 设置区域查看混合端口，并开启系统代理。以下示例假设混合端口为 7897，实际操作以客户端显示值为准。
  4. 进入 Windows「设置」→「网络和 Internet」→「代理」，检查手动代理是否指向 127.0.0.1 和刚才记录的端口。
  5. 用浏览器访问目标网站，同时查看客户端「连接」或「日志」页面，确认连接命中了哪个规则、策略组与节点。

节点延迟测试成功，只能证明该测试目标在当时可达。它不能证明所有网站、UDP 流量或 DNS 请求都已经正常。如果节点列表为空，先处理订阅格式、下载错误或配置解析错误，不要直接转向 TUN 驱动排查。

用显式代理测试区分故障位置

打开 PowerShell，执行下面两条命令。第一条检查本地端口，第二条明确指定 HTTP 代理访问测试站点。这里使用 curl.exe，避免旧版 Windows PowerShell 将 curl 解析为其他命令。

Test-NetConnection 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com
  • TcpTestSucceeded : False：先查内核是否运行、端口是否改过，以及是否有其他程序占用端口。
  • 能够连接本地代理，但出现握手失败或超时：结合日志检查节点、目标站点、DNS 与 TLS 错误。
  • 显式代理能够取得 HTTP 响应，但浏览器失败：优先查浏览器代理设置、扩展、系统代理写入与绕过列表。

测试站点返回 403、405 等 HTTP 状态也可能说明已经收到了服务器响应，但不等于业务访问成功。还要对照客户端连接记录，确认该请求实际走了预期的代理策略，而不是被规则交给直连。

服务模式与 TUN：按顺序安装、启用和验证

系统代理是给愿意读取 Windows 代理设置的应用使用的。部分命令行工具、游戏和自带网络栈的软件不会读取它。TUN 则通过虚拟网络接口与路由接管流量，覆盖范围更广，但也会引入路由、DNS 和权限方面的变量。

先让服务模式工作

  1. 在客户端「设置」中找到「服务模式」相关入口，执行安装，确认 Windows 用户账户控制弹窗显示的程序来源后再授权。
  2. 安装完成后，确认客户端显示服务已运行。若界面仍提示未安装或启动失败，先查看客户端日志，不要连续重复安装。
  3. 保留已经验证可用的配置与节点，再开启 TUN 模式。观察日志中是否出现创建接口失败、权限不足或设置路由失败。
  4. 按 Win + R，运行 ncpa.cpl，查看网络连接中的虚拟接口；也可以用下方 PowerShell 命令查看隐藏接口。
Get-NetAdapter -IncludeHidden |
  Select-Object Name, InterfaceDescription, Status

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20 DestinationPrefix, NextHop, InterfaceAlias, RouteMetric

接口名称由内核与配置决定，不一定包含固定的 Clash 字样。看到虚拟网卡不代表流量一定经过它，还要结合路由和客户端连接记录判断。开启 TUN 也不必然删除原有默认路由，内核可能添加更具体的路由来实现接管。

TUN 驱动报错不要直接搜索随机下载包

Windows 上创建 TUN 接口需要匹配的驱动支持和足够权限；具体由所用内核与客户端发行包的实现决定。正常流程应使用客户端提供的安装、修复或更新机制。日志明确提示驱动组件缺失时，先检查安全软件的隔离记录，以及安装是否完整，再使用可信发行来源修复。

服务模式负责以服务方式运行相关组件，并不负责让订阅自动兼容，也不会修复失效节点。若系统代理测试本来就失败，先回到配置和节点排查。仅开启 TUN 通常不会让同一个故障节点恢复。

系统代理开了却不生效：按现象定位

“开关已经打开”只说明客户端尝试设置了代理，不说明目标应用读取了它。先看请求有没有进入客户端，再决定查应用、规则还是节点。下面的判断顺序比反复重装更直接。

现象 优先检查 下一步动作
所有浏览器都失败，本地端口测试也失败 内核运行状态、端口、监听进程 核对混合端口，读取内核启动日志。
显式代理成功，只有某个浏览器失败 代理扩展、浏览器独立代理、绕过列表 暂时停用代理扩展，检查浏览器网络设置。
浏览器正常，终端或游戏不走代理 应用是否支持系统代理 配置应用代理、临时代理变量，或验证 TUN。
请求进入客户端，但显示 DIRECT 规则顺序、策略组选择、运行模式 查看命中规则，再调整对应规则或策略。
开启 TUN 后才断网 DNS、路由、其他 VPN、服务权限 关闭 TUN 恢复基线，再逐项排查。

端口占用：查 PID，不要凭进程名结束任务

若日志提示地址已被占用，可在 PowerShell 中查询监听者。下面仍以 7897 为例；将查到的进程 ID 代入任务管理器核对程序路径。多个代理客户端同时运行是常见原因，但未知进程不能直接强制结束。

Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

终端不继承系统代理：先用临时变量测试

对支持这些环境变量的命令行工具，可以只在当前 PowerShell 窗口设置代理。变量不会让所有程序自动支持代理，也不应在尚未验证时写成全局系统变量。

$env:HTTP_PROXY = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"

# 测试结束后清理当前窗口中的变量
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

HTTPS_PROXY 的值使用 http:// 并不表示目标网站降级为 HTTP。它描述的是客户端连接本地 HTTP 代理的方式，HTTPS 目标通常通过 CONNECT 隧道访问。应用如果只接受 SOCKS 代理，应按它的文档填写，而不是照搬 HTTP 设置。

TUN 开启后断网：检查 DNS 与其他虚拟网络

先关闭 TUN，保留系统代理做一次同样的访问测试。若立即恢复，说明问题更可能位于 TUN 接管链路，而不是订阅整体失效。记录开关前后的日志时间，检查是否存在重复 VPN、其他代理软件、虚拟机网络或企业安全客户端。

区分 DNS 缓存与解析路径

  • 修改 DNS 配置后，可以执行 ipconfig /flushdns 清理 Windows DNS 缓存，再重启测试应用。浏览器还可能保留自己的缓存和连接。
  • 浏览器的安全 DNS、应用内置 DoH 可能绕开系统 DNS 路径。排查时先记录原设置，再做一次受控对比，不要同时改多个 DNS 入口。
  • 启用 fake-ip 后，部分域名可能显示为 198.18.0.0/16 范围内的地址。这是常见的映射方式，不应仅凭它判断 DNS 被污染，也不应把该地址直接写成真实服务器地址。
  • 公司内网域名与局域网设备可能需要专门的 DNS 策略或排除规则。公网域名能打开，不代表内网解析也已经正确。

若配置启用了 DNS 劫持，应核对实际劫持范围和内核日志。传统 53 端口 DNS 与通过 HTTPS 发送的 DNS 请求不是同一种流量，不能认为配置一条 53 端口劫持规则就能统一处理所有应用解析。

其他 VPN 与虚拟机网络怎样处理

不要直接卸载全部虚拟网卡。先退出暂时不用的 VPN 或其他代理客户端，再重新开启 TUN 测试。对于必须同时运行的企业 VPN，应由管理员确认路由优先级、内网网段和 DNS 分流方案。随意降低路由度量值，可能把本该留在内网的连接交给错误出口。

退出、开机启动与日常维护

完成安装后，先做一次正常退出测试：关闭 TUN 与系统代理，再退出客户端，确认普通网络仍然可用。如果客户端异常退出后浏览器断网，进入 Windows「设置」→「网络和 Internet」→「代理」，检查是否仍残留指向本地端口的手动代理；确认没有其他程序依赖它后再关闭。

  1. 最后再设置开机启动。先验证一次重启后的订阅加载、内核运行与代理状态。图形界面自启动和服务启动不是同一件事。
  2. 更新后复查关键项。核对内核版本、混合端口、服务模式和 TUN 状态；遇到配置字段变化时，以当前内核文档与错误日志为准。
  3. 长期修改使用覆写功能。直接修改订阅下载得到的内容，可能在下一次刷新后被覆盖。
  4. 提交问题时提供最小信息。记录 Windows 版本、客户端与内核版本、复现步骤和脱敏日志。隐藏订阅凭据、节点密码及管理接口密钥。

排查的核心是保留一条已经验证可用的路径：本地端口能连接、显式代理能返回响应、规则命中符合预期，然后再扩大到系统代理和 TUN。每一步都有明确结果，就不需要靠反复重装来碰运气。