proxy_buffer_size 必须基于实测响应头大小（含\r\n）精准配置，加20%~30%余量后向上取整至2的幂次（如5212→8k），且小于proxy_buffers单块大小、置于location中proxy_pass前、仅proxy_buffering on时生效，并需同步调优http2_max_field_size及精简后端头。

要让 proxy_buffer_size 正确起作用，关键不是堆大数值，而是精准匹配后端实际返回的最大响应头长度，并满足底层协同约束。

怎么测出真实响应头大小

不能靠猜，必须实测：

• 用 curl -v https://your-api/ 2>&1 | grep '^ 抓取原始响应头，逐行统计所有字符 + 每个 <code>\r\n（各算 1 字节）
• 或临时开启 debug 日志：error_log /var/log/nginx/error.log debug;，复现请求后日志会明确写 header: 13782 bytes
• 取多次请求中的最大值，再加 20%～30% 余量防波动

怎么设值才合理

按规则定值，兼顾安全与效率：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 向上取整到最近的 2 的幂次：实测 5212 字节 → 设 proxy_buffer_size 8k；实测 12345 字节 → 设 16k；实测 28900 字节 → 设 32k
• 该值必须小于 proxy_buffers 的单块大小。例如 proxy_buffers 8 128k，则 proxy_buffer_size 最大只能设 128k，但通常 16k 就够用
• 常见稳妥取值：普通 API 用 8k，JWT/SSR 登录页用 16k，多中间件+动态 Cookie 场景建议 32k

配置位置和生效前提

放错地方或条件不满足，这个参数就等于没设：

• 必须放在 location 或 server 块中，且在 proxy_pass 指令之前
• 仅在 proxy_buffering on 时生效；若关闭（如 SSE、gRPC-Web、LLM 流式响应），此参数被完全忽略
• HTTP/2 环境下，还需同步检查 http2_max_field_size（默认仅 4k），它独立限制 HPACK 解码后的单字段长度，否则仍可能 502

配套参数必须一起调

单改 proxy_buffer_size 是半套方案：

• proxy_buffers 8 16k：表示共 8 个缓冲区，每个 16k；其中第一个专供响应头，所以 proxy_buffer_size 必须 ≤ 16k
• proxy_busy_buffers_size 32k：正在发送中的缓冲区总上限，建议设为单 buffer 大小的 2 倍（如 16k × 2 = 32k）
• 优先精简后端响应头：关调试头、合并重复 Set-Cookie、避免中间件层层追加 X-Trace-ID，比调大 buffer 更治本