Clash Verge 闪退排查

先区分窗口消失与内核退出

Clash Verge 打开即闪退，先保留日志，再按故障层定位；不要第一步就删除配置目录。桌面界面、后台服务和 mihomo 内核不是同一个进程。界面退出可能与 WebView2 或应用状态文件有关；界面正常但代理不可用，则更应检查内核配置、监听端口和 TUN 权限。节点延迟测试失败也不能直接证明客户端发生了启动崩溃。

本文同时涉及旧 Clash Verge 与后续 Clash Verge Rev 的排查思路，但不把两者的目录和菜单当成完全相同。记录正在使用的项目名称、完整版本、安装包架构及系统版本；Windows 可按 Win + R，输入 winver 查看系统版本。切换客户端前先备份，避免把旧版状态文件直接覆盖到新版目录。

先在 Windows「任务管理器」→「详细信息」确认应用进程是否退出，再查看托盘。若只是窗口隐藏，尝试从托盘恢复；若后台进程卡住，先正常退出，必要时结束明确属于该客户端的进程。不要批量终止所有名称含有代理或服务字样的进程。

找到启动日志与崩溃时间点

界面能打开：从应用目录入口查起

在 Clash Verge Rev 的「设置」页查找「应用目录」或打开目录的入口，再查看日志相关目录；不同版本的入口文字可能不同。Windows 安装版的数据通常位于用户的 %APPDATA% 下，便携包可能把数据放在程序附近。不要仅凭网上的一条路径，就断定当前安装没有日志。

应用无法打开时，可先用下面的 PowerShell 命令列出名称包含 Verge 的候选数据目录。这一步只读取目录列表，不会删除或改写文件。找到目录后，按修改时间寻找最近的日志文件；如有应用日志、服务日志和内核日志，应分别保存。

# Windows PowerShell：查找候选用户数据目录
Get-ChildItem -LiteralPath $env:APPDATA -Directory -Force |
  Where-Object { $_.Name -match 'verge' } |
  Select-Object Name, FullName, LastWriteTime

界面完全打不开：补充系统记录

1. 记下本地时间，只复现一次闪退，避免连续启动让旧日志被滚动覆盖。
2. 按 Win + R 输入 eventvwr.msc，进入「Windows 日志」→「应用程序」，查看同一分钟的错误记录。
3. 记录故障应用程序、故障模块、异常代码和路径。常见的事件 ID 1000、1001 可以作为线索，但并非每次崩溃都会生成这两个事件。
4. 也可运行 perfmon /rel 打开可靠性监视器，查看对应日期的应用程序失败详情。

内核日志中的 fatal、error、panic 是入口，不是完整结论。应连同前后约 20 行一起阅读：最后一行“进程退出”往往只是结果，真正的原因可能是前面的配置解析失败或绑定端口失败。GUI 程序没有在终端输出文字，也不能证明它没有发生异常。

配置文件损坏：先验证再隔离

如果日志出现 yaml: line 18、unmarshal、parse config 或策略名称不存在，应先沿配置链排查。YAML 对缩进和数据类型敏感；使用 Tab 缩进、把列表写成字符串、引用已删除的策略组，都可能阻止内核启动。但界面状态文件解析失败与代理配置解析失败属于两类问题，不应混在一起处理。

用当前安装附带的内核测试

mihomo 提供配置测试参数 -t，可在不启动正常代理监听的情况下检查配置。以下示例假设终端位于包含 mihomo.exe 的目录，待测文件已复制为 config-test.yaml。实际包内的内核文件可能使用其他名称，应使用当前客户端附带的那个文件，而不是临时换一个内核得出结论。

# Windows PowerShell：测试独立复制的配置
.\mihomo.exe -t -f .\config-test.yaml
$LASTEXITCODE

测试失败时记录完整输出和退出码。含有规则集、地理数据或相对文件路径的配置，还依赖工作目录及外部资源；“资源不存在”与“YAML 语法错误”需要分开处理。测试通过只说明这次测试条件下配置检查通过，不代表服务权限、TUN 或网络连接全部正常。

1. 完整备份：退出应用，确认相关进程停止，把用户数据目录复制到单独位置。订阅、覆写脚本、规则与界面设置都可能在其中。
2. 撤回最后一次改动：如果故障出现在编辑规则或脚本后，优先还原这项修改；不要同时更新订阅、替换内核和修改端口。
3. 定位实际生效配置：客户端可能合并订阅、覆写与脚本后再交给内核。原始订阅能解析，不代表合并后的配置有效。
4. 隔离应用状态：只有日志指向某个界面状态文件时，才在备份后将该文件改名并测试。不要猜一个文件名后批量删除。

若必须用全新数据目录验证，应先停止客户端及其相关服务、保存原目录，再按该版本支持的方式创建独立环境。新环境能启动，只能说明旧环境里的配置或状态值得继续排查，不代表应永久丢弃全部订阅。恢复时分批导入，出现问题后即可缩小到某个配置或覆写项。

端口占用：确认监听进程

