nginx server块不直接配置连接池大小，而是通过worker_connections全局控制；但可通过client_header_buffer_size、proxy_buffers等指令优化每请求内存开销，并借助proxy_http_version 1.1、keepalive_timeout等实现连接复用与内存隔离。
Nginx 的 Server 块本身不直接配置连接池大小，因为连接池（connection pool）是 Worker 进程级的底层资源，由 events 块中的 worker_connections 全局控制，而非单个 server。但 Server 块可通过影响请求生命周期、缓冲区分配和连接复用行为，显著优化高并发下的内存消耗——尤其在反向代理场景中。
下面这些配置虽写在 server 或其子块（如 location）里，却能精准调控每请求/每连接的内存开销：
控制每个请求的缓冲区用量，避免内存膨胀
客户端请求头、请求体、后端响应数据若缓冲区设得过大，会在高并发时造成大量空闲内存驻留；设得太小又触发频繁扩容或临时文件落盘。
client_header_buffer_size 4k;
设置初始请求头缓冲区大小。默认 1k，对含 JWT 或长 Cookie 的现代 API 易超限，导致降级使用large_client_header_buffers，每次额外分配一个新内存块（可能 8KB+）。4k 覆盖绝大多数场景，平衡安全与开销。large_client_header_buffers 4 8k;
当请求头超出client_header_buffer_size，Nginx 会按此配置逐个分配 buffer。4 个 × 8KB 是合理上限，防止恶意大 header 耗尽内存。client_body_buffer_size 128k;
请求体（如表单、JSON）在此尺寸内全程走内存池小块分配；超过则写入临时文件（磁盘 IO + 更多内存管理开销）。API 场景建议 128k～256k；文件上传服务应配合client_max_body_size并启用proxy_buffering off避免缓存整个上传体。-
proxy_buffering on;
开启后，Nginx 会缓存后端响应再发给客户端，减少后端压力；但需配好以下参数：-
proxy_buffer_size 16k;：首块缓冲区（存响应头），至少等于最大响应头长度； -
proxy_buffers 8 16k;：后续数据缓冲区，8 块 × 16KB = 128KB 总缓存空间； -
proxy_busy_buffers_size 32k;：允许发送中的缓冲区上限，避免阻塞新数据写入。
-
示例：10 万并发下，若
proxy_buffers设为16 64k（1MB/连接），仅此一项就占用约 100GB 内存——远超必要。
强制复用连接，减少连接池碎片与内存抖动
Server 块中通过 proxy_* 指令驱动连接复用，直接影响 upstream 连接池的稳定性和内存驻留量：
proxy_http_version 1.1;
启用 HTTP/1.1 是复用的前提，否则默认用 HTTP/1.0，每次请求新建连接。proxy_set_header Connection "";
清除客户端传来的Connection: close头，避免 Nginx 被误导而主动关闭连接。proxy_set_header Proxy-Connection "";
兼容老旧客户端，防止中间设备干扰 keepalive。keepalive_timeout 60s;
配合 upstream 的keepalive 200;使用，确保连接在空闲 60 秒内可复用。过短（如 5s）导致频繁重建连接；过长（如 300s）会让空闲连接长期占用 socket 和内存。
隔离请求内存上下文，防止池污染
Server 块中所有 proxy_pass 请求都应确保使用独立请求池（Nginx 自动完成），但需避免手动干预破坏这一机制：
- 不要在
location中调用ngx_alloc或malloc分配内存后不挂入r->pool->large； - 不要跨请求复用
r->pool中的指针（例如缓存到共享变量）； - 若需自定义模块处理，必须用
ngx_pcalloc(r->pool, ...)分配，并在 handler 返回前释放或交由 Nginx 自动回收。
这类操作一旦出错，会导致小块分配失败、大块脱离内存池管理，使“4095 字节以内走线性区”的设计失效，间接放大内存碎片和延迟。
不复杂但容易忽略
