Nginx中Lua脚本实现动态黑名单自动封禁机制

为什么直接用 access_by_lua_block 写封禁逻辑容易失效

因为 nginx 的 lua 模块（openresty）中，access_by_lua_block 阶段执行时，请求尚未进入 upstream 或日志阶段，但若后续有 rewrite_by_lua_block 或其他模块重写 uri、跳转，可能绕过该阶段；更关键的是，它不自动阻断后续处理——你得显式调用 ngx.exit(403)，否则脚本跑完就继续往下走。

常见错误现象：ngx.var.remote_addr 被封了，但请求仍能访问后端；或日志里看到 ip 出现在黑名单里，http 状态码却是 200。

• 务必在封禁分支末尾加 ngx.exit(403)，不能只设变量或写 redis
• 如果用了 try_files 或 error_page 重定向，要确认它们不会覆盖或跳过 access_by_lua_block
• 避免在 access_by_lua_block 中做耗时操作（如 http 请求），会阻塞 worker 进程

如何用 redis + lua 做毫秒级黑名单匹配

本地内存（如 shared_dict）适合短时频控，但跨 worker、跨实例的黑名单必须依赖外部存储。redis 是最常用选择，关键是用原子操作避免并发查改导致漏放行。

推荐用 eval 执行一段内联 lua 脚本，一次性完成「查是否存在」+「若存在则返回 1」，不依赖两次网络往返：

local exists = redis.call("exists", "blacklist:" .. keys[1])
if exists == 1 then
  return 1
else
  return 0
end

在 nginx 配置中调用：

access_by_lua_block {
  local red = require "resty.redis"
  local r = red:new()
  r:set_timeout(100)
  local ok, err = r:connect("127.0.0.1", 6379)
  if not ok then
    ngx.log(ngx.err, "failed to connect to redis: ", err)
    return
  end
  local ip = ngx.var.remote_addr
  local res, err = r:eval(
    "return redis.call('exists', 'blacklist:' .. argv[1])",
    0, ip
  )
  if res == 1 then
    ngx.exit(403)
  end
}

• 不要用 get + if 两步，竞态下可能刚查完就被删掉
• redis key 建议带前缀（如 blacklist:）并设置 ttl，避免长期堆积
• 连接池比每次新建连接更高效，可用 resty.redis.connect + set_keepalive

怎么让封禁规则支持动态更新而不 reload nginx

reload 会中断连接、丢失共享字典状态，不适合高频更新的黑名单。真正可行的方式是：把规则存 redis，nginx 每次请求都实时查——只要 redis 响应够快（通常如果你真想降低 redis 查询压力，可以用双层缓存：先查 shared_dict，未命中再查 redis，并异步刷新本地缓存（用 lua-resty-lock 防穿透）：

local dict = ngx.shared.blacklist_cache
local ip = ngx.var.remote_addr
local cached = dict:get(ip)
if cached == 1 then
  ngx.exit(403)
end
-- 加锁后查 redis 并回填
local lock = require "resty.lock":new("locks")
local elapsed, err = lock:lock(ip)
if not elapsed then
  ngx.log(ngx.err, "failed to acquire lock: ", err)
  return
end
local red = --[[...redis init...]]
local res, _ = red:eval("return redis.call('exists', 'blacklist:' .. argv[1])", 0, ip)
if res == 1 then
  dict:set(ip, 1, 60) -- 缓存 60 秒
  ngx.exit(403)
end
lock:unlock()

• 别用定时拉取（如 timer.at）同步 redis 到 shared_dict，worker 间不同步且易超时
• shared_dict 的 ttl 必须比 redis 的短，否则会出现“redis 已解封，本地还拦着”的情况
• 若业务对延迟极度敏感，考虑用 redis 的 scan + 本地 bloom filter 预筛，但实现复杂度陡增

误封怎么快速放行又不影响线上

最安全的做法是提供独立管理接口（比如一个仅限内网访问的 /api/unban），由运维或自动化脚本调用，而不是手动改 redis 或 reload。

示例接口只需一行命令：

location /api/unban {
  allow 10.0.0.0/8;
  deny all;
  content_by_lua_block {
    local ip = ngx.var.arg_ip
    if not ip or #ip == 0 then
      ngx.status = 400
      ngx.say("missing ip")
      return
    end
    local red = require "resty.redis":new()
    red:set_timeout(100)
    red:connect("127.0.0.1", 6379)
    red:del("blacklist:" .. ip)
    red:del("blacklist_cache:" .. ip) -- 清本地缓存
    ngx.say("ok")
  }
}

• 严禁开放 del * 或无白名单的批量操作接口
• redis 的 del 是原子的，但 shared_dict 清除需各 worker 协同，所以建议用 key 名一致的命名空间（如都加 blacklist: 前缀），便于脚本批量清理
• 记录所有封禁/解封操作到独立日志文件（用 ngx.log(ngx.info, ...)），排查误封时比翻 access.log 直观得多

实际部署时最容易被忽略的是 redis 连接失败后的降级策略——默认行为是放行，但有些场景要求“宁可误杀也不能漏封”，这时就得在 redis:connect 失败时主动 ngx.exit(503)，而不是静默跳过。这个决策点不在代码里，而在你的安全等级定义中。

到此这篇关于nginx中lua脚本实现动态黑名单自动封禁机制的文章就介绍到这了,更多相关nginx lua动态黑名单自动封禁内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！