中文 
𰻞𰻝面
deepin
2026-09-07 03:53 deepin 没有遇到啊，可以安装成功。是不是你的网络运营商进行流量劫持，导致数据异常，换个DNS试试
Reply Like 0 View the author
All Replies
#1
加菲不是胖橘
2026-09-07 10:45 deepin product team
目前只看到你这一例下载失败，可能是你这边网络问题下载的包不完整，你apt update更新下索引了再重新安装试试。
Reply Like 0 View the author
Frank-lab-hash
deepin
2026-09-07 12:27 deepin 加菲不是胖橘：
目前只看到你这一例下载失败，可能是你这边网络问题下载的包不完整，你apt update更新下索引了再重新安装试试。
已多次执行 apt update，索引签名验证正常。进一步抓取 HTTP 响应后发现并非下载中断：当前 Packages 索引声明 deepin-wine-builder 大小为 25893570，但 CDN 对象自身通过 Content-Range 明确声明总大小为 25804938。
当前响应长期为 X-Cache-Status: HIT，Age 已超过 6 天，Last-Modified 为 8 月 27 日；Cache-Control: no-cache 后仍返回同一对象。
另一位用户能正常安装，因此我怀疑可能只是部分 CDN/网络路径命中了旧缓存，而非全局问题。能否帮忙检查一下 e2b82cf32e9a430ca47aa33d5a1135c8.deb 的 CDN 缓存/对象映射是否正常？
Reply Like 0 View the author
neko
deepin
2026-09-07 13:49 deepin Ecological co-builder
Q&A Team
大概率是区域CDN同步的锅，开源用超级ping改hosts指定host到其它CDN服务器应该能暂时解决。
Reply Like 0 View the author
在月光下等候清晨 deepin
2026-09-08 11:09 deepin apt更新索引后，通过应用商店更新兼容引擎、通过终端apt更新兼容引擎是否正常，如果正常就不要再纠结了。
Reply Like 0 View the author
Frank-lab-hash deepin
2026-09-08 14:42 deepin 又做了进一步多节点测试。通过 AliDNS/Google DoH 获取真实公网地址后，用 curl --resolve 保持官方 hostname、SNI 和正常 TLS 校验逐节点测试：
- 两个 App Store 入口 IP
120.77.173.206、112.74.190.222都 307 到同一个e2b82cf32e9a430ca47aa33d5a1135c8.deb - 文件 CDN 测试了
220.205.124.35、156.238.128.8/9/10 - 四个节点全部返回
Size=25804938 - ETag、Last-Modified、CRC64 也完全一致
但当前已签名 Packages 索引仍要求：
Size=25893570
SHA256=62475ed8562a446769396e534fb067bfeee71132d60cf1d31fd09f5baa2d0721
因此基本可以排除单个区域 CDN edge 缓存异常。看起来更像 App Store 的 package→apppkg 映射、共享上游缓存、origin object 或发布流程问题。麻烦官方重点检查 e2b82cf32e9a430ca47aa33d5a1135c8.deb 对应的源对象是否正确。
Reply Like 0 View the author
Please sign in first
Popular Ranking
Change
List of bugs and suggestions Popular Events
More
【应用商店/CDN】deepin-wine-builder 包元数据与实际 CDN 对象长期不一致，导致 APT 无法安装
问题概述
在 Deepin 25 Crimson 环境中尝试安装「统信 Windows 应用兼容引擎」时，发现：
App Store 已签名的 Packages 索引中记录的
deepin-wine-builder文件 Size / SHA256，与 App Store CDN 实际返回的.deb对象不一致。该问题已经持续多日。
APT 的完整性校验因此正确拒绝安装。
目前观察到的现象不是依赖冲突、签名错误或本地 APT 数据损坏，而是：
APT 主源：
App Store：
目标软件包
当前 APT Candidate：
Packages 中的 Filename：
已签名 APT 元数据
正常执行：
成功：
当前 InRelease：
APT 当前已验证 Packages 数据：
CDN 实际返回对象
入口：
入口返回：
最终映射到：
使用与 APT 类似的 User-Agent 请求，可以正常返回文件。
通过：
测试得到：
因此 CDN 实际对象总大小为：
但签名 Packages 索引要求：
差值：
CDN 缓存信息
当前响应：
OSS 信息包括：
Age = 536459，约：此前同一对象观察到：
随后增长到：
增长约：
在此期间以下信息始终未变化：
Cache-Control 测试
使用：
重新请求。
结果仍然：
ETag、Last-Modified、对象内容特征均未变化。
no-cache没有使 CDN 获取与当前 Packages 索引匹配的新对象。Cache-busting 测试
对 App Store 入口 URL 添加唯一 query string：
结果：
因此客户端无法通过普通 cache-busting 绕开该旧对象。
APT 实际表现
执行正常安装时，APT 报错类似：
APT 没有开始解包软件包。
随后检查：
正常。
正常。
以下包均未安装：
已排除的问题
已经确认：
APT 签名问题
不是。
签名验证成功。
没有：
或其他认证错误。
软件依赖问题
不是。
在当前 Deepin 25 Crimson 环境中：
均满足 Builder 要求。
执行：
可以正常解析：
无：
本地 APT/dpkg 损坏
不是。
当前判断
目前可以确认：
当前网络路径持续命中：
的旧对象，而当前已签名 Packages 要求：
并且：
同时：
Cache-Control: no-cache无效因此高度怀疑以下环节之一存在异常：
由于当前网络使用代理/TUN，DNS 返回 Fake-IP，无法直接枚举真实 CDN edge，因此无法进一步确认具体是哪一级 CDN 节点出现问题。
希望官方协助检查
请协助检查：
对应：
是否确实应该对应当前 Packages 中：
以及 App Store/CDN 是否需要：
目前没有使用：
也没有绕过 APT 的完整性检查。