SSL/TLS加密显著抬高单连接资源开销，压缩worker_connections可用上限：每个HTTPS连接比HTTP多占100–250KB内存、额外fd，并引入SSL上下文、会话缓存、OCSP stapling等附加资源消耗。
SSL/TLS 加密连接会显著抬高单连接资源开销，从而实质性压缩 worker_connections 的可用上限——它不是“加了 SSL 就少一半连接”，而是每个 HTTPS 连接比 HTTP 多占用 100–250 KB 内存、额外消耗文件描述符，并引入 SSL 上下文、会话缓存、OCSP stapling 等附加资源项。
SSL/TLS 如何拉低实际可支撑连接数
启用 HTTPS 后，worker_connections 数值虽不变，但真实并发能力下降，原因在于：
- 每个 HTTPS 连接需维护独立的 SSL/TLS 上下文（含密钥、加密状态、缓冲区），内存占用从纯 HTTP 的 20–50 KB 升至 100–250 KB；
- SSL 会话复用（session cache）本身也占 fd 和内存，
ssl_session_cache shared:SSL:10m会额外预留约 1–2 万个会话槽位，对应同等数量的潜在 fd 消耗； - OCSP stapling 启用后，Nginx 需定期与 OCSP 响应服务器建立后台连接，这些连接也计入
worker_connections总量； - HTTP/2 over TLS 下，多路复用虽减少连接数，但单个连接承载更多流（stream），对 buffer 和上下文管理压力更大，单连接内存可能逼近 300 KB。
配置建议：HTTPS 场景下 worker_connections 的安全取值
不能直接套用 HTTP 场景的数值。需按“可用内存 ÷ 单连接平均开销”反推，并留足余量：
- 若服务器可用内存为 6 GB，走 HTTPS + 反向代理，预估单连接均值 250 KB，则理论最大连接数 ≈ 6 × 1024 ÷ 0.25 ≈ 24,576；
- 设
worker_processes auto（8 核即为 8），则单个worker_connections应控制在 3072 左右（24576 ÷ 8），推荐取整为 4096 并同步配平限制； - 若启用了
ssl_session_tickets on和较大 session cache（如shared:SSL:20m），建议将worker_connections降低 15%–20%，避免 fd 耗尽或 OOM； - 长连接保活型 HTTPS（如 WebSocket over TLS 或监控上报），应配合
keepalive_timeout 30;，并把worker_connections控制在 2048–6144 区间，重点保障worker_rlimit_nofile≥ 该值 × 1.2。
必须同步调优的配套项
只改 worker_connections 对 HTTPS 场景几乎无效，以下三项必须对齐：
-
系统级 fd 限制：确保
ulimit -n≥worker_connections × worker_processes × 1.3（例如 4096 × 8 × 1.3 ≈ 42,500），并在/etc/security/limits.conf中为 nginx 用户持久设置； -
Nginx 进程级声明：在
nginx.conf主块（events 外）添加worker_rlimit_nofile 65536;，该值须 ≥worker_connections × worker_processes； -
内核网络参数：调大
net.core.somaxconn（建议 ≥ 32768）和net.ipv4.tcp_max_syn_backlog（≥ 16384），防止 TLS 握手阶段连接在内核队列中溢出丢弃。
验证是否真正生效
配置重载后，不能只看 nginx 启动成功，要实测确认：
- 运行
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认Max open files值已提升； - 用
ss -s观察tcp连接总数是否接近预期上限； - 开启
stub_status，持续压测时关注Active connections是否稳定在worker_connections × worker_processes的 80% 以内； - 检查错误日志是否有
accept() failed (24: Too many open files)或SSL_do_handshake() failed类报错。
