根本原因是maxAllowedContentLength仅限制请求体总长度（不含HTTP头），而multipart/form-data实际请求体比文件大10%–20%，设100MB常卡在92MB失败，错误码404.13；需预留15%余量、正确配置web.config层级、同步调大maxRequestLength，并通过FREB日志确认拒绝原因。
为什么 maxAllowedContentLength 修改后仍上传失败？
根本原因不是 IIS 没读配置，而是它只控制「请求体总长度」，不包含 HTTP 头。如果你用 multipart/form-data 传大文件，实际请求体 = 文件内容 + 边界字符串 + 其他字段，比文件本身大 10%–20%。常见现象是：设了 100MB 却卡在 92MB 左右失败，错误码通常是 404.13（Content Length Too Large）。
实操建议：
- 计算时预留至少 15% 余量，比如要传 100MB 文件，
maxAllowedContentLength至少设为104857600 * 1.15 ≈ 120586240字节 - 确认修改的是正确的
web.config层级：站点根目录的配置会覆盖服务器全局设置，但子应用可能有自己独立的web.config - 改完必须执行
iisreset或重启对应应用程序池，仅刷新浏览器或重载页面无效
如何在 web.config 中正确设置 maxAllowedContentLength？
该值单位是字节，且只能在 <system.webServer> 的 <security> → <requestFiltering> → <requestLimits> 节点下配置，不能写在 <system.web> 里（那是 maxRequestLength，ASP.NET Framework 用的，单位是 KB，两者必须同时调大）。
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" />
</requestFiltering>
</security>
</system.webServer>
<system.web>
<httpRuntime maxRequestLength="2097152" />
</system.web>
</configuration>注意：maxAllowedContentLength 最大支持 2147483648（2GB），超过会直接拒绝请求；maxRequestLength 最大为 2097151 KB（约 2GB），设更大值会被截断为默认 4MB。
maxAllowedContentLength 和前端 JS 的关系
这个限制发生在 IIS 接收请求阶段，**完全不经过 JavaScript**。也就是说，fetch() 或 XMLHttpRequest 在发送前无法预知 IIS 会不会拒收，也不会触发 onerror —— 请求会发出去，但 IIS 直接返回 404.13，前端收到的是网络层失败，不是业务逻辑错误。
实操建议：
- 不要依赖
input[type="file"].files[0].size做唯一校验，它只反映客户端文件大小，不反映最终请求体大小 - 上传前用
FormData构造一次模拟体并估算长度（需手动拼接边界、换行、字段名等），复杂度高，一般只在关键业务中做 - 更可靠的做法：服务端返回明确的
404.13响应，并在前端捕获该状态码，提示“文件过大，请压缩或分片上传”
上传超限时看到的错误信息和日志定位方法
IIS 默认不记录详细拒绝原因，只记一条 404.13。要确认是否真由 maxAllowedContentLength 触发，需开启失败请求跟踪（FREB）：
- 在 IIS 管理器中选中站点 → “失败请求跟踪规则” → 启用，筛选状态码
404.13 - 复现上传失败，去
%SystemDrive%\inetpub\logs\FailedReqLogFiles查看 XML 日志 - 关键线索在
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">下的ModuleName="RequestFilteringModule"和Reason="RejectedByRequestFilteringModuleMaxContentLength"
如果日志里没出现这个 Reason，说明问题不在 maxAllowedContentLength，可能是反向代理（如 Nginx）、WAF、或客户端断连导致的假性超限。
