為什么直接用 access_by_lua_block 寫封禁邏輯容易失效

因?yàn)?Nginx 的 Lua 模塊（OpenResty）中，access_by_lua_block 階段執(zhí)行時(shí)，請(qǐng)求尚未進(jìn)入 upstream 或日志階段，但若后續(xù)有 rewrite_by_lua_block 或其他模塊重寫 URI、跳轉(zhuǎn)，可能繞過該階段；更關(guān)鍵的是，它不自動(dòng)阻斷后續(xù)處理——你得顯式調(diào)用 ngx.exit(403)，否則腳本跑完就繼續(xù)往下走。

常見錯(cuò)誤現(xiàn)象：ngx.var.remote_addr 被封了，但請(qǐng)求仍能訪問后端；或日志里看到 IP 出現(xiàn)在黑名單里，HTTP 狀態(tài)碼卻是 200。

• 務(wù)必在封禁分支末尾加 ngx.exit(403)，不能只設(shè)變量或?qū)?Redis
• 如果用了 try_files 或 error_page 重定向，要確認(rèn)它們不會(huì)覆蓋或跳過 access_by_lua_block
• 避免在 access_by_lua_block 中做耗時(shí)操作（如 HTTP 請(qǐng)求），會(huì)阻塞 worker 進(jìn)程

如何用 Redis + Lua 做毫秒級(jí)黑名單匹配

本地內(nèi)存（如 shared_dict）適合短時(shí)頻控，但跨 worker、跨實(shí)例的黑名單必須依賴外部存儲(chǔ)。Redis 是最常用選擇，關(guān)鍵是用原子操作避免并發(fā)查改導(dǎo)致漏放行。

推薦用 EVAL 執(zhí)行一段內(nèi)聯(lián) Lua 腳本，一次性完成「查是否存在」+「若存在則返回 1」，不依賴兩次網(wǎng)絡(luò)往返：

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

在 Nginx 配置中調(diào)用：

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 兩步，競態(tài)下可能剛查完就被刪掉
• Redis key 建議帶前綴（如 blacklist:）并設(shè)置 TTL，避免長期堆積
• 連接池比每次新建連接更高效，可用 resty.redis.connect + set_keepalive

怎么讓封禁規(guī)則支持動(dòng)態(tài)更新而不 reload Nginx

reload 會(huì)中斷連接、丟失共享字典狀態(tài)，不適合高頻更新的黑名單。真正可行的方式是：把規(guī)則存 Redis，Nginx 每次請(qǐng)求都實(shí)時(shí)查——只要 Redis 響應(yīng)夠快（通常如果你真想降低 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()

• 別用定時(shí)拉取（如 timer.at）同步 Redis 到 shared_dict，worker 間不同步且易超時(shí)
• shared_dict 的 TTL 必須比 Redis 的短，否則會(huì)出現(xiàn)“Redis 已解封，本地還攔著”的情況
• 若業(yè)務(wù)對(duì)延遲極度敏感，考慮用 Redis 的 SCAN + 本地 Bloom Filter 預(yù)篩，但實(shí)現(xiàn)復(fù)雜度陡增

誤封怎么快速放行又不影響線上

最安全的做法是提供獨(dú)立管理接口（比如一個(gè)僅限內(nèi)網(wǎng)訪問的 /api/unban），由運(yùn)維或自動(dòng)化腳本調(diào)用，而不是手動(dòng)改 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")
  }
}

• 嚴(yán)禁開放 DEL * 或無白名單的批量操作接口
• Redis 的 DEL 是原子的，但 shared_dict 清除需各 worker 協(xié)同，所以建議用 key 名一致的命名空間（如都加 blacklist: 前綴），便于腳本批量清理
• 記錄所有封禁/解封操作到獨(dú)立日志文件（用 ngx.log(ngx.INFO, ...)），排查誤封時(shí)比翻 access.log 直觀得多

實(shí)際部署時(shí)最容易被忽略的是 Redis 連接失敗后的降級(jí)策略——默認(rèn)行為是放行，但有些場景要求“寧可誤殺也不能漏封”，這時(shí)就得在 redis:connect 失敗時(shí)主動(dòng) ngx.exit(503)，而不是靜默跳過。這個(gè)決策點(diǎn)不在代碼里，而在你的安全等級(jí)定義中。

到此這篇關(guān)于Nginx中Lua腳本實(shí)現(xiàn)動(dòng)態(tài)黑名單自動(dòng)封禁機(jī)制的文章就介紹到這了,更多相關(guān)Nginx Lua動(dòng)態(tài)黑名單自動(dòng)封禁內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論