因access_by_lua_block不自动阻断后续流程，必须显式调用ngx.exit(403)才能生效；若遗漏该语句、被rewrite或error_page跳过，或使用非原子Redis查询（如GET后IF），均会导致封禁失效。
为什么直接用 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)，而不是静默跳过。这个决策点不在代码里，而在你的安全等级定义中。
