iptables 的 -m connlimit 模块不支持 UDP 协议，因其依赖连接跟踪状态而 UDP 默认无连接状态；应改用 --limit、hashlimit、端口白名单等组合策略进行 UDP 泛洪防护。
iptables 的 -m connlimit 模块**不支持 UDP 协议**，因为它依赖连接状态（如 ESTABLISHED、RELATED），而 UDP 是无连接协议，内核不会为普通 UDP 流维护连接跟踪条目（除非启用 nf_conntrack_udp_* 相关模块并触发连接跟踪，但非常有限且不稳定）。因此，不能用 connlimit 对 UDP 端口做并发连接数限制——这是常见误区。
为什么 connlimit 对 UDP 基本无效
– connlimit 依赖 netfilter 的 connection tracking（conntrack）子系统；
– UDP 包默认不进入 conntrack 表（除非匹配特定规则或使用如 DNS、SIP 等需状态识别的协议）；
– 即使强制开启 UDP conntrack（如 modprobe nf_conntrack_udp），其超时短、易丢失、无法准确反映“并发会话”，不适合抗泛洪；
– 实测中对 UDP 端口使用 -m connlimit --connlimit-above N 几乎不生效，规则会被跳过或误判。
真正有效的 UDP 泛洪防护替代方案
针对特定 UDP 端口（如 53/DNS、123/NTP、27015/游戏），应采用以下组合策略：
-
基于速率限制（--limit）：按源 IP 或全局限制每秒包数
iptables -A INPUT -p udp --dport 53 -m limit --limit 20/sec --limit-burst 60 -j ACCEPTiptables -A INPUT -p udp --dport 53 -j DROP -
基于每个源 IP 的速率（hashlimit）：更精准防分布式攻击
iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-name dns_limit --hashlimit-mode srcip --hashlimit-rate 10/sec --hashlimit-burst 30 -j ACCEPTiptables -A INPUT -p udp --dport 53 -j DROP -
端口白名单 + 默认拒绝：只放行已知合法用途的 UDP 端口
iptables -P INPUT DROPiptables -A INPUT -p udp --dport 53 -j ACCEPTiptables -A INPUT -p udp --dport 123 -j ACCEPTiptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -
配合 conntrack 做有状态辅助（仅限极少数场景）：如 DNS 响应需回包，可启用状态匹配
modprobe nf_conntrack_dnsiptables -A INPUT -p udp --dport 53 -m state --state NEW -m limit --limit 15/sec -j ACCEPT
关键操作提醒
– 所有规则建议加在 INPUT 链开头，避免被其他规则提前放行；
– 使用 iptables -L INPUT -v -n --line-numbers 查看规则顺序和命中数；
– 生产环境务必先测试 --limit-burst 值，过小会误伤正常突发流量（如 DNS 批量查询）；
– 若服务器本身是 DNS 递归服务，建议结合 bind9 内置的 rate-limit 机制，比 iptables 更语义化；
– 超大规模攻击（如 >1Gbps UDP Flood）需上云清洗或硬件防火墙，iptables 仅作兜底。
