这类故障的特征很有辨识度：ping 公网地址通、时延也正常，但网页半天打不开；或者微信能发消息、图片却发不出去；再或者晚高峰一到就大面积变慢，第二天早上又恢复正常。在东创伟业处理过的酒店与办公网络里，这种“协议层通、业务层不通”的组合，出口设备的会话表是要查的位置之一。
一、原理速览：为什么会话数会卡住上网
出口网关做 NAT 时，每一个“内网终端:端口 ↔ 公网地址:端口 ↔ 外部服务器”的通信都对应一条会话表项。设备能同时维护的会话数由规格决定（内存与软件能力共同约束）。
会话数接近或达到上限时的典型表现：
新连接建立缓慢或失败：无空闲会话表项；
已建立的连接能继续用：老会话未被回收；
ping 通但新请求超时：ping 属已有、轻负载路径，新建连接受阻；
重启设备后恢复：会话表清空。
这类现象与带宽不足的区别在于：带宽满时是所有流量都慢，会话满时是“老连接能用、新连接起不来”。
二、第一步：取当前会话数与规格上限
华为体系：
display nat session
display nat session statistics
display firewall session table statistics
Linux iptables 体系：
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
或者：
conntrack -L | wc -l
判读：
当前值 / 上限 大于 80%：进入警戒区间，需进一步分析；
接近上限：新连接失败的直接原因基本可确认；
会话数不高但 CPU 高：方向转向 CPU 与日志审计性能。
同时记录 CPU、内存利用率，避免把“CPU 打满”误判成“会话打满”。
三、第二步：找出占会话的终端与应用
- 按内网地址统计会话数（Linux 示例）：
conntrack -L | awk '{print $5}' | sort | uniq -c | sort -rn | head -20
不同版本输出列位置不同，需先跑一条 conntrack -L | head 确认列序； - 看目的端口分布：80、443 为主说明是网页类，大量随机高端口且有固定对端，可能是 P2P 类应用；
- 看 DNS 请求量：DNS QPS 高时即使会话数不高，也会拖慢上网体验；
- AP、AC 或认证侧：按终端 MAC 反查具体设备，再确认该终端在跑什么应用。
高频成因：
视频客户端、云同步工具、下载类软件的后台连接；
P2P 类应用持续建立大量半开连接；
内网终端被恶意程序控制后对外发起大量连接；
单台终端开了大量浏览器标签与即时通信工具；
会话超时时间设置过长，导致表项回收慢。
四、第三步：排除其他同类现象
相似现象区分：
带宽跑满：出口流量曲线接近上限，所有业务均匀变慢；
DNS 问题：域名解析失败或超时（相关排查另篇展开）；
地址池耗尽：终端拿不到地址（相关排查另篇展开）；
认证设备瓶颈：认证日志与审计设备告警；
内网泛洪：内网端口广播、组播计数异常（相关排查另篇展开）。
判据要点：会话满时，已建立的远程连接仍能维持，但新连接起不来；带宽满时则是所有流量一起变慢。
五、第四步：处理动作（按代价从低到高）
- 限制单终端会话数：按每 IP 设置连接数上限，避免单台终端吃满整表；
- 调整会话超时：把长时间无流量的连接（尤其是 UDP 与半开连接）超时时间调短，加快回收；
- 关闭不必要的 UPnP：UPnP 自动映射会额外占用表项，非必要场景建议关闭；
- 应用层管控：对 P2P 下载、视频客户端做限速或分时段策略；
- 分流：把大流量业务（如监控回传、备份）分流到其他链路或错峰执行；
- 扩容规格：当会话数确属业务正常增长时，按终端规模重新核算出口设备规格。
改前必做：导出当前配置并留档；限速与超时类策略先在单个测试网段试配，观察 24 小时业务表现后再推广。
六、验证与回退
单 IP 会话限制：验证会话总数下降、单终端不再异常增长；
缩短超时：验证空闲会话数回落、业务无感知；
关闭 UPnP：验证映射表项减少、无业务报障；
应用限速：验证高峰会话数回到规格的合理区间；
规格扩容：验证高峰会话数 / 上限留出明显余量。
回退方式：保留原配置文件，策略类调整可整段还原；扩容需安排在低谷时段并保留原设备作为回退。
七、容量规划建议（避免复发）
按终端数估，不按房间数估：一间客房可能有电视、手机、平板、笔记本多台终端；
按业务类型分档：视频为主场景的单终端会话数明显高于纯办公；
留余量：按峰值并发核算，规格选择留出余量；
定期巡检：把会话数、CPU、内存纳入月度巡检项，趋势比单点数值更有价值。
八、避坑小结
- ping 通不等于没问题，新建连接失败是会话满的典型表现；
- 会话数不高也可能是 CPU 或 DNS 问题，三者要同时看；
- 不要只靠重启解决，重启清空会话表只是临时缓解；
- 限速策略要分批验证，一次全量下发容易影响正常业务；
- 扩容前先算清楚是正常增长还是异常占用，避免为异常流量买单。
速查：出口侧“时好时坏”
老连接正常、新连接起不来，优先查 NAT 会话数；
所有流量均匀变慢，优先查出口带宽利用率；
域名解析慢、网页首屏慢，优先查 DNS（相关排查另篇展开）；
部分终端完全拿不到地址，优先查 DHCP 地址池（相关排查另篇展开）；
重启后短期恢复，优先查会话表或内存泄漏类问题；
特定应用慢，优先查应用限速策略或 QoS。
常见问题（FAQ）
Q：NAT 会话数上限一般怎么估算设备规格？
A：按终端数与业务类型估算，而不是按房间数或人数。做法是统计实际并发终端数，再按业务类型取单终端会话经验值（视频与下载类应用明显高于普通办公），两者相乘后留出余量。已有网络可直接读取高峰时段的实际会话数作为基准，按增长趋势推算未来一到两年的需求。
Q：缩短会话超时会不会影响正常业务？
A：可能影响长连接类业务，比如远程桌面、VPN、即时通信的心跳连接。做法是先区分协议：TCP 已建立连接与 UDP 流使用不同的超时策略，缩短的是长时间无流量的空闲表项，而不是活跃连接。调整后需要观察业务侧反馈一到两天再固化。
Q：为什么重启出口设备后网络就恢复正常了？
A：重启会清空会话表与缓存，会话打满、内存泄漏、表项残留这类问题会随之消失，所以表现为“重启就好”。但这是临时缓解，不是处理完成。正确做法是重启后立即开始采集会话数、CPU 与内存曲线，定位是规格不足、策略不当还是异常流量导致，再按原因处理。
