Nginx来限制访问控制的方法有多种，nginx主要有2个模块控制，但是那些不支持自定义，非常死，在大多数场景下并不实用。今天分享一个：利用openresty+lua+redis 实现封杀频繁恶意访问IP地址，当然这个方式也是有弊端的，那就是不断试用代理 IP之类的，但是作用还是有的，起码提高了恶意的成本。

nginx的版本有淘宝nginx，还有春哥的 openresty，但是openresty打包了 nginx 的时候，集成了很多的有用的扩展，特别是 lua，一个小巧的编程语言。本文就是：openresty最新稳定版本+lua Lua +redis最新稳定版本 。

具体环境我就不安装了，大家可以使用宝塔面板啥的安装openresty，如果你的原生态的nginx就需要手动安装，网上教程都是有的，也比较简单。

lua脚本

ip_bind_time =3600  --封禁IP多长时间,单位秒
ip_time_out = 2    --指定统计ip访问频率时间范围,秒
connect_count = 5 --指定ip访问频率计数最大值,秒
--上面的意思就是2秒内访问超过5次，自动封 IP 60分钟。
 
--连接redis
local redis = require "resty.redis"
local cache = redis.new()
local ok , err = cache.connect(cache,"127.0.0.1","6379")
cache:set_timeout(60000)
cache:auth("1234")  -- redis密码
 
--如果连接失败，跳转到脚本结尾
if not ok then
  goto Lastend
end
 
--查询ip是否在封禁段内，若在则返回403错误代码
--因封禁时间会大于ip记录时间，故此处不对ip时间key和计数key做处理
local is_bind , err = cache:get("bind_"..ngx.var.remote_addr)
 
if is_bind == '1' then
  ngx.exit(ngx.HTTP_FORBIDDEN)
  -- 或者 ngx.exit(403)
  -- 当然，你也可以返回500错误啥的，搞一个500页面，提示，亲您访问太频繁啥的。
  goto Lastend
end
 
local start_time , err = cache:get("time_"..ngx.var.remote_addr)
local ip_count , err = cache:get("count_"..ngx.var.remote_addr)
 
--如果ip记录时间大于指定时间间隔或者记录时间或者不存在ip时间key则重置时间key和计数key
--如果ip时间key小于时间间隔，则ip计数+1，且如果ip计数大于ip频率计数，则设置ip的封禁key为1
--同时设置封禁key的过期时间为封禁ip的时间
 
if start_time == ngx.null or os.time() - start_time > ip_time_out then
  res , err = cache:set("time_"..ngx.var.remote_addr , os.time())
  res , err = cache:set("count_"..ngx.var.remote_addr , 1)
  res , err = cache:expire("time_"..ngx.var.remote_addr,ip_bind_time)
  res , err = cache:expire("count_"..ngx.var.remote_addr,ip_bind_time)
else
  ip_count = ip_count + 1
  res , err = cache:incr("count_"..ngx.var.remote_addr)
  if ip_count >= connect_count then
    res , err = cache:set("bind_"..ngx.var.remote_addr,1)
    res , err = cache:expire("bind_"..ngx.var.remote_addr,ip_bind_time) --fix keys
  end
end
local ok, err = cache:close()
--结尾标记
::Lastend::

openresty nginx配置：

做了个简单的反向代理, 本机8888端口下发login请求，转发到项目实际登录接口

access_by_lua_file配置导入lua脚本

效果：刷新五次后403并封IP， 频率和时间都是在脚本中设置

redis数据：

局限性

限流组件保证了高可用，牺牲了性能，增加了一层 IO 环节的开销，单机限流在本地，分布式限流还要通过网络协议。限流组件保证了高可用，牺牲了一致性，在大流量的情况下，请求的处理会出现延迟的情况，这种场景便无法保证强一致性。特殊情况下，还无法保证最终一致性，部分请求直接被抛弃。限流组件拥有流控权，若限流组件挂了，会引起雪崩效应，导致请求与业务的大批量失败。

引入限流组件，增加系统的复杂程度，开发难度增加，限流中间件的设计本身就是一个复杂的体系，需要综合业务与技术去思考与权衡，同时还要确保限流组件本身的高可用与性能，极大增加工作量，甚至需要一个团队去专门开发。