Nginx IP黑名单仅适用于封禁少量已知恶意IP，不能防御大规模DDoS；需与limit_req、limit_conn及边缘防护分层配合，黑名单应作为精准拦截的最后一环。
直接在生产环境测试 DDoS 防御效果风险极高，也不现实。Nginx 的 IP 黑名单本身不适用于防御大规模分布式拒绝服务攻击，它只适合封禁已确认的、数量有限的恶意源 IP（比如扫描器、暴力破解源）。真正应对 DDoS，需分层配合限流、连接控制和边缘防护。但你可以通过可控方式验证黑名单是否按预期生效，并确认它在混合攻击场景中的定位是否合理。
先验证黑名单基础功能是否正常
这是前提：确保你写的 deny 或 geo + if 规则真能返回 403，且不误伤合法请求。
- 在
location /test-block/中单独配置黑名单规则，避免影响主服务 - 用
curl -v --header "Host: example.com" http://your-server/test-block/从被封 IP 发起请求，检查响应状态码是否为 403 Forbidden，响应头中是否有Server字段被隐藏（建议配置server_tokens off） - 换一个白名单 IP 请求同一路径，确认返回 200 —— 验证“放行”逻辑没被破坏
- 查看 Nginx
error.log，搜索access forbidden by rule，确认拦截日志真实产生
模拟小规模恶意请求，观察黑名单+限流协同效果
DDoS 往往伴随高频请求。单靠黑名单无法应对流量洪峰，必须叠加限流机制。
- 在关键路径（如
/login）同时启用：limit_req zone=login_limit burst=10 nodelay;if ($blocked_ip) { return 403; } - 用
ab或hey工具从一个被封 IP 发起 50 次并发请求：hey -n 50 -c 50 -H "Host: example.com" http://your-server/login - 预期结果：
所有请求应快速返回 403（无延迟），access.log中对应条目状态码全为 403，limit_req日志不出现（说明未进入限流阶段，被黑名单提前截断）
识别黑名单的局限性——它不是 DDoS 解决方案
以下情况说明黑名单已“力不从心”，此时必须依赖其他手段：
- 攻击者使用成百上千个不同 IP（如僵尸网络），手动或脚本维护黑名单文件会迅速失效
- 你发现
access.log中大量 403 条目来自新 IP，但error.log出现could not add new connection或accept() failed—— 表明连接队列已满，攻击已穿透到系统层 - 服务器 CPU/带宽持续满载，而 Nginx 日志里没有明显高频 IP —— 流量可能来自伪造源地址（SYN Flood）或应用层慢速攻击，黑名单完全无效
真正应对 DDoS 的推荐组合策略
把黑名单当作最后一道“精准清除”环节，前面必须有更宽口径的防护：
- 边缘层（首选）：接入 Cloudflare 或阿里云 DDoS 高防，自动清洗海量流量，隐藏源站 IP
-
传输层：用
iptables/nftables限制新建连接速率（如iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP） -
Nginx 层：
–limit_conn控制单 IP 并发连接数（防连接耗尽）
–limit_req限制关键路径请求频率（防 CC）
–geo + map动态加载黑名单，配合日志分析工具自动更新 - 应用层：后端增加登录验证码、设备指纹、行为分析等业务风控，不依赖单一 IP 判断
