Nginx响应截断需先定位是响应头还是响应体被截：查日志（upstream sent too big header）、curl对比、$upstream_http_content_length比对、tcpdump抓包；头超限调proxy_buffer_size（按实测值取2的幂次，置于location内）；体超限合理设proxy_buffers与proxy_busy_buffers_size（参考P95×1.2）；流式场景可关proxy_buffering并调大超时。
Linux 下 Nginx 代理响应数据被截断，本质是缓冲区容量与实际响应不匹配。关键不是堆大所有参数，而是先定位截断位置（响应头 or 响应体），再分层调整对应参数。
先确认截断发生在哪一部分
不查日志就改配置，大概率白忙活：
- 看错误日志：出现 upstream sent too big header → 响应头超限，问题在
proxy_buffer_size - 用 curl 对比：执行
curl -i http://your-api/ | wc -c，再直连后端（绕过 Nginx）做同样操作；若 Nginx 返回字节数明显偏少且无报错 → 响应体被截断 - 加日志字段验证：在
log_format中加入$upstream_http_content_length，对比该值与实际返回长度的差值，就是被截掉的字节数 - 抓包辅助判断：用
tcpdump -i lo port 80观察 TCP payload 是否卡在 4K、32K 等整数边界，可实锤是否为缓冲硬限制
响应头过大：调大 proxy_buffer_size
这个参数只管响应头（状态行 + 所有 Header），和响应体无关。默认 4k 在 JWT、多 Cookie、链路追踪头场景下极易打爆：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 实测响应头大小：用
curl -v http://api/ 2>&1 | grep '^<'提取头，再wc -c统计总字节；若 ≥ 4096，就必须调 - 推荐值：从 16k 起步，JWT+多 Cookie 场景设 16k；OAuth2 回调或全链路埋点密集时设 32k 或 64k
- 必须写在
location块内，且位于proxy_pass之前；若启用 HTTP/2，还需同步检查http2_max_field_size（默认也是 4k）
响应体过大：合理配置 proxy_buffers 和 busy 缓冲区
这是响应体缓冲主力，目标不是“越大越好”，而是匹配业务真实体积：
- 参考后端 P95 响应体大小：例如接口 P95 是 400KB，按 1.2 倍冗余 → 需至少 480KB 缓冲总量；可设
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所在磁盘有空间、权限可写
流式或超大响应场景：考虑关闭缓冲
对 SSE、日志流、大文件导出等持续输出接口，Nginx 缓冲反而成为瓶颈：
- 在对应
location中设proxy_buffering off，此时proxy_buffers和proxy_busy_buffers_size失效，数据收到即发 - 必须同步延长超时：如
proxy_send_timeout 300（SSE 推荐）、proxy_read_timeout 300（需 ≥ send_timeout） - 注意权衡：关缓冲会降低并发控制能力，弱网客户端更易中断，仅用于明确支持流式且后端稳定输出的场景