address already in use 或 bind 错误通常意味着监听地址冲突。常见示例端口包括 7890、7897 和控制接口使用的 9090，但它们不是所有版本的固定值。以当前生效配置中的 mixed-port、port、socks-port、external-controller 为准。

# Windows PowerShell：按实际报错端口调整列表
$ports = 7890, 7897, 9090
Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
  Where-Object { $_.LocalPort -in $ports } |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 示例：把 1234 换成上一步查到的实际进程 ID
Get-Process -Id 1234

上面的 1234 仅是演示进程 ID，不应直接用于结束进程。先核对进程名称、程序路径以及是否属于另一个已开启的代理客户端。旧内核残留时，优先从原客户端退出；若确需结束进程，只处理已经确认的那个实例。

• 两个客户端并行运行：给它们分配不同的代理监听端口和控制端口；只改代理端口，控制接口仍可能冲突。
• 修改了代理端口：同时核对系统代理和手动配置代理的程序，否则程序可能继续连接旧端口。
• 报错是访问被拒绝：不一定有普通进程占用，也可能涉及端口保留或安全策略，不能把它直接当成同一种错误。

若端口已经空闲但仍无法绑定，可用 netsh interface ipv4 show excludedportrange protocol=tcp 查看 IPv4 TCP 排除范围；IPv6 环境还应检查相应配置。不要为了代理启动随意删除系统保留范围，通常更适合先选择一个确认可用的端口验证。

内核权限与 TUN：分层恢复

遇到 permission denied、access is denied、无法创建 TUN 设备或服务连接失败，应先判断失败发生在“启动内核”还是“创建虚拟网卡”。系统代理主要影响遵循系统代理设置的应用；TUN 通过虚拟网络接口接管流量，涉及服务、权限和路由，排查路径更长。

先用非 TUN 模式建立基线

1. 若界面可操作，先关闭 TUN，保留规则模式，用系统代理测试同一个网站。
2. 非 TUN 模式可以使用而 TUN 失败时，重点查看服务状态、虚拟网卡和路由日志，不必马上更换节点。
3. 在当前版本的设置页检查服务模式；需要安装或修复服务时，仅对这一项授权，并观察操作后的日志。
4. 按 Win + R 输入 services.msc，核对对应服务的运行状态及可执行文件路径，防止服务仍指向旧安装目录。

管理员身份运行可以用于一次受控的权限对照，但不应成为掩盖问题的长期方案。若只有提升权限后才能访问某个用户数据文件，应检查文件所有者、目录访问权限及安装位置；随意放宽整个磁盘的权限会扩大风险。

Windows 还可查看「Windows 安全中心」→「病毒和威胁防护」→「保护历史记录」，确认是否有内核文件或组件被阻止。核对文件来源和事件详情后再处理，不要把关闭全部防护作为排查步骤。macOS 应结合「控制台」和「系统设置」→「隐私与安全性」中的提示判断；Linux 则要结合启动方式查看终端或服务日志，不能直接套用 Windows 的服务修复方法。

运行库与安装包：按故障模块修复

Windows 上基于 Tauri 的 Clash Verge 系列界面通常依赖 WebView2。缺少或损坏的界面运行时可能造成窗口无法创建，但不能仅凭“窗口一闪而过”就确定是 WebView2。应把系统事件中的故障模块、安装器错误和客户端日志放在一起判断。

Windows 的「设置」→「系统」→「系统信息」可查看系统类型；x64 与 ARM64 包应按操作系统和项目支持情况选择。macOS 则区分 Apple 芯片与 Intel 机型。架构选错、组件混用或旧文件未被正确替换，都比“订阅坏了”更接近这类加载错误。

需要重新安装时，先备份用户数据并保存当前版本信息，再关闭客户端和相关进程，使用同一项目的完整安装包。重装通常不会自动清除用户配置，因此重装后仍然闪退并不能排除配置问题。也不要把原版 Clash Verge、Clash Verge Rev 与其他客户端的程序文件混放到同一个目录。

恢复后的验证与问题报告

程序成功显示窗口只是第一步。建议按下面顺序恢复，每次只改变一个变量；一旦某一步重新触发错误，就保留该时间点的日志，回到上一项能正常工作的状态。

1. 验证界面：能够进入设置页，关闭再启动一次，确认不是只恢复了单次启动。
2. 验证内核：日志中没有持续的解析或监听错误，内核进程没有循环退出。
3. 验证本地代理：确认实际监听端口，再用遵循系统代理的应用测试访问。
4. 恢复配置：先导入一个已知可用的配置，再逐项恢复覆写、自定义规则和订阅更新。
5. 最后启用 TUN：检查 DNS、路由和访问是否正常，不把系统代理可用直接当成 TUN 也可用。

排查顺序可以归纳为：确认进程是否真的退出，按时间找到日志，再处理配置、端口、权限或运行时中的对应分支。需要核对配置字段时可查阅协议手册；恢复后遇到系统代理或订阅问题，可继续查看常见问题。更换客户端前先比较内核与平台支持，不必把所有启动故障都转化为迁移操作。