这是一个非常好的问题，它触及了HTTP协议、连接管理和Nginx限流模块之间关系的核心。
答桉是：不，效果不一样。即使Keep-Alive关闭，limit_conn和limit_req也绝对有必要同时设置，因为它们防御的是完全不同维度的攻击。
Keep-Alive关闭后的情况
你说得对，当Keep-Alive关闭后（keepalive_timeout 0;），Nginx会在响应完一个请求后立即发送 Connection: close 头部，并关闭TCP连接。这意味着一个TCP连接理论上只能用于发送一个HTTP请求。
在这种情况下：
并发连接数 ≈ 并发请求数
每秒新建连接数 ≈ 每秒请求数
虽然数值上近似，但limit_conn和limit_req的防御重点和生效时机完全不同。
为什么必须同时设置？—— 防御场景不同
我们通过一个攻击场景来理解：
假设一个恶意IP 1.2.3.4 试图攻击你的网站。
1. 只有 limit_req (e.g., rate=10r/s)，没有 limit_conn
攻击者行为：攻击者可以非常快速地建立100个TCP连接，但每个连接上只发送1个请求，然后断开。
Nginx视角：
limit_req： “我1秒内只收到了100个请求，平均速率是100r/s，远远超过10r/s的限制！后面的90个请求，我要拒绝掉（返回429/503）。”
limit_conn： （未设置，所以不生效）
结果：虽然最终只成功了10个请求，但攻击者成功建立了100个TCP连接。每个连接的建立和断开都需要消耗服务器的CPU、内存（套接字描述符）等资源。如果攻击者用大量IP同时进行这种攻击，很容易导致服务器连接资源被耗尽，无法为正常用户提供服务。这是一种典型的资源耗尽攻击。
2. 只有 limit_conn (e.g., limit_conn 10;)，没有 limit_req
攻击者行为：攻击者建立10个TCP连接，然后在每个连接上以毫秒级的速度疯狂发送大量请求（虽然Keep-Alive关了，但他可以快速建连->发请求->关连->再建连...）。
Nginx视角：
limit_conn： “当前只有10个并发连接，没有超过限制，允许建立。”
limit_req： （未设置，所以不生效）
结果：攻击者虽然只有10个连接，但他可以在这些连接上并发送大量请求。这些请求会穿透Nginx，直接冲击你的后端应用（如PHP、Python、数据库），消耗大量的CPU和数据库连接资源，导致应用崩溃。这是一种典型的CC攻击。
3. 同时设置 limit_conn 和 limit_req
攻击者行为：任何形式的攻击。
Nginx视角：
limit_conn： “想建立大量连接耗尽我的资源？没门！”
limit_req： “想用少量连接发送大量请求刷爆我的后端？休想！”
结果：全方位防护。服务器既不会被连接池拖垮，也不会被应用请求冲垮。
总结与类比
可以把你的服务器想象成一个游乐园：
TCP连接：是进入乐园的大门。
HTTP请求：是游客在乐园里玩的项目（过山车、旋转木马）。
Keep-Alive：是通票，允许游客从同一个大门进出多次。
Keep-Alive关闭：是单次票，玩一个项目就必须从大门出去再重新进来。
limit_conn：限制同时打开的门的数量。
防止太多人堵在入口，造成拥堵（资源耗尽）。
limit_req：限制每秒玩项目的总次数。
防止乐园内的项目被过度使用而瘫痪（应用层攻击）。
即使所有人都必须玩一次就重新排队（Keep-Alive关闭），你仍然需要既限制入口的人数，又限制项目被玩的频率。 两者缺一不可。
结论
无论Keep-Alive是否开启，limit_conn和limit_req都是互补的、必须同时配置的两道安全防线。
limit_conn：保护的是服务器本身的连接资源（防御SYN Flood、连接耗尽攻击）。
limit_req：保护的是后端的应用资源（防御CC攻击、应用层DDoS）。
只设置其中一个，会给攻击者留下一个明确的攻击面。