Clash Verge 打开就闪退：启动崩溃的排查顺序与修复办法

先区分：窗口崩溃、后台驻留，还是内核启动失败

Clash Verge 的界面进程、代理内核和系统服务不是同一个组件。窗口消失不一定代表整个客户端退出；窗口正常显示但内核启动失败，也不能直接归因于 WebView2。先记录系统版本、客户端完整版本、安装包架构，以及故障发生在更新后、导入订阅后，还是首次安装时。

旧版 Clash Verge 与后续维护的 Clash Verge Rev 不应当作同一发行版本处理。两者的数据目录、服务名称、设置标签可能不同。能进入界面时，到「设置」页面的版本信息区域记录版本；进不去时，从安装包文件名或可执行文件属性确认，不要仅凭桌面快捷方式名称判断。

1. 检查任务栏通知区域；Windows 可打开隐藏图标，macOS 检查菜单栏。
2. 退出客户端后，再查看任务管理器或活动监视器。只结束已确认属于该客户端的残留进程。
3. 启动一次并记录准确时间。不要连续双击，否则单实例锁和多个启动记录会干扰判断。

第一步：Windows 检查 WebView2 与应用程序错误

Windows 上的 Clash Verge 界面依赖 WebView2。Microsoft Edge 浏览器能正常打开，不等于 WebView2 Runtime 一定正常。若主窗口白屏、出现 WebView2 创建失败提示，或崩溃记录涉及 WebView2 组件，应先处理运行环境，而不是反复修改订阅。

修复运行库的操作顺序

1. 退出客户端。在 Windows 11 打开「设置」→「应用」→「已安装的应用」，搜索 Microsoft Edge WebView2 Runtime。部分系统的应用列表展示方式不同，搜索不到不能单独作为缺失结论。
2. 若条目提供「修改」或修复入口，按提示执行；若没有，使用微软官方提供的 Evergreen WebView2 Runtime 安装程序修复或补装。离线环境可使用对应架构的独立安装程序。
3. 完成安装后，重启客户端；安装程序要求重启系统时，先保存工作再重启。
4. 仍然闪退时，按 Win + R，输入 eventvwr.msc，查看「Windows 日志」→「应用程序」，按刚才记录的时间查找错误。

事件来源为 Application Error、事件 ID 为 1000 的记录可作为线索，但并非每次故障都有这一条。保留“故障应用程序名称”“故障模块名称”“异常代码”。仅看到 ntdll.dll 不能断定系统文件损坏，它可能只是异常最终发生的位置。

白屏与真正闪退分开处理

若窗口白屏但进程一直存在，优先保留界面日志，再检查运行库和用户数据。若连进程都没有留下，应同时看系统应用程序错误。不要把网上流传的禁用 GPU 参数直接套到所有版本；不同构建未必接受相同参数，未经确认的启动参数可能根本没有生效。

WebView2 的检查只适用于 Windows。macOS 使用系统 WebKit；Linux 构建通常依赖 WebKitGTK 等系统组件，不能通过安装 Windows 运行库修复。

第二步：检查端口占用，区分代理端口与控制端口

日志出现 address already in use 或 Only one usage of each socket address 时，先检查监听端口。端口占用通常造成内核启动失败，不一定使界面崩溃。若界面也退出，应继续检查界面日志，不要把两个现象混为一谈。

配置中的 mixed-port 是混合代理入口，external-controller 是控制接口。下面使用 7897 和 9090 演示查询，它们不是所有版本的固定默认值；请替换成日志或当前配置中的实际端口。

Windows：先找到监听进程

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

Get-Process -Id 4321

在 PowerShell 执行第一条命令，再将第二条命令的 4321 换成实际的 OwningProcess。没有输出只说明查询时这些 TCP 端口没有监听，不能证明内核其他端口也正常。不要照着示例 PID 结束进程。

macOS 与 Linux：检查监听者

# macOS
lsof -nP -iTCP:7897 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7897'
ss -ltnp 'sport = :9090'

