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

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

常見錯誤現象：ngx.var.remote_addr 被封了，但請求仍能訪問后端；或日志里看到 IP 出現在黑名單里，HTTP 狀態(tài)碼卻是 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 是最常用選擇，關鍵是用原子操作避免并發(fā)查改導致漏放行。

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

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

reload 會中斷連接、丟失共享字典狀態(tài)，不適合高頻更新的黑名單。真正可行的方式是：把規(guī)則存 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()

• 別用定時拉?。ㄈ?nbsp;timer.at）同步 Redis 到 shared_dict，worker 間不同步且易超時
• shared_dict 的 TTL 必須比 Redis 的短，否則會出現“Redis 已解封，本地還攔著”的情況
• 若業(yè)務對延遲極度敏感，考慮用 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 協(xié)同，所以建議用 key 名一致的命名空間（如都加 blacklist: 前綴），便于腳本批量清理
• 記錄所有封禁/解封操作到獨立日志文件（用 ngx.log(ngx.INFO, ...)），排查誤封時比翻 access.log 直觀得多

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

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

最新評論