核心是匹配响应特征：proxy_buffer_size至少16k保响应头完整，proxy_buffers按JSON大小设为8 4m或4 16m等组合，总容量≥最大响应体且单buffer≥TCP分包大小，并配proxy_busy_buffers_size、proxy_max_temp_file_size 0及proxy_read_timeout。
处理接口返回超大 JSON 时的性能问题，核心不是“把缓冲区设得越大越好”，而是让 Nginx 的缓冲机制匹配实际响应特征：既要稳收完整响应（不丢、不断、不报 502），又要避免内存浪费或频繁拷贝拖慢吞吐。
先确认问题根源是响应体还是响应头
超大 JSON 本身不会直接触发 502 Bad Gateway，真正导致失败的常见原因有两个：
- 响应头过大（比如长 JWT 在 Set-Cookie 或 Authorization 中），触发 "upstream sent too big header" 错误——这时要调 proxy_buffer_size
- 响应体过大但 proxy_buffers 总容量不足 或单 buffer 太小，导致接收过程中缓冲区溢出、连接重置——这时要调 proxy_buffers 及关联参数
验证方法：查 error.log 中是否有上述错误；用 curl -v 抓响应头总长度，看是否超过默认 4k；用抓包或后端日志确认响应体真实大小。
合理设置 proxy_buffer_size（专管响应头）
这个值只影响 HTTP 响应头的接收能力，和 JSON 内容无关，但必须足够容纳最长单行 header。典型配置：
- proxy_buffer_size 8k; —— 普通带 JWT 和基础追踪头的系统
- proxy_buffer_size 16k; —— 含多域名 Cookie、链路 ID、调试字段的中大型服务
- proxy_buffer_size 32k; —— 极少数 OAuth2 或遗留系统（不建议盲目设 1m）
注意：必须放在 location 或 server 块中、proxy_pass 之前生效。
科学配置 proxy_buffers（承载响应体）
关键看两个维度：总容量 ≥ 最大响应体，单 buffer 大小 ≥ TCP 分包典型 payload（通常 4k–16k）。推荐组合：
- JSON 稳定在 20–50 MB：proxy_buffers 8 4m;（总 32 MB，单块 4 MB，兼顾复用与分片效率）
- JSON 波动大（5 MB ~ 100 MB）：proxy_buffers 4 16m;（总 64 MB，单块更大，减少 buffer 管理开销）
- 极端场景（如导出百 MB 配置）：proxy_buffers 16 1024k;（总 16 MB？不对，是 16 × 1024k = 16 MB？等等——实际是 16 MB？不，1024k = 1MB，16×1MB = 16MB，仍不够。应为 proxy_buffers 16 8m; 或 proxy_buffers 8 16m;）
同时必须配齐联动参数：
- proxy_busy_buffers_size 32m;（设为单 buffer 大小的 2 倍，防止过早转发中断上游流）
- proxy_max_temp_file_size 0;（禁用落盘，避免磁盘 I/O 拖慢大响应）
- proxy_read_timeout 300;（给上游留足生成时间，尤其导出类接口）
其他关键协同项不能漏
光调缓冲区还不够，这些设置直接影响大 JSON 转发的稳定性：
- proxy_buffering on;（保持开启；关掉会把压力甩给客户端，弱网下更易失败）
- client_max_body_size 与业务对齐（避免请求阶段就拒掉合法的大 JSON 上报）
- 确保 /var/tmp/nginx/proxy_temp 目录权限正确（Nginx 用户可读写），否则缓冲区满后落盘失败也会报 502
- 若用 HTTP/2，检查 http2_max_field_size 是否足够（默认 4k，长 header 会截断）
