proxy_buffer_size 仅控制响应头缓冲大小，用于避免“upstream sent too big header”导致的502错误；需按实际header长度（如jwt、set-cookie、vary等）精准设置，且必须≤proxy_buffers单块大小，并配合proxy_buffering on及合理清理冗余响应头。
proxy_buffer_size 只管响应头，不碰响应体，也不是 TCP 层参数。调它不是为了“提升吞吐”，而是防止 502 错误——后端返回的 header 太大时，Nginx 拒绝接收，直接报 upstream sent too big header。
先确认要不要调
别一上来就加到 64k。很多业务 header 实际不到 2KB，盲目调大会浪费每个请求的固定内存开销（它是 per-request 分配的）。真正该调的情况有：
- 登录后返回含长 JWT 或多段 Set-Cookie 的 HTML/SSR 页面
- 启用了
Vary: Cookie, User-Agent, Accept-Encoding且 Cookie 值动态增长 - 后端注入了调试头（如
X-Trace-ID、X-Request-ID多层嵌套） - 错误日志中反复出现
upstream sent too big header
验证方法：用 curl -v http://your-api/ 抓响应，统计所有 ^ 行字节数（含 CRLF），再加 20% 余量。比如实测 5212 字节，设 <code>proxy_buffer_size 8k 更稳妥。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
按典型场景设值
数值不是越大越好，要匹配你后端最宽的 header 场景，并满足一个硬约束：必须 ≤ 单个 proxy_buffers 的大小（否则 Nginx 启动失败）：
- 普通 REST API / 静态资源：保持默认
4k或设8k - JWT 认证的 Next.js / Nuxt SSR 应用：建议
12k–16k - 多中间件链路 + 动态 Cookie + Vary 组合：实测常达 10–14k，设
16k起步 - HTTP/2 环境下：还需同步检查
http2_max_field_size（默认也是 4k），否则 HPACK 解码失败同样 502
别忘了配套动作
单改 proxy_buffer_size 是半套配置。它必须和其它缓冲参数协同，否则可能卡死或触发落盘：
- 确保
proxy_buffering on—— 关闭后这个参数被忽略 - 配合
proxy_buffers设置，例如proxy_buffers 8 128k，此时proxy_buffer_size最高只能设128k - 清理后端冗余头比调参数更有效：关掉调试开关、合并重复 Cookie、避免中间件层层追加 trace 头
- 若 header 持续膨胀，优先查后端逻辑，而不是无限制扩大 buffer
常见误区提醒
这几个说法都不对：
- “proxy_buffer_size 是调 TCP 缓冲” → 它是 Nginx 用户态 HTTP 解析层参数，和
tcp_rmem无关 - “设大点更稳” → 每个请求都独占这块内存，16k × 万级并发 = 百 MB 内存，得算清楚
- “放在 http 块里全局生效就行” → 必须放在
location或server块中，且在proxy_pass之前，否则不生效 - “proxy_buffering off 时也要调它” → 不需要，关闭 buffering 后 Nginx 直接透传 header，不校验长度
