先把当时的情况摆出来。nginx 1.24，limit_req_zone 配 20r/s，burst 设 5 并加 nodelay，页面首屏一次发 30 个请求，一半直接返回 503。
真正麻烦的地方在于，几个原因的现象几乎一样。burst 小于单页并发请求数。另一种情况是所有接口共用同一个 zone，互相挤占。
还有一种情况，没配 limit_req_status，默认码不好区分。另外，上游慢导致请求堆积，占满桶容量。
数清 503 的分布
awk '$9==503' access.log | wc -l调大 burst 并保留 nodelay
python -c "print('limit_req zone=api burst=50 nodelay;')"静态接口单独开一个 zone
python -c "print('limit_req_zone $binary_remote_addr zone=static:10m rate=200r/s;')"reload 后压测一次
hey -n 300 -c 30 https://example.com/api/list这次没动代码，只在配置和运行环境上找原因。
隔了一天再看，现象没变，说明不是偶发。
那几天正好在做别的变更，先把时间线对齐才敢动手。
排查用的命令都是临时敲的，没有写成脚本，事后才整理。
恢复的判定其实很直接。首屏 30 个请求全部返回 200，压测下 503 比例低于 0.5%，正常用户不再被误伤。
补一句。burst 是允许的突发深度，配得比页面并发还小，等于给正常用户设了一道墙。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。