From 698d60bb65e14cd35b59cfdd3f21faa04aa6a3d6 Mon Sep 17 00:00:00 2001 From: zijunchiang Date: Thu, 17 Sep 2026 01:40:27 +0800 Subject: [PATCH] =?UTF-8?q?docs(proxy):=20=E8=AE=B0=E5=BD=95=20Gitea=20?= =?UTF-8?q?=E9=99=84=E4=BB=B6=E4=B8=8A=E4=BC=A0=E4=B8=8A=E9=99=90=E7=9A=84?= =?UTF-8?q?=E4=B8=A4=E9=98=B6=E6=AE=B5=E5=AE=9E=E6=B5=8B=EF=BC=88IIS=20?= =?UTF-8?q?=E6=94=BE=E5=BC=80=E5=90=8E=E4=BB=8D=E6=98=AF=20500=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 按文档 §5.7 硬性要求 4「若用 A 方案，先在发布文档里记录实测上限」，把这次 Windows v0.2.0 整包（38,245,661 字节）发布的实测结果写进 deploy/proxy/README.md 第九节，并修正第九节里「只改 IIS 就够」的隐含假设： 第一阶段（IIS 未放开）：14 MB 通过；30.5 / 40 MB 返回 HTTP 413。 第二阶段（IIS 已放开）：38,245,661 字节的请求体被**完整接收**（115 s）， 不再有 413 —— 说明 maxAllowedContentLength 已经够用；但随后 **Gitea 自己返回 HTTP 500**（响应体是 Gitea 的 API 错误信封，message 为空），瓶颈转移到了 Gitea 侧。 同接口边界测量：914 KB 与 16,372,427 B 通过；16,400,000 B 及以上失败； 且**在若干次大包失败之后，连 100 KB 都会在 0.3 秒内 500** —— 这不符合「上传体积上限」的特征（体积判断会先读完请求体）， 更像上传临时目录 / 数据盘写满（Gitea 先写 data/tmp）。 因此文档明确要求运维按顺序查两件事：①Gitea 数据盘剩余空间（含 data/tmp， 以及它是否在小容量 tmpfs 上）并清理失败上传的残留临时文件； ②app.ini 的 [attachment] MAX_SIZE。并在 IIS 配置小节加醒目提示： 若放开 requestLimits 后仍为 500 而非 413，说明请求体已到达 Gitea， 要按上述两件事继续排查。 --- deploy/proxy/README.md | 36 +++++++++++++++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/deploy/proxy/README.md b/deploy/proxy/README.md index 62ab205..d2a4597 100644 --- a/deploy/proxy/README.md +++ b/deploy/proxy/README.md @@ -236,7 +236,9 @@ firewalld / ufw / iptables 的放行情况，并直接给出修复命令。 > **Gitea**（源码仓库 + Release 附件）的站点。Windows 客户端的发布整包走 Gitea， > 因此**必须**单独放开 Gitea 站点的上限。 -### 9.1 实测结论 +### 9.1 实测结论（两阶段） + +**第一阶段（IIS 上限未放开时）** | 上传体积 | 结果 | |--|--| @@ -244,6 +246,34 @@ firewalld / ufw / iptables 的放行情况，并直接给出修复命令。 | 30.5 MB | **失败 HTTP 413**（IIS「请求实体过大」页面） | | 40 MB | **失败 HTTP 413** | +**第二阶段（IIS 上限放开之后）** —— 放开的效果是**可验证**的： +38,245,661 字节的请求体被**完整接收**（耗时 115 s），不再出现 413， +说明 IIS 的 `maxAllowedContentLength` 已经够用。但随后 **Gitea 自己返回 HTTP 500** +（响应体是 Gitea 的 API 错误信封 `{"message":"","url":".../api/swagger"}`， +`message` 为空）——即瓶颈已从 IIS 转移到 Gitea 侧。 + +同阶段的边界测量（同一个 Release 的资产上传接口）： + +| 上传体积 | 结果 | +|--|--| +| 914 KB（web v0.7.1 tar.gz） | 通过 | +| 16,372,427 B（android v0.2.0 zip） | 通过 | +| 16,400,000 B | **HTTP 500** | +| 16,500,000 B / 18 MB / 21 MB / 24 MB | **HTTP 500** | +| 100,000 B（在第一轮失败之后） | **HTTP 500，且仅耗时 0.3 s** | + +最后一行是关键：**在若干次大包失败之后，连 100 KB 都会在 0.3 秒内 500** —— +这不符合"上传体积上限"的特征（上限判断会先读完请求体）， +更像**上传临时目录 / 数据盘已满**（Gitea 先把请求体写入 `data/tmp`， +失败时可能在磁盘上留下残留临时文件）。 + +> **因此运维侧需要按顺序检查两件事**： +> 1. **Gitea 数据盘的剩余空间**（尤其是 `data/tmp`，以及它是否落在小容量的 +> tmpfs 上），并清理失败上传留下的临时文件； +> 2. Gitea `app.ini` 的 `[attachment] MAX_SIZE`（下文第 3 条）。 +> +> 只放开 IIS 是不够的：本节第 1 步之后仍然 500，说明还有 Gitea 侧的限制或磁盘问题。 + → 默认上限就是 **IIS 的 `maxAllowedContentLength = 30,000,000` 字节（≈28.6 MiB）**。 Windows 客户端整包约 38 MB（`OpenDance.exe` ≈104 MB 未压缩 + `OpenDance.pck`）， 早先因此被拆成 `zip.part0/1/2`（每卷 13 MiB）才传上去 —— 用户拿到的是 @@ -302,6 +332,10 @@ Windows 客户端整包约 38 MB（`OpenDance.exe` ≈104 MB 未压缩 + `OpenDa 5. 改完执行 `iisreset /noforce`（或只重启站点），再按下节复验。 +> **注意**：`requestLimits` 只是第一道闸。IIS 放开后若仍为 500（而不是 413）， +> 说明请求体已经到达 Gitea，此时要按 9.1 的两件事继续排查 +> （Gitea 数据盘空间 / `[attachment] MAX_SIZE`）。 + ### 9.3 复验方法 ```bash