小文件能传，大文件失败？413 报错的检查顺序

小文件能上传，大文件却失败，先看上传请求返回了什么错误。如果是 HTTP 413，优先检查请求大小和接收端的限制；如果只是超时或连接重置，再按连接问题排查。开着代理时出现故障，不代表换一个节点就能解决。

本文适合网页上传、云盘发送文件或接口提交遇到大小相关报错的情况。需要区分的是“传得慢”和“请求被拒绝”，不要把二者当成同一个问题。

作者：小六｜资料核对日期：2026年10月15日

413 在说明什么？

HTTP 413 表示接收请求的服务器认为内容超过了它愿意或能够处理的大小，因此拒绝处理。它描述的是请求内容限制，不是上传速度。定义见 RFC 9110 的 413 说明。

有些界面会写 Content Too Large，也可能写 Payload Too Large。后者是仍然常见的旧名称，不能仅凭英文不同就当成两种故障。见 MDN 状态码说明。

单凭 413，还不能确定是谁设置了限制。上传路径可能经过网站入口、反向代理和应用服务，应结合实际请求地址、响应说明及站点日志判断。

网页上传常会把文件、表单字段和分隔信息一起发送。如果一次选了多个文件，请求里还可能包含它们的总量。因此，“单个文件没有超标”不一定说明整个请求没有超标。

MDN 的文件上传示例展示了 multipart/form-data 请求，它除了文件内容还有表单结构。这里不需要背格式，记住接收端可能检查整个请求即可。

先核对网站写的是“单文件限制”“每次上传限制”还是“账户剩余空间”。这三项不是同一个数值。记录文件大小时也保留原单位，避免把软件显示的不同单位直接混用。

有时页面只提示“上传失败”，却没有把状态码显示出来。桌面浏览器可以打开开发者工具的 Network（网络）面板，再做一次必要的上传观察。

这里只是定位请求，不需要修改请求头或反复重发。界面中的进度条也未必代表服务器已经接收并保存了完整文件，最终结果应看应用的完成状态。

对照时保持上传入口和文件类型一致，每次只改变一个条件。不要一边换节点，一边改格式和拆文件，否则恢复后也难以知道原因。

这些是定位线索，不是最终证明。需要换节点作对照时，仍应保持同一入口和同一文件；即使结果不同，也要检查两次请求实际使用的地址是否一致。

如果上传本身成功，只是上传期间网页、通话都变卡，可以另看本站的上行带宽与负载延迟检查。那属于不同的排查方向。

压缩是否有效，取决于原文件内容。已经压缩过的视频或图片，重新打包不一定会明显变小；网站也可能不接受压缩包。只有应用允许相应格式，而且请求确实变小，才可能帮助满足限制。

分片上传通常需要应用把文件分成多次请求，并在接收端校验、合并。自己把文件拆成若干份后逐个上传，不一定能还原成网站需要的文件，也可能改变业务操作的含义。

传输中使用分块编码，与应用提供分片上传并不是一回事，不能据此推断大小限制自动失效。下载支持续传，也不能直接证明上传支持断点恢复，应查看上传功能自己的说明。

如果使用的是第三方网站，应把状态码、文件大小、上传入口和脱敏的错误说明交给网站支持人员，询问当前功能允许的大小或是否有官方提供的其他上传方式。

如果网站由自己管理，可以结合日志检查具体入口。例如 Nginx 的 client_max_body_size 用于限制请求体大小，超过设置值可返回 413，而且配置可以位于不同作用范围。见官方指令说明。

即使一层已经调整，应用本身或其他入口仍可能有限制。因此要先确认是哪一层拒绝请求，再由对应管理者处理，不能仅凭换客户端或换机场套餐提高目标网站的上传上限。

RFC 9110 说明，限制属于临时情况时，服务器应通过 Retry-After 告知何时可以再试。但等待不会自动缩小请求：如果实际问题是固定大小上限，继续提交同一份超大的内容仍可能失败。

遇到超时而没有明确结果时，先查看应用的文件列表或上传记录，确认是否已经保存，再决定下一步。若主要是连接中断，可以参考从订阅到 DNS 的排查顺序。

想交流大文件上传报错，可以提供大小、类型、状态码及失败阶段，截图时遮住账户信息、上传凭据和带令牌的地址：Telegram 联系我。