发布日期：2026 年 9 月 21 日 · RootGS 技术编辑
小图片能上传，大文件却返回413；也有请求上传到一半断开，或者页面提示成功但附件无法打开。上传流程跨越浏览器、公网入口、反向代理、应用解析和最终存储，各层可能拥有独立限制。本文以常见Nginx与PHP场景说明排查方法，并强调先确定失败位置，再调整容量与时间参数，避免把所有限制直接放开。
一、记录失败发生在上传的哪个阶段
先记录请求地址、方法、文件大小、文件数量、开始和结束时间、HTTP状态以及应用返回信息。浏览器开发工具中的请求记录可以帮助区分请求是否真正发出、传输是否完成、服务器何时返回。分享抓包时要去除Cookie、认证头和客户文件内容。
用同一账号、同一路径和相同文件类型，比较小文件与较大文件。不要直接用批量大文件持续压测生产；先选能稳定复现的最小样本。若跨不同网络表现不同，再记录客户端速率与中途停顿，避免把网络条件变化当作配置修改效果。
二、找出究竟是哪一层拒绝请求
413通常表示某一层认为请求体超过允许范围，但它可能由CDN、网关、Nginx或应用返回。响应样式和头部可以提供线索，仍应结合对应时间的访问与错误记录。某一层没有记录，也不一定说明请求没到达，还需考虑日志范围、缓存、采样与入口选择。
如果前方有第三方公网入口，应先核对当前套餐及功能的上传限制。源站放大上限，不会自动改变前方限制。直连源站测试必须在授权范围和既定访问控制内进行，不能为了排查临时把源站完全暴露。
三、Nginx限制的是整个请求体
client_max_body_size控制请求体允许的大小，可以出现在http、server或location上下文。应核对上传路径真正匹配的配置，而不是只搜索到某一处数字就认为已经生效。值为0会关闭该项大小检查，不适合作为所有上传问题的通用修复。
文件大小不完全等于请求体大小。multipart表单还包含边界、字段及其他内容，多文件请求则累计计算。例如业务允许单文件20MiB，应为表单开销和其他字段留出合理空间，并明确一次允许几个文件；不能把代理上限恰好设成单文件字节数后要求所有边界样本必定成功。
配置变更前进行语法检查，按既定维护方式加载，再从真实公网路径验证。只检查配置文件内容，不能确认前方节点和所有服务实例都已采用新值。
四、PHP与应用还有各自的限制
在常见PHP上传流程中，upload_max_filesize影响单个文件，post_max_size影响POST数据总量。后者需要覆盖全部文件及表单开销；超过post_max_size时，应用可能看到空的POST与FILES，而不一定收到直观的文件超限提示。应用必须识别这种情况，给出明确错误而不是继续执行后续业务。
应检查实际处理请求的PHP-FPM池或Web运行环境。命令行PHP显示的配置未必与网站一致，公开放置完整phpinfo页面也会暴露过多环境信息。可以通过受控诊断仅确认相关配置值，完成后撤除临时诊断入口。
框架或业务代码可能另外限制文件类型、单次数量和单文件大小，最终存储也可能拒绝请求。让各层限制形成一致的策略，并保证应用能在可控范围内返回清楚的错误。
五、大小限制与时间限制要分开判断
Nginx的client_body_timeout针对读取请求体时相邻读操作之间的等待，并不是整个上传任务的统一总时长。应用处理超时、网关响应超时和对象存储超时又属于不同阶段。把一个超时参数调大，未必覆盖实际失败的位置。
上传字节完成后，病毒检查、解压、转码或索引建立仍可能耗时。如果业务适合，可将接收文件与后续处理分开，通过任务状态反馈进度；但异步任务也要有失败处理与清理机制。先以时间线定位等待发生在哪一段，再决定是否需要调整超时或改造流程。
六、临时空间、安全校验和最终文件同样要验收
代理缓冲和应用接收文件可能使用临时目录，最终目标磁盘有空间不代表临时位置也有空间。应检查相关挂载点、inode、目录权限及清理策略。多个并发上传会增加临时占用，不能只用单个文件成功来估算高峰容量。
业务应校验内容与允许类型，不信任用户提供的扩展名或原始路径；保存名称由服务端控制，上传目录避免被当作脚本执行位置。完成响应前，应明确文件是否已进入最终存储。若返回下载链接，还要检查权限、长度或校验值，避免把收到请求误报为文件可用。
七、用边界样本关闭问题
准备略小于上限、接近上限、超过上限的样本，同时覆盖多文件、慢速上传、中途取消和重复提交。预期结果应同时包含成功路径与明确拒绝路径，并核对失败后是否遗留临时文件或产生重复业务记录。不要用无上限上传换取表面上的“全部通过”。
保存原配置、修改范围、加载时间、验证结果及回退步骤。若有多个应用节点，应逐个确认一致性。有效的上传方案不仅能接收较大文件，还应让超限可解释、失败可恢复、存储可核对，并且不会让正常业务被少量异常请求拖垮。
