keepalive_timeout 0 并非强制关闭长连接，而是禁用 keepalive 功能，导致每个请求新建并立即关闭 TCP 连接，加剧 TIME_WAIT 堆积、CPU 和内存压力；应改用 limit_conn、合理 timeout 及超时控制等精准防御措施。
将 keepalive_timeout 0 设置为 0 并不能“强制关闭长连接”来抵御大流量攻击，反而会显著加剧服务器压力，属于典型误用。该配置实际含义是：**禁用 keepalive 功能，即每个 HTTP 请求都必须建立并立即关闭 TCP 连接**。在高并发场景下，这会导致大量 TIME_WAIT 连接堆积、CPU 和内存开销陡增、SSL 握手频繁耗尽资源，反而更容易被压垮。
理解 keepalive_timeout 0 的真实行为
当设为 0 时：
- Nginx 不再复用客户端连接，每个请求独占一个 TCP 连接，响应后立刻发送 FIN 关闭
- 客户端若发起 pipelined 请求或重用连接（如浏览器默认行为），将收到 RST 或 400 错误
- 服务器端 socket 快速进入 TIME_WAIT 状态，可能触发端口耗尽（尤其在 NAT 或代理后）
- 对 HTTPS 流量，每次连接都要完整 TLS 握手，CPU 使用率飙升
真正有效的应对大流量攻击的替代方案
防御连接类攻击（如 Slowloris、RUDY 或连接耗尽型 CC），应聚焦于连接生命周期控制与资源隔离，而非粗暴禁用长连接：
-
合理设置 keepalive_timeout：通常 15–60 秒足够（如
keepalive_timeout 30s;），既减少握手开销，又避免连接长期空占 -
限制单 IP 并发连接数：用
limit_conn模块（需先定义 zone），例如：limit_conn_zone $binary_remote_addr zone=addr:10m;limit_conn addr 10; -
缩短 read/write 超时：防范慢速攻击，如
client_header_timeout 5s;、client_body_timeout 5s;、send_timeout 5s; -
启用连接拒绝策略：配合
limit_req限速，或使用ngx_http_geo_module+if对可疑 IP 主动返回 444（关闭连接不响应）
确认是否真需干预长连接
多数真实 DDoS/CC 攻击并非靠“保持长连接”本身造成危害，而是通过：
- 海量低频请求耗尽 worker 进程
- 构造超长 header/body 触发缓冲区分配
- 利用漏洞（如 CVE-2021-23017）制造解析阻塞
- HTTPS 层反复握手或非法 SNI 耗尽 CPU
此时应结合日志分析（$request_time, $upstream_response_time, $status）定位瓶颈，而非统一关掉 keepalive。
调试与验证建议
调整后务必验证效果：
- 用
ss -ant | grep :443 | wc -l观察 ESTABLISHED 连接数趋势 - 检查
/proc/net/sockstat中 TIME_WAIT 数量是否异常增长 - 启用 Nginx stub_status 模块，监控
Active connections和Reading/Writing/Waiting分布 - 对比攻击时段前后
nginx -T 2>/dev/null | grep -E "(keepalive|limit_conn|timeout)"配置生效状态
