文件描述符耗尽是高并发ssl场景下nginx握手失败或连接重置的常见底层原因，需从系统限制、nginx配置（如worker_connections、ssl_session_cache）、运行时fd状态三方面交叉排查与优化。
当 Nginx 在高并发 SSL 场景下出现握手失败（如 SSL_ERROR_SSL、ssl_handshake_timeout）或连接被重置（Connection reset by peer），文件描述符（file descriptor, fd）耗尽是常见却易被忽略的底层原因。Nginx 每个 HTTPS 连接至少占用 2 个 fd（监听 socket + 客户端连接 socket），加上证书链加载、OCSP stapling、日志写入等，fd 消耗远超 HTTP 明文流量。排查需从系统级限制、Nginx 配置、运行时状态三方面交叉验证。
确认系统级文件描述符限制是否触顶
Linux 系统对每个进程和全局 fd 数量均有硬限制。Nginx worker 进程若达到上限，新连接将无法 accept，表现为 SYN 接收但无 ACK 回复，客户端看到 handshake timeout 或 connection reset。
- 查看当前 Nginx 主进程和 worker 进程的 fd 使用量：
ls -l /proc/$(cat /var/run/nginx.pid)/fd | wc -l
再查任一 worker（如ps aux | grep 'nginx: worker' | head -1）的 fd 数：ls -l /proc/<em>worker_pid</em>/fd | wc -l - 检查该进程的软/硬限制：
cat /proc/<em>worker_pid</em>/limits | grep "Max open files" - 对比系统全局限制：
cat /proc/sys/fs/file-max和已分配数cat /proc/sys/fs/file-nr（第三列即已使用） - 注意：systemd 启动的 Nginx 默认受
DefaultLimitNOFILE限制，需在/etc/systemd/system/nginx.service.d/override.conf中显式设置：
[Service]
LimitNOFILE=65536
然后执行systemctl daemon-reload && systemctl restart nginx
检查 Nginx 配置中与 fd 相关的关键参数
Nginx 自身配置会间接放大 fd 压力，尤其在启用 SSL 高级特性时：
-
worker_connections：必须 ≤ 单个 worker 的 ulimit -n。例如 ulimit 为 4096，则
worker_connections 4096是理论极限；实际应预留 10%~20% 给日志、临时文件、上游连接等，建议设为 3000–3500。 -
ssl_session_cache：使用
shared缓存（如ssl_session_cache shared:SSL:10m）可显著降低重复握手开销，减少新建连接频率，从而缓解 fd 压力；禁用或仅用builtin会加剧短连接场景下的 fd 泄漏风险。 -
ssl_stapling 和
ssl_trusted_certificate：OCSP stapling 需要额外发起上游 DNS 和 HTTP 请求，每个请求占用独立 fd；若上游不可达或超时，fd 可能卡住不释放。可临时关闭测试：ssl_stapling off; -
access_log / error_log：高频写入日志（尤其未缓冲）会快速消耗 fd。确保使用
buffer=64k flush=5s或异步写入（OpenResty）；避免access_log /dev/stdout类直接设备写入。
捕获运行时 fd 分配异常与连接生命周期异常
仅看总数不够，需定位“谁占了 fd”以及“为何不释放”：
- 用
lsof -p <em>worker_pid</em> | awk '{print $9}' | sort | uniq -c | sort -nr | head -20查看 fd 分配类型（如socket:[123456]、REG、anon_inode），大量socket且状态为can't identify protocol往往表示连接未正常关闭。 - 抓包确认是否真有 handshake 失败：
tcpdump -i any -nn port 443 -w ssl_issue.pcap，然后用 Wireshark 打开，筛选ssl.handshake.type == 1（ClientHello）后无 ServerHello，或出现TCP RST，基本可锁定服务端主动断连。 - 检查 Nginx error log 中是否有：
* * * * * no live upstreams while connecting to upstream（可能因上游 fd 耗尽）
* * * * * connect() failed (24: Too many open files) while connecting to upstream
* * * * * accept() failed (24: Too many open files) - 启用
worker_rlimit_nofile并设为略高于worker_connections（如 4096），让 Nginx 在启动时主动调用setrlimit，避免依赖 systemd 或 shell ulimit。
验证与长期防护建议
修改后务必做压测验证，而非仅看配置生效：
- 用
ab -n 10000 -c 200 https://yourdomain.com/或更贴近生产的wrk -t4 -c500 -d30s --latency https://yourdomain.com/观察 error log 和 fd 增长趋势。 - 部署监控：通过
nginx_stub_status（配合Active connections）与/proc/<em>pid</em>/fd数联动告警；Prometheus + nginx-exporter 可采集nginx_connections_active与系统指标node_filefd_allocated对比。 - 生产环境推荐组合：
系统级：fs.file-max = 2097152，Nginx serviceLimitNOFILE=65536
Nginx 配置：worker_rlimit_nofile 65536;，worker_connections 32768;，ssl_session_cache shared:SSL:20m;，ssl_session_timeout 4h; - 定期检查
netstat -an | awk '$1 ~ /tcp/ {print $6}' | sort | uniq -c | sort -n，若TIME_WAIT异常高（>50% active），需调优内核：net.ipv4.tcp_tw_reuse = 1和net.ipv4.tcp_fin_timeout = 30，避免 fd 被长时间占用。
