nginx并发连接能力取决于linux内核的半连接队列（tcp_max_syn_backlog）和全连接队列（somaxconn），需同步调优二者并匹配worker_rlimit_nofile与worker_connections。
在 Nginx 中，epoll 本身没有独立的“连接队列长度上限”可调参数，真正影响并发连接接纳能力的是 Linux 内核的两个关键队列：**半连接队列（SYN Queue）** 和 **全连接队列（Accept Queue）**。Nginx 的事件模型（如 epoll）依赖于这两个内核队列的健康运作。优化目标其实是避免队列溢出导致丢包、连接超时或 `accept()` 失败（如日志中出现 accept() failed (24: Too many open files) 或更隐蔽的 accept() failed (11: Resource temporarily unavailable)）。
调整内核全连接队列长度（net.core.somaxconn）
这是最常被忽略也最关键的配置。它限制了已完成三次握手、等待 Nginx 调用 accept() 取走的 TCP 连接数上限。默认值（通常是 128 或 512）在高并发场景下极易成为瓶颈。
- 查看当前值：
sysctl net.core.somaxconn - 临时生效：
sysctl -w net.core.somaxconn=65535 - 永久生效：在
/etc/sysctl.conf中添加net.core.somaxconn = 65535，然后运行sysctl -p - Nginx 配置中需显式启用该上限：在
http或server块中设置listen 80 backlog=65535;（注意：backlog 值不能超过somaxconn，否则会被内核截断）
控制半连接队列与 SYN 攻击防护（net.ipv4.tcp_max_syn_backlog）
该参数决定未完成三次握手（SYN_RECV 状态）的连接最大数量。当遭遇突发 SYN 包或轻微攻击时，此队列满会导致内核丢弃新 SYN，表现为客户端连接缓慢或超时。
- 建议值：设为与
somaxconn相同或略高，例如net.ipv4.tcp_max_syn_backlog = 65535 - 同时确保
net.ipv4.tcp_syncookies = 1（开启 SYN Cookie），在队列满时提供兜底防护（不影响正常连接） - 若业务环境可信且无攻击风险，可关闭
tcp_syncookies以降低微小延迟；但生产环境强烈建议保持开启
匹配 Nginx worker 进程与文件描述符限制
epoll 能高效管理大量连接，但前提是系统允许 Nginx 打开足够多的 socket。连接数上限最终受限于每个 worker 进程能打开的文件描述符数。
- 检查 ulimit：启动 Nginx 前，确保用户级限制足够，例如
ulimit -n 1048576 - Nginx 配置中设置：
worker_rlimit_nofile 1048576;（放在 main 块） - 确认
worker_connections值合理：例如events { worker_connections 10240; }，总理论连接数 ≈worker_processes × worker_connections，应小于worker_rlimit_nofile
验证是否生效与常见误区
光改参数不验证等于没改。重点关注以下几点：
- 用
ss -lnt查看监听端口的Recv-Q列：若长期 > 0（尤其接近 backlog 值），说明应用处理 accept 不及时，需优化 Nginx 或后端逻辑 - 检查内核日志：
dmesg | grep -i "possible syn flooding"—— 出现即表示半连接队列持续过载 - 注意：Nginx 的
backlog参数只在使用listen指令时生效，UNIX domain socket 不适用；且 systemd 启动的 Nginx 可能受LimitNOFILE限制，需在 service 文件中单独配置 - 不要盲目追求极大值：过大的
somaxconn会增加内存占用（每个连接约占用几百字节），按实际峰值连接数 × 1.2～1.5 倍设置更稳妥
