NGINX：请求队列（burst）中请求限流超时行为疑问

这问题我之前也碰到过类似的，咱们一步步拆解原因：

1. 限流队列的超时逻辑你可能搞混了 #

你设置的burst=3000是允许的突发请求排队数，但Nginx的limit_req模块默认不会让请求在队列里等待超时——如果没显式配置timeout参数，队列一满就直接返回503，根本不会等到30秒后再发408。

要让排队的请求因等待超时返回408，你需要在limit_req指令里加上timeout=30s，比如：

limit_req zone=your_zone burst=3000 timeout=30s;

这个timeout才是控制请求在队列中等待的最长时间，和你设置的Keep-Alive超时完全是两码事。

2. Keep-Alive超时是连接层面的，和请求排队无关 #

你设置的keepalive_timeout 30s是指客户端和Nginx之间的空闲连接保持时间——如果一个长连接在30秒内没有新请求，Nginx会主动关闭它。但这个参数管不到已经进入队列等待转发的请求，排队请求的超时逻辑是由上面说的limit_req timeout控制的。

3. 可能是后端Servlet容器的瓶颈导致503 #

如果后端容器的处理能力跟不上，比如它的连接池满了、线程池耗尽，Nginx转发请求时会直接收到后端的拒绝，这时Nginx也会返回503，而不是让请求在自己的队列里等待。这种情况下，你得检查后端的日志和资源使用情况，看看是不是后端先扛不住了。

4. 再确认下你的限流配置细节 #

有没有可能你误加了nodelay参数？如果limit_req里加了nodelay，超过速率的请求不会进入队列，而是直接返回503，这也会导致你看不到408。

总结一下：最可能的原因是你没给limit_req配置timeout=30s，队列满了直接拒绝返回503；其次要区分开Keep-Alive超时和请求排队超时的差异，再排查下后端的处理能力。

内容的提问来源于stack exchange，提问作者Piotr Gwóźdź