直接排查 TLS Session Ticket 文件读写引发的文件描述符卡顿，关键是确认 Nginx 是否配置了 ssl_session_ticket_key 指向磁盘文件，导致每个 worker 进程独占一个 fd，叠加后易触达 ulimit -n 上限；应改用内存密钥或关闭 tickets 并启用 shared session cache。
直接排查 TLS Session Ticket 文件读写引发的文件描述符卡顿，关键不是看日志有没有报错，而是确认 Nginx 是否真的在用文件方式操作 ticket 密钥、且该行为已突破系统资源上限。
确认是否启用了基于文件的 Session Ticket
Nginx 的 ssl_session_tickets on 本身不涉及文件读写——它只启用客户端携带票据的能力；真正触发文件 I/O 的是 ssl_session_ticket_key 指令。只要配置了这行并指向一个磁盘路径（如 /etc/nginx/ssl/ticket.key），Nginx 就会在 worker 进程启动时打开该文件，并持续持有其文件描述符。
- 检查配置中是否存在
ssl_session_ticket_key指令，且路径为本地文件（非内存设备或符号链接） - 运行
lsof -p $(pgrep nginx) | grep ticket，若看到多个 worker 进程都打开了同一个 .key 文件，说明每个 worker 都独占一个 fd - worker 进程数 × 1 = 实际占用的 ticket key fd 数量；8 个 worker 就占 8 个 fd，叠加其他模块很容易触达
ulimit -n限制
快速验证文件描述符是否成为瓶颈
不是所有“卡顿”都源于 fd 耗尽，但高并发下 ticket key 文件被重复打开是最隐蔽的 fd 泄漏源之一。
- 执行
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，确认软限制值（通常是 1024 或 65535） - 统计当前所有 nginx 进程打开的文件总数：
lsof -p $(pgrep nginx) | awk '{print $2}' | sort -u | wc -l - 若接近或等于软限制值，再查其中 ticket.key 占比：例如
lsof -p $(pgrep nginx) | grep ticket.key | wc -l，若结果等于 worker 数量，基本可定位
治本方案：改用内存密钥或禁用 tickets
Session Ticket 本意是提升复用效率，但 Nginx 当前实现对多进程共享支持不完善，文件方式反而引入资源竞争和 fd 压力。
- 推荐关闭：
ssl_session_tickets off;，改用ssl_session_cache shared:SSL:50m;+ssl_session_timeout 4h;组合，复用率更高、无文件依赖 - 若必须保留 tickets，避免用磁盘文件：将密钥内容 base64 编码后通过
ssl_session_ticket_key直接写入配置（需 Nginx ≥ 1.19.7），跳过文件打开环节 - 绝对不要用
ssl_session_ticket_key指向 NFS 或网络存储路径——单次读取延迟放大后会拖垮整个握手链路
配套检查项（防止误判）
文件描述符卡顿常被误认为是 ticket 导致，实际可能混杂其他因素：
- 确认未同时开启
ssl_stapling on且 OCSP 响应缓存目录（如/var/cache/nginx/ocsp）权限异常或磁盘满，那也会阻塞 handshake 并占用 fd - 检查
worker_rlimit_nofile是否已设为足够大（如 65535），且系统级 limits.conf 已同步生效 - 禁用 tickets 后，用
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "New, TLS"验证 session 复用是否仍生效（输出含 “Reused, TLS” 即正常）
