开启proxy_buffering可缓解后端长连接堆积：Nginx快速收完响应并立即释放上游连接，避免慢客户端拖住Java/PHP/Python等后端线程；需配合proxy_buffer_size、proxy_buffers等参数调优，并在SSE、流式下载等场景关闭。
核心思路是：用 proxy_buffering on 让 Nginx 快速收完后端响应、尽早释放上游连接，避免后端线程/连接被慢客户端拖住。
为什么开启 buffering 能缓解长连接堆积
后端（如 Java 应用、PHP-FPM、Python 服务）通常按请求分配连接或线程。如果客户端网络差、接收响应慢，Nginx 默认边收边发（proxy_buffering off），就会让后端一直挂着连接等 Nginx 把数据“吐”给客户端——这直接导致后端连接池耗尽、新请求排队甚至超时。
开启 buffering 后，Nginx 会以高速（内网带宽）从后端一次性读取完整响应（存内存或临时文件），然后立即关闭与后端的连接；后续再按客户端实际速度慢慢发送。这样后端资源快速释放，堆积问题自然缓解。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
关键配置项与推荐值
仅设 proxy_buffering on 不够，需协同调优缓冲能力：
- proxy_buffer_size 16k：确保能装下所有响应头（含大量 Cookie、重定向 Location、自定义 Header）；小于实际头大小会报 “upstream sent too big header”
- proxy_buffers 8 16k：共 128KB 内存缓冲区，适合多数 HTML/API 响应；大文件或模板渲染体可适当加大
- proxy_busy_buffers_size 32k：控制“正在发给客户端”的缓冲上限，设为单 buffer 大小的 2 倍较稳妥
- proxy_max_temp_file_size 1024m：允许单个响应最多写 1GB 临时文件，防小缓冲 + 大响应频繁落盘
- proxy_temp_path /var/tmp/nginx/proxy_temp：指定独立磁盘分区存放临时文件，避开系统盘 IO 瓶颈
配套必须设置的超时与健壮性参数
缓冲只是加速释放后端，不解决后端本身慢的问题。还需防止 Nginx 卡在无效等待上：
- proxy_read_timeout 90：从后端读响应的最长等待时间，超时即断连并返回错误（如 504）；比默认 60s 更宽松，适配慢查询
- proxy_ignore_client_abort on：客户端中途关闭连接时，Nginx 主动中断与后端通信，避免白忙一场
- proxy_next_upstream error timeout http_502 http_503 http_504：任一 upstream 失败自动重试其他节点，提升容错
- upstream 中配置 health_check：主动探测后端存活与响应延迟，连续失败自动剔除，防止流量打到已卡死的实例
哪些情况不能开 buffering？要关掉
不是所有场景都适用 buffering，以下必须设为 proxy_buffering off：
- SSE（Server-Sent Events）、WebSocket 代理（需同时配
Upgrade和Connection: upgrade） - 流式大文件下载、视频分片（mp4/hls）、实时日志推送
- 后端已做 chunked 分块且依赖逐块实时送达（如某些 AI 推理流式输出）
- 客户端与 Nginx 同机房（网络极快），开 buffering 反而增加无谓内存和延迟
