只有raw表+notrack能从源头规避conntrack耗尽雪崩，因其在prerouting/output链（路由前）跳过nf_conntrack_init，实现零状态开销；其他表均在conntrack初始化后介入，无法避免资源占用。
要彻底规避高并发下 conntrack 耗尽导致的整机雪崩，关键不是“调大 nf_conntrack_max”，而是让不该进状态跟踪的流量根本绕过它——raw 表 + NOTRACK 是唯一能从源头切断 conntrack 资源消耗的手段。它不缓解瓶颈，而是直接移除瓶颈环节。
为什么只有 raw 表能真正“规避”而非“缓解”
conntrack 在数据包进入 Netfilter 的最早阶段（路由前）即被触发。raw 表的 PREROUTING 和 OUTPUT 链是整个 iptables 架构中唯一早于 conntrack 初始化的位置。其他所有表（filter、nat、mangle）都在 conntrack 状态已创建之后才介入：
- 在 filter 表里写 -j DROP，包早已被分配 ct entry、计入哈希表、占用内存和 CPU
- 在 nat 表做 DNAT，会强制触发 conntrack，哪怕你前面写了 ACCEPT
- 只有 raw 表的 -j NOTRACK 能让内核跳过整个 nf_conntrack_init() 流程，实现“零状态开销”
哪些流量必须 NOTRACK —— 安全与性能的交界点
NOTRACK 不是放行，而是“卸载状态责任”。只对无状态、可信、高频且无需连接语义的流量启用：
- 本地回环通信：iptables -t raw -A PREROUTING -i lo -j NOTRACK；iptables -t raw -A OUTPUT -o lo -j NOTRACK
- 监控与心跳流量（如 Zabbix Agent、Consul UDP 健康检查）：iptables -t raw -A PREROUTING -p udp --dport 10050 -s 10.0.10.0/24 -j NOTRACK
- DNS 响应包（仅限 --sport 53 且目标为可信客户端）：iptables -t raw -A PREROUTING -p udp --sport 53 -d 192.168.0.0/16 -j NOTRACK
- CDN 回源 UDP 流量（如 QUIC、DNS over UDP）：iptables -t raw -A PREROUTING -p udp --dport 443 -s 203.208.136.0/21 -j NOTRACK
⚠️ 绝对禁止对公网入向 TCP 新建连接（如 HTTP/HTTPS）、未过滤的 UDP Flood 目标端口、或需 NAT/FTP-ALG 的流量使用 NOTRACK。
NOTRACK 后必须显式控制 —— 防火墙逻辑重构
一旦标记 NOTRACK，该包就变成 UNTRACKED 状态，-m conntrack、--ctstate ESTABLISHED 等全部失效。你不能再依赖“状态防火墙”逻辑，必须转向无状态控制：
- 用 -m limit 替代基于状态的限速：iptables -A INPUT -p tcp --dport 80 -m limit --limit 100/sec --limit-burst 200 -j ACCEPT
- 用 -m hashlimit 做 IP 级防刷：iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-above 5/sec --hashlimit-name dns_flood -j DROP
- 所有 NOTRACK 流量仍需在 filter 表中明确 -j ACCEPT 或 -j DROP，否则默认策略接管，可能意外丢包
配套调优与验证 —— 确保策略落地生效
NOTRACK 生效后需同步确认底层支撑和可观测性：
- 确认模块加载：lsmod | grep nf_conntrack（必须有输出）
- 检查当前连接数压力：cat /proc/sys/net/netfilter/nf_conntrack_count 与 nf_conntrack_max 对比
- 验证 NOTRACK 是否命中：watch -n1 'conntrack -C'（数值应明显低于未启用前）
- 禁用冗余跟踪：echo 1 > /proc/sys/net/netfilter/nf_conntrack_untracked（确保 untracked 包不被误捕）
- 压测验证：用 iperf3 + hping3 混合发包，观察 softirq 时间、丢包率、nf_conntrack_count 波动
