Nginx 连接吞吐：如何配置 listen 指令的 deferred 参数让 HTTPS 套接字在真正收到加密数据时才激活 Worker-Nginx-PHP中文网

deferred 是 tcp 层优化参数，仅影响三次握手完成后、accept() 前的连接排队行为，不干预 tls 握手或 worker 激活时机；在 https 中有效但仅限于提升 tcp 连接接纳效率。

nginx 连接吞吐：如何配置 listen 指令的 deferred 参数让 https 套接字在真正收到加密数据时才激活 worker

deferred 参数不是用来“让 HTTPS 套接字在真正收到加密数据时才激活 Worker”的——这个理解存在根本性偏差。它实际作用是优化 TCP 连接建立阶段的内核行为，与 TLS 握手、Worker 激活时机、或“延迟解密”完全无关。

下面直接说清楚关键点：

`deferred` 的真实作用

只影响 listen 指令绑定的 TCP socket 在 accept() 系统调用前的行为：

启用后，内核会把已完成三次握手（SYN_RECV → ESTABLISHED）但尚未被 Nginx 调用 accept() 取出的连接，暂存在更高效的队列中；
避免因 Worker 进程忙于处理已有请求，导致新连接在 accept 队列中堆积超时（net.ipv4.tcp_abort_on_overflow=1 时会被丢弃）；
本质是减少 accept() 调用开销 + 缓冲已建连但未取走的连接，不干预 TLS 握手过程，也不推迟 Worker 处理。

HTTPS 场景下 `deferred` 是否有效？

✅ 有效，但仅限于 TCP 层：

Nginx

在宝塔面板中轻松管理Nginx高性能Web服务器。提供可视化配置反向代理、负载均衡、SSL证书及HTTP缓存功能，一键优化高并发性能，助您高效搭建稳定、快速的网站运行环境。

下载

TLS 握手仍由 Worker 进程完成（ssl_handshake 在 accept() 后发生）；
deferred 让连接更快进入 ESTABLISHED 状态并排队等待 accept()，不加速或延迟证书交换、密钥协商等 TLS 步骤；
它对高并发短连接（如大量 HTTPS 建连）有收益，对长连接或 TLS 处理瓶颈无帮助。

如何正确配置（含 HTTPS）

server {
    listen 443 ssl deferred;  # ✅ 放在 listen 行末，仅对 TCP 生效
    server_name example.com;
    ssl_certificate /etc/nginx/ssl/example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    # 其他 SSL 配置...
}

注意：