先看结论：上传成功，需要文件完整性的证据
实际处理日期：2026年9月29日。群合官网一个约14 MB的主题 ZIP 上传中断。在保留 HTTPS、证书和安全规则的前提下，对该站 HTTP 协议进行兼容处理，随后上传成功。
本次验证了文件入库与下载完整性；浏览器、网络链路和服务器 HTTP/2 处理中的具体根因仍未定位。本文是历史工作记录，不把兼容处理说成彻底根治。
文件没有超限，为什么仍然上传失败？
后台显示的上传限制为50 MB，待上传 ZIP 实际为14,367,077字节，压缩包检查通过。原文件名和简短英文文件名都曾失败，因此不能直接归因于超限或中文文件名。
页面提示“从服务器收到预料之外的响应”；浏览器曾出现 ERR_HTTP2_PING_FAILED。与该次上传对应的服务器请求多次记录为 HTTP/2，状态499。这些证据指向进一步检查上传链路，但不足以单独认定 SSL 证书、浏览器或服务器的具体故障。
怎样处理：备份之后，只改变一个条件
- 保留原 ZIP，核对实际大小、ZIP 完整性及后台上传限制。
- 对应上传时间核对浏览器错误和上传端点日志，不根据通用提示盲目提高上限。
- 仅将目标站的 HTTP/2 切换到 HTTP/1.1 进行兼容对照；HTTPS、原证书、安全规则及其他网站保持不变。
- 用原文件名再次上传，等待完整入库；此次没有安装主题，也没有执行其他站点升级。
怎样验证：进度条结束只是第一步
- 请求：成功上传请求使用 HTTP/1.1，返回200。
- 媒体记录：刷新媒体库后，附件记录与文件链接仍可正常打开。
- 公开文件：重新下载返回200，实际大小仍为14,367,077字节。
- 完整性：下载文件与原件逐字节一致，SHA-256一致。
- 网站访问：首页复查返回200。
因此可以确认本次文件完整入库。仅看到状态200、文件名或媒体库缩略图，不能单独证明上传文件未损坏。
为什么不建议所有网站都关闭 HTTP/2？
本次 HTTP/1.1 是特定环境下验证有效的兼容方案，可能影响并发资源加载效率。HTTPS与HTTP协议版本是不同层面的设置；本案并未关闭加密连接。
相似报错仍需要按实际环境排查。Nginx版本、CDN、代理和协议终止位置不同，配置方式也会不同。在尚未定位根因前恢复 HTTP/2，可能重现上传中断；应先做受控对照并保留回退方案。
记录只保留问题、实施范围及验证结果，移除了服务器地址、后台入口、凭据和真实文件下载地址。技术参考：Nginx HTTP/2 模块官方文档。
遇到同类问题？提供网址、完整错误提示及发生时间，便于判断排查范围。约定的后台处理由群合执行。
