notrack真正作用是保内核资源，让特定流量绕过nf_conntrack以避免哈希表打爆、cpu软中断飙升及半连接队列丢包；必须在raw表prerouting/output链配置，因仅此处能在连接跟踪初始化前介入。
NOTRACK不能直接防SYN Flood丢包，它真正的作用是保内核资源——让特定流量绕过连接跟踪（nf_conntrack），避免在超大规模伪造SYN冲击下，conntrack哈希表被迅速打爆、CPU软中断飙升、甚至触发“SYNs to LISTEN sockets dropped”这类半连接队列丢包。
为什么必须用 raw 表配 NOTRACK
只有 raw 表的 PREROUTING 和 OUTPUT 链能在数据包进入连接跟踪模块前介入。一旦错过这个时机（比如在 filter 或 mangle 表里操作），包已经分配了 conntrack entry、占用了内存和哈希桶，再 DROP 也晚了——资源早已浪费。
- 正确位置：
iptables -t raw -A PREROUTING ... -j NOTRACK - 典型错误：在 INPUT 链写
-j DROP或-m state --state NEW -j ACCEPT——此时连接状态已创建，无效缓解 - 验证是否生效：运行
cat /proc/sys/net/netfilter/nf_conntrack_count，施加压力后若增长明显变缓，说明 NOTRACK 起效
哪些 SYN 流量可安全豁免跟踪
NOTRACK 不是放行，而是“不记账”。只对明确无状态、来源可信、且不参与 NAT/FTP-ALG 等依赖 conntrack 功能的流量启用。
- 本地回环通信（必配）：
iptables -t raw -A PREROUTING -i lo -j NOTRACK和iptables -t raw -A OUTPUT -o lo -j NOTRACK - 已知监控探针的 TCP 健康检查（如 Consul HTTP 检查）：
iptables -t raw -A PREROUTING -p tcp --dport 8500 -s 10.10.0.0/16 -j NOTRACK - DNS/NTP 服务的响应包（注意方向）：
iptables -t raw -A OUTPUT -p udp --sport 53 -d 10.20.0.0/16 -j NOTRACK（仅限出口已确认目标可信） -
禁止对公网入向的
--syn包设 NOTRACK，这等于放弃所有连接状态管理，会破坏后续限速、连接数控制等防御逻辑
NOTRACK 后必须改用无状态规则控制
一旦跳过 conntrack，-m conntrack --ctstate ESTABLISHED 类规则全部失效。需切换为基于包特征的匹配方式：
- 用
-m limit替代连接态限速：iptables -A INPUT -p tcp --dport 80 --syn -m limit --limit 30/sec --limit-burst 60 -j ACCEPT - 用
-m hashlimit控制单 IP 新建连接频次：iptables -A INPUT -p tcp --dport 443 --syn -m hashlimit --hashlimit-above 5/sec --hashlimit-name https_syn --hashlimit-mode srcip -j DROP - 务必补一条兜底 DROP：
iptables -A INPUT -p tcp --syn -j DROP，防止未匹配规则的伪造 SYN 进入协议栈
配合内核参数堵住底层丢包缺口
NOTRACK 解决的是 conntrack 瓶颈，但半连接队列（SYN queue）溢出仍会导致 SYNs to LISTEN sockets dropped。必须同步加固：
- 启用 SYN Cookie：
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 - 以上写入
/etc/sysctl.conf并执行sysctl -p持久化
