iptables -t raw表的核心价值是卸载conntrack开销，通过notrack在prerouting链跳过连接跟踪，避免表溢出与性能雪崩，属性能加固手段，需配合其他防护层使用。
在超大规模攻击流量场景下，iptables -t raw 表的核心价值不是“防御”，而是卸载连接跟踪（conntrack）开销，让内核跳过 nf_conntrack 模块的资源消耗，从而避免因连接表溢出、哈希冲突或超时等待导致的性能雪崩。这属于性能加固手段，需配合其他防护层使用。
为什么raw表能缓解高并发冲击
Linux 默认对每个进入的 TCP/UDP 数据包启动连接跟踪，记录五元组并维护状态（ESTABLISHED、TIME_WAIT 等）。当攻击流量达数万连接/秒时：
- nf_conntrack 表迅速占满（默认通常 65536 条），新连接被丢弃或延迟建立
- 大量 TIME_WAIT 连接长期占用条目（MySQL 默认 5 天），规则变更无法即时生效
- CPU 持续忙于哈希查找与超时扫描，影响正常业务响应
raw 表在 PREROUTING 链最早介入，用 NOTRACK 目标直接标记数据包“不跟踪”，后续 nat、filter 表均跳过 conntrack 查询——相当于给特定流量“开快速通道”。
典型适用场景与匹配条件
NOTRACK 不是万能开关，只适用于无需状态检测、且自身协议栈能可靠处理连接生命周期的流量。常见适配对象：
- 对外提供纯无状态服务的端口：如 DNS（53/udp）、NTP（123/udp）、健康检查端口（如 /health HTTP GET）
- 已由应用层做连接管理的长连接服务：如某些基于 epoll 的自研网关、gRPC over TLS（若 TLS 终止在应用侧）
- 明确来源可信、仅需基础过滤的内部服务接口（如 Consul agent 端口 8301/tcp）
⚠️ 不适用：需要 DNAT/SNAT 的流量、依赖 conntrack 做状态放行（如 ESTABLISHED 规则）、SSH、常规 Web（HTTP/HTTPS 通常仍需状态跟踪保障会话）
安全可用的 raw 规则写法
以下命令需以 root 执行，建议先测试再上线：
- 对指定 UDP 端口（如 DNS）完全绕过连接跟踪：
iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK - 对某 IP 段访问的 HTTP 健康检查路径跳过跟踪（需配合应用层识别）：
iptables -t raw -A PREROUTING -s 10.0.0.0/8 -p tcp --dport 8000 -m string --string "/health" --algo bm -j NOTRACK - 禁止对特定端口启用连接跟踪后，必须在 filter 表中显式放行（因为 ESTABLISHED 规则失效）：
iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
注意：NOTRACK 后 filter 表规则将失去状态判断能力，所有放行必须基于 IP、端口、协议等静态特征；DROP 规则也需前置，避免误杀。
配套关键操作与验证
启用 raw 规则后，必须同步调整运维习惯：
- 监控 conntrack 使用率：
cat /proc/sys/net/netfilter/nf_conntrack_count 与 cat /proc/sys/net/netfilter/nf_conntrack_max - 确认规则生效：
iptables -t raw -L -n -v 查看 PREROUTING 链计数器是否增长 - 清除已有连接跟踪干扰（非实时，慎用）：
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal（临时放宽 TIME_WAIT 处理）
或更彻底：conntrack -F（清空当前表，可能中断合法长连接）
实际效果取决于业务模型。例如 Nginx 对外服务，即使 80 端口启用 NOTRACK，只要 keepalive_timeout 设置合理（如 65 秒），conntrack 压力本身可控；而 MySQL 3306 若直连暴露，NOTRACK 可避免 5 天超时僵局，但必须靠网络层 ACL 或代理层限速兜底。
