Clash Verge Rev 里最容易混在一起的三件事，其实在不同层：System Proxy 负责把系统代理指向本机端口；Service Mode 负责用更高权限拉起 Mihomo 内核；enhanced-mode: fake-ip 属于 DNS 行为。先分层，后重置，能少走很多弯路。

截至 2026-05-23，官方安装页仍能看到 clash-verge-service.exe、install-service.exe、uninstall-service.exe、verge-mihomo.exe 等组件说明；Release 页可见 v2.5.1，历史发布说明中 v2.5.0 提到 Mihomo 内核升级到 v1.19.25 和系统代理 PAC 修复，v2.4.5 提到新版本前先卸载旧 TUN 服务的迁移提示。排错时版本和安装来源要一起记录。

判断坏在哪一层

不要一上来重装客户端，把故障放进这张表：

表现更可能的层查什么典型关键词
点击 Service Mode 后提示未安装服务安装 / IPCWindows 服务列表、管理员权限、安装器是否被拦service not installed、Some issue with service IPC Path、os error 2
System Proxy 打开但浏览器没变化系统代理写入操作系统代理设置、本机端口、浏览器扩展sysproxy、proxy guard、127.0.0.1
开 TUN 后断网或没连接虚拟网卡 / 路由Service Mode、TUN stack、DNS 劫持failed to create tun device、permission denied、dns-hijack
fake-ip 写了但仍像 redir-hostDNS enhanced-mode运行时配置、覆写脚本、核心日志enhanced-mode、fake-ip、redir-host
Rule 改 Global 后表现仍一样模式误判连接是否已经进 MihomoMATCH、GLOBAL、策略组
订阅更新失败且端口报错端口冲突 / 回环mixed-port、控制端口、旧客户端address already in use、bind、7890

这张表的用法很简单：先找“入口”。请求没有进入 127.0.0.1:7890，就不要急着改规则；服务没有装好，就不要先调 fake-ip。

为什么 System Proxy 能开，不代表所有应用都进来了？

Clash Verge Rev quickstart 说明，系统代理是通过开关自动修改操作系统代理设置，适合大多数浏览器流量。term 文档说得更直白：系统代理把监听端口写到系统约定位置，应用自己读取后再转发请求；它不能代理 UDP，也不是所有程序都会遵守。

做一个最小测试。假设你的本机入口是常见的 127.0.0.1:7890，不要把示例里的端口直接套到生产配置，看客户端当前设置。

Windows PowerShell：

curl.exe -x http://127.0.0.1:7890 https://example.com -I
netstat -ano | findstr ":7890"
netstat -ano | findstr ":9090"

macOS：

curl -x http://127.0.0.1:7890 https://example.com -I
lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

7890 常被用作 mixed-port，9090 常被用作 external-controller 示例端口。Clash Verge Rev 官方 config 示例里出现过 mixed-port: 7897、external-controller: 127.0.0.1:9090；Mihomo mixed inbound 文档示例里也出现过 port: 7892。这些数字只能当排错参照，不能当固定默认值。

如果 curl -x 能通，说明系统代理入口和出站链路至少有一条可用。如果浏览器仍不通，查浏览器扩展、PAC、企业代理、Firefox 独立代理设置。此时不要改 TUN。

Windows 上 Service Mode 怎么查？

Service Mode 不是按钮状态。官方 term 文档说明，服务模式会用管理员权限安装并启动服务进程，再由服务进程拉起内核；授权后，即使非管理员身份也能启用 TUN。clash-verge-service 还是独立后台进程，退出 Clash Verge Rev 后也可能继续运行。

Windows，确认服务真实存在：

Get-Service | Where-Object {$_.Name -match "clash|verge|mihomo"}
Get-Process | Where-Object {$_.ProcessName -match "verge|mihomo|clash"}

遇到 issue #6512 里那类日志，优先按服务 IPC 查，而不是改订阅：

Some issue with service IPC Path: 系统找不到指定的文件。 (os error 2)
需要安装服务，执行安装流程
service not installed

安全处理顺序：

  1. 在 Clash Verge Rev 界面里关闭 TUN 和 System Proxy。
  2. 在界面里卸载 Service Mode；如果有单独的卸载服务按钮，用按钮。
  3. 完全退出客户端，确认任务管理器里没有 clash-verge、verge-mihomo 残留进程。
  4. 右键以管理员身份启动 Clash Verge Rev。
  5. 重新安装 Service Mode，再打开 TUN。
  6. 回到 PowerShell 用 Get-Service 和日志确认。

