大报文在负载均衡转发中被截断本质是某层缓冲或传输环节强制切分丢弃，需聚焦“谁在截”和“为什么截”：重点检查nginx client_body_buffer_size（须设于location块）、client_max_body_size、后端接收限制及中间设备干预，并通过三端抓包比对content-length与tcp流完整性来精确定位。
大报文在负载均衡接入转发过程中被截断，本质是请求体在某一层缓冲或传输环节被强制切分、丢弃或落盘失败，而非网络层分片问题。排查要聚焦“谁在截”和“为什么截”，重点看Nginx（或其他LB）的缓冲配置、后端接收能力、以及中间设备对TCP流的干预。
检查Nginx client_body_buffer_size与关联参数是否匹配
这是最常见原因。client_body_buffer_size设得太小，Nginx会在读取POST体时提前触发落盘或直接拒绝，表现就是大报文被截断、返回413或502。
- 确认该参数在
location块中设置，而非全局server或upstream——Nginx不支持后两者生效 - 若后端支持流式处理（如WebFlux、Express raw parser），建议设为
1m并开启proxy_request_buffering off;，绕过Nginx缓存 - 若后端需完整接收（如Java Servlet、PHP-FPM），缓冲区至少设为
2m，且必须同步配client_max_body_size 20m（不能只设缓冲区） - 禁用
client_body_in_file_only on;——该指令会强制所有请求体写磁盘，极易因临时目录满或权限问题导致截断
验证后端服务能否原样接收未缓冲的大流
即使Nginx没截，后端也可能因自身限制丢弃或截断数据。需单独测试绕过LB直连后端：
- 用curl -X POST --data-binary @large-file.bin 直连后端地址，观察是否完整接收
- 检查后端框架的body size限制：Spring Boot的
server.max-http-header-size和spring.servlet.max-request-size、Node.js的express.json({limit: '50mb'})等 - 确认后端没有启用反向代理类中间件（如某些API网关）二次做body解析和截断
抓包定位截断发生在哪一跳
用Wireshark在客户端、Nginx、后端三处分别抓包，比对HTTP请求体长度：
- 客户端发出的POST请求Content-Length是多少？实际TCP流是否发全？
- Nginx所在机器上抓Loopback或对应网卡，看它收到的是否完整；再看它发给后端的请求是否已变短
- 后端机器上抓包，确认是否收到被Nginx改写后的短请求，或根本没收到后续数据段
- 特别注意TCP窗口、RST、Zero Window等异常标志——可能是某端主动中断了流
排除中间设备干扰（如WAF、防火墙、SD-WAN）
某些安全设备或广域网优化设备会对HTTP body做深度检测或重组，对超长或非标准格式报文直接截断或重置连接：
- 临时旁路WAF或防火墙，复现问题是否消失
- 检查SD-WAN控制器是否启用了应用识别策略，对大POST流量做了限速、分片或QoS标记干扰
- 确认链路上没有MTU不匹配导致TCP分段异常，尤其在含VXLAN/GRE隧道的场景下
