这类故障的特征很有辨识度：ping公网地址通、时延也正常，但网页半天打不开；或者微信能发消息、图片却发不出去；再或者晚高峰一到就大面积变慢，第二天早上又恢复正常。
遇到这种「协议层通、业务层不通」的组合，出口设备的会话表是要查的位置之一。
一、原理速览：为什么会话数会卡住上网
出口网关做NAT时，每一个「内网终端:端口 ↔ 公网地址:端口 ↔ 外部服务器」的通信都对应一条会话表项。设备能同时维护的会话数由规格决定（内存与软件能力共同约束）。
会话数接近或达到上限时的典型表现：
| 表现 | 原因 |
|---|---|
| 新连接建立缓慢或失败 | 无空闲会话表项 |
| 已建立的连接能继续用 | 老会话未被回收 |
| ping通但新请求超时 | ping属已有或轻负载路径，新建连接受阻 |
| 重启设备后恢复 | 会话表清空 |
这类现象与带宽不足的区别在于：带宽满时是所有流量都慢，会话满时是”老连接能用、新连接起不来”。
二、第一步：取当前会话数与规格上限
华为体系：
display nat session
display nat session statistics
display firewall session table statisticsLinux 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 -20conntrack -L | head确认列序； - 看目的端口分布：80/443为主说明是网页类，大量随机高端口且有固定对端，可能是P2P类应用；
- 看DNS请求量：DNS QPS高时即使会话数不高，也会拖慢上网体验；
- AP/AC或认证侧：按终端MAC反查具体设备，再确认该终端在跑什么应用。
高频成因：
- 视频客户端、云同步工具、下载类软件的后台连接；
- P2P类应用持续建立大量半开连接；
- 内网终端被恶意程序控制后对外发起大量连接；
- 单台终端开了大量浏览器标签与即时通信工具；
- 会话超时时间设置过长，导致表项回收慢。
四、第三步：排除其他同类现象
| 相似现象 | 区分方式 |
|---|---|
| 带宽跑满 | 出口流量曲线接近上限，所有业务均匀变慢 |
| DNS问题 | 域名解析失败或超时（见 DNS解析故障的排查与处理） |
| 地址池耗尽 | 终端拿不到地址（见 DHCP地址池耗尽与IP冲突排查） |
| 认证设备瓶颈 | 认证日志与审计设备告警 |
| 内网泛洪 | 内网端口广播与组播计数异常（见 交换机环路与广播风暴排查） |
判据要点：会话满时已建立的远程连接仍能维持，但新连接起不来；带宽满时则是所有流量一起变慢。
五、第四步：处理动作（按代价从低到高）
- 限制单终端会话数：按每IP设置连接数上限，避免单台终端吃满整表；
- 调整会话超时：把长时间无流量的连接（尤其是UDP与半开连接）超时时间调短，加快回收；
- 关闭不必要的UPnP：UPnP自动映射会额外占用表项，非必要场景建议关闭；
- 应用层管控：对P2P下载、视频客户端做限速或分时段策略；
- 分流：把大流量业务（如监控回传、备份）分流到其他链路或错峰执行；
- 扩容规格：当会话数确属业务正常增长时，按终端规模重新核算出口设备规格。
改前必做：导出当前配置并留档；限速与超时类策略先在单个测试网段试配，观察24小时业务表现后再推广。
六、验证与回退
| 动作 | 验证指标 |
|---|---|
| 单IP会话限制 | 会话总数下降，单终端不再异常增长 |
| 缩短超时 | 空闲会话数回落，业务无感知 |
| 关闭UPnP | 映射表项减少，无业务报障 |
| 应用限速 | 高峰会话数回到规格的合理区间 |
| 规格扩容 | 高峰会话数与上限之间留出明显余量 |
回退方式：保留原配置文件，策略类调整可整段还原；扩容需安排在低谷时段并保留原设备作为回退。
七、容量规划建议（避免复发）
- 按终端数估，不按房间数估：一间客房可能有电视、手机、平板、笔记本多台终端；
- 按业务类型分档：视频为主场景的单终端会话数明显高于纯办公；
- 留余量：按峰值并发核算，规格选择留出余量；
- 定期巡检：把会话数、CPU、内存纳入月度巡检项，趋势比单点数值更有价值。
八、避坑小结
- ping通不等于没问题，新建连接失败是会话满的典型表现；
- 会话数不高也可能是CPU或DNS问题，三者要同时看；
- 不要只靠重启解决，重启清空会话表只是临时缓解；
- 限速策略要分批验证，一次全量下发容易影响正常业务；
- 扩容前先算清楚是正常增长还是异常占用，避免为异常流量买单。
速查表：出口侧「时好时坏」
| 现象 | 优先排查 |
|---|---|
| 老连接正常、新连接起不来 | NAT会话数 |
| 所有流量均匀变慢 | 出口带宽利用率 |
| 域名解析慢、网页首屏慢 | DNS解析链路 |
| 部分终端完全拿不到地址 | DHCP地址池 |
| 重启后短期恢复 | 会话表或内存泄漏类问题 |
| 特定应用慢 | 应用限速策略或QoS |
山西东创伟业科技有限公司（2013年成立）与山西联通、山西电信、山西移动、山西广电渠道直连。地址：太原市小店区长治路139号大唐智能花园12幢1单元7层1号 ｜ 服务热线：400-666-8372 ｜ 官网：https://www.58120.net
