Clash Verge Rev 更新失败,常见表现是点击“更新”后出现 error sending request for url,或下载进度长时间不动。排查时应确认报错地址是否指向软件安装包;确认是下载环节失败后,可以从项目发布页手动下载对应安装包升级,不必反复点击更新。
如果当前版本仍能正常使用,不必急着卸载。先下载好新安装包、备份配置,再退出旧程序完成升级。下载报错、安装报错和升级后仍显示旧版本,需要分别处理。
Clash Verge Rev 更新失败的类型与排查顺序
更新弹窗出现,只说明客户端取得了新版本信息。安装包还需要单独下载,之后才会启动安装程序。报错地址和弹窗内容可以帮助定位失败的环节。
| 故障现象 | 优先检查什么 | 下一步 |
|---|---|---|
| 报错地址以 update.json 或 update-proxy.json 结尾 | 版本信息请求未成功 | 到发布页确认是否有适用的新版本 |
| 地址包含 releases/download,末尾是 .exe 或 .app.tar.gz | 软件更新包下载失败 | 用浏览器尝试下载官方安装包 |
| 进度条缓慢或停住 | 下载连接是否仍在传输 | 比较浏览器下载,必要时换网络再试 |
| 提示 invalid Zip archive | 收到的文件无法作为预期压缩包读取 | 重新获取正确安装包,不重复使用异常文件 |
| 安装结束,打开后仍是旧版本 | 启动的程序路径、是否存在多个安装副本 | 检查实际启动位置 |
如果错误发生在订阅卡片上,地址是机场提供的订阅接口,处理方法参见订阅请求失败与超时排查。相同的错误文字可能出现在不同请求中,判断依据是操作位置和完整地址。
error sending request for url:更新包没有下载成功

图中的下载地址经过 download.clashverge.dev 中转,目标是 GitHub 上的 macOS 更新包。error sending request for url 表示请求未成功,具体原因还需结合网络连接和日志判断。此时尚未进入安装阶段,不需要改动订阅配置。
开启代理后,用浏览器下载安装包
下载前,选择可用节点并开启系统代理,确认浏览器能够访问 GitHub 并下载安装包。需要订阅可参考Clash 机场推荐。
- 保持客户端运行,选择一个可用节点,并开启“系统代理”。仅选中节点并不代表浏览器已经使用代理;如果浏览器单独配置了代理插件,还需要检查插件设置。
- 确认浏览器能通过代理访问 GitHub,再打开Clash Verge Rev 正式版发布页。
- 展开 Assets,选择与你的系统和处理器架构一致的安装包。
- 确认下载能够完成,而不只是发布页能够打开。GitHub 页面和附件下载可能使用不同的域名。
浏览器能完成下载:直接用下载好的安装包手动升级。浏览器与客户端可能使用不同的下载地址或代理路径,因此浏览器能下载,并不保证应用内更新也能成功。
浏览器同样下载失败:先记录错误,再更换一个可用节点或网络做对比。每次只改变一项,确认能否完整下载;不要同时更改 DNS、代理模式和系统设置,否则无法判断哪项起作用。
切换全局模式是否有用?
全局模式只会影响进入代理的请求。如果更新请求没有经过代理,或下载服务本身异常,切换模式也未必有效。可以临时切换并重试一次,测试结束后恢复原模式。模式区别可参考规则、全局与直连模式说明。
手动升级:下载正确安装包,再替换程序
手动升级绕过的是应用内下载环节。下载期间保持旧版客户端和系统代理开启,安装包完整下载到电脑后,再退出客户端进行安装。如果当前客户端已经无法连接,需要使用其他可用的代理工具或能够访问 GitHub 的网络下载,不要先卸载当前版本。
第一步:备份配置
保留订阅地址、自定义规则、脚本和必要设置的副本。如果当前版本提供备份功能,先生成并检查备份;同时记录程序版本和原安装位置。订阅链接包含访问凭据,不要放进公开截图、评论或问题反馈。
第二步:选择与你的设备匹配的文件
| 设备 | 通常选择的安装包 |
|---|---|
| Windows,Intel / AMD 64 位处理器 | x64 的 setup.exe |
| Windows,ARM 设备 | arm64 的 setup.exe |
| Mac,Apple M 系列芯片 | aarch64 的 .dmg |
| Mac,Intel 芯片 | x64 的 .dmg |
不要选 Source code,也不要把自动更新使用的 .app.tar.gz 或签名文件当作普通安装包。Windows 可在“设置 → 系统 → 系统信息”确认系统类型;Mac 可在“关于本机”确认芯片或处理器型号。系统最低要求以项目安装说明为准。
第三步:退出旧程序后安装
Windows:从托盘菜单退出客户端,而不只是关闭窗口。运行下载好的安装程序,核对目标目录与原安装位置一致,按安装向导完成操作。如果提示程序仍在运行,先检查是否有另一个窗口或会话正在使用,不要直接删除安装目录。
macOS:退出正在运行的客户端,打开下载好的 DMG,将应用放入“应用程序”目录,出现同名应用提示时确认替换。随后从“应用程序”目录启动,不要继续运行磁盘映像里的副本。
如果原来通过包管理器安装,或使用便携目录,请沿用原来的升级方式,避免产生多个安装副本。首次安装步骤参见客户端下载与安装教程。
第四步:检查版本和原配置
打开设置中的版本信息,确认已经变成刚安装的版本,再检查订阅、规则和连接。如果订阅或规则没有显示,先确认启动的是新安装的程序,以及用户和配置目录是否与升级前一致。确认后再恢复备份,并保留一份原始备份文件。
下载进度卡住,或出现压缩包错误怎么办?
下载进度长时间停滞时,应检查传输速度是否仍有变化,并与浏览器下载同一发布版本的表现比较。若浏览器能够顺利完成,使用手动升级即可,不必等待应用内重复下载。

invalid Zip archive: Could not find central directory end 表示收到的内容无法按预期 ZIP 格式读取。下载不完整、服务器返回的内容不是预期压缩包,都可能触发这类错误。应先重新下载文件,不能直接归因于磁盘故障。
不要修改文件扩展名后强行安装。重新从正式发布页取得适用安装包,并确认下载完成。如果发布页提供校验值,可以核对文件是否一致;若下载正常仍无法安装,应保留完整错误信息,转而排查安装环节。
安装完成后,为什么打开还是旧版本?
先检查启动入口。桌面快捷方式、任务栏固定项和原安装目录可能指向不同副本。Windows 可检查快捷方式的目标路径,再与新安装位置比较;Mac 应检查是否仍在打开下载目录或挂载映像里的旧应用。
部分旧版本升级时可能无法正确识别原安装目录,导致新旧版本分别装在不同位置。确认存在多个安装副本后,先备份配置,再移除多余副本并重新安装最新版。
仍然失败时,需要提供哪些信息?
提交反馈前,记录当前版本、目标版本、操作系统和处理器架构,再补充以下信息:
- 在哪个阶段失败:检查版本、下载、安装,还是启动后版本没有变化。
- 完整报错和对应截图,尤其是请求地址的域名、文件名。
- 浏览器能否下载官方安装包,换网络后结果是否不同。
- 与失败时间对应的应用日志片段。
上传截图和日志前,记得遮住订阅链接中的 token、账号、密钥及个人路径。这些信息与软件更新故障无关,不需要发给其他人。