排查Nginx代理响应截断应先定位是Header还是Body被截：查error.log中“upstream sent too big header”或“prematurely closed connection”提示；用curl对比代理与直连结果，结合-D -检查Content-Length与实际字节数是否一致；通过access日志中$upstream_http_content_length与$body_bytes_sent差值量化截断量；tcpdump抓包观察TCP payload是否卡在4096/8192/32768等缓冲边界。
排查 Nginx 代理响应被截断，关键不是一上来就改配置，而是先确认“哪里断了”——是响应头（Header）被砍掉，还是响应体（Body）只传了一半。盲目调大所有 buffer，既浪费内存，还可能掩盖真实瓶颈，甚至引发 TCP 窗口收缩、忙缓冲区卡死等问题。
看错误日志，快速锁定是 Header 还是 Body 问题
打开 Nginx 错误日志（error.log），重点搜索这两类提示：
- upstream sent too big header → 响应头超限，问题出在 proxy_buffer_size
- upstream prematurely closed connection 或反复出现 client timed out，但后端实际很快返回 → 很可能是 proxy_buffers 不够用，导致 Nginx 暂停读取，上游被迫中断
用 curl 对比，验证响应是否真的不完整
执行两条命令做比对：
- 通过 Nginx 代理请求：curl -s -i http://your-domain/api/ | wc -c
- 绕过 Nginx 直连后端（如 curl -s -i http://127.0.0.1:8080/api/ | wc -c）
如果代理结果明显偏小（比如差几万字节），且没有报错日志，基本可判定是响应体被截断。再加 -D - 查看响应头里的 Content-Length，和实际 body 字节数是否一致——不一致就是截断的直接证据。
加日志字段，量化截断量
在 log_format 中加入 $upstream_http_content_length，例如：
log_format main '$remote_addr - $request_time $upstream_response_time $upstream_http_content_length $body_bytes_sent';
请求后查看 access 日志：若 $upstream_http_content_length 是 42567，但 $body_bytes_sent 只有 32768，差值 9799 就是被截掉的字节数。这个数字能帮你精准判断该调哪个参数、调多大。
抓包确认是否卡在缓冲边界
用 tcpdump -i lo port 80 -w nginx_cut.pcap 抓 Nginx 回包流量，用 Wireshark 打开，看 TCP payload 长度是否频繁停在 4096、8192、32768 这类整数边界。一旦发现规律性卡点，基本实锤是缓冲区硬限制导致的截断，不是后端或网络问题。
