企业网站后台通常会提供图片、附件和其他文件上传功能。
例如：
产品图片；
文章配图；
PDF文件；
资料附件；
后台数据文件。
有时小文件上传正常，但文件稍大以后就会失败。
浏览器开发者工具中可能直接看到：
413 Request Entity Too Large
或者：
413 Payload Too Large
这类问题比较典型。
413表示服务器认为当前请求体太大，但真正需要确认的是：
究竟是哪一层认为它太大。
因为一个上传请求可能经过：
浏览器
→ Nginx
→ 后端应用
→ 上传程序
→ 文件存储
其中任何一层存在较小的限制，都可能让上传失败。
一、先确认问题是不是和文件大小有关
排查前可以准备几个不同大小的测试文件。
例如：
较小图片可以正常上传；
中等文件偶尔失败；
较大文件稳定出现413。
如果错误与文件体积变化存在明显对应关系，就可以优先检查请求大小限制。
如果所有文件无论大小都上传失败，就需要同时检查：
接口地址；
权限；
文件类型；
服务器目录；
应用异常。
不要只看到“上传失败”就直接判断为413问题。
二、先判断413在哪一层返回
一个比较重要的排查原则是：
不要一开始同时修改 Nginx、后端和前端。
先找出请求停在哪一层。
可以打开浏览器开发者工具，在 Network 面板找到上传请求。
重点查看：
请求地址；
状态码；
响应内容；
响应头；
上传请求有没有真正完成发送。
然后再查看 Web服务器日志。
如果 Nginx 日志明确出现“请求体过大”一类提示，通常可以判断：
请求还没有真正进入后端程序，就已经在代理层被拒绝。
这样排查范围就会缩小很多。
三、检查 Nginx 的请求体大小设置
在 Nginx 中，与这类问题关系比较直接的配置项是：
client_max_body_size
它用于控制客户端请求体允许达到的范围。
例如网站后台允许上传几兆大小的图片，那么代理层允许的请求体大小就不能比实际上传需求更小。
配置位置可以根据网站结构放在：
全局 HTTP 范围；
某个 server；
某个具体 location。
如果只有后台上传接口需要较大的请求体范围，可以考虑针对对应上传路径设置，而不是无差别放大整个网站所有请求。
这种方式更容易控制。
四、修改配置后不要马上判断已经解决
调整 Nginx 后，需要确认修改真正生效。
可以先检查 Nginx 配置语法。
常用命令是：
nginx -t
确认没有配置错误以后，再根据服务器部署方式重新加载 Nginx。
然后重新上传同一个测试文件。
如果原来的413消失，说明请求已经通过当前代理层。
如果出现新的应用错误，反而说明请求已经进入更后面的处理流程，需要继续检查后端。
五、代理层放开以后，后端仍可能有限制
很多开发框架自身也会限制上传文件大小。
因此上传限制实际上可能有多层：
Nginx允许10MB；
后端只允许5MB；
业务程序只允许3MB。
这种情况下，即使 Nginx 已经放开，较大的文件仍然无法成功。
排查时可以继续查看应用程序日志。
重点检查：
单文件大小限制；
整个请求大小限制；
Multipart 上传限制；
业务层文件限制；
应用网关限制。
具体配置名称与使用的开发框架有关。
不需要为了处理一个413问题，同时修改所有参数。
应该先确认请求已经到达哪一层，再修改对应位置。
六、文件大小不等于整个HTTP请求大小
这也是上传限制中容易忽略的一点。
例如用户选择的是一个接近5MB的文件。
实际浏览器发送的请求除了文件本身，还可能包含：
文件名；
表单字段；
分隔信息；
其他参数；
Multipart协议内容。
所以整个 HTTP 请求通常会比文件本身稍大。
如果业务要求允许上传接近5MB的文件，而服务器限制也刚好设置为5MB，就可能出现边界文件仍然无法上传。
因此，请求体限制需要结合真实上传结构预留合理空间。
七、不要简单把限制调得特别大
遇到413后，把请求体限制直接调得非常大，看起来可以快速解决问题。
但网站并不一定真的需要接收非常大的文件。
更合理的方法是根据不同业务设置范围。
例如：
头像尺寸较小；
产品图片适中；
PDF附件可以更大一些；
视频文件可能需要使用单独的上传方式。
如果所有文件都通过同一个接口上传，并统一允许超大请求，后续服务器资源管理也会更加困难。
网站建设阶段先确定不同上传场景的真实需求，会比出现问题以后不断扩大限制更容易维护。
八、浏览器端也应该提前提示
服务端限制负责真正控制上传。
但用户体验层面也可以提前处理。
例如后台允许上传的图片不超过某个范围，那么用户选中文件以后，前端就可以先检查：
文件大小；
扩展名；
文件类型。
发现明显不符合规则时直接提示，不需要等整个文件上传完成后再告诉用户失败。
不过浏览器端检查只能用于改善使用体验。
真正的限制仍然需要在服务器端再次验证，因为前端规则并不能代替服务器安全检查。
九、解决413以后还要注意超时
文件变大以后，另一个常见问题是：
上传时间变长。
如果网络较慢，较大的文件可能需要较长时间才能上传完成。
即使大小限制已经满足，也可能因为其他超时设置出现：
上传中断；
接口超时；
浏览器提示网络失败；
服务器提前关闭连接。
因此，当错误不再是413但上传仍然失败时，就需要换一个排查方向。
可以继续检查：
代理超时；
应用处理时间；
客户端网络；
文件保存耗时。
十、请求进入应用以后还可能保存失败
还有一种情况：
浏览器上传请求已经成功进入后端，程序也开始处理文件，但最终文件没有保存下来。
这时需要检查：
目标目录是否存在；
服务器运行用户有没有写权限；
磁盘空间是否充足；
临时目录是否正常；
文件名称是否合法；
文件存储程序是否发生异常。
如果此时已经没有413状态，就不要继续围绕请求体大小修改配置。
应该根据新的错误信息进入文件处理环节排查。
十一、修改完成后怎样测试
不要只拿一个能够上传成功的文件验证。
可以准备：
明显小于限制的文件；
接近限制值的文件；
明显超过限制的文件。
然后分别观察。
例如业务允许某个范围以内的文件：
较小文件应该正常上传；
接近限制的文件应该正常处理；
超过限制的文件应该被明确拒绝。
同时检查：
浏览器状态码；
Nginx日志；
应用日志；
后台提示；
文件最终是否保存。
这样才能确认整个上传规则真正符合业务要求。
十二、建立清晰的上传处理链路
一个完整的网站后台上传功能，可以把责任拆开。
浏览器端：
提前检查文件类型和大小，给用户清晰提示。
Nginx：
控制 HTTP 请求体范围。
后端程序：
按照业务要求再次验证文件。
上传程序：
处理文件名称、类型和保存逻辑。
存储层：
检查目录、空间和权限。
每一层职责清楚以后，后续再出现上传问题，就可以根据错误发生的位置逐层判断。
十三、遇到413时可以按这个顺序排查
可以整理成一条比较简单的流程：
确认状态码是不是413；
比较不同文件大小；
检查浏览器上传请求；
查看 Nginx 日志；
确认 client_max_body_size；
重新加载配置并测试；
继续检查后端上传限制；
再检查超时和文件保存；
使用不同大小文件进行边界验证。
这样做比同时修改多个参数更容易确认真正原因。
总结
企业网站后台上传文件出现413，本质上通常是请求大小超过了某一层允许的范围。
武汉网站建设涉及图片、附件和文件上传时，可以按照：
浏览器
→ Nginx
→ 应用程序
→ 上传逻辑
→ 文件存储
逐层确认。
其中 client_max_body_size 是 Nginx 环境中需要重点检查的配置项，但不能把所有上传问题都归因到这一处。
先通过状态码和日志判断请求停在哪一层，再修改对应限制，既能解决问题，也能避免为了通过一个大文件测试而无差别放大服务器配置。
本文由梓彤超越（武汉）科技有限公司整理。
