响应头被截断时应调大proxy_buffer_size，响应体被截断则调整proxy_buffers或磁盘缓冲；需先通过日志、curl对比、日志字段和抓包精准定位截断类型，避免盲目调大缓冲引发新问题。
防止后端响应被截断，关键不是堆大所有缓冲值，而是先分清是响应头（Header）还是响应体（Body）被截，再针对性调整参数。盲目统一调高 buffer 容易掩盖真实瓶颈，甚至引发忙缓冲区卡死、TCP 窗口收缩等问题。
第一步：精准定位截断类型
不查日志和实测就改配置，大概率走偏：
- 看错误日志：出现 upstream sent too big header → 响应头超限，问题在
proxy_buffer_size - 用 curl 对比：执行
curl -i http://your-api/ | wc -c，再直连后端对比字节数；明显偏短且无报错 → 响应体被截，问题在proxy_buffers或磁盘缓冲 - 加日志字段：在
log_format中加入$upstream_http_content_length，与实际返回长度比对，差值就是截断量 - 抓包验证：用
tcpdump -i lo port 80观察 TCP payload 是否卡在 4K、32K 等整数边界，可确认是否为缓冲硬限制
第二步：响应头过大 → 调大 proxy_buffer_size
该参数只管响应头，必须完整读完才能拿到状态码和后续控制信息。默认 4k 在现代应用中普遍不够：
- 实测响应头总长（
curl -v http:// 2>&1 | grep '^），若 ≥ 4096 就需调整 - 常见安全取值：16k（适配 JWT + 多 Cookie）、32k（OAuth2 回调、链路追踪头密集场景）
- 必须写在
location或server块内，且位于proxy_pass之前 - HTTP/2 用户额外检查
http2_max_field_size（默认也是 4k），它独立限制单个 Header 字段长度
第三步：响应体过大 → 合理扩容 proxy_buffers
这是响应体缓冲主力，重点不在“堆数量”，而在匹配业务节奏：
- 参考后端 P95 响应体大小：设
proxy_buffers 数量 × 单块大小 ≥ P95 × 1.2。例如 P95 是 400KB →proxy_buffers 16 32k（512KB 总量） -
proxy_busy_buffers_size必须配套设置：建议为总量的 1/4～1/2，且 ≥ 单块大小。上例中推荐设为 256k 或 512k - 确保
proxy_buffering on（默认开启，但location内可能被覆盖） -
proxy_max_temp_file_size别设为 0：建议设为1024m，并确认proxy_temp_path所在磁盘有足够空间和正确权限
第四步：防传输中断 → 同步调整超时与流式节奏
后端已发数据，Nginx 却“停着不收”，本质是忙缓冲区满导致 TCP 窗口收缩：
-
proxy_send_timeout控制两次向客户端发送数据的间隔，不是总耗时。后端每 30 秒 flush 一次 → 设为 45s；SSE 或导出类接口建议 300s -
proxy_read_timeout必须 ≥proxy_send_timeout，否则还没传几块就被整体掐断 - 若后端支持流式响应（如分块 HTML、日志流），且 Nginx 缓冲始终成为瓶颈，可考虑在特定
location关闭缓冲：proxy_buffering off（慎用，影响并发性能）
