这是一个非常好的问题！答桉是：有限制，而且 iptables 的限制会先生效，并使得 limit_req 更高的限制实际上无法达到。
你的配置 iptables限制每秒新建连接数10，limit_req限制每秒15个请求 会产生一个“瓶颈效应”，最终的效果是每秒最多只能处理大约10个请求，而不是15个。
详细解释：HTTP 请求 vs. TCP 连接
要理解这一点，关键是要区分 TCP 连接 和 HTTP 请求：
TCP 连接：这是网络层面的连接。客户端和服务器需要进行三次握手来建立一条通道。iptables 工作在这一层。
HTTP 请求：这是在已经建立好的 TCP 连接上发送的实际应用数据。limit_req 工作在这一层。
一个 TCP 连接可以承载多个 HTTP 请求（尤其是在 HTTP/1.1 的 Keep-Alive 模式下）。
场景模拟
假设一个客户端 IP 以最高速度向你的服务器发送请求。
第1秒：
客户端疯狂创建新的 TCP 连接来发送 HTTP 请求。
iptables 发现：“太快了！1秒内已经新建了10个连接。” 于是它开始丢弃第11个及之后的 TCP SYN 包（握手包）。
因此，最终只有10个 TCP 连接成功建立。
假设这10个连接上，每个连接都只发送了 1个 HTTP 请求。
Nginx 的 limit_req 模块看到：“这秒内收到了10个请求，距离我的15个限制还差得远呢，全部放行。”
结果：成功处理了 10 个请求。limit_req 没起到限制作用。
如果客户端使用 Keep-Alive：
客户端先建立 10 个 TCP 连接（达到了 iptables 的限制）。
然后，它在这 10 个连接上，以毫秒级的速度连续发送多个 HTTP 请求。
现在，limit_req 开始工作了：“1秒内已经从你这个IP收到了超过15个请求，后面的请求返回429错误！”
结果：成功处理了大约 15 个请求（取决于请求发送的速度），其余的被 limit_req 拒绝。
关键结论
iptables 的限制是 limit_req 的“天花板”：你无法处理超过 iptables 连接数限制的请求，因为HTTP请求需要先建立在TCP连接之上。如果连接都建不起来，根本就谈不上发请求。
limit_req 用于细化管理：在连接数限制的“天花板”之下，limit_req 可以更精细地控制每个连接上的请求速率，防止客户端滥用单个连接进行狂刷。
防御目标不同：
iptables 10 conn/s：主要用于防御网络层的洪水攻击（如SYN Flood），这种攻击的特征是大量新建连接但可能不发任何数据。
limit_req 15 req/s：主要用于防御应用层的CC攻击，这种攻击的特征是建立连接后，高速发送大量合法或半合法的HTTP请求，旨在耗尽后端资源（CPU、数据库连接）。
给你的建议
这种配置是合理且常见的：
iptables (10 conn/s)：作为第一道粗颗粒度的防线，拦住最“傻”最暴力的攻击。
Nginx limit_req (15 req/s)：作为第二道细颗粒度的防线，解决那些能够建立连接但发送请求过快的攻击者。
最终效果是：你的服务器每秒最多能处理 10~15 个来自同一IP的请求。 既防止了连接洪水，也防止了请求洪水。