Nginx 通过负载均衡、健康检查、限流与连接控制缓解应用层 DDoS：启用 upstream 主动探测与 proxy_next_upstream 实现故障隔离；按场景选算法并设 max_conns 防连接耗尽；用 limit_req 全局及接口级限速；隐藏头信息、增强日志与监控提升溯源响应。
Nginx 本身不是专用的 DDoS 防御设备，但它在分布式攻击（尤其是应用层 DDoS）的缓解中扮演关键角色——核心思路不是“挡住所有攻击”，而是通过负载均衡机制把压力分散、隔离、限流和快速熔断，避免单点崩溃，为上层 WAF 或云清洗服务争取响应时间。
用 upstream 分组 + 健康检查实现自动故障隔离
DDoS 攻击常导致部分后端节点响应变慢或超时，若不干预，Nginx 默认轮询仍会持续转发请求，形成雪崩。必须启用主动健康探测与智能剔除：
- 配置 主动健康检查：使用
health_check interval=5 fails=2 passes=2（需 nginx-plus；开源版可用proxy_next_upstream搭配被动检测） - 设置 失败容忍策略：如
max_fails=2 fail_timeout=15s，节点连续失败 2 次后，15 秒内不再分发新请求 - 开启 失败重试回退：添加
proxy_next_upstream error timeout http_500 http_502 http_503，让异常请求自动转向其他健康节点 - 对关键接口（如登录、下单），可单独定义 upstream 组，与静态资源、API 分离，防止攻击蔓延
选对算法 + 辅助机制，避免流量误导向
算法本身不抗 DDoS，但错误配置会放大攻击效果。关键在于匹配场景并叠加防护：
-
轮询（round robin）：默认公平，但无感知能力；务必搭配
proxy_next_upstream和max_fails，否则慢节点会持续吸走请求 -
最少连接（least_conn）：适合长连接场景，但仅看 TCP 连接数，不反映 CPU/IO 真实负载；建议加
slow_start=30s防新节点被突袭打垮 -
慎用 ip_hash：NAT 环境下极易造成“IP 聚合攻击”，比如一个运营商出口 IP 被打爆，整片用户失效；改用
hash $request_uri consistent对 URL 哈希，更均匀且利于缓存穿透防护 - 所有 upstream server 行都应设
max_conns=150，硬性限制单实例最大并发连接，防连接耗尽
在 proxy 层叠加限流与连接控制
负载均衡是第一道分流关，但必须配合主动防御才真正有效：
- 全局限流：用
limit_req_zone $binary_remote_addr zone=ddos:10m rate=10r/s控制单 IP 请求频次，突发允许少量（burst=20 nodelay）但不放任刷量 - 接口级限流：对 /login、/api/pay 等高危路径单独限速，例如
limit_req zone=login burst=5 - 连接数限制：在 upstream 中为每台 server 加
max_conns=200，在 server 块中设limit_conn addr 100（基于 IP 的连接总数） - 超时收紧：缩短
proxy_connect_timeout 3s、proxy_read_timeout 8s，快速释放卡住的连接，避免资源堆积
隐藏后端 + 日志监控，提升攻击溯源与响应效率
防御不仅是技术动作，更是运营闭环：
- 隐藏后端标识：
proxy_hide_header Server、proxy_hide_header X-Powered-By，防止攻击者识别技术栈发起针对性攻击 - 记录真实攻击特征：在 log_format 中加入
$upstream_addr、$upstream_response_time、$request_time，按分钟聚合分析各后端接收的 IP 数量与响应延迟，及时发现倾斜或慢节点 - 启用 stub_status 模块，暴露
/nginx_status，监控Active connections、Writing、Waiting分布，建立基线并告警突增 - 结合 openresty 或 lua，在请求入口做轻量 UA/Referer 异常识别，拦截明显扫描器或恶意 bot 流量
