least_conn不能直接防御DDoS，但可延缓连接耗尽型攻击导致的后端瘫痪；需在upstream中配置least_conn;，配合keepalive、健康检查及limit_conn_module才能有效发挥负载均衡与防护作用。
least_conn 本身不直接防御 DDoS，但它在连接耗尽型攻击（如 Slowloris、SYN+HTTP 慢速攻击、大量短连接洪泛）中能显著延缓后端集体瘫痪——关键在于它让新连接“避开已堆积的节点”，避免雪崩式压垮单台服务器。
least_conn 配置要点
在 upstream 块中启用即可，无需参数：
- 写法简洁：直接加 least_conn;，放在 server 行之前
- 支持健康检查：max_fails / fail_timeout 照常生效，故障节点自动剔除
- weight 不影响实时决策：weight 只影响初始连接概率，真实分配仍以当前活跃连接数为准
必须搭配 keepalive 才有效
若后端使用 HTTP/1.1 或长连接协议，不配 keepalive 会导致 least_conn 统计失真——连接频繁新建关闭，活跃数波动大，失去“谁闲谁接”的意义。
- 建议设置 keepalive 32;（每 worker 进程缓存 32 个空闲连接）
- 客户端侧需配 proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务也需开启 HTTP Keep-Alive 支持，否则连接无法复用
结合限连模块防 IP 级耗尽
least_conn 管的是 upstream 节点间均衡，不防单 IP 恶意建连。必须叠加 limit_conn_module：
- 定义连接限制区：limit_conn_zone $binary_remote_addr zone=perip:10m;
- 在 server 或 location 中启用：limit_conn perip 15;（根据业务调至 10–30）
- 该限制作用于 Nginx 接入层，可立即阻断慢速攻击或扫描器的连接洪泛
验证是否生效
仅靠日志难判断，需启用 stub_status 并配合监控：
- 编译时确保含 --with-http_stub_status_module
- 配置 location /nginx_status { stub_status; }，再用 curl 查看 Active connections 分布
- 攻击发生时对比各 backend 的 Active connections 值，应明显趋于均衡而非某台飙升