不要先运行网上复制来的 sc.exe delete <服务名>。只有在界面卸载失败、服务名已确认、配置已备份时，才考虑手动清理服务。服务残留是问题，删错系统服务是更大的问题。

macOS 为什么更像“授权问题”？

macOS 的关键不是管理员弹窗点过一次就结束。TUN 和网络接管能力会经过系统网络扩展或过滤器授权；应用路径、签名、更新方式变化后，旧授权也可能失效。

按这个顺序看：

  1. 把应用放在 /Applications，不要长期从下载目录运行。
  2. 打开系统设置，查看 VPN、过滤器、登录项、网络扩展相关位置是否有 Clash Verge Rev 项。
  3. 如果更新后异常，先删除旧的 Clash Verge Rev 网络项，再重新打开客户端授权。
  4. 切换 Wi-Fi 后 System Proxy 静默失效时，比对当前网络服务的代理设置。

GitHub issue #6529 报告过 macOS 15 Apple Silicon 在切换 Wi-Fi SSID 后，System Proxy 对新网络为空，流量直接按系统默认路径走，且没有错误提示。这个问题和 Rule/Global 无关，因为请求还没稳定进入 Mihomo。

macOS 日志里如果看到下面几类词，查系统授权和网络服务顺序：

NetworkExtension
permission denied
utun
failed to create tun device
proxy config empty

不要直接 rm -rf ~/Library/Application Support/...。这会把 profiles、订阅、覆写脚本、规则缓存一起带走，最后你会同时失去故障现场和恢复路径。

端口冲突先看本机，不要先怪规则

端口冲突最常见的表现是核心起不来、系统代理打开但无响应、Dashboard 进不去，或者日志里出现 bind，看本机监听端口：

端口示例常见用途冲突表现安全处理
127.0.0.1:7890mixed HTTP/SOCKS 入站浏览器代理无响应、连接被旧客户端接走改 Clash Verge Rev 入站端口，或退出旧代理客户端
127.0.0.1:7897官方 config 示例里的 mixed-port复制示例后和现有端口重叠只保留一个 mixed-port，更新浏览器代理设置
127.0.0.1:9090external-controller 示例端口Dashboard/API 无法打开改控制端口，不要暴露到公网地址
0.0.0.0:53 / any:53DNS hijack 示例DNS 初始化失败、TUN 后断网排查时先退回本机测试，不要接管局域网 DNS

日志关键词：

bind: address already in use
listen tcp 127.0.0.1:7890: bind
failed to start mixed listener
external controller listen error

如果你同时装了 Clash Verge Rev、Mihomo Party、旧 Clash for Windows、浏览器代理扩展，先只保留一个客户端。端口由入口决定，规则只决定进入后的去向；入口已经被占用时，规则不会生效。

Rule 模式、Global 模式到底改了什么？

Rule 和 Global 是“出站选择”，不是“系统接管”。

Rule 模式会按 rules 命中策略，例如：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,10.10.0.0/24,DIRECT,no-resolve
  - MATCH,Proxy

Global 模式会让已进入 Mihomo 的连接统一走全局策略组或选定出站。问题在“已进入”三个字：如果应用没有读取系统代理，或者 TUN 没创建成功，切到 Global 也不会让它突然出现连接记录。

排查顺序：

  1. 连接列表没有任何记录：查 System Proxy、TUN、端口、浏览器设置。
  2. 有记录但走错策略：查 Rule/Global、规则顺序、策略组选择。
  3. 有记录但 DNS 异常：查 enhanced-mode、fake-ip-filter、dns-hijack。
  4. 有记录但反复回到本机端口：查代理回环和上游配置。

所以”系统代理失败”和”规则分流失败”不能混着修。

enhanced-mode / fake-ip 失败时看运行时配置

Clash Verge Rev config 文档示例里有：

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

同一页还示例了 TUN DNS hijack：

tun:
  enable: true
  dns-hijack:
    - any:53
    - tcp://any:53

enhanced-mode 是 DNS 解析结果的处理方式，不是 Service Mode 的别名，也不是 Rule/Global 的开关。GitHub issue #2158 里有用户报告在 Windows 11 24H2、Clash Verge Rev 2.0.1 下把 DNS enhanced-mode 设为 fake-ip 后，运行时仍显示 redir-host，并且通过 Global Extend Script 或 Edit File 修改也没有解决。

