geo+map组合实现千万级IP封禁，核心依赖geo的哈希查找（O(1)）与map的语义转换；需预处理IP为CIDR、分文件include、reload平滑更新，并用return 403轻量拦截。
用 map 指令实现千万级 IP 封禁，核心不是靠它“存数据”，而是靠它配合 geo 指令完成高效哈希映射——真正扛住高并发的，是 Nginx 内部基于哈希表的 geo 查找机制，map 只负责做一次轻量转换。它本身不提速，但能让封禁逻辑干净、可维护、不拖慢请求。
geo + map 是一对固定搭档，缺一不可
geo 负责把 IP 映射成数字标记（比如 1 表示黑名单），底层用的是哈希表，查找复杂度接近 O(1)，哪怕加载 500 万条 CIDR 或单 IP，平均匹配耗时仍在微秒级；map 则把那个数字转成语义清晰的变量（比如 $blocked），方便后续用 if 或 return 统一拦截。
- 别直接在
geo块里写几百条192.168.1.100 1;—— 手动维护不可行，应统一存到外部文件，用include加载 -
geo不支持运行时更新，但支持include，所以更新名单只需改文件 +nginx -s reload，无需改主配置 -
map块必须放在http级，且不能嵌套，变量名要避免和内置变量冲突（如不用$ip、$host）
大规模 IP 列表必须做结构优化
原始日志或扫描器导出的 IP 往往是离散的，直接全量写入会极大膨胀配置体积、降低哈希效率。真实生产中必须预处理：
- 合并连续 IP 段：把
192.168.1.1–192.168.1.254归并为192.168.1.0/24 - 去重并排序：避免重复加载、提升
geo初始化速度 - 优先使用 CIDR 而非单 IP：一条
/24等效 256 个单 IP，内存占用更小，匹配更快 - 超 10 万条建议拆分文件：比如按地区或风险等级分
blacklist-cn.conf、blacklist-bot.conf，便于灰度更新
拦截动作要轻量，避免引入额外开销
封禁本身必须秒级生效、零延迟，不能触发日志写入、不能调外部服务、不能进 Lua 或子请求。最稳妥方式是用 return 403 直接终结：
- 别用
deny指令拼大量规则——它是顺序匹配，IP 超 50 条后性能明显下滑 - 别在
if里做复杂判断，例如if ($blocked && $request_method = POST)会多一次字符串比较，纯if ($blocked) { return 403; }即可 - 确保
return 403放在server或location顶层，不在嵌套块里，避免被其他指令覆盖 - 可搭配
error_page 403 = @block_log记录被拦 IP，但日志要异步写，不影响主流程
reload 不等于中断，关键在平滑过渡
很多人担心 nginx -s reload 会导致连接断开，其实 Nginx 的 reload 是优雅重启：旧 worker 进程继续处理已有连接，新 worker 加载新配置后开始承接新请求，整个过程无感知。
- 每次 reload 前务必执行
nginx -t校验语法，防止配置错误导致服务中断 - 建议搭配 systemd 或 supervisord 监控 reload 状态，失败自动告警
- 若需更高可用性（如金融级），可考虑双机热备+DNS 切流，而非强求单机零 reload
- 对变更频率要求毫秒级的场景，
geo + map不适用，应切换至 OpenResty + shared_dict 或 nftables map