• 如果占用者是另一款代理客户端，先从其托盘或菜单栏正常退出，再重试。
• 如果是上一次启动留下的内核，先确认所属路径，避免误停其他用户或其他软件的服务。
• 确需改端口时，在客户端支持的端口设置中调整；若存在覆写配置，还要检查最终生效值，不要只改订阅原文件。

代理端口改变后，浏览器扩展、终端的代理环境变量及其他手工配置也要同步。控制端口调整后，客户端与内核的连接地址需要一致。不要为绕过本地故障，将控制接口直接暴露到 0.0.0.0。

第三步：备份用户数据，隔离损坏的配置

如果故障恰好出现在导入订阅、修改 YAML 或升级之后，配置和本地状态应列为重点。卸载程序往往保留用户数据，因此“卸载再安装”未必改变启动时读取的内容。正确方法是先备份，再让程序以新的数据目录启动。

先定位目录，不要按软件名称猜路径

能打开界面时，优先使用「设置」中的配置目录或日志目录入口；不同发行版名称可能是「配置目录」「打开配置目录」或「应用目录」。无法进入时，检查以下系统位置中的应用专属子目录，并结合目录修改时间、日志和应用标识确认归属。

• Windows：在资源管理器地址栏分别输入 %APPDATA% 与 %LOCALAPPDATA%。配置与 WebView 缓存可能分开保存。
• macOS：在访达使用「前往」→「前往文件夹」，检查 ~/Library/Application Support/ 下的对应应用目录。
• Linux：检查 ${XDG_CONFIG_HOME:-$HOME/.config} 与 ${XDG_DATA_HOME:-$HOME/.local/share} 下的应用目录；自定义 XDG 环境变量时以实际路径为准。

用改名方式建立空白环境

1. 退出客户端和已确认属于它的后台进程，必要时先停止对应服务。
2. 把整个应用配置目录复制到单独的备份位置。备份可能包含订阅地址、节点凭据和控制接口密钥，应限制访问。
3. 将原配置目录改名，加上 .backup-20261017 等可识别后缀。不要删除整个 AppData、Library 或 .config。
4. 启动客户端，暂不导入旧配置，不开启 TUN，确认主窗口能否稳定打开。
5. 若新环境正常，先导入一份确认可用的订阅，再逐项恢复规则覆写、脚本和其他设置。

日志出现 yaml: line、unmarshal 或策略名称不存在等错误时，应检查对应行、字段类型与引用关系。YAML 缩进使用空格，同级字段对齐；策略组引用的节点或组名需要实际存在。客户端外壳能打开，不代表当前内核一定支持旧配置中的所有字段。

第四步：排查服务模式残留与 TUN 权限

服务模式用于让后台组件以所需权限运行，TUN 则通过虚拟网卡接管流量；两者有关联，但不是同一开关。系统代理可用、开启 TUN 才失败时，应优先看服务状态、权限和虚拟网卡，而不是重新安装 WebView2。

先恢复普通代理，再处理服务

1. 能进入设置时，先关闭 TUN，再使用客户端提供的服务模式管理入口停止或修复服务。具体按钮以当前版本显示为准。
2. Windows 按 Win + R，输入 services.msc。在候选服务的「属性」中核对可执行文件路径，确认是否指向旧安装位置。
3. 若升级后仍存在旧服务，优先用原客户端或对应安装程序提供的卸载、修复流程处理，再由当前客户端安装服务。
4. 重新启动后，先在 TUN 关闭的情况下验证界面和内核，再单独测试 TUN。

不要根据相似的显示名称直接执行 sc delete，也不要批量删除虚拟网卡。旧服务路径失效、服务无法启动、路由冲突需要分别处理；管理员权限只能解决其中一部分权限问题，不能修复损坏的配置或被占用的端口。

macOS 的后台辅助组件、Linux 的 systemd 服务同样应核对程序路径。若服务文件属于另一款仍在使用的客户端，不要顺手清理。公司设备还可能受网络策略限制，需先确认设备管理要求。

第五步：查看安全软件拦截记录，不要直接全局关闭防护

“昨天正常，今天突然打不开”可能与程序更新、内核文件被隔离或安全策略变化有关。Windows 打开「Windows 安全中心」→「病毒和威胁防护」→「保护历史记录」，对照闪退时间查看是否涉及客户端、内核或辅助服务文件。

• 记录被处理文件的完整路径、检测名称和时间。仅凭桌面图标仍在，不能判断程序文件完整。
• 先确认安装包来自对应项目的正式发布渠道，检查发布说明及系统提供的签名信息；不要恢复来源不明的可执行文件。
• 确认属于误拦截后，再按组织策略处理申诉或最小范围的例外，不要将整个下载目录或用户目录加入排除。
• 受控文件夹访问若阻止写入，也可能使应用无法保存状态；只为已确认可信的具体程序授权。

macOS 如显示“无法验证开发者”或“应用已损坏”，先重新下载匹配架构的正式安装包，并查看系统安全提示。不要直接执行批量移除隔离属性的命令。Linux 则需同时检查文件执行权限、系统日志和安装包依赖错误。

各平台清理重装：保留证据，分阶段恢复

前面的检查仍无法定位时，再进行清理重装。先保存崩溃日志、版本信息和用户数据备份，并关闭系统代理，避免卸载后浏览器继续连接已经不存在的本地端口。安装目标是当前系统支持的维护版本，不是随意找一个更旧的安装包。

Windows

1. 正常退出客户端，停止已核实的服务，然后到「设置」→「应用」→「已安装的应用」卸载对应程序。
2. 将已确认属于该应用的残留配置目录改名保留；不要删除共享的 WebView2 Runtime。
3. 按系统架构重新安装。若出现文件占用或服务仍运行的提示，先处理残留进程，必要时重启系统。
4. 首次启动不恢复旧配置。界面正常后依次测试订阅、系统代理、服务模式，最后测试 TUN。

macOS

1. 从菜单栏退出客户端；通过客户端支持的流程卸载其辅助服务，再移除「应用程序」中的旧应用。
2. 备份并改名对应的 Application Support 数据目录。不要清空整个 Library。
3. 从苹果菜单的「关于本机」确认设备使用 Apple 芯片还是 Intel 处理器，再选择相应安装包。
4. 若仍崩溃，在「控制台」中检查崩溃报告，并留意 ~/Library/Logs/DiagnosticReports/ 内对应时间的报告。

Linux

1. 确认安装方式是 DEB、RPM 还是其他发行格式；先用原包管理方式卸载，避免同时保留多个来源的桌面入口。
2. 从终端启动实际可执行文件并保存标准错误输出。检查缺失库、显示会话和权限错误，再按发行版要求安装依赖。
3. 备份并改名对应 XDG 数据目录后重装。WebKitGTK 依赖名称因发行版与构建而异，不要跨系统照抄旧依赖清单。
4. 普通桌面窗口稳定后再配置服务与 TUN。不要为了能打开窗口，长期以 root 身份运行整个图形客户端。

恢复后验证：每次只加回一项设置

修复完成的标准不仅是窗口出现，还包括内核持续运行、日志不再重复报错、退出后系统网络能恢复。建议按以下顺序验证，哪一步重新出现故障，就回到该环节检查，而不是再次从头卸载。

1. 空白启动：不导入旧数据，连续启动和退出两次，确认窗口、托盘与后台进程行为一致。
2. 单份配置：导入确认可用的订阅，检查配置是否被选中，内核是否成功加载。
3. 系统代理：核对实际监听端口，开启系统代理后访问日常使用的网站，查看请求是否出现在连接记录中。
4. 自定义规则：逐项恢复覆写、脚本及规则集。问题重现时，保留本次新增项与报错行。
5. TUN 与服务：最后启用，检查是否与其他 VPN、虚拟网卡或企业网络软件冲突。

需要提交问题反馈时，附上系统版本与架构、客户端和内核版本、安装方式、故障发生时间、触发步骤、空白配置是否复现，以及相关日志。删除订阅链接、节点地址、密码、控制密钥和个人路径中的敏感信息。能明确说明“空白配置可启动，恢复某项覆写后失败”，通常比只写“打开就闪退”更容易定位。