Large multipart/form-data偶发无法传输至后端，该如何排查？

排查方向 #

客户端侧逻辑排查 #

• 校验前端表单提交的最大内容长度阈值，对比服务端配置的请求大小限制（如Spring栈的server.max-http-header-size、spring.servlet.multipart.max-request-size参数），部分服务端触发大小阈值时会直接断开连接，请求不会进入业务逻辑层，也不会返回可识别的异常报文。
• 检查前端提交相关的中断逻辑：长内容输入时是否存在用户误触发页面刷新、表单重复提交拦截逻辑误判提前终止请求、路由跳转自动取消未完成请求的规则，这类场景下请求未完成发送，Wireshark无法捕获完整HTTP报文。
• 在前端提交逻辑中增加埋点，记录请求发起时间、payload大小、XMLHttpRequest/fetch的错误回调状态、超时参数配置，确认请求是在发送阶段被终止还是传输阶段被断开。

中间代理层配置排查 #

• 检查服务端前置Nginx、CDN、WAF等代理设备的配置：重点核对client_max_body_size、client_body_timeout、请求体缓冲区大小参数，长内容传输超过超时时间或大小阈值时，代理会直接断开TCP连接，请求不会到达后端业务服务，服务端侧无法捕获对应HTTP报文。
• 核对服务端TCP内核参数：如net.ipv4.tcp_fin_timeout、net.core.somaxconn，高并发场景下连接队列满会直接丢弃新连接的请求包，也会触发类似现象。

服务端前置解析逻辑排查 #

• 确认当前使用的file-upload.jar版本是否存在已知BUG：低版本Apache Commons FileUpload处理分块传输的大表单时，存在误判请求为EOF的已知问题，可升级到最新稳定版验证是否复现。
• 检查请求Content-Type配置：长内容表单如果未正确配置multipart/form-data或边界值异常，会导致请求体解析提前终止，直接标记为EOF。

复现验证方案 #

• 用接口测试工具直接构造超大payload的表单请求，高频压测目标接口，排除用户操作、网络波动的干扰，尝试稳定复现问题。
• 异常发生时同时在客户端、代理层、服务端三层抓包，对比TCP包流转情况：如果客户端已发送TCP包但服务端未收到，优先排查中间网络链路；如果客户端未发起请求发送，优先定位前端逻辑问题。

内容的提问来源于stack exchange，提问作者mazha