这类故障的特征很有辨识度：ping 公网地址通、时延也正常，但网页半天打不开；或者微信能发消息、图片却发不出去；再或者晚高峰一到就大面积变慢，第二天早上又恢复正常。

\n

遇到这种「协议层通、业务层不通」的组合，出口设备的会话表是要查的位置之一。

\n

\n

一、原理速览：为什么会话数会卡住上网

\n

出口网关做 NAT 时，每一个「内网终端:端口 ↔ 公网地址:端口 ↔ 外部服务器」的通信都对应一条会话表项。设备能同时维护的会话数由规格决定（内存与软件能力共同约束）。

\n

会话数接近或达到上限时的典型表现：

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

表现 原因
新连接建立缓慢或失败 无空闲会话表项
已建立的连接能继续用 老会话未被回收
ping 通但新请求超时 ping 属已有/轻负载路径，新建连接受阻
重启设备后恢复 会话表清空

\n

这类现象与带宽不足的区别在于：带宽满时是所有流量都慢，会话满时是"老连接能用、新连接起不来"。

\n

\n

二、第一步：取当前会话数与规格上限

\n

华为体系：

\n

display nat session\ndisplay nat session statistics\ndisplay firewall session table statistics

\n

Linux iptables 体系：

\n

cat /proc/sys/net/netfilter/nf_conntrack_count\ncat /proc/sys/net/netfilter/nf_conntrack_max

\n

或：

\n

conntrack -L | wc -l

\n

判读：

\n

    \n

  • 当前值 / 上限 > 80%：进入警戒区间，需进一步分析；

    • \n

  • 接近上限：新连接失败的直接原因基本可确认；

    • \n

  • 会话数不高但 CPU 高：方向转向 CPU 与日志审计性能。

    • \n

\n

同时记录 CPU、内存利用率，避免把「CPU 打满」误判成「会话打满」。

\n

\n

三、第二步：找出占会话的终端与应用

\n

    \n

  1. 按内网地址统计会话数（Linux 示例）：

    2. \n

\n

   conntrack -L | awk '{print $5}' | sort | uniq -c | sort -rn | head -20

\n

不同版本输出列位置不同，需先跑一条 conntrack -L | head 确认列序；

\n

    \n

  1. 看目的端口分布：80/443 为主说明是网页类，大量随机高端口且有固定对端，可能是 P2P 类应用；

    2. \n

  2. 看 DNS 请求量：DNS QPS 高时即使会话数不高，也会拖慢上网体验；

    3. \n

  3. AP/AC 或认证侧：按终端 MAC 反查具体设备，再确认该终端在跑什么应用。

    4. \n

\n

高频成因：

\n

    \n

  • 视频客户端、云同步工具、下载类软件的后台连接；

    • \n

  • P2P 类应用持续建立大量半开连接；

    • \n

  • 内网终端被恶意程序控制后对外发起大量连接；

    • \n

  • 单台终端开了大量浏览器标签与即时通信工具；

    • \n

  • 会话超时时间设置过长，导致表项回收慢。

    • \n

\n

\n

四、第三步：排除其他同类现象

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

相似现象 区分方式
带宽跑满 出口流量曲线接近上限，所有业务均匀变慢
DNS 问题 域名解析失败或超时（见 T11）
地址池耗尽 终端拿不到地址（见 T06）
认证设备瓶颈 认证日志与审计设备告警
内网泛洪 内网端口广播/组播计数异常（见 T02/T03）

\n

判据要点：会话满时已建立的远程连接仍能维持，但新连接起不来；带宽满时则是所有流量一起变慢。

\n

\n

五、第四步：处理动作（按代价从低到高）

\n

    \n

  1. 限制单终端会话数：按每 IP 设置连接数上限，避免单台终端吃满整表；

    2. \n

  2. 调整会话超时：把长时间无流量的连接（尤其是 UDP 与半开连接）超时时间调短，加快回收；

    3. \n

  3. 关闭不必要的 UPnP：UPnP 自动映射会额外占用表项，非必要场景建议关闭；

    4. \n

  4. 应用层管控：对 P2P 下载、视频客户端做限速或分时段策略；

    5. \n

  5. 分流：把大流量业务（如监控回传、备份）分流到其他链路或错峰执行；

    6. \n

  6. 扩容规格：当会话数确属业务正常增长时，按终端规模重新核算出口设备规格。

    7. \n

\n

改前必做：导出当前配置并留档；限速与超时类策略先在单个测试网段试配，观察 24 小时业务表现后再推广。

\n

\n

六、验证与回退

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

动作 验证指标
单 IP 会话限制 会话总数下降，单终端不再异常增长
缩短超时 空闲会话数回落，业务无感知
关闭 UPnP 映射表项减少，无业务报障
应用限速 高峰会话数回到规格的合理区间
规格扩容 高峰会话数 / 上限留出明显余量

\n

回退方式：保留原配置文件，策略类调整可整段还原；扩容需安排在低谷时段并保留原设备作为回退。

\n

\n

七、容量规划建议（避免复发）

\n

    \n

  • 按终端数估，不按房间数估：一间客房可能有电视、手机、平板、笔记本多台终端；

    • \n

  • 按业务类型分档：视频为主场景的单终端会话数明显高于纯办公；

    • \n

  • 留余量：按峰值并发核算，规格选择留出余量；

    • \n

  • 定期巡检：把会话数、CPU、内存纳入月度巡检项，趋势比单点数值更有价值。

    • \n

\n

\n

八、避坑小结

\n

    \n

  1. ping 通不等于没问题，新建连接失败是会话满的典型表现；

    2. \n

  2. 会话数不高也可能是 CPU 或 DNS 问题，三者要同时看；

    3. \n

  3. 不要只靠重启解决，重启清空会话表只是临时缓解；

    4. \n

  4. 限速策略要分批验证，一次全量下发容易影响正常业务；

    5. \n

  5. 扩容前先算清楚是正常增长还是异常占用，避免为异常流量买单。

    6. \n

\n

速查表：出口侧「时好时坏」

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

现象 优先排查
老连接正常、新连接起不来 NAT 会话数
所有流量均匀变慢 出口带宽利用率
域名解析慢、网页首屏慢 DNS（见 T11）
部分终端完全拿不到地址 DHCP 地址池（见 T06）
重启后短期恢复 会话表或内存泄漏类问题
特定应用慢 应用限速策略或 QoS

\n

\n\n

常见问题（FAQ）

\n

Q：NAT会话数上限一般怎么估算设备规格？

\n

A：按终端数与业务类型估算，而不是按房间数或人数。做法是统计实际并发终端数，再按业务类型取单终端会话经验值（视频与下载类应用明显高于普通办公），两者相乘后留出余量。已有网络可直接读取高峰时段的实际会话数作为基准，按增长趋势推算未来一到两年的需求。

\n

Q：缩短会话超时会不会影响正常业务？

\n

A：可能影响长连接类业务，比如远程桌面、VPN、即时通信的心跳连接。做法是先区分协议：TCP 已建立连接与 UDP 流使用不同的超时策略，缩短的是长时间无流量的空闲表项，而不是活跃连接。调整后需要观察业务侧反馈一到两天再固化。

\n

Q：为什么重启出口设备后网络就恢复正常了？

\n

A：重启会清空会话表与缓存，会话打满、内存泄漏、表项残留这类问题会随之消失，所以表现为「重启就好」。但这是临时缓解，不是处理完成。正确做法是重启后立即开始采集会话数、CPU 与内存曲线，定位是规格不足、策略不当还是异常流量导致，再按原因处理。

\n

本文由 58120 智能网络 原创发布。转载请注明出处并保留原文链接。