高效ip黑名单动态同步只有两类落地方案：一是geo+map预加载文件+平滑reload，适合中小规模；二是openresty+redis共享字典定时同步，毫秒级生效、支持ttl与分布式，适合中高并发场景。
要在 Nginx 中实现高效的 IP 黑名单动态同步管理，关键不是“每次封一个 IP 就 reload 一次”，而是让黑名单能实时生效、不中断服务、不拖慢请求，同时便于运维批量更新和审计追溯。目前真正落地且生产验证过的高效方案只有两类：基于文件预加载的轻量级方案（适合中小规模），以及基于 OpenResty + Redis 的运行时方案（适合中高并发、需时效性与分布式协同的场景）。
用 geo + map 实现低开销的文件级动态同步
这是最稳妥、零依赖、性能接近原生的方案。核心是把黑名单当作静态数据预加载进内存，靠外部脚本更新文件 + 平滑 reload 触发生效。
- 在 http 块中定义 geo 变量，将 IP 映射为标记值：
geo $bad_ip {<br> default 0;<br> include /usr/local/nginx/conf/blacklist.conf;<br>}
注意：blacklist.conf 只写纯 IP 或 CIDR，每行一条，不带 deny 指令 - 再用 map 转成易读布尔变量：
map $bad_ip $blocked { 1 "1"; default ""; } - 在 location 中拦截：
if ($blocked) { return 403; }
（不推荐在 if 中做复杂逻辑，但仅作拦截是安全且高效的） - 外部脚本（如每 3 分钟 cron 执行）分析 access.log，提取恶意 IP 写入 blacklist.conf，然后执行：
nginx -t && nginx -s reload || echo "配置校验失败，跳过重载" - 为防误封，白名单可放在 geo 块最顶部：
192.168.0.0/16 0;<br>10.0.0.0/8 0;
，优先级高于后续规则
用 OpenResty + Redis 实现毫秒级运行时同步
当黑名单需秒级生效、支持 TTL 过期、跨多台 Nginx 共享、或要对接自动化封禁系统（如 WAF、SIEM）时，必须用 OpenResty。普通 Nginx 加 lua-module 无法跑通，会报 unknown directive "lua_shared_dict" 或 attempt to index global 'resty' 错误。
- 确认安装的是 OpenResty（非 nginx + lua）：
openresty -v输出应含 OpenResty 字样；openresty -t必须通过 - 在 http 块顶层声明共享字典：
lua_shared_dict ip_blacklist 50m;
50MB 可存约 250 万个 IPv4 地址，设小了会导致 set() 静默失败 - 用
init_worker_by_lua_file定时从 Redis 同步全量黑名单：
脚本里 connect → auth → smembers ip_blacklist → flush_all → 逐条 set(ip, true)，每 60 秒执行一次 - Redis 数据结构必须是 SET（不是 string/hash），key 名任意，如
ip_blacklist - 实际拦截写在
access_by_lua_block中：local is_blocked = ngx.shared.ip_blacklist:get(ngx.var.remote_addr)<br>if is_blocked then return ngx.exit(403) end
全程走内存查表，无网络 IO，单次耗时
避免常见陷阱的实操细节
很多方案上线后失效，往往卡在权限、路径或配置层级上。
- blacklist.conf 文件权限设为
644，属主为root:www-data（Nginx 主进程需可读） - OpenResty 的 Lua 脚本路径必须绝对且 openresty 用户可读，例如
/usr/local/openresty/nginx/conf/lua/load_blacklist.lua - 超量 IP（如 >10 万）务必 CIDR 合并：用 Python 脚本聚合连续地址段，减少 geo 条目数，提升匹配效率
- 不要在 access_by_lua_file 里直连 Redis——那是把每次请求都变成远程调用，延迟飙升；必须靠共享字典 + 定时同步解耦
- 所有变更必须先
nginx -t或openresty -t校验，失败则跳过 reload，防止配置错误导致服务中断
按业务规模选择合适路径
没有银弹方案。小流量后台系统，geo+map+定时 reload 已足够可靠；日均百万请求以上、需自动联动风控系统的，OpenResty + Redis 是唯一可行路径。iptables 方案虽快，但缺乏 HTTP 层上下文（比如只封 /login 接口异常 IP），且难审计、难回滚，仅建议作为应急兜底手段。
