ss -ant 不能查看 conntrack 表状态，因其仅显示 socket 层 tcp 状态（如 established、syn_recv），而 conntrack 表由 netfilter 独立维护，需用 conntrack 工具（如 conntrack -s、conntrack -l）查看条目分布、invalid 或 syn_sent/recv 等真实跟踪状态。
ss -ant 不能直接查看连接跟踪表（conntrack）状态分布，它只显示 socket 层面的 TCP 连接状态，和内核 netfilter 的 conntrack 表是两套机制。 想看攻击导致的 conntrack 表堆积（比如大量 SYN_RECV、INVALID 或超时未清理条目），得用 conntrack 工具，不是 ss。
为什么 ss -ant 看不到真正的连接跟踪表状态
ss -ant 输出的是内核 socket 子系统中当前已建立或处于半开状态的 TCP 连接，比如 ESTABLISHED、SYN-RECV、TIME-WAIT。但这些状态和 netfilter 的 conntrack 表项不完全一一对应：
-
ss中的SYN-RECV是三次握手未完成的 socket，而conntrack里对应的是SYN_SENT或SYN_RECV状态，但仅当连接经过了 netfilter 链（如启用 iptables/nftables 规则）才会被跟踪 - 大量短连接或扫描包可能根本没走到 socket 层（被 DROP 在 INPUT 链之前），
ss完全不可见，但conntrack -L可能残留INVALID或超时未删除条目 -
ss -s统计里的TCP: synrecv是 socket 数，不是 conntrack 条目数；两者数值常不一致
真正排查攻击导致的 conntrack 表异常该怎么做
先确认是否启用了连接跟踪（大多数有防火墙规则的服务器都启用）：
cat /proc/sys/net/netfilter/nf_conntrack_max
再用 conntrack 查看实时分布：
- 统计各状态条目数：
conntrack -S（输出类似entries = 1248、searched = 89234、invalid = 21） - 列出所有
INVALID条目（常见于分片攻击、TCP 校验失败、时序混乱）：conntrack -L | grep 'INVALID' - 筛选大量
SYN_SENT或SYN_RECV（疑似 SYN Flood）：conntrack -L | awk '$3 ~ /SYN_(SENT|RECV)/ {print $0}' | head -20 - 按源 IP 聚合统计，找攻击源：
conntrack -L | awk '{print $7}' | cut -d= -f2 | sort | uniq -c | sort -nr | head -10
ss -ant 在攻击排查中还能怎么用（有限但有用）
虽然它不等于 conntrack，但在某些攻击表征下仍有参考价值：
- 发现异常多的
SYN-RECVsocket：ss -ant state syn-recv | wc -l—— 若远超正常并发（比如 >1000），且netstat -s | grep "SYNs to LISTEN sockets"也在飙升，说明可能正在受 SYN Flood 影响 - 大量
TIME-WAIT本身不是攻击，但若配合ss -s显示TCP: time_wait占比过高（如 >60%），且业务非高并发短连接，需检查是否被慢速攻击（如 Slowloris）拖住连接释放 - 用
watch -n 1 'ss -ant state syn-recv | wc -l'实时观察波动，比翻conntrack -L更快感知突发
真正要定位连接跟踪表是否被耗尽或污染，conntrack 是唯一正解；ss 只能辅助验证攻击是否已穿透到传输层。别把 ss -ant 当成 conntrack 替代品——这是最常被忽略的边界问题。
