用户传几百兆视频老失败，413 和 504 都报过，只把网关限制调大管用吗？

开篇结论：用户上传几百兆文件失败，413 和 504 往往是两个不同层发出的信号：413 表示请求体超过了某一层配置的上限，504 表示链路中有节点在设定时间内没等到上游或落盘完成。按 2026 年常见交付经验，只把网关的体积上限调大，通常只能消掉 413，接下来超时、临时文件落盘、应用内存和对象存储分片会依次暴露。所以先分层定位，再决定是继续调参数还是改成分片上传。

413 和 504 分别是谁在报，先分清三层

413 Request Entity Too Large 一般发生在请求体还没读完的时候，由反向代理或应用框架直接拒绝，属于「没进门」的错误；504 Gateway Timeout 表示请求已经进了某一层，但这一层在等待后端、等待落盘或等待上游响应的过程中超过了阈值。同一段上传代码，在不同部署形态下先撞到哪一层限制，就会报哪个错。

区分有个简单办法：看响应码返回的时机和日志落点。响应在几秒内就返回 413，多半是体积上限；进度条走到一大半才 504，多半是超时或者缓冲落盘。两侧日志只出现一条，说明限制在那一侧；两侧都有记录，说明请求已经穿透到内层。

• 入口网关：请求体上限、读取超时、是否开启缓冲以及缓冲用的临时目录；
• 应用与框架：multipart 单文件与总大小阈值、临时目录、请求体上限；
• 业务处理：是否把整个流读进内存、对象存储单次写入超时、分片大小与重试策略。

按三层核对的顺序：先定层，再只改一个参数

为什么按从外到内划分？外层决定请求能不能进门，中层决定能不能接住，内层决定处理得完。跳过外层去改内层参数，往往看不到任何变化，因为请求在外层就被拒了；反过来，只放开外层而不看内层，错误会被推到更晚的环节出现，排查反而更费时间。

1. 先复现并记录：浏览器网络面板里的响应码、响应耗时、响应头中的服务端标识，同时保存网关与应用两侧的日志，确认是哪一侧先拒绝；
2. 核对入口网关：请求体上限、读取超时、缓冲开关与临时目录剩余空间，这一步只改一层，改完立刻复现一次；
3. 核对应用层：框架的请求体配置、multipart 阈值、临时目录配额是否比网关更小；
4. 核对处理层：是否边读边写对象存储、单次写入超时是否短于用户可接受的等待时间、失败重试会不会重复占用连接和磁盘。

每改一层就复现一次，并记录报错是否换位，这是判断「改对了」还是「只是把问题推后」的主要依据。把三层参数同时调大，常见的结果是错误在更晚的节点才出现，日志里反而找不到清晰线索。

为什么把限制调大，问题常常换一层继续报

在一次项目交付中，约束是这样的：运维只给一个改配置的窗口，素材是几段几百兆的视频，预算和排期内不方便立刻上分片方案。做法通常是把网关请求体上限从默认值抬到能覆盖单个文件，再顺手把读取超时从几十秒调到几分钟。结果 413 确实消失了，但报错改成 504，进度条卡在八九成——原因是开启缓冲后，文件要先写进网关临时目录，慢盘加上合并落盘的耗时超过了超时时间。当晚只能把配置改回并追加磁盘和超时，第二天补分片方案，整体排期往后延了一天左右。这类过程说明：调参数能验证方向，不能替代方案选择。

同步直传和分片上传，怎么按场景选

判断不只看文件大小，还要看网络稳定性、是否需要断点续传，以及合规上是否要求文件必须经过服务端。下面这组对比按常见的交付口径给出经验区间，供估算改造量时参考。

• 体积与网络：单文件几十兆以内、内网或稳定网络，同步直传够用；几百兆到 GB 级、移动网络，分片更稳；
• 网关压力：整包过网关会长时间占用连接，还可能触发磁盘缓冲；分片每片较小，压力可以摊平到多次请求；
• 断点续传：同步直传断线基本要整包重传；分片可以按片重传，前端记录已完成的分片编号即可；
• 实现成本：同步几乎不用改前端；分片要处理切片、合并、状态记录与过期清理，按经验区间，实现加联调大致多出几天到两周，视团队对对象存储的熟悉度浮动；
• 直传对象存储：前端拿一次临时签名直接上传，服务端只做签名与回调确认，适合公网大素材，但单文件大小上限、签名有效期和内容类型要写进策略里。

几种形态并不互斥。2026 年常见做法是：小文件走同步、大文件走分片或直传，服务端保留一次元数据校验，避免客户端绕开业务规则直接写入。

上线前的验收口径：做到什么算合格

• 用真实弱网和移动端各复现一次，而不是只在办公内网上传；
• 失败时用户能看到明确提示，而不是进度条卡住没有任何反馈；
• 成功与失败两条路径下，临时文件和半截对象都被清理；
• 单次上传不会把网关连接、应用内存或磁盘配额吃满；
• 重试同一份文件，不会在业务库里产生两条记录。

这些口径写进交付验收清单，比口头约定「注意大文件」有用得多，也能在联调阶段减少反复扯皮。

适用场景与边界

适合改成分片或直传的情况：面向公网用户、单文件经常到几十兆以上、网络不稳定、需要断点续传或秒传的业务。这类场景里，改造收益通常能覆盖实现成本。

不必上的情况：内网后台、Excel 导入普遍只有几兆、上传频率很低时，先把网关与应用的大小和超时配对调好即可，硬上分片只会增加前端复杂度与联调时间。

边界判断句：要不要改架构，不看文件上限的数字本身，而看失败是否影响核心流程、是否频繁需要重传、以及网关磁盘和超时是否已经反复成为瓶颈。

常见问题

上传一半报 413，改完变 504，是配置改错了吗？

通常是限制从一层换到了下一层：体积放开后请求真的开始传输，超时和缓冲落盘的问题才第一次暴露出来。

分片上传合并失败，会不会在存储里留下半截文件？

会。常见做法是合并成功后再对外可见，并给上传会话设置状态和过期清理，失败分片由定时任务回收。

前端直传对象存储，服务端是不是就不用管文件大小了？

不是。签名时要写入单文件大小上限、有效期和内容类型限制，桶侧也要配策略，否则等于把限制交给客户端。

内网系统传几十兆的 Excel，也要改成分片吗？

一般不必。内网带宽稳定、失败可重试，先把网关与应用的大小和超时配置配对核对更划算。

怎么区分是超时断掉，还是被防火墙切断？

看两侧日志时间点是否对得上。超时通常有明确耗时边界，中间设备断连常表现为连接重置且应用层没有对应记录。

如果是第一次遇到，先把网关、应用、处理三层各核一遍，再决定改参数还是改方案；只有公网、大素材、断点续传需求同时成立时，分片或直传才值得排进排期。内网小文件场景优先保证提示清晰和临时文件清理干净，不必为了架构好看增加交付复杂度。