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