Clash Party v2.0.0 已于 2026-07-07 取代 v1.9.6，成为 GitHub Latest。大型订阅测速时界面卡顿、provider 节点显示不全、GNOME Wayland 每次启动都最大化，或 Windows 的 Post Up 钩子路径异常，可以安排升级。即使 v1.9.6 运行正常，也先导出备份，别把大版本号当成必须立即覆盖的通知。
官方 Release 没有要求清空配置目录，也没有公布固定的 Mihomo 内核版本。升级后要分别查看客户端版本和正在运行的内核版本，不能只看安装包文件名。
2.0.0 到底改了哪些工作路径？
这次新增服务商插件机制、拖拽安装插件、按状态切换托盘图标，以及可选的 Post Up 内核启动检测。侧边卡片还增加了记忆选择和锁定位置开关。它们会改变界面和启动检测，但不会自动修正错误的订阅内容。
下面这张表按故障表现找对应变化。没有命中这些表现，不必为了“2.0”三个字符打断正在工作的配置。
| 当前表现 | v2.0.0 对应变化 | 升级后看什么 |
|---|---|---|
| 大型订阅执行代理组延迟测试时界面明显卡住 | 优化代理组测速结果更新 | 同一 Profile、同一代理组再测一次，观察列表是否持续刷新 |
| 连接页应用图标越来越多，长时间运行后内存持续上升 | 限制连接图标与应用名称缓存大小 | 保持原使用方式，比较任务管理器或活动监视器中的进程内存 |
| GNOME Wayland 重启后窗口总是最大化 | 修复窗口尺寸记忆，同时处理 Windows 高 DPI 窗口逐次变大 | 调整窗口、退出、重开，确认宽高没有重置 |
| provider 节点显示不全或无法完成测速 | 适配 Mihomo API 变更 | 更新原 Profile 后核对节点数，再对同一 provider 测速 |
非 info / debug 日志等级下启动检测异常 | 修复生成配置与检测逻辑 | 保留当前日志等级，重启一次内核并查看第一条启动错误 |
| TUN 排除网段填错后，其他设置也无法保存 | 拒绝非法 CIDR，避免坏项卡住整页保存 | 先删掉错误网段，再保存一项无关设置 |
| Windows Post Up 钩子无法完成启动检测 | 修复钩子路径 | 只启用 Post Up 检测，重启内核后查钩子退出状态 |
| 配置热重载后 Gist 内容没有更新 | 修复热重载后的 Gist 同步 | 改一个可识别字段，热重载后再比对 Gist |
Release 还列出了白屏、IP 信息来源切换竞态、下载重试进度条抖动、PowerShell 5.1 版本误判、macOS 托盘模板图标、悬浮窗流量文字裁切和订阅刷新提示遮挡等修复。本文没有逐个平台安装复测，这些结论只按发布说明陈述。
哪些设备适合现在升级？
正在使用 provider、大型 Profile、Post Up 启动检测或 GNOME Wayland 的设备，升级收益最明确。尤其是 provider 列表被截断时，反复删订阅不会修复 Mihomo API 适配，换到 v2.0.0 才对应 Release 的处理范围。
依赖 TUN 排除网段的人也值得升级。旧界面允许保存非法 CIDR，错误项会拦住其他设置。v2.0.0 修的是输入和保存链路，不代表旧配置里的坏值一定会自动消失。升级后仍要打开 TUN 设置逐条看 route-exclude-address。
三类环境先保留 v1.9.6 安装包：
- TUN 承担远程维护、局域网共享或持续任务，短时中断也会影响工作。
- 使用自定义插件或启动钩子，但没有单独记录插件文件、参数和退出码。
- Windows 11 设备正好依赖 Apple Music，或曾出现 Wintun / Meta Tunnel 创建异常；文末列出的开放 Issue 需要先看。
v2.0.0 Release 没有写必须迁移数据格式，也没有承诺所有旧插件兼容。旧版稳定、又不使用上述功能时，可以先备份，等下一个维护窗口。
Windows、macOS、Linux 应该下哪个包？
安装包由系统版本、处理器架构和包管理器决定。文件名前缀同时存在 clash-party 与 mihomo-party 两套；Release API 中 36 对同平台资产的大小与 SHA-256 均相同，默认下载一套即可。
| 系统与处理器 | 默认文件 | 容易下错的文件 |
|---|---|---|
| Windows 10/11，Intel 或 AMD 64 位 | clash-party-windows-2.0.0-x64-setup.exe | arm64、ia32、.sha256 |
| Windows 10/11，ARM64 | clash-party-windows-2.0.0-arm64-setup.exe | x64-setup.exe |
| Windows 7/8，Intel 或 AMD 64 位 | clash-party-win7-2.0.0-x64-setup.exe | 不要用 windows 前缀替代 win7 |
| macOS 11+，Apple Silicon | clash-party-macos-2.0.0-arm64.pkg | x64.pkg、catalina 包 |
| macOS 11+，Intel | clash-party-macos-2.0.0-x64.pkg | arm64.pkg |
| macOS 10.15，Intel | clash-party-catalina-2.0.0-x64.pkg | macos、arm64 包 |
| Debian / Ubuntu，x86-64 | clash-party-linux-2.0.0-amd64.deb | RPM、ARM64 包 |
| Fedora / RHEL，x86-64 | clash-party-linux-2.0.0-x86_64.rpm | DEB、AArch64 包 |
| ARM64 Linux | 对应发行版的 arm64.deb 或 aarch64.rpm | amd64.deb、x86_64.rpm |
Windows 的 portable.7z 不等于更轻的安装版。它适合明确要把程序和便携数据放在固定目录的人；平时靠开始菜单、卸载器和覆盖升级管理软件，继续选 setup.exe。
升级前的 ZIP 实际备份了什么？
在设置页找到“备份与恢复”，点击“导出备份”。保存对话框默认生成 clash-party-backup-日期_时间.zip。导出结束后，先到文件管理器确认 ZIP 存在、大小不是 0，再开始覆盖安装。
v2.0.0 的备份源码显示，ZIP 会收入应用配置、受控 Mihomo 配置、Profile 配置、覆写配置，以及存在的 themes、profiles、override、rules、substore 目录。备份里可能含订阅内容和账号类配置，不要把原 ZIP 上传到公开 Issue。
再留一份纯文本状态，回滚时才能判断是程序、内核还是 Profile 发生变化：
Clash Party：v1.9.6
Mihomo：<关于页显示的完整版本>
当前 Profile：<名称与更新时间>
系统代理：开 / 关
TUN：开 / 关
日志等级：<当前值>
启动检测：默认 / Post Up
Sub-Store：启用 / 停用如果你使用外部插件，再把插件原文件放到 ZIP 之外。拖拽安装成功不等于插件包可以从配置里重新导出。
SHA-256 怎么和官方值对上？
v2.0.0 为每个安装资产都附了同名 .sha256 文件，GitHub Release API 也返回 digest。例如 Windows x64 setup 的 API digest 是 9f26ed34820260e710056de9e80e823b8b711809b1aad9bb456ead5269ee48da；macOS ARM64 PKG 是 a5e2e3fbb8a8b0ac981ab86bc5f4ebf1014ddec64dc0c9ce3a689607150550b4；Linux amd64 DEB 是 5355b359bdbdfc0cac9e53f114c953a143a85f72a9af74caa3ffbe885f485e4a。
macOS 或 Linux 把安装包与它的 .sha256 文件放在同一目录，再执行：
FILE="clash-party-macos-2.0.0-arm64.pkg"
EXPECTED="$(tr -d '\r\n ' < "$FILE.sha256")"
ACTUAL="$(shasum -a 256 "$FILE" | awk '{print $1}')"
printf 'expected=%s\nactual=%s\n' "$EXPECTED" "$ACTUAL"
test "$EXPECTED" = "$ACTUAL" && echo "SHA-256 OK"Windows PowerShell 用对应的 x64 setup：
$File = ".\clash-party-windows-2.0.0-x64-setup.exe"
$Expected = (Get-Content "$File.sha256" -Raw).Trim().ToLower()
$Actual = (Get-FileHash $File -Algorithm SHA256).Hash.ToLower()
[pscustomobject]@{ File = $File; Expected = $Expected; Actual = $Actual; Match = ($Expected -eq $Actual) }Match 必须为 True。摘要不一致就停止安装，删除安装包和摘要文件，从同一条 v2.0.0 Release 重新获取。不要拿 mihomo-party 文件的名字配 clash-party 摘要文件，即使对应二进制当前相同。
装完以后怎么确认升级没有改坏配置？
一次只验一个层面。不要在刚升级后同时换 Profile、改 DNS、开 TUN、装插件和切换启动检测。
- 打开关于页，确认 Clash Party 显示
v2.0.0；另记下 Mihomo 完整版本。 - 保持原 Profile，手动更新一次。先确认更新时间变化，再核对 provider 和代理组数量。
- 对原来使用的一个代理组执行延迟测试。大型订阅重点看列表刷新，不用一次测全部组。
- 打开最终配置，确认 TUN 排除网段都是合法 CIDR；不要只看设置页开关。
- 原来使用 TUN 的设备再开关一次，检查虚拟网卡、路由与第一条内核错误日志。
- 使用 Gist 同步的人只改一个容易识别的字段，热重载后比对远端内容。
- 最后再安装插件或切到 Post Up 检测，记录钩子退出码和内核启动时间。
Linux 可以先确认安装包登记的版本，再看进程：
# Debian / Ubuntu
dpkg-query -W -f='${Package}\t${Version}\n' clash-party 2>/dev/null
# Fedora / RHEL
rpm -qa | grep -E '^(clash-party|mihomo-party)'
# 只看匹配的运行进程，不在这里结束它
ps -eo pid,comm,args | grep -E '[c]lash-party|[m]ihomo'包名可能随安装资产采用 mihomo-party，所以两种前缀都要看。命令没有输出时先检查实际包名，不要据此删除配置目录。
v2.0.0 还有哪些已报告风险？
截至 2026-07-25，仓库有三条在 v2.0.0 发布后提交、且仍为 Open 的 Windows 11 报告。它们是用户提交，不等于维护者已经确认根因，也不能证明所有 v2.0.0 设备都会遇到。
| Issue | 报告的环境与表现 | 升级判断 |
|---|---|---|
#1999 | Windows 11 开 TUN 后 Apple Music 无法启动，报告版本为 v2.0.0 | 工作设备依赖该应用时，先保留 v1.9.6 和升级前 ZIP |
#1993 | Windows 11 出现 Meta Tunnel 感叹号、Mihomo 虚拟网卡未创建 | 不要直接照抄 Issue 内的注册表或驱动删除动作，先保存设备管理器错误码与内核日志 |
#1990 | Windows 11 固定到开始菜单后图标失真 | 属于界面报告，不影响订阅和内核运行，可单独观察 |
#1993 正文包含提交者自己的系统修复过程，其中涉及驱动与注册表。它不是项目维护者发布的通用修复。没有相同错误码时不要执行，更不要为了排除一个变量先做系统级重置。
回到 1.9.6 时先退程序还是先恢复配置？
先退程序。退出 Clash Party 托盘与后台进程，保留 v2.0.0 日志，再安装 v1.9.6 官方 Release 中对应系统和架构的包。重开后确认客户端版本已经回到 v1.9.6，然后用原 Profile 测一次。
程序回退后恢复正常，就先保留现有配置，不必导入 ZIP。只有 Profile、覆写、规则或 Sub-Store 内容确实被改变，才到“备份与恢复”导入升级前的文件。v2.0.0 源码会把 ZIP 解压到数据目录，并覆盖备份中同名文件；这个动作不能当作第一步。
官方 Release 没有单独的降级步骤，也没有说明新旧配置是否存在迁移边界；上面的顺序是为了减少覆盖范围，不是官方回退承诺。如果故障仍在，问题更可能落在 Mihomo 内核、系统虚拟网卡或原 Profile，而不是桌面程序版本。把 v1.9.6、v2.0.0 的客户端版本、Mihomo 版本和第一条错误日志放在同一条记录里，再对照 Mihomo Party 客户端页 与 TUN、DNS hijack 排查。这样才能判断该继续回滚，还是只修一条 CIDR 或启动钩子。