必须从系统资源、进程限制、nginx自身配置三层协同优化：系统级设置fs.file-max≥655360及nginx用户nofile软硬限为65536，systemd需额外配置limitnofile；nginx主配置中设worker_rlimit_nofile 65536，events块中worker_connections按÷4估算（如16384），启用epoll与multi_accept，并配置worker_cpu_affinity auto确保tls加解密缓存高效。
要让 Nginx 稳定支撑高并发 HTTPS 连接，不能只调 worker_connections，必须从系统资源、进程限制、Nginx 自身配置三层协同优化。HTTPS 每个活跃连接实际占用 3～5 个文件描述符（FD），远高于 HTTP，单点调优极易失效。
系统级文件描述符上限必须拉满
这是最常被忽略的底层前提：
- 运行
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 资源
仅靠系统设置，Nginx worker 进程未必能拿到上限值，必须显式接管：
- 在
nginx.conf的全局块（main context）中添加：worker_rlimit_nofile 65536;
该值不能超过上一步设置的hard nofile，否则启动失败 - 此配置让每个 worker 进程在 fork 后立即调用
setrlimit()，避免因启动环境差异导致 FD 限制被截断
worker_connections 与 HTTPS 实际开销对齐
盲目设高反而触发 too many open files 错误：
- 每个 HTTPS 连接至少消耗：1 个客户端 socket + 1 个日志句柄 + 1 个 SSL session cache slot + （可能）OCSP stapling 文件句柄
- 建议按公式估算：最大安全
worker_connections≤worker_rlimit_nofile ÷ 4（留出余量）
例如worker_rlimit_nofile 65536，则worker_connections设为16384更稳妥 - events 块中启用高效模型：
events {use epoll;worker_connections 16384;multi_accept on;}
CPU 亲和性与 TLS 加密性能绑定
HTTPS 密钥交换、加解密高度依赖 L1/L2 缓存热度，跨核迁移会显著拖慢握手速度：
- 配置
worker_processes auto;和worker_cpu_affinity auto;（Nginx 1.9.10+ 支持） - 验证是否生效：
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n
输出应显示每个 worker PID 固定对应一个唯一 CPU 号（PSR），且编号连续 - 若未生效（如容器环境），需手动指定，例如 4 核：
worker_processes 4;worker_cpu_affinity 0001 0010 0100 1000;
不复杂但容易忽略——系统 ulimit、Nginx rlimit、worker_connections 三者必须数值匹配且逐层生效，缺一不可。
