必须从系统资源、Nginx进程限制、TLS层复用三方面协同优化：系统级设fs.file-max≥655360及nginx用户nofile软硬限为65536，systemd需额外配置LimitNOFILE；Nginx主配置设worker_rlimit_nofile 65536，events块中worker_connections按÷4估算（如16384），启用epoll与multi_accept；TLS层启用ssl_session_cache shared:SSL:10m、ssl_stapling on及精简密码套件。
要让 Nginx 稳定处理高并发 HTTPS 响应，不能只调 worker_connections，必须从系统资源、Nginx 进程限制、TLS 层复用三方面协同发力。HTTPS 每个活跃连接实际占用 3～5 个文件描述符（FD），且 TLS 握手、证书验证、OCSP 查询等环节都会放大延迟和资源开销。
系统级文件描述符必须拉满
这是最易被忽略的底层前提：
- 运行
cat /proc/sys/fs/file-max，确保 ≥ 655360；不足则写入fs.file-max = 655360到/etc/sysctl.conf并执行sysctl -p - 编辑
/etc/security/limits.conf，添加（用户名需与 Nginx 的user指令一致）：nginx soft nofile 65536nginx hard nofile 65536 - 若使用 systemd（绝大多数现代系统），还需在
/etc/systemd/system/nginx.service.d/override.conf中加入：[Service]LimitNOFILE=65536
然后执行systemctl daemon-reload && systemctl restart nginx - 验证：执行
sudo -u nginx bash -c 'ulimit -n'，输出应为65536
Nginx 主动声明并约束 FD 资源
仅靠系统设置，worker 进程未必能拿到上限值，必须显式接管：
- 在
nginx.conf全局块（main context）中添加：worker_rlimit_nofile 65536;
该值不能超过limits.conf中设置的hard nofile，否则启动失败 - 此配置让每个 worker 在 fork 后立即调用
setrlimit()，避免因启动环境差异导致 FD 限制被截断
worker_connections 与 HTTPS 实际开销对齐
盲目设高反而触发 too many open files 错误：
- 建议按公式估算：
最大安全worker_connections ≤ worker_rlimit_nofile ÷ 4（预留余量）
例如worker_rlimit_nofile 65536，则设为16384更稳妥 - events 块中启用高效模型：
events {use epoll;worker_connections 16384;multi_accept on;}
TLS 层复用与响应加速
高并发 HTTPS 的瓶颈常在握手和证书验证环节，复用是关键：
- 启用共享内存 SSL 会话缓存：
ssl_session_cache shared:SSL:10m;
10MB 可缓存约 4 万个会话，适合日均百万级请求 - 设置合理超时：
ssl_session_timeout 10m;
过短（如 1m）复用率低，过长（如 4h）易占满内存且增加泄露风险 - 启用 OCSP Stapling：
ssl_stapling on;ssl_stapling_verify on;
让 Nginx 主动获取并缓存吊销状态，省去客户端额外查询 RTT - 精简加密套件，优先 ECDHE：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
禁用 TLSv1.0/1.1：ssl_protocols TLSv1.2 TLSv1.3;
