必须用access_by_lua_block而非content_by_lua_block，因其在proxy_pass前执行，可阻断攻击流量于网关层；若误用后者，请求已发往后端，造成资源浪费且封禁失效。
直接上结论：用 OpenResty + lua-resty-redis 在 access_by_lua_block 阶段查 Redis 黑名单，比应用层拦截快一个数量级，且不依赖后端服务存活 —— 但 IP 提取不准、Redis 连接未复用、超时未设，三者任一出错都会让封禁失效或拖慢所有请求。
为什么必须用 access_by_lua_block 而不是 content_by_lua_block
封禁动作要发生在请求真正转发给后端之前，否则攻击流量已穿透网关。OpenResty 的 access_by_lua_block 阶段在 Nginx 的 access phase 执行，早于 proxy_pass，适合做访问控制；而 content_by_lua_block 是内容生成阶段，此时后端可能已被调用。
- 错误写法：
content_by_lua_block里判断 IP 并ngx.exit(403)—— 请求头已发往 upstream，连接开销白费 - 正确位置：放在
location块内，紧贴proxy_pass上方 - 注意：该阶段不能调用
ngx.say()或ngx.print()，只能用ngx.exit()或ngx.redirect()
lua-resty-redis 连接必须复用，否则扛不住高并发
每次请求都新建 Redis 连接，1000 QPS 就会创建上千个 socket，很快耗尽本地端口或触发 TIME_WAIT 拥塞。OpenResty 不自带连接池，必须手动管理。
- 用
redis:set_keepalive(60000, 100)把连接放回 cosocket 连接池，第一个参数是空闲超时（毫秒），第二个是最大空闲数 - 初始化连接应放在
init_by_lua_block或set_by_lua_block之外的全局作用域，避免每次请求重复 new - 务必检查
redis:connect()返回值，失败时 fallback 到直通（不要静默忽略） - 示例关键片段：
local redis = require "resty.redis"<br>local red = redis:new()<br>red:set_timeout(500)<br>local ok, err = red:connect("127.0.0.1", 6379)<br>if not ok then ngx.log(ngx.ERR, "redis connect failed: ", err) return end<br>local res, err = red:get("blacklist:" .. ip)<br>if res == "1" then ngx.exit(403) end<br>red:set_keepalive(60000, 100)
真实客户端 IP 提取顺序不能只信 remote_addr
如果 Nginx 前面还有 SLB、CDN 或多层代理，remote_addr 只是最后一跳的 IP（通常是代理地址），直接拿它去查黑名单等于形同虚设。
- 标准提取链：
ngx.var.http_x_real_ip→ngx.var.http_x_forwarded_for（取第一个非私有 IP）→ngx.var.remote_addr - 必须过滤私有地址段：
10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.1、::1等，否则内网 IP 可能被误封或绕过 - 建议封装成 Lua 函数，在
access_by_lua_block开头统一调用，避免每处重复逻辑 - 验证是否生效：用
curl -H "X-Real-IP: 1.1.1.1" http://your-domain/测试，再查 Redis key 是否命中
Redis 键设计和 TTL 设置容易被忽略
黑名单不是永久的，但 TTL 设太短会导致刚封就解，设太长又难快速响应新威胁。键名没加前缀或没区分环境，测试和生产 Redis 混用会出大问题。
- 键名格式建议：
blacklist:prod:v4:.. ip（加环境+协议版本前缀，避免 key 冲突） - TTL 推荐 300～3600 秒之间，用
redis:setex()一步写入值和过期时间，别先set再expire - 管理接口写入时，务必校验 IP 格式（IPv4/IPv6），否则非法字符串写入 Redis 可能导致后续
get返回 nil 而非 false，逻辑判断出错 - 封禁日志必须带完整上下文：
ngx.log(ngx.WARN, "BLACKLIST_HIT ip=", ip, " uri=", ngx.var.uri, " agent=", ngx.var.http_user_agent)
Redis 连接超时、IP 提取逻辑漏掉 IPv6 场景、黑名单 key 未加环境隔离 —— 这三个点在线上最常引发“明明写了封禁却没生效”的故障，排查时优先盯死它们。
