上周有个做后台系统的朋友甩给我一张截图，用户上传一个二十多兆的附件，浏览器上直接蹦出白底黑字一行：413 Request Entity Too Large，页面连样式都没有，一看就是服务器吐出来的默认错误页。他第一反应是去翻应用日志，翻了半小时什么都没找到，于是怀疑是代码写错了。我看了一眼就说，别翻日志了，请求根本没走到你的代码里，在半路上就被拦下来了。这类问题的迷惑性就在这儿——它长得像一个业务错误，实际上是一个传输层准入错误，是两个完全不同的东西。
413 Request Entity Too Large 说白了就是「你送来的东西超出了我这道门允许的尺寸」。它可能来自反向代理、来自应用容器、来自 Web 框架的中间件、来自云上的七层负载均衡、来自 CDN 或安全防护组件，甚至来自客户端自己在拼请求时踩的坑。链路上任何一环设了上限，而你没对齐，用户就会看到这一行字。这篇文章我打算把这条链路从头到尾拆一遍：每一层的开关叫什么、默认值是多少、怎么改、改完怎么验证，以及改完之后大文件上传这件事到底应该怎么设计才不至于下次再炸。不管你是刚接手运维的新人，还是写了几年业务代码但一直没搞明白请求是怎么进来的后端，应该都能从里面找到能直接抄的东西。
1. 先弄明白 413 到底是谁发出来的
1.1 这个状态码的来历与真实含义
HTTP 状态码里 4xx 这一族表示「客户端的问题」，413 属于其中比较特殊的一个。它最早的正式名称是 Request Entity Too Large，后来规范修订时改叫 Payload Too Large，但很多服务器和框架的默认错误页还沿用旧名字，所以你看到的就是这行英文。它的语义非常明确：服务器拒绝处理这个请求，因为请求体超过了服务器愿意处理的范围。注意这里的关键词是「请求体」，也就是 body，不包括 URL 和请求头。请求头太大是另一个错误，通常是 431 或者直接被断开。
这个状态码在设计上还有一个容易忽略的细节：服务器可以在还没有读完整个请求体的情况下就返回 413。这很好理解，既然已经知道超了，干嘛还要把剩下的几十兆数据收完再拒绝，白白占用带宽和内存。但这个「提前拒绝」会带来一个副作用——客户端还在拼命往外写数据，服务端已经把连接关掉了，于是客户端可能看到的不是漂亮的 413 页面，而是Connection reset by peer、Broken pipe或者浏览器上的「网络错误」。这就是为什么同一份配置，用不同客户端、不同网络环境测，表现出来的现象会不一样。搞不清楚这一点，很容易在排查时被带偏方向。
1.2 为什么你的应用日志里一片空白
这是绝大多数人第一次遇到 413 时最困惑的地方。你在业务代码里打了详尽的入参日志、异常日志，结果什么都没有，仿佛这个请求从来没发生过。原因很直接：请求在到达你的应用进程之前就被拒了。反向代理收到请求头，看到Content-Length: 26214400，和自己的上限一比，超了，直接构造一个 413 响应返回去，连后端服务的端口都没碰一下。你的应用当然不会有任何记录。
反过来还有一种情况：日志里有记录，但记录的是一个奇怪的异常，比如「连接被对端关闭」「读取请求体失败」。这时说明请求已经进了应用，但应用在读 body 的时候被上游掐断了，或者应用自己读到了一半发现超限。这两种现象的排查方向完全不同，前者往网关配置上找，后者往框架配置和代码逻辑上找。我一般的判断方法是看访问日志里有没有这条请求的记录——如果有记录且状态码是 413，说明是这一层自己生成的；如果连记录都没有，那问题在更外层。
注意：有些代理默认不记录被自己拒绝的请求，或者只记录在 error 级别的日志里。别只盯 access log，error log 和代理自己的错误日志也要翻。
1.3 一条上传请求要穿过哪些关卡
要在脑子里建立起这条链路，排查才不会乱。一个典型的「浏览器 → 服务端」上传请求，中间可能经过这么多道门：
| 层级 | 典型组件 | 常见默认上限 | 超限表现 |
|---|---|---|---|
| 客户端 | 浏览器 / 移动端 / SDK | 无硬限制，但受内存与超时约束 | 卡死、超时、主动中止 |
| CDN / 边缘节点 | 内容分发网络 | 各家不同，常见几 MB 到几十 MB | 413 或 403 |
| 安全防护 | WAF、风控组件 | 请求体检测上限，常见 8MB 到 10MB | 413 或直接拦截页 |
| 七层负载均衡 | 云负载均衡、硬件设备 | 常见 10MB 到 60MB 不等 | 413 |
| 反向代理 | Nginx、Apache、Caddy | Nginx 默认 1MB | 413 |
| 应用容器 | Tomcat、Undertow、Gunicorn | 表单解析有独立上限 | 参数丢失或 413 |
| 应用框架 | Spring、Express、Django | 1MB 到 10MB 不等 | 413 或 500 |
| 运行时/语言 | PHP-FPM 等 | 2MB / 8MB | 空表单或 413 |
| 业务代码 | 自己写的校验 | 你定的 | 自定义错误 |
这张表建议收藏。很多人只改了自己知道的 Nginx，改完发现还是 413，就是因为前面还有 CDN 和负载均衡两道门，它们的上限比 Nginx 还小。木桶效应在这里体现得淋漓尽致：整条链路的实际上限等于所有环节里最小的那个值。
2. 分层排查：从最外层一步步往里收
2.1 排查顺序定错了会浪费多少时间
我见过太多人上来就改应用配置，把框架的上限从 1MB 调到 100MB，重启，测，还是 413，然后开始怀疑人生。原因很简单：如果 Nginx 那关只放行 1MB，你把后面调到 100GB 也没用，请求在门口就被打回去了。所以顺序必须是从外往里，一层一层确认「这一层放行了没有」，直到找到真正卡住的那一环。
反向操作也有它的道理——如果你已经确定外层配置是宽松的，那从里往外查更快。但对一个陌生的、历史包袱重的系统，从外往里是唯一稳妥的选择。因为外层的配置文件往往不在代码仓库里，是运维手工维护的，变更历史不明，你根本不知道上一任在哪个角落埋了个限制。先确认边界，再谈优化，这个习惯能帮你省掉大量来回试错的时间。
还有一点：如果是多环境（开发、测试、预发、生产），务必先确认问题出在哪个环境。我遇到过测试环境一切正常、生产必现的情况，最后发现是生产入口多挂了一层安全防护，测试环境没有。环境之间的链路拓扑不一样，配置自然不一样，拿测试环境的结论去推生产，很容易翻车。
2.2 三条命令快速锁定返回方
先别急着看配置文件，用命令行发一个真实的、略大的请求，看响应头，这是最快的定位手段。下面这几条在大多数场景下都能用：
# 造一个 5MB 的测试文件 dd if=/dev/zero of=test.bin bs=1M count=5 # 直接打后端端口，跳过所有代理 curl -i -X POST http://127.0.0.1:8080/upload -F "file=@test.bin" # 打经过代理的入口 curl -i -X POST https://your-domain.com/upload -F "file=@test.bin" # 只要状态码，便于批量测不同尺寸 for s in 1 2 5 10 20; do dd if=/dev/zero of=t.bin bs=1M count=$s status=none printf "%sMB -> " "$s" curl -s -o /dev/null -w "%{http_code}\n" -X POST https://your-domain.com/upload -F "file=@t.bin" done最后那段循环特别有用。它给你的是一个阈值曲线：1MB 通过、5MB 通过、10MB 返回 413，那你基本就知道卡点在哪一个数量级上了，1MB、10MB 这些都是业界常见的默认值，对着默认值就能反推出是哪一层。
再看响应头，很多服务器会留下线索。Server:字段能告诉你是 Nginx 还是别的什么；有些组件会带自己的标识头；返回的 HTML 错误页样式也是一个强信号——Nginx 的默认错误页、云厂商的拦截页、框架的 JSON 错误体，长得完全不一样。先看长相，再查配置，效率高得多。
2.3 一份可以直接照着走的排查清单
把上面的思路整理成一份可以照着做的清单，遇到 413 从第一条开始往下走，基本不会漏：
- 确认现象边界：多大文件必现？是不是所有用户都这样？换网络、换浏览器有没有变化？先排除掉客户端和服务端偶发网络问题。
- 直连后端端口测试：跳过所有中间层，如果这一步就 413，说明问题在应用容器或框架层，直接跳到第 5 条。
- 逐层加回中间层：经过反向代理测一次，经过负载均衡测一次，经过 CDN 测一次，哪一层加上去就开始报 413，凶手就找到了。
- 核对每层的配置值：注意单位，Nginx 写
10m是 10MB，写10M也是，但有些组件单位是字节，写10485760才对。 - 检查框架与运行时：文件上传相关的配置项通常有两三个，只改一个不够。
- 检查超时：大文件上传容易同时撞上大小限制和超时限制，413 解决了可能变成 504。
- 回归验证：用大于上限和刚好小于上限两个尺寸各测一遍，边界值最容易出问题。
3. 各层参数怎么调：能直接抄的配置
3.1 反向代理层的核心参数与容量估算
Nginx 是这一层最常见的主角，它的关键参数就一个：client_max_body_size，默认值 1MB。这个默认值设计得很保守，因为绝大多数请求都不带 body 或者 body 很小，1MB 对普通表单绰绰有余。但一旦有文件上传需求，几乎百分之百要改。
配置的位置有讲究，可以写在 http、server、location 三个层级，就近生效。我一般建议写在具体的 location 上，粒度最细，不会因为一个上传接口把整个站点的限制放得特别宽：
location /api/upload { client_max_body_size 50m; client_body_buffer_size 1m; client_body_temp_path /var/cache/nginx/body 1 2; client_body_timeout 120s; proxy_pass http://backend; proxy_request_buffering on; proxy_read_timeout 300s; proxy_send_timeout 300s; }这里每个参数都有它的用意。client_max_body_size是硬上限，超了直接 413。client_body_buffer_size决定请求体在内存里缓冲多少，超过这个量的部分会写到临时文件。默认值很小（8k 或 16k 视平台而定），意味着稍微大一点的请求都会落到磁盘上，磁盘 IO 是瓶颈的话，并发一上来就会拖慢整体响应。调到 1MB 到 4MB 之间比较实用，再大就没必要了，因为不可能每个请求都给你几十兆内存。
client_body_temp_path是临时文件目录，这个经常被忽略。上传高峰时这个目录的磁盘占用会飙升，如果分区规划得小，很容易把磁盘写满，然后出现一堆莫名其妙的 500。我见过一次线上事故就是这个原因——临时目录所在的盘只有 10GB，几个大文件并发上传直接打满。
上限值怎么定？不能拍脑袋写个 1000m。我的算法是：业务允许的最大单文件体积 × 1.3 + 表单其他字段的余量。乘 1.3 是因为 multipart 编码本身有开销——每个字段都有分隔符、头部信息，二进制内容虽然不会被转义，但边界和元数据是实打实的额外字节。如果业务里还有 base64 编码的内容（比如前端把图片转成 base64 塞进 JSON），膨胀率是 33% 以上，得按 1.5 倍算。举个例子，业务要求支持 100MB 的附件，那client_max_body_size设成 128m 到 150m 之间比较稳，别设成 100m 整，边界值最容易出问题。
3.2 应用容器与框架层的对应开关
穿过代理之后，下一个可能卡你的是应用容器和框架。这里的特点是参数分散、名字五花八门，不查文档基本靠猜。
Java 体系里，Spring Boot 的两个配置项是必改的：
spring: servlet: multipart: enabled: true max-file-size: 100MB max-request-size: 120MB file-size-threshold: 2MB location: /data/tmp/uploadmax-file-size管单个文件，max-request-size管整个请求（多个文件加起来），后者一定要大于前者，否则多文件上传时会出现「单文件没超但整体超了」的诡异现象。file-size-threshold决定多大以内放内存，超过写磁盘。location不给的话用系统临时目录，容器化部署时这个目录可能在内存盘上，大文件一写就把内存吃光，这是个很隐蔽的坑。
超限之后，Spring 会抛MaxUploadSizeExceededException。默认情况下这个异常被处理成 500，而不是 413，所以你会看到一个「服务器内部错误」，很容易误判成代码 bug。想要返回标准的 413，得自己写一个异常处理器把它接管过来：
@RestControllerAdvice public class UploadExceptionHandler { @ExceptionHandler(MaxUploadSizeExceededException.class) public ResponseEntity<String> handle(MaxUploadSizeExceededException e) { return ResponseEntity.status(HttpStatus.PAYLOAD_TOO_LARGE) .body("{\"code\":413,\"msg\":\"文件超出大小限制\"}"); } }Node 体系里，Express 用body-parser或者内置的express.json()、express.urlencoded()，它们都有limit参数，默认 100kb。这个默认值调过的都知道，稍微传点数据就 413 了。文件上传一般用 multer 之类的中间件，它有自己的limits.fileSize。两者的关系是：multer 处理 multipart，body-parser 处理 JSON 和 urlencoded，两条路径的上限要分别设置，只设一个另一个照样炸。
Python 体系里，Django 的DATA_UPLOAD_MAX_MEMORY_SIZE默认 2.5MB，FILE_UPLOAD_MAX_MEMORY_SIZE默认也是 2.5MB，后者控制内存与临时文件的切换阈值。Flask 更隐蔽，它依赖 WSGI 服务器的配置，MAX_CONTENT_LENGTH不设就基本不限制，但反过来前面的 Nginx 会先拦你。
PHP 这套组合拳最容易踩坑，因为它有两个完全独立的限制。upload_max_filesize管单个文件，默认 2MB；post_max_size管整个 POST 请求，默认 8MB。前者超了，$_FILES里的 error 是 1，页面还能正常走；后者超了，$_POST和$_FILES直接变成空数组，页面可能白屏或者报一个跟上传毫无关系的错误。这个差异坑过无数人，改的时候两个必须一起改，而且 post_max_size 要大于 upload_max_filesize，通常留 20% 到 30% 的余量。
3.3 云上链路里那些容易被忽略的上限
如果你用的是云服务，链路上还有几道你平时根本想不起来的门。七层负载均衡一般对请求体有默认上限，各家的数值不同，但普遍在 10MB 到 60MB 这个量级，需要在控制台或者监听配置里单独调整。CDN 也有类似限制，而且 CDN 的配置往往和回源配置分开，改了一个忘了另一个。
安全防护组件这一环更隐蔽。它需要对请求体做内容检测，自然会有一个检测上限，超过之后有的直接拒绝，有的截断后放行但标记为可疑。它的上限通常比你想的小，因为要全量扫描内容，成本很高。很多团队排查了半天 Nginx，最后发现是防护策略里的一个默认值。
还有一个思路上的提醒：如果你的业务涉及大文件，与其一层层往上调限制，不如考虑让文件根本不要经过这条链路。这个后面第 5 节会细说，但先埋个伏笔——很多时候改配置只是把问题往后推，链路越长，你能控制的部分越少。
4. 一次完整的大文件上传故障处理记录
4.1 现象收集与信息确认
说个我实际处理过的场景，细节做了脱敏。某业务系统的附件上传功能，用户反馈超过 20MB 的文件必定失败，10MB 以下正常。前端提示「请求失败」，后端日志干净得像刚重启过一样。
先做信息收集。第一，确认失败的边界：用 5MB、10MB、15MB、20MB、25MB 各测一遍，结果是 15MB 通过，20MB 失败。说明阈值在 15 到 20 之间，这个区间很有意思，因为 16MB 是个很常见的默认值。第二，确认是所有用户还是部分用户：全量用户都这样，排除了地域和网络问题。第三，确认是哪个接口：只有附件上传接口有问题，其他接口正常，排除了全局配置。
这三条信息定下来，基本可以确定是某一个统一作用于所有请求、且阈值接近 16MB 的配置项。下一步就是找出它在哪一层。
4.2 逐层验证定位真正原因
第一步，直连应用服务的内网端口，跳过所有代理和负载均衡，用 25MB 文件测，结果成功。这就把应用容器、框架、业务代码全部排除了，问题一定在代理层或者更外层。
第二步，打反向代理的地址，25MB 失败。到这里范围缩小到反向代理本身或者它上游的负载均衡。查看反向代理的配置，client_max_body_size写的是16m，对上了。这是一个很典型的遗留问题——最初设这个值是因为当时业务只允许传 10MB 以内的附件，后来业务扩展了，配置没跟着改。
但问题到这儿还没完。只改这一处够不够？我把反向代理的配置临时改成 100m，重启，测 25MB，成功。再测 50MB，失败。说明上游还有一层限制。继续往上查负载均衡的监听配置，果然也有一个请求体上限，值是 30MB 左右。两层都改成 128m 之后，50MB 通过，100MB 也通过了。
还有一个细节差点被漏掉：临时文件目录。查了一下磁盘，反向代理的临时目录所在分区剩余空间不到 5GB，而按要求要支持并发 10 个 100MB 上传，理论上要 1GB 的瞬时占用，加上临时文件不一定是及时清理的，5GB 余量太紧张了。最后把这个目录挪到了一个空间充裕的分区上，同时配了定期清理。
4.3 配置修改与灰度验证
配置改完之后不能直接全量上。这类变更的风险不在于功能本身，而在于放开了限制之后，原本被挡住的异常流量会涌进来。比如有客户端在疯狂重试、有脚本在批量上传，之前被 413 挡着没影响，现在全放进来了，可能把带宽或者磁盘打满。
我的做法是先在一台实例上灰度，观察三个指标：一是上传接口的平均耗时和 P99，看有没有明显劣化；二是临时目录的磁盘增长速率，估算出峰值需要多少空间；三是错误率，特别是 502、504 这类，因为请求体变大之后，后端处理时间变长，超时相关的错误会跟着冒出来。观察了半天，P99 从 1.2 秒涨到 2.8 秒，还没到超时阈值，可以接受，然后才全量。
4.4 上线后的观察指标
全量之后的一周内，重点盯这几个：临时目录占用有没有异常增长、上传失败的分布从「413 为主」变成什么样、有没有出现原本没有的 504。同时在业务侧补了一条前置校验——前端在选择文件时就直接判断大小并给友好提示，避免用户辛辛苦苦传到 99% 才被拒。这个改动的价值比调配置本身还大，因为它把一次失败的等待变成了一次即时的反馈。
还有一个收尾动作：把这次用到的所有上限值整理成一张表，写在运维文档里，标注每一层的配置位置和修改方式。下次再遇到同类问题，直接查表就行，不用再从头排查一遍。这个习惯我强烈建议养成，配置是有记忆的，但人的记忆不可靠。
5. 治本方案：大文件上传该怎么设计
5.1 分片上传的分片大小怎么定
把限制一路调大，本质上是在用「更大的管道」解决问题。但管道再粗也有极限，而且每次调大都在放大风险。真正的解法是让单个请求变小，这就是分片上传。把一个大文件切成若干块，每块单独发一个请求，服务端收齐后合并。这样一来，每个请求的体量都很小，任何一层的限制都轻松通过，而且断网了只重传失败的那一片，不用从头再来。
分片大小怎么定？这里有个约束条件很多人不知道：对象存储类的服务对分片数量有上限，常见是 10000 片。所以分片大小不能拍脑袋，得按最大文件反推：
分片大小 = max(最小允许分片, ceil(最大文件体积 / 最大分片数))假设最小分片是 5MB（这也是很多服务的下限），最大支持文件 60GB，那 60GB / 10000 约等于 6.1MB，向上取整到 8MB 或 16MB 比较合适。如果按 5MB 切，60GB 需要 12288 片，直接超上限，合并会失败。
实际选值的时候，还要考虑网络环境。分片太小，请求数多，每个请求的头部开销和握手成本占比就高，整体吞吐反而下降；分片太大，单次失败重传的代价就大。经验值是在 5MB 到 20MB 之间，公网环境偏小一点，内网环境可以偏大一点。我一般先取 8MB 做压测，看单分片的上传耗时，控制在 10 到 30 秒这个区间比较舒服，太长容易被中间设备的空闲超时干掉。
并发数也要控制。浏览器对同一域名的并发连接数是有限制的，开太多分片并发反而互相挤占。实践下来 3 到 5 个并发比较稳妥，既能把带宽用起来，又不会把连接池打满。同时建议给每个分片请求加指数退避重试，失败后等 1 秒、2 秒、4 秒再试，别一失败就立刻重试，那样在弱网环境下只会雪崩。
5.2 直传对象存储省掉的到底是什么
比「分片」更彻底的一层，是让文件根本不经过你的业务服务器。流程大概是：客户端先向业务服务申请一个上传凭证，业务服务返回一个带签名的、有时效的地址，客户端拿着这个地址把文件直接传到存储服务，传完之后把结果告诉业务服务，业务服务再去做记录和后续处理。
这个方案省掉的东西比表面看起来多。第一是带宽，文件不走业务服务器，服务器的出口带宽压力直接归零。第二是内存和磁盘，不用在本地缓冲请求体，也不用管临时目录会不会写满。第三是故障域，上传慢或者失败不会拖累业务接口，两者在资源上彻底隔离了。第四是安全，凭证是短期有效的，泄露了也传不了多少东西，而且可以精确限定只能写某个路径。
代价也有：上传成功后需要一个「回调或确认」机制来保证数据一致性，如果客户端传完就跑了，业务侧不知道文件已经在存储里了，得靠定时任务扫垃圾数据。另外跨域配置要弄对，否则浏览器那关就过不去，这个坑我踩过——存储侧的跨域规则没配，前端一直报跨域错误，看着像 413 的兄弟问题，其实是完全不同的原因。
5.3 上传通道的限流与安全边界
限制放开之后，安全边界必须同步收紧，这是很多人调完配置就忘掉的一环。大小限制本身不是安全措施，它只是碰巧挡住了一些滥用。真正该做的有几件事：
第一，按用户和 IP 做上传频率与总量限流。单个用户每分钟能传多少个文件、每天总量多少，这个在网关或业务层都能做。第二，校验文件类型，不能只信扩展名和 Content-Type，要读文件头做魔数校验，必要时做深度检测。第三，限制文件名的处理方式，别把用户传上来的文件名直接拼进路径，路径穿越这类问题至今还在出现。第四，存储侧设置为不可执行，上传目录不允许解析脚本，这一条能挡住大部分「传个脚本上去然后访问它」的玩法。第五，给临时文件设生命周期，无论是本地临时目录还是存储上的分片，都要有过期清理策略，不然时间一长就是一堆垃圾数据。
提示：调大上传限制之后，务必同步检查反向代理的
client_body_timeout、后端的读超时、负载均衡的空闲超时。这三个值要形成梯度，从外到内依次变大，否则会出现「外面还在传，里面已经超时断开」的错位。
6. 常见问题与避坑速查
6.1 配置改了还是 413 的六种情况
第一种，改错了文件。Nginx 的配置可能有多份，一份在/etc/nginx/，一份在容器镜像里，一份被配置管理工具覆盖。改完一定要nginx -T把最终生效的配置全打出来看一眼，别只看你改的那个文件。
第二种，没重载。改完配置不 reload 或者 reload 失败（语法错误），跑的还是老配置。reload 之后要确认 worker 进程确实换了。
第三种，被更内层的配置覆盖。http 层设了 100m，location 层写了个 1m，就近生效，你以为改了大值实际上没用。
第四种，前面还有一层。CDN、负载均衡、安全防护，这三个是最常被漏掉的。判断方法就是第 2 节说的逐层加回测试。
第五种，单位写错。client_max_body_size 50是 50 字节，不是 50MB。这个错误不报错、不警告，就是死活不生效，我第一次栽进去的时候查了快一个小时。
第六种，客户端提前中止。有些前端库在发送前会自己校验大小，超了就本地拒绝，压根没发请求，但错误提示被包装成了服务端返回的样子。看浏览器网络面板里有没有真的发出这条请求，一眼就能分辨。
6.2 常见问题速查表
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 413 但应用日志无记录 | 被代理或上游拦截 | 直连后端端口对比测试 |
| 413 页面是默认样式 | 由中间件生成而非业务代码 | 看响应头Server字段 |
| 改了 Nginx 仍 413 | 上游还有限制 | 逐层加回中间层测试 |
| 413 变成 504 | 大小放开但超时没调 | 检查各级读超时与空闲超时 |
| 请求失败但无状态码 | 连接被提前关闭 | 抓包看是否收到 RST |
| 小文件正常大文件失败 | 命中了某个默认阈值 | 用递增尺寸测出边界值 |
| 上传成功但文件损坏 | 缓冲或临时文件问题 | 校验文件大小与哈希 |
| 偶发失败重试就好 | 超时或限流 | 看限流日志与耗时分布 |
| 表单字段全为空 | 运行时层 POST 上限 | 检查 PHP 类运行时的 post 上限 |
| 容器重启后配置失效 | 配置未持久化 | 检查挂载与配置下发 |
6.3 几条踩出来的经验
别把限制调成无限大。见过有人图省事直接写client_max_body_size 0，意思是取消限制。这在测试环境很爽，在生产环境等于把门拆了，任何一个客户端发疯都能把你的带宽和磁盘吃干净。设一个略高于业务需求的值，比设成无限安全得多。
先看边界值，再猜原因。用递增尺寸测出准确阈值，这件事的性价比高到离谱。16MB、10MB、2MB、1MB，这几个数字对应着业界最常见的默认配置，测出阈值基本就能反推是哪一层。我做这类排查，第一步永远是画那条「通过 / 失败」的分界线曲线。
调完配置记得同步文档和监控。配置是有时效的，业务发展半年后可能又不够用了。把每个上限值、它的位置、当前值、上次调整时间记下来，同时给 413 的响应数加个监控告警——正常情况下它应该是 0 或者一个很低的值，一旦曲线抬头就说明要么配置回退了，要么有客户端在异常重试。
前端校验是成本最低的一道防线。在用户选文件的那一刻就判断大小并给出明确提示，比让用户等半分钟然后看到一个 413 页面体验好太多。这个改动通常只需要几行代码，收益却比服务端调参数大得多。
给大文件上传单独设计一条路径。如果你的业务里上传只是偶尔发生，那调调配置就够了；如果上传是核心功能，那值得单独规划——独立的域名或路径、独立的超时策略、独立的分片逻辑、独立的监控指标。混在通用接口里，早晚会因为某个参数互相牵制。我个人的体会是，凡是涉及「大」和「长」的请求，都应该和普通请求分开治理，它们在资源模型上根本就不是一类东西。
最后再补一个容易被忘的点：日志里要能看见 413。默认很多组件的 access log 会记录 413，但错误详情不会。可以在代理层配一个自定义的日志格式，把请求体大小、命中限制的配置名一起打出来，排查时能省掉大量猜测。这个改动一次投入，长期受益。
踩过的坑大致就这些。回头看，413 这个错误最麻烦的地方从来不是「怎么改配置」，而是「不知道改哪一层」。把链路在脑子里画清楚，用递增尺寸快速定界，剩下的都是查文档和改参数的体力活。真正值得花心思的是后面那一层——为什么你的架构会让一个大文件穿过这么多道门，这件事想明白了，下次就不会再被同一行英文绊倒。
