Connlimit模块仅能被动限制单IP并发连接数，无法刚性熔断SYN洪水；它依赖nf_conntrack统计SYN_RECV状态，不记录时间、不自动封禁，对分布式海量伪造IP攻击效果有限，须与hashlimit、recent及tcp_syncookies等协同才能实现有效防护。
Connlimit 模块本身不能“刚性熔断”SYN泛洪，它只限制每个源IP的并发连接数（即处于 SYN_RECV 状态的半连接数量），属于被动限流手段，不是实时阻断或自动封禁。真正起熔断效果的是与 recent 或 hashlimit 配合使用的动态拦截规则。单独用 connlimit 只能防住单IP慢速扫段式攻击，对大规模分布式SYN洪水作用有限。
Connlimit 的核心能力与适用边界
connlimit 依赖内核连接跟踪（nf_conntrack）识别 TCP 半连接状态，其本质是统计每个源IP当前在 SYN_RECV 状态的连接数。它不记录时间窗口、不触发封禁、不自动拉黑，只是做“此刻是否超限”的瞬时判断。
- 支持按单 IP（
--connlimit-mask 32）或网段（如/24）统计 - 仅对
--syn包生效，且必须配合-m state --state NEW或--ctstate NEW使用才准确 - 对 UDP 完全无效——UDP 无连接状态，connlimit 无法识别“并发会话”
- 阈值设置需结合业务：Web 服务通常设为 30–50；API 网关可压到 10–20；游戏服务器可能需放宽至 80+
让 Connlimit 发挥“准熔断”效果的关键配置
要使 connlimit 规则接近“熔断”体验（即超限立即丢弃、不响应、不排队），必须满足三个条件：位置靠前、动作强硬、避免干扰。
- 规则插入 INPUT 链顶部（
-I INPUT 1），确保在 ESTABLISHED 允许规则之前执行 - 动作为
-j DROP，而非REJECT；REJECT会发 RST 包，反而增加攻击者反馈信息 - 显式匹配 SYN 标志：
--tcp-flags FIN,SYN,RST,ACK SYN，防止被其他标志绕过 - 示例命令：
iptables -I INPUT -p tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 40 --connlimit-mask 32 -j DROP
为什么单靠 Connlimit 不足以应对高并发SYN洪水
SYN洪水的本质是短时海量伪造源IP发起连接请求，connlimit 的局限性在此类场景中暴露明显：
- 攻击者用百万级僵尸IP发起攻击，每个IP只发3–5个SYN，远低于 connlimit 阈值（如40），但总量压垮半连接队列
- connlimit 不记录时间维度，无法识别“60秒内累计100次新SYN”这类行为模式
- Linux 默认
tcp_max_syn_backlog一般为 1024，connlimit 无法提升该硬限制，只能在其之上再设一层软门槛 - 若未启用
tcp_syncookies=1，connlimit 规则尚未触发，队列已满，新SYN直接被内核丢弃，用户无感知
真正实现“刚性熔断”的组合策略
把 connlimit 当作基础水位计，再叠加速率控制和动态封禁，才能形成有响应、有记忆、有阈值的防护闭环：
-
第一层：速率压制（limit/hashlimit）
用--limit 5/sec --limit-burst 15控制全局 SYN 流量，抑制突发冲击 -
第二层：源IP并发控制（connlimit）
防止单IP持续占坑，例如--connlimit-above 20丢弃多余半连接 -
第三层：动态封禁（recent）
60秒内触发5次 connlimit 丢弃，就加入黑名单：-m recent --name synblock --set+--update --seconds 300 --hitcount 5 -j DROP -
系统级加固不可少
同步开启：echo 1 > /proc/sys/net/ipv4/tcp_syncookies、echo 2 > /proc/sys/net/ipv4/tcp_synack_retries、echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
