nftables 的 ct state 无法直接接管 SYN_RECV 半连接，因其未进入 conntrack 表；平滑处理需结合 SYN Cookie、ct state invalid/new 识别与限速、established/related 快速放行等协同策略。
nftables 的 ct state 本身不能直接接管或“平滑接管”半连接状态（SYN_RECV）的流量，因为半连接（即三次握手未完成的连接）在内核中不被视为 ESTABLISHED，也不进入 conntrack 表的正常生命周期——它只存在于 TCP 半连接队列（syn queue），尚未被连接跟踪模块（nf_conntrack）正式记录。
真正能“平滑处理”这类流量的，是配合连接跟踪状态判断 + 主动防御策略 + 队列协同参数调优，而非单靠 ct state 指令接管。以下是关键逻辑和实操要点：
ct state 能识别的状态有限，半连接不在其中
nftables 中 ct state 可匹配的值只有：
-
invalid（无法归类或损坏的包） -
new（首次 SYN 包，且成功进入 conntrack） -
established（已有双向通信，如 SYN-ACK 后的 ACK） -
related（如 FTP 数据连接、ICMP 错误关联等）
⚠️ 注意：一个纯 SYN 包若因 net.ipv4.tcp_syncookies=1 或 tcp_max_syn_backlog 溢出被丢弃，它根本不会触发 conntrack 创建，自然也不会有 ct state new 可匹配。所以你无法用 ct state new 精确捕获所有“正在尝试建立”的半开连接。
真正可用的半连接协同策略
-
启用 SYN Cookie 防御（内核级兜底）
sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_max_syn_backlog=4096
这让服务端在队列满时用加密序列号应答 SYN，避免 TCB 占用，使合法客户端仍可完成握手——这是“平滑”的底层基础。
-
用
ct state invalid+ TCP 标志组合识别异常半开行为
恶意扫描器常发 SYN 后不响应 SYN-ACK，或伪造源 IP 导致大量ct state invalid包：nft add rule inet filter input tcp flags & (fin | syn | rst | ack) == syn ct state invalid counter name "syn-invalid" drop
这类包虽未建连，但已触发 conntrack 尝试跟踪并失败，可作为攻击信号。
-
对高频
ct state new源做速率限制（保护半连接队列不被耗尽）nft add rule inet filter input ct state new limit rate 5/second burst 20 packets counter accept nft add rule inet filter input ct state new counter drop
防止攻击者用海量 SYN 填满
tcp_max_syn_backlog，间接保障真实用户 SYN 能入队。 -
允许
ct state established,related无条件通行（保障已建连流量不中断）nft add rule inet filter input ct state established,related counter accept
这是“平滑接管”的核心体现：一旦连接真正建立（哪怕之前经历过 SYN 重传、cookie 验证），后续所有数据包都靠此规则零延迟放行，无需再走复杂匹配。
不要误解“接管”的含义
nftables 不会、也不能把一个卡在 SYN_RECV 状态的连接“拉进 conntrack 表”强行转为 ESTABLISHED。它的作用是：
- 让合法连接尽可能完成握手（靠内核参数 + SYN Cookie）
- 让已完成握手的连接获得极速路径（靠
ct state established直接跳过其他规则） - 让恶意试探被快速识别并抑制（靠
invalid+ 速率限制 + 黑名单）
这才是面向半连接场景的真实“平滑”。
