zijunchiang
7037abf066
docs(proxy): 修正 Gitea 附件上传失败的结论——与体积无关，指向宿主机磁盘
上一版把失败记成「两阶段 + 约 16.4 MB 边界」，那是**误判**：
当时磁盘正在被失败的请求逐步填满，所以看起来像有个体积阈值。补做与体积、
与仓库都无关的隔离测试后，结论要改：
- 1 KB 与 100 KB 也失败，且**瞬间**失败（0.14~0.3 s，不是读完请求体才判断）
-> 不是 [attachment] MAX_SIZE 这类体积上限；
- opendance-web / opendance-windows / opendance-android 三个 Release 的资产
上传接口**同样**失败 -> 与仓库无关；
- 创建 Release、PATCH Release 说明（纯 JSON）都成功 -> 只有「附件文件落盘」
这条通道坏掉；
- 全部失败期间仍有 927 KB 的附件成功上传过一次 -> 间歇性。
最可能的原因：**Gitea 宿主机磁盘（或上传临时目录所在分区/tmpfs）几乎写满**
（Gitea 先把请求体写入数据目录的临时目录，空间不足时返回 500 而非 413）。
同时确认：IIS 那一关**已经放开且生效**（38,245,661 字节的请求体被完整接收，
不再 413），因此若仍失败应直接排查 Gitea 宿主机，而不是继续改 IIS。
deploy/proxy/README.md 第九节的 9.1 重写为上述隔离结论，并给出运维排查顺序
（df -h / Gitea 日志里的真实错误 / 清理临时文件 / 最后再改 MAX_SIZE）。
Windows 端 tasks/014-full-package.md 同步修正（原先的「16.4 MB 边界」表述作废）。
2026-09-17 01:51:32 +08:00
..
2026-09-15 00:34:52 +08:00
2026-09-15 00:34:52 +08:00
2026-09-17 01:51:32 +08:00
2026-09-15 21:25:25 +08:00
2026-09-17 00:05:02 +08:00
2026-09-16 02:56:50 +08:00
2026-09-16 02:55:32 +08:00
2026-09-15 22:26:58 +08:00
2026-09-15 22:26:58 +08:00
2026-09-15 13:55:54 +08:00
2026-09-16 02:55:32 +08:00
2026-09-15 01:27:47 +08:00