启用tcp快速打开（tfo）可减少首次请求rtt，需内核≥3.7且net.ipv4.tcp_fastopen=3；nginx需编译支持http/2及上游tfo配合；ss -i验证fastopen标记。
启用 TCP 快速打开（TFO）
在高并发反向代理场景下，TCP 握手延迟会成为瓶颈。Nginx 本身不直接控制 TFO，但内核支持后，可显著减少首次请求的 RTT。需确认系统内核 ≥ 3.7（Linux），并开启以下参数：
- net.ipv4.tcp_fastopen = 3：同时启用客户端和服务端 TFO
- 应用层需配合：Nginx 编译时确保 --with-http_v2_module 和内核 TCP 栈兼容；上游服务（如后端应用）也需支持 TFO 才能全程生效
- 验证方式：ss -i 查看连接是否带 fastopen 标记
调优 Nginx 事件模型与连接管理
默认的 epoll 已高效，但需精细配置以匹配硬件与负载特征：
- worker_processes auto;：绑定 CPU 核心数，避免跨核调度开销
- worker_cpu_affinity auto;：自动绑定 worker 到独立 CPU，降低缓存失效
- worker_connections 65535;：结合 ulimit -n 调整至一致（如设为 10 万），防止“too many open files”
- multi_accept on;：让单个 epoll 事件尽可能接受多个新连接，提升突发流量吞吐
精简 TLS/SSL 处理开销
HTTPS 反向代理中，加解密是主要 CPU 消耗源。优化重点在复用与卸载：
- 启用 ssl_session_cache shared:SSL:10m; 与 ssl_session_timeout 4h;，大幅减少 TLS 握手频次
- 优先使用 ssl_protocols TLSv1.2 TLSv1.3;，禁用 TLSv1.0/1.1；TLSv1.3 默认禁用重协商且 1-RTT 握手，性能提升明显
- 若硬件支持，通过 ssl_engine rdrand;（Intel）或加载 openssl engine 利用 AES-NI 加速加密运算
合理设置 upstream 连接池与超时
反向代理性能不仅取决于 Nginx 本身，更受后端连接复用效率影响：
- 在 upstream 块中启用 keepalive 32;（建议 16–64），复用到后端的长连接，避免频繁建连/断连
- 配套设置 proxy_http_version 1.1; 与 proxy_set_header Connection '';，显式启用 HTTP/1.1 持久连接
- 调整超时避免资源滞留：proxy_connect_timeout 3s;、proxy_read_timeout 30s;、proxy_send_timeout 30s;，按后端响应特性微调，不宜过长
