net.core.somaxconn是Nginx扛住HTTPS瞬时握手的第一道生死线，必须与Nginx listen backlog对齐（如均设为262144），否则连接被内核静默丢弃；还需同步调优tcp_max_syn_backlog、netdev_max_backlog、file-max等参数，并启用multi_accept和epoll以提升取连接效率。
要让 Nginx 真正扛住大规模瞬间 HTTPS 握手（比如秒杀、活动开抢、CDN 回源高峰），net.core.somaxconn 不是“可选优化”，而是第一道生死线。它管的是“三次握手已完成、但还没被 Nginx accept() 取走”的连接队列。默认 128 或 1024，一瞬万级建连直接溢出——连接被内核静默丢弃，客户端只看到超时、重传、502/503，Nginx 日志里根本没记录。
必须对齐：somaxconn 和 Nginx listen backlog 是硬绑定关系
两者取最小值生效：实际队列长度 = min(net.core.somaxconn, Nginx listen backlog)。只改内核不改 Nginx 配置，等于白调。
- 在 server 块中显式声明 HTTPS 监听，并带 backlog 参数：
listen 443 ssl http2 backlog=65535;（若内存充足、目标百万级，可设为 131072 或 262144） - 不要依赖默认值（旧版 Nginx 默认 backlog=511，新版仍可能 fallback）
- 验证是否生效：运行 ss -ltn | grep ':443'，看 Send-Q 列是否已更新为你设置的数值
按 HTTPS 场景算准下限：别拍脑袋设值
HTTPS 握手比 HTTP 更耗 CPU 和上下文切换，瞬时积压更严重。需结合 worker 分布估算单端口压力：
- 假设 8 核服务器，worker_processes auto → 实际 8 个 worker
- 设 worker_connections 65535，理论总连接约 52 万
- HTTPS 流量集中在 :443 端口，最坏情况该端口需承载近半连接 → 单端口待 accept 连接峰值 ≥ 20 万
- 推荐 net.core.somaxconn = 262144（留 30% 余量应对毛刺与分布不均）
同步加固 TCP 全链路缓冲，避免前序环节卡死
somaxconn 只是“全连接队列”一环。SYN 半连接、网卡收包、文件句柄任一环节不足，都会导致握手在更早阶段失败：
- net.ipv4.tcp_max_syn_backlog = 262144：匹配 somaxconn，防 SYN 队列满丢包
- net.core.netdev_max_backlog = 131072：提升网卡软中断处理能力，防突发流量丢包
- fs.file-max = 655350：系统级文件描述符上限，按并发 ×1.5 预留
- net.ipv4.tcp_tw_reuse = 1：启用 TIME-WAIT 复用，缓解上游主动建连（如网关回源）端口耗尽
Nginx 内部配置必须配套，否则队列再大也取不出来
光有队列不够，还得让 Nginx 快速、批量地把连接从队列里“捞出来”：
- 全局配置中加入：multi_accept on; —— 让每个事件循环尽可能多地 accept 就绪连接
- 设 worker_rlimit_nofile 65535;，确保 worker 进程能真正使用到 ulimit 限制
- 确认使用 epoll（Linux 默认），并检查 use epoll; 是否显式启用
- 临时提限：ulimit -n 65535；永久提限：写入 /etc/security/limits.conf
