Nginx 请求限制设置
1. 核心参数拆解
假设你的配置是：limit_req_zone $binary_remote_addr zone=api_strict:10m rate=10r/m;
Rate (速率)
rate=10r/m：这意味着 Nginx 每 6 秒 才会产生一个“通行令牌”。如果不加 burst：用户每 6 秒只能点一次。如果他 1 秒内点了 2 下，第 2 下会直接报 503。这显然不符合现代网页加载 10 多个 API 的需求。
Burst (突发容量)
burst=12：这相当于在门口放了一个**“等候区”**，里面有 12 个座位。用法：当令牌还没产生时，多出来的请求可以先在座位上“坐着等”。
生活例子：银行柜台每 6 秒办完一个人。突然来了 10 个人，如果没有
burst，剩下 9 人直接轰走；有了burst=12，这 9 个人可以进大厅坐着等。
Nodelay (无延迟)
核心作用：如果你不加
nodelay，排队的请求会严格按照 6 秒一个的速度慢慢处理，用户会感到网页加载极慢。加上 nodelay：Nginx 会让坐在
burst座位上的 12 个人立刻进去处理。代价：这 12 个座位被占用了。如果这 12 个名额在 1 秒内用完，那么接下来的 6 秒内（直到产生新令牌），任何新请求都会被拒。
2. 还有哪些实用的用法？
除了你现在用的这一套，针对你这种“房产数据”场景，还有几个进阶配置：
A. Delay (延迟上限控制)
这是 Nginx 1.15.7 之后引入的“折中方案”，比 nodelay 更智能。
Nginx
limit_req zone=api_strict burst=20 delay=10;
逻辑：前 10 个请求（delay 值）立刻处理，不等待。
后续：第 11 到 第 20 个请求依然允许进入
burst排队，但会强制它们排队等待（增加延迟感）。意义：让首屏加载非常快，但如果用户疯狂乱点，他会感觉到操作变慢了，起到“警告”作用。
B. 使用 $limit_req_status 自定义状态码
默认是 503，但你现在改成了 553。这在多层架构中非常有用，可以帮你一眼分辨出是 Nginx 拦的（553）还是后端 IIS 报错了。
Nginx
limit_req_status 429; # 429 Too Many Requests 是更标准的限流状态码
C. 结合多重限流（阶梯防御）
你可以同时应用多个限流池。例如：一个池限制单 IP 的总频率，另一个池限制单 IP 访问登录接口的频率。
Nginx
location /login.ashx {
limit_req zone=api_strict burst=5; # 通用限流
limit_req zone=login_limit burst=2; # 针对登录的额外严审
proxy_pass http://backend;
}
