排查生产环境里的访问异常时我做得最多的一个动作不是急着抓包而是先看一眼防火墙设备上的连接跟踪表这条连接到底在不在表里状态是 NEW 还是 ESTABLISHED有没有回包方向的记录这个习惯帮我省下过大量瞎折腾的时间。这篇文章从一个最基础的运维问题切入如何查看当前系统中所有活跃的连接跟踪条目。我会把连接跟踪机制、常用查看工具、字段含义、容量评估以及实战排查思路串在一起讲清楚无论你是刚接触防火墙的小白还是已经在维护生产环境的老手都能从里面找到可以直接用的命令和判断逻辑。1. 连接跟踪到底是什么先搞清楚你要查看的对象1.1 Netfilter 里的连接跟踪机制绝大多数 Linux 防火墙包括云主机安全组、内网网关、负载均衡后端本质上都建立在 Netfilter 框架之上。而 Netfilter 最核心的内存结构之一就是连接跟踪表conntrack table。当第一个数据包经过防火墙时Netfilter 会尝试归类这个包属于哪个连接。如果查不到现有条目就创建一个新条目记录这个包的协议、源地址、源端口、目的地址、目的端口以及在反向流量里对应的地址和端口。之后这条数据流的所有后续包都在这个条目的上下文里做判断。防火墙的 allow/deny 规则、NAT 的地址转换、连接数限制全都依赖这张表。打个比方如果一台服务器是一栋办公楼那连接跟踪表就是门口保安手里的访客登记本。每个进出的人都要登记保安才知道你是谁、进了哪间办公室、什么时候该放你出去。防火墙设备就是那个保安而查看活跃连接跟踪条目就是把登记本翻开看看现在楼里有哪些人。1.2 活跃是一个动态概念标题里说的活跃连接跟踪条目严格来说并不是一个静态快照。表里的条目会随数据包流动不断刷新超时时间也会随连接关闭被回收。比如一条 TCP 连接在四次挥手后条目并不会立刻消失而是要等内核里的 TCP 超时参数把它扫地出门。一条 UDP 会话更是完全靠超时来判定生死几十秒没有新包条目就会被回收。所以你在不同时刻执行同一条查看命令输出结果一定不一样。这也意味着如果你在排查问题时第一次没有看到期望的连接不要急着下结论多观察几秒可能条目刚好被回收也可能数据包根本没走到防火墙这一层。1.3 哪些场景下连接跟踪表里会有内容只要启用了防火墙规则、NAT 功能或开启了连接追踪几乎所有的进出流量都会生成条目。常见的场景包括内网主机访问公网在网关设备上做 SNAT 时会产生双向地址转换后的条目。外部用户访问内部服务器的 80/443 端口防火墙转发流量时会产生 Forward 链路的条目。服务器本机进程发起对外请求在 INPUT/OUTPUT 链上也会记录条目。ICMP 请求和响应比如 ping同样会生成跟踪条目。某些特殊协议如 FTP 的主动/被动模式还会产生 RELATED 状态的关联条目。搞清楚这些你就知道查看连接跟踪条目并不是只适用于大型防火墙场景普通 Linux 服务器同样依赖它。2. 两条主力查看路线conntrack 命令行与 /proc 接口2.1 内核自带的 /proc/net/nf_conntrack最朴素的办法是直接读内核导出的文件cat /proc/net/nf_conntrack输出长这样不同内核版本字段略有差异ipv4 2 tcp 6 431999 ESTABLISHED src192.168.1.10 dst203.0.113.5 sport24567 dport443 packets1024 bytes154321 src203.0.113.5 dst192.168.1.10 sport443 dport24567 packets2048 bytes890123 [ASSURED] mark0 use1 ipv4 2 udp 17 29 src192.168.1.20 dst8.8.8.8 sport53000 dport53 packets3 bytes180 src8.8.8.8 dst192.168.1.20 sport53 dport53000 packets3 bytes150 [ASSURED] mark0 use1 ipv4 2 icmp 1 28 src192.168.1.30 dst203.0.113.9 type8 code0 id30001 packets1 bytes60 src203.0.113.9 dst192.168.1.30 type0 code0 id30001 packets1 bytes60 [ASSURED] mark0 use1这个文件的优点是直接来自内核任何 Linux 系统只要有 nf_conntrack 模块加载就能读不需要额外安装工具。缺点也很明显条目一多输出就是几千上万行用 grep 做简单过滤还凑合但要做协议、状态、端口的组合筛选就很吃力。2.2 更强力的 conntrack 工具推荐安装conntrack-tools包它提供的conntrack命令才是日常排查的主力# CentOS / RHEL yum install -y conntrack-tools # Debian / Ubuntu apt-get install -y conntrack查看全部条目conntrack -L只看 TCPconntrack -L -p tcp只看某个目的端口conntrack -L -p tcp --dport 443只看某个来源网段conntrack -L -s 192.168.1.0/24只看处于 ESTABLISHED 状态的条目conntrack -L --state ESTABLISHEDconntrack的输出格式和/proc/net/nf_conntrack基本一致但可读性和过滤能力要强得多后面几节我会详细拆解它的输出。2.3 两条路线怎么选场景推荐方式原因快速确认模块是否生效cat /proc/net/nf_conntrack系统自带零依赖少量条目临时看一眼cat /proc/net/nf_conntrack足够用生产环境定位具体连接conntrack -L 系列过滤支持按协议、地址、端口、状态组合筛选持续跟踪状态变化conntrack -E实时输出新事件适合抓瞬态问题统计当前表项数量conntrack -C一行命令输出数字适合脚本取数我的习惯是先conntrack -C看总量再按协议和端口过滤定位目标连接。几百上千条的原始输出直接刷屏除了让自己眼花之外没什么帮助。3. 一行连接跟踪条目的字段到底怎么读3.1 逐段拆解一个 TCP 条目拿前面那条 TCP 输出来看ipv4 2 tcp 6 431999 ESTABLISHED src192.168.1.10 dst203.0.113.5 sport24567 dport443 packets1024 bytes154321 src203.0.113.5 dst192.168.1.10 sport443 dport24567 packets2048 bytes890123 [ASSURED] mark0 use1第一段ipv4 2 tcp 6表示三层协议是 IPv4地址族编号 2四层协议是 TCP协议号 6。紧跟其后的431999是这个条目剩余的生存时间秒单位是倒计时的。ESTABLISHED是连接状态。中间的一大段是两组五元组以空格分隔字段原始方向回复方向src192.168.1.10谁发起的203.0.113.5谁回应dst203.0.113.5要访问谁192.168.1.10回应给谁sport24567源端口443服务端口dport443目的端口24567回包目的端口packets / bytes1024 个包 / 154321 字节2048 个包 / 890123 字节后面中括号里的[ASSURED]表示这个连接已经被确认双向都有流量属于稳定的活跃连接。如果是[UNREPLIED]则说明只看到了发起方向的包还没见回包。mark0是防火墙标记值use1是内核引用计数。一个非常容易困惑的地方是输出里有两个 src/dst/sport/dport顺序是先原始方向、后回复方向。实际排查时我通常会先确定我关心的那台机器 IP 出现在哪个方向再去看对应的端口否则容易看反。3.2 状态字段的含义NEW / ESTABLISHED / RELATED / INVALID连接跟踪把连接分成几种基础状态理解它们比背字段重要得多。NEW看到了第一个数据包但还没有建立完整的双向关联。TCP 场景下单方向 SYN 就能把状态标记为 NEWUDP 则是看到第一个包。ESTABLISHED双向都有流量连接已经确认了。TCP 是完成握手UDP 是双方互发过包。RELATED与已有连接相关的衍生连接。典型例子是 FTP 控制连接之外的数据连接以及 ICMP 差错报文。INVALID状态不对的包。比如序列号不在窗口内的 TCP 包或者伪造的响应包。防火墙通常直接 drop 掉这类包。排查问题时看到一条预期中的连接一直停在NEW几乎可以断定是回包路径有问题。想想看请求明明出去了为什么防火墙一直见不到回复方向的包要么被路由丢了要么回复里的源 IP 和端口和连接跟踪表对不上要么被防火墙安全组规则挡了。3.3 [ASSURED] 和 [UNREPLIED] 是判断问题的重要线索[ASSURED]和[UNREPLIED]不是状态字段但与状态强相关。[UNREPLIED]意味着这个条目只记录到了单方向包NAT 场景下尤其危险外网主动访问一个内网端口时如果只看到请求方向没有回包说明反向路径或安全策略有阻断。从资源角度看未确认的连接也更容易被回收。当连接跟踪表快满时内核优先清理[UNREPLIED]的条目这就是为什么 SYN 泛洪容易被发现表里全是一堆没有[ASSURED]的半截连接正常业务连接反而进不来。4. 连接跟踪表满了怎么办容量评估、超时与清理4.1 当前表容量和使用量怎么看查看当前总条目数conntrack -C查看最大可容纳条目数sysctl net.netfilter.nf_conntrack_max查看统计信息conntrack -Sconntrack -S的输出里能看到当前表使用总量、分配失败次数、搜索次数等更细的计数器。如果insert_failed这个计数器持续增长说明有包因为表满被丢弃这是很硬的故障信号。一条连接跟踪条目在内存中通常占据几百字节。粗算一下nf_conntrack_max设为 65536 时光连接跟踪表就可能吃掉两三百 MB 内核内存。这个数字会随内核版本和编译选项浮动但方向上你就按一千万条目大概要几个 GB 内存这个量级去估别把 max 值调得漫无天际。4.2 表满之后的表现和定位过程表满时系统的表现往往不是完全不能访问而是随机丢包、连接时好时坏。因为当新包进来需要创建条目时内核发现表满就会选择丢包同时触发清理逻辑尝试回收一部分过期条目。业务方感受就是某个端口连了几次成功一次或者长连接过一会儿就断。先看有没有内核丢包记录dmesg -T | grep -i nf_conntrack能看到类似 nf_conntrack: table full, dropping packet 的输出基本就坐实了是表溢出。接下来按步骤走查总量conntrack -C。查上限sysctl net.netfilter.nf_conntrack_max。按协议统计conntrack -L -p tcp | wc -l、conntrack -L -p udp | wc -l。找异常大户用conntrack -L -p udp --dport 53 | wc -l这类命令看是不是 DNS 流量异常多或者 SYN 半开连接堆积。我遇到过最常见的情况就是 UDP 超时设置过长或者某个端口被扫描工具扫出了大量半连接。先找出占用大头再决定是调整超时参数还是清理指定连接盲目调大 max 只会推迟问题爆炸的时间。4.3 调整超时参数比盲调 max 更值得做超时参数决定条目在表里躺多久。常见的几个sysctl -w net.netfilter.nf_conntrack_udp_timeout30 sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream120 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent60 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established432000TCP 长连接保持 4 小时左右没问题但 SYN 半连接、UDP 单包会话没必要留太久。把 UDP 超时从默认值压到 30 秒能显著减少会话表压力。调整时要同时考虑业务DNS 查询通常很快30 秒绰绰有余但某些视频流、游戏 UDP 会话持续时间长压太狠会导致连接中途被拆反而引发新问题。4.4 手工清理特定连接生产环境慎用conntrack -F清空整个表这和在生产库上执行 DROP TABLE 差不多一个性质一执行所有现存连接全部失联连接状态全丢对外访问全部重新建连。更安全的操作是精准删除# 删除某个目的端口的 UDP 条目 conntrack -D -p udp --dport 53 # 删除来自某个 IP 的连接 conntrack -D -s 192.168.1.100 # 删除某个五元组 conntrack -D -p tcp -s 192.168.1.10 -d 203.0.113.5 --dport 443注意conntrack -D删除的是整条双向关联不存在只删一边的操作。触发删除后后续两个方向的包会被当作新连接重新创建条目这正是我们想要的效果——让卡住的状态清零重新建立一条干净连接。5. 实战排查从连接跟踪表看一次能通但很慢的问题5.1 一个典型场景的完整排查链路假设业务方反馈内网某台主机访问外网的一个 Web 服务偶尔能通偶尔超时ping 又正常。第一件事不是抓包而是看这台主机产生的连接在防火墙上的状态conntrack -L -p tcp -s 10.10.10.5假设输出如下tcp 6 95 SYN_SENT src10.10.10.5 dst198.51.100.20 sport40001 dport443 packets30 bytes3000 src198.51.100.20 dst10.10.10.5 sport443 dport40001 packets0 bytes0 [UNREPLIED] mark0 use1这里能看到两个关键信息状态是 SYN_SENT说明连接还停留在发起 SYN 的阶段。回复方向 packets 和 bytes 都是 0[UNREPLIED] 显示回包从未被防火墙记录。问题链条立即清晰请求方向的数据确实经过了防火墙但回应数据没有回到这台设备。原因可能是回程路由走偏了也可能是对端服务根本没有响应又或者中间某个设备把回包丢弃了。紧接着顺着这个方向去抓包很快就能定位到丢包节点。5.2 结合 NAT 场景看条目如果这台机器是通过网关做 SNAT 出网的连接跟踪表里看到的地址就不止一层。比如内网主机 10.10.10.5 访问 198.51.100.20:443经网关 SNAT 后源地址变成网关公网地址 203.0.113.100tcp 6 300 ESTABLISHED src10.10.10.5 dst198.51.100.20 sport40002 dport443 packets50 bytes4000 src198.51.100.20 dst203.0.113.100 sport443 dport40002 packets40 bytes9000 [ASSURED] mark0 use1注意回复方向的 dst 变成了 203.0.113.100而不是原始的 10.10.10.5这就是 NAT 在连接跟踪表里的痕迹。看到这种情况说明 SNAT 生效了反向包回来时网关能根据这条记录把地址翻译回内网地址。如果没有这条记录即使回包到了网关也会因为找不到映射关系被丢弃。排查 NAT 问题最常犯的错是只在内网主机上抓包看不到公网侧的地址转换。在网关上用连接跟踪表把两端的地址对应关系串起来整个链路就清晰了。5.3 用 conntrack -E 实时观察连接建立过程静态快照只能看到某一瞬间的状态想看连接是怎么一步步失败的用conntrack -E实时监控新事件conntrack -E -p tcp --dport 443命令会阻塞一旦有相关事件就实时打印。比如专门开一个终端跑这个命令另一台机器发起访问你就能看到 NEW、ESTABLISHED 分别在哪一步出现哪一步缺失。对排查连接建立被卡住的问题特别管用。配合ss -tnp使用效果更好ss看本机 socket 层的状态conntrack看防火墙层的状态。两边一对比就能分清问题是发生在协议栈内部还是防火墙转发的半路上。5.4 常见异常条目特征总结排查多了之后我发现异常连接跟踪条目其实就那么几类现象可能原因大量 SYN_SENT [UNREPLIED]回程路由问题、对端无响应大量 ESTABLISHED 但 bytes 几乎不增长连接挂死、客户端或服务端超时参数问题UDP 条目堆积超时太长、DNS/日志流量异常INVALID 状态条目连接已重置但表未及时清理、NAT 端口冲突表满 insert_failed 计数增长nf_conntrack_max 太小或超时太长每类问题对应的处理方向都不同。如果你看到表里全是ESTABLISHED且 bytes 还在稳定增长那防火墙基本没有锅问题大概率在应用层或链路质量上。6. 日常维护中我常用的几个小技巧检查连接跟踪表这件事最好在故障发生前就形成习惯。我自己的服务器上会放一个简单脚本每分钟把关键指标写进日志#!/bin/bash echo $(date %F %T) conntrack_count$(conntrack -C 2/dev/null || echo 0) max$(sysctl -n net.netfilter.nf_conntrack_max 2/dev/null || echo 0) insert_failed$(conntrack -S 2/dev/null | awk /insert_failed/ {print $2})这样哪天业务反馈异常先翻开日志看故障时间点的 conntrack 指标比事后猜原因靠谱得多。另外一个很实用的技巧是需要保存现场时直接导出快照到文件conntrack -L -o timestamp /var/tmp/conntrack_$(date %Y%m%d_%H%M%S).txt-o timestamp会显示条目创建时间帮助判断这些连接是什么时候建立的。排查长连接泄漏问题时这个参数能帮你找出那些在表里存活了几天甚至几周的僵尸条目。最后提醒一句在连接跟踪表上做的任何清空、删除操作都要格外谨慎。生产环境里宁可使用精准的-D参数删指定连接也不要顺手敲-F全清。我曾经见过有人在排查时图省事直接清空结果所有 NAT 会话瞬间全部失效在线业务集体闪断那时你才会真正感受到这张表到底有多重要。
排查生产环境里的访问异常时我做得最多的一个动作不是急着抓包而是先看一眼防火墙设备上的连接跟踪表这条连接到底在不在表里状态是 NEW 还是 ESTABLISHED有没有回包方向的记录这个习惯帮我省下过大量瞎折腾的时间。这篇文章从一个最基础的运维问题切入如何查看当前系统中所有活跃的连接跟踪条目。我会把连接跟踪机制、常用查看工具、字段含义、容量评估以及实战排查思路串在一起讲清楚无论你是刚接触防火墙的小白还是已经在维护生产环境的老手都能从里面找到可以直接用的命令和判断逻辑。1. 连接跟踪到底是什么先搞清楚你要查看的对象1.1 Netfilter 里的连接跟踪机制绝大多数 Linux 防火墙包括云主机安全组、内网网关、负载均衡后端本质上都建立在 Netfilter 框架之上。而 Netfilter 最核心的内存结构之一就是连接跟踪表conntrack table。当第一个数据包经过防火墙时Netfilter 会尝试归类这个包属于哪个连接。如果查不到现有条目就创建一个新条目记录这个包的协议、源地址、源端口、目的地址、目的端口以及在反向流量里对应的地址和端口。之后这条数据流的所有后续包都在这个条目的上下文里做判断。防火墙的 allow/deny 规则、NAT 的地址转换、连接数限制全都依赖这张表。打个比方如果一台服务器是一栋办公楼那连接跟踪表就是门口保安手里的访客登记本。每个进出的人都要登记保安才知道你是谁、进了哪间办公室、什么时候该放你出去。防火墙设备就是那个保安而查看活跃连接跟踪条目就是把登记本翻开看看现在楼里有哪些人。1.2 活跃是一个动态概念标题里说的活跃连接跟踪条目严格来说并不是一个静态快照。表里的条目会随数据包流动不断刷新超时时间也会随连接关闭被回收。比如一条 TCP 连接在四次挥手后条目并不会立刻消失而是要等内核里的 TCP 超时参数把它扫地出门。一条 UDP 会话更是完全靠超时来判定生死几十秒没有新包条目就会被回收。所以你在不同时刻执行同一条查看命令输出结果一定不一样。这也意味着如果你在排查问题时第一次没有看到期望的连接不要急着下结论多观察几秒可能条目刚好被回收也可能数据包根本没走到防火墙这一层。1.3 哪些场景下连接跟踪表里会有内容只要启用了防火墙规则、NAT 功能或开启了连接追踪几乎所有的进出流量都会生成条目。常见的场景包括内网主机访问公网在网关设备上做 SNAT 时会产生双向地址转换后的条目。外部用户访问内部服务器的 80/443 端口防火墙转发流量时会产生 Forward 链路的条目。服务器本机进程发起对外请求在 INPUT/OUTPUT 链上也会记录条目。ICMP 请求和响应比如 ping同样会生成跟踪条目。某些特殊协议如 FTP 的主动/被动模式还会产生 RELATED 状态的关联条目。搞清楚这些你就知道查看连接跟踪条目并不是只适用于大型防火墙场景普通 Linux 服务器同样依赖它。2. 两条主力查看路线conntrack 命令行与 /proc 接口2.1 内核自带的 /proc/net/nf_conntrack最朴素的办法是直接读内核导出的文件cat /proc/net/nf_conntrack输出长这样不同内核版本字段略有差异ipv4 2 tcp 6 431999 ESTABLISHED src192.168.1.10 dst203.0.113.5 sport24567 dport443 packets1024 bytes154321 src203.0.113.5 dst192.168.1.10 sport443 dport24567 packets2048 bytes890123 [ASSURED] mark0 use1 ipv4 2 udp 17 29 src192.168.1.20 dst8.8.8.8 sport53000 dport53 packets3 bytes180 src8.8.8.8 dst192.168.1.20 sport53 dport53000 packets3 bytes150 [ASSURED] mark0 use1 ipv4 2 icmp 1 28 src192.168.1.30 dst203.0.113.9 type8 code0 id30001 packets1 bytes60 src203.0.113.9 dst192.168.1.30 type0 code0 id30001 packets1 bytes60 [ASSURED] mark0 use1这个文件的优点是直接来自内核任何 Linux 系统只要有 nf_conntrack 模块加载就能读不需要额外安装工具。缺点也很明显条目一多输出就是几千上万行用 grep 做简单过滤还凑合但要做协议、状态、端口的组合筛选就很吃力。2.2 更强力的 conntrack 工具推荐安装conntrack-tools包它提供的conntrack命令才是日常排查的主力# CentOS / RHEL yum install -y conntrack-tools # Debian / Ubuntu apt-get install -y conntrack查看全部条目conntrack -L只看 TCPconntrack -L -p tcp只看某个目的端口conntrack -L -p tcp --dport 443只看某个来源网段conntrack -L -s 192.168.1.0/24只看处于 ESTABLISHED 状态的条目conntrack -L --state ESTABLISHEDconntrack的输出格式和/proc/net/nf_conntrack基本一致但可读性和过滤能力要强得多后面几节我会详细拆解它的输出。2.3 两条路线怎么选场景推荐方式原因快速确认模块是否生效cat /proc/net/nf_conntrack系统自带零依赖少量条目临时看一眼cat /proc/net/nf_conntrack足够用生产环境定位具体连接conntrack -L 系列过滤支持按协议、地址、端口、状态组合筛选持续跟踪状态变化conntrack -E实时输出新事件适合抓瞬态问题统计当前表项数量conntrack -C一行命令输出数字适合脚本取数我的习惯是先conntrack -C看总量再按协议和端口过滤定位目标连接。几百上千条的原始输出直接刷屏除了让自己眼花之外没什么帮助。3. 一行连接跟踪条目的字段到底怎么读3.1 逐段拆解一个 TCP 条目拿前面那条 TCP 输出来看ipv4 2 tcp 6 431999 ESTABLISHED src192.168.1.10 dst203.0.113.5 sport24567 dport443 packets1024 bytes154321 src203.0.113.5 dst192.168.1.10 sport443 dport24567 packets2048 bytes890123 [ASSURED] mark0 use1第一段ipv4 2 tcp 6表示三层协议是 IPv4地址族编号 2四层协议是 TCP协议号 6。紧跟其后的431999是这个条目剩余的生存时间秒单位是倒计时的。ESTABLISHED是连接状态。中间的一大段是两组五元组以空格分隔字段原始方向回复方向src192.168.1.10谁发起的203.0.113.5谁回应dst203.0.113.5要访问谁192.168.1.10回应给谁sport24567源端口443服务端口dport443目的端口24567回包目的端口packets / bytes1024 个包 / 154321 字节2048 个包 / 890123 字节后面中括号里的[ASSURED]表示这个连接已经被确认双向都有流量属于稳定的活跃连接。如果是[UNREPLIED]则说明只看到了发起方向的包还没见回包。mark0是防火墙标记值use1是内核引用计数。一个非常容易困惑的地方是输出里有两个 src/dst/sport/dport顺序是先原始方向、后回复方向。实际排查时我通常会先确定我关心的那台机器 IP 出现在哪个方向再去看对应的端口否则容易看反。3.2 状态字段的含义NEW / ESTABLISHED / RELATED / INVALID连接跟踪把连接分成几种基础状态理解它们比背字段重要得多。NEW看到了第一个数据包但还没有建立完整的双向关联。TCP 场景下单方向 SYN 就能把状态标记为 NEWUDP 则是看到第一个包。ESTABLISHED双向都有流量连接已经确认了。TCP 是完成握手UDP 是双方互发过包。RELATED与已有连接相关的衍生连接。典型例子是 FTP 控制连接之外的数据连接以及 ICMP 差错报文。INVALID状态不对的包。比如序列号不在窗口内的 TCP 包或者伪造的响应包。防火墙通常直接 drop 掉这类包。排查问题时看到一条预期中的连接一直停在NEW几乎可以断定是回包路径有问题。想想看请求明明出去了为什么防火墙一直见不到回复方向的包要么被路由丢了要么回复里的源 IP 和端口和连接跟踪表对不上要么被防火墙安全组规则挡了。3.3 [ASSURED] 和 [UNREPLIED] 是判断问题的重要线索[ASSURED]和[UNREPLIED]不是状态字段但与状态强相关。[UNREPLIED]意味着这个条目只记录到了单方向包NAT 场景下尤其危险外网主动访问一个内网端口时如果只看到请求方向没有回包说明反向路径或安全策略有阻断。从资源角度看未确认的连接也更容易被回收。当连接跟踪表快满时内核优先清理[UNREPLIED]的条目这就是为什么 SYN 泛洪容易被发现表里全是一堆没有[ASSURED]的半截连接正常业务连接反而进不来。4. 连接跟踪表满了怎么办容量评估、超时与清理4.1 当前表容量和使用量怎么看查看当前总条目数conntrack -C查看最大可容纳条目数sysctl net.netfilter.nf_conntrack_max查看统计信息conntrack -Sconntrack -S的输出里能看到当前表使用总量、分配失败次数、搜索次数等更细的计数器。如果insert_failed这个计数器持续增长说明有包因为表满被丢弃这是很硬的故障信号。一条连接跟踪条目在内存中通常占据几百字节。粗算一下nf_conntrack_max设为 65536 时光连接跟踪表就可能吃掉两三百 MB 内核内存。这个数字会随内核版本和编译选项浮动但方向上你就按一千万条目大概要几个 GB 内存这个量级去估别把 max 值调得漫无天际。4.2 表满之后的表现和定位过程表满时系统的表现往往不是完全不能访问而是随机丢包、连接时好时坏。因为当新包进来需要创建条目时内核发现表满就会选择丢包同时触发清理逻辑尝试回收一部分过期条目。业务方感受就是某个端口连了几次成功一次或者长连接过一会儿就断。先看有没有内核丢包记录dmesg -T | grep -i nf_conntrack能看到类似 nf_conntrack: table full, dropping packet 的输出基本就坐实了是表溢出。接下来按步骤走查总量conntrack -C。查上限sysctl net.netfilter.nf_conntrack_max。按协议统计conntrack -L -p tcp | wc -l、conntrack -L -p udp | wc -l。找异常大户用conntrack -L -p udp --dport 53 | wc -l这类命令看是不是 DNS 流量异常多或者 SYN 半开连接堆积。我遇到过最常见的情况就是 UDP 超时设置过长或者某个端口被扫描工具扫出了大量半连接。先找出占用大头再决定是调整超时参数还是清理指定连接盲目调大 max 只会推迟问题爆炸的时间。4.3 调整超时参数比盲调 max 更值得做超时参数决定条目在表里躺多久。常见的几个sysctl -w net.netfilter.nf_conntrack_udp_timeout30 sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream120 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent60 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established432000TCP 长连接保持 4 小时左右没问题但 SYN 半连接、UDP 单包会话没必要留太久。把 UDP 超时从默认值压到 30 秒能显著减少会话表压力。调整时要同时考虑业务DNS 查询通常很快30 秒绰绰有余但某些视频流、游戏 UDP 会话持续时间长压太狠会导致连接中途被拆反而引发新问题。4.4 手工清理特定连接生产环境慎用conntrack -F清空整个表这和在生产库上执行 DROP TABLE 差不多一个性质一执行所有现存连接全部失联连接状态全丢对外访问全部重新建连。更安全的操作是精准删除# 删除某个目的端口的 UDP 条目 conntrack -D -p udp --dport 53 # 删除来自某个 IP 的连接 conntrack -D -s 192.168.1.100 # 删除某个五元组 conntrack -D -p tcp -s 192.168.1.10 -d 203.0.113.5 --dport 443注意conntrack -D删除的是整条双向关联不存在只删一边的操作。触发删除后后续两个方向的包会被当作新连接重新创建条目这正是我们想要的效果——让卡住的状态清零重新建立一条干净连接。5. 实战排查从连接跟踪表看一次能通但很慢的问题5.1 一个典型场景的完整排查链路假设业务方反馈内网某台主机访问外网的一个 Web 服务偶尔能通偶尔超时ping 又正常。第一件事不是抓包而是看这台主机产生的连接在防火墙上的状态conntrack -L -p tcp -s 10.10.10.5假设输出如下tcp 6 95 SYN_SENT src10.10.10.5 dst198.51.100.20 sport40001 dport443 packets30 bytes3000 src198.51.100.20 dst10.10.10.5 sport443 dport40001 packets0 bytes0 [UNREPLIED] mark0 use1这里能看到两个关键信息状态是 SYN_SENT说明连接还停留在发起 SYN 的阶段。回复方向 packets 和 bytes 都是 0[UNREPLIED] 显示回包从未被防火墙记录。问题链条立即清晰请求方向的数据确实经过了防火墙但回应数据没有回到这台设备。原因可能是回程路由走偏了也可能是对端服务根本没有响应又或者中间某个设备把回包丢弃了。紧接着顺着这个方向去抓包很快就能定位到丢包节点。5.2 结合 NAT 场景看条目如果这台机器是通过网关做 SNAT 出网的连接跟踪表里看到的地址就不止一层。比如内网主机 10.10.10.5 访问 198.51.100.20:443经网关 SNAT 后源地址变成网关公网地址 203.0.113.100tcp 6 300 ESTABLISHED src10.10.10.5 dst198.51.100.20 sport40002 dport443 packets50 bytes4000 src198.51.100.20 dst203.0.113.100 sport443 dport40002 packets40 bytes9000 [ASSURED] mark0 use1注意回复方向的 dst 变成了 203.0.113.100而不是原始的 10.10.10.5这就是 NAT 在连接跟踪表里的痕迹。看到这种情况说明 SNAT 生效了反向包回来时网关能根据这条记录把地址翻译回内网地址。如果没有这条记录即使回包到了网关也会因为找不到映射关系被丢弃。排查 NAT 问题最常犯的错是只在内网主机上抓包看不到公网侧的地址转换。在网关上用连接跟踪表把两端的地址对应关系串起来整个链路就清晰了。5.3 用 conntrack -E 实时观察连接建立过程静态快照只能看到某一瞬间的状态想看连接是怎么一步步失败的用conntrack -E实时监控新事件conntrack -E -p tcp --dport 443命令会阻塞一旦有相关事件就实时打印。比如专门开一个终端跑这个命令另一台机器发起访问你就能看到 NEW、ESTABLISHED 分别在哪一步出现哪一步缺失。对排查连接建立被卡住的问题特别管用。配合ss -tnp使用效果更好ss看本机 socket 层的状态conntrack看防火墙层的状态。两边一对比就能分清问题是发生在协议栈内部还是防火墙转发的半路上。5.4 常见异常条目特征总结排查多了之后我发现异常连接跟踪条目其实就那么几类现象可能原因大量 SYN_SENT [UNREPLIED]回程路由问题、对端无响应大量 ESTABLISHED 但 bytes 几乎不增长连接挂死、客户端或服务端超时参数问题UDP 条目堆积超时太长、DNS/日志流量异常INVALID 状态条目连接已重置但表未及时清理、NAT 端口冲突表满 insert_failed 计数增长nf_conntrack_max 太小或超时太长每类问题对应的处理方向都不同。如果你看到表里全是ESTABLISHED且 bytes 还在稳定增长那防火墙基本没有锅问题大概率在应用层或链路质量上。6. 日常维护中我常用的几个小技巧检查连接跟踪表这件事最好在故障发生前就形成习惯。我自己的服务器上会放一个简单脚本每分钟把关键指标写进日志#!/bin/bash echo $(date %F %T) conntrack_count$(conntrack -C 2/dev/null || echo 0) max$(sysctl -n net.netfilter.nf_conntrack_max 2/dev/null || echo 0) insert_failed$(conntrack -S 2/dev/null | awk /insert_failed/ {print $2})这样哪天业务反馈异常先翻开日志看故障时间点的 conntrack 指标比事后猜原因靠谱得多。另外一个很实用的技巧是需要保存现场时直接导出快照到文件conntrack -L -o timestamp /var/tmp/conntrack_$(date %Y%m%d_%H%M%S).txt-o timestamp会显示条目创建时间帮助判断这些连接是什么时候建立的。排查长连接泄漏问题时这个参数能帮你找出那些在表里存活了几天甚至几周的僵尸条目。最后提醒一句在连接跟踪表上做的任何清空、删除操作都要格外谨慎。生产环境里宁可使用精准的-D参数删指定连接也不要顺手敲-F全清。我曾经见过有人在排查时图省事直接清空结果所有 NAT 会话瞬间全部失效在线业务集体闪断那时你才会真正感受到这张表到底有多重要。