遇到这种情况，按四步查：

  1. 打开 Clash Verge Rev 当前运行配置，确认不是只改了模板文件。
  2. 搜索所有覆写脚本、merge 脚本和 profile merge，找第二个 enhanced-mode。
  3. 看日志里启动的是 verge-mihomo 还是 verge-mihomo-alpha，是否走 Service Mode。
  4. 复制备份 DNS 覆写后临时禁用，只保留 enable、enhanced-mode、fake-ip-range、nameserver 最小块。

不要同时改 fake-ip-range、fake-ip-filter、dns-hijack、strict-route 和规则集。DNS 问题最怕一次改五处。

TUN 和 Service Mode 的关系怎么验证？

Mihomo TUN 文档把 TUN 放在更底层的入站能力里，示例包含 stack: system、dns-hijack 等字段；Clash Verge Rev term 文档还提到 TUN 默认堆栈是 GVisor，并提醒要放行 verge-mihomo、verge-mihomo-alpha 防火墙规则。

排查时可以只改一个变量：

测试项只改什么观察什么
系统代理基线关闭 TUN，只开 System Proxycurl -x 是否能通，Dashboard 是否有连接
服务权限开 Service Mode，不改 DNS服务是否 Running，日志是否有 IPC 报错
TUN 创建开 TUN，不加复杂规则是否出现虚拟网卡，日志是否有 tun device
DNS 劫持加 dns-hijack 一项DNS 请求是否进入日志
路由严格度最后再调 strict-route局域网、打印机、开发服务是否被误接管

如果普通系统代理可用，TUN 不可用，订阅通常不是第一嫌疑，看权限、虚拟网卡、防火墙、旧服务和 DNS 劫持。

安全重置：哪些能清，哪些别删？

重置的目标是恢复服务和端口状态，不是把配置证据全部抹掉。

备份这些：

  • 当前 profile 文件和订阅 URL。
  • profile merge / parser / global extend script。
  • 自定义规则、rule provider、proxy provider。
  • 端口设置、external-controller、secret。
  • 最近一份日志。

不要先删除这些：

不要先删原因替代动作
整个配置目录会丢失订阅、覆写、日志现场导出 profile，再单独重置服务
profiles / 订阅文件订阅可用性会变成新变量用系统代理基线验证后再判断
provider 缓存会让规则与节点更新混入排查只在确认缓存损坏后清理
global extend script常是 enhanced-mode 被覆盖的证据复制出来，再临时禁用
服务二进制文件版本和签名状态会变乱用官方安装器或界面卸载服务

推荐重置序列：

  1. 导出或复制当前 profile、覆写脚本、日志。
  2. 关闭 System Proxy、TUN、Service Mode。
  3. 在界面卸载 Service Mode。
  4. 退出 Clash Verge Rev，确认没有残留进程。
  5. 重启系统，释放旧端口和虚拟网卡状态。
  6. 安装或升级到同一来源的最新版，不混用商店版、压缩包版和包管理器版。
  7. 以管理员权限启动 Windows 客户端；macOS 重新批准网络扩展。
  8. 只导入一个最小 profile，先测 127.0.0.1:7890。
  9. 再开 Service Mode、TUN、DNS enhanced-mode。
  10. 最后恢复自定义规则和脚本。

Release 页中 v2.4.5 相关说明提到“需要先在旧版本卸载 TUN 服务后再安装新版本服务”。如果你是从旧版本升级后才出问题，这句话比“清空所有配置”更值得先执行。

修好后怎么验收？

按三层验收，不要只看网页能不能打开。

层级通过标准验收命令或位置
System Proxy本机端口有监听，curl -x 成功127.0.0.1:7890、系统代理设置、浏览器连接记录
Service Mode服务存在且能拉起内核Windows Get-Service；macOS 网络扩展授权；Clash Verge Rev 日志
enhanced-mode / TUNDNS 与连接记录匹配预期日志里有 DNS、TUN、规则命中；无 bind、permission denied、redir-host 异常回退

最后再切 Rule/Global。Rule 下看规则命中，Global 下看所有已进入 Mihomo 的连接是否走同一个全局策略。两者都不能代替系统代理和服务安装验收。

相关阅读