设备都连着Wi-Fi，新网页却偶尔打不开：NAT表满了还是运营商限制会话数？

家里的手机、电脑和摄像头都显示在线，正在播放的视频没有立刻中断，但新打开的网页转圈，App重新登录也失败。重启路由器后暂时恢复，过一段时间又出现。这种现象和普通Wi-Fi掉线并不一样。

设备仍连着Wi-Fi、已有视频也能播放，新网页和新连接却频繁失败时，问题可能落在家中路由器的连接跟踪表，也可能出在运营商CGNAT或出口策略。

先看故障设备是否仍显示已连接，再记录IP、默认网关和DNS。设备掉回169.254地址，或者连网关都ping不通，应先查DHCP、无线关联或AP。网关稳定可达，而新网站和新TCP连接失败，才继续看NAT会话和宽带出口。

故障发生时查看：

1. 记录设备IP、网关和DNS
2. 连续ping默认网关
3. 测试一个已有连接和一个新连接
4. 比较有线设备是否同时异常

有线、无线设备同时出现新连接失败，范围通常在主路由或运营商出口。只有某个房间的无线设备异常，则更像AP、回程或覆盖问题。

NAT设备会为每个连接保存状态。下载、短视频、P2P、摄像头云连接和异常重试都可能快速增加会话数量。表接近上限时，已经建立的连接可能继续传输，新连接却无法创建。普通家用路由器未必展示完整计数，OpenWrt等系统可以查看conntrack当前值与上限。

路由器支持时查看：

1. 查看连接数或会话数页面
2. OpenWrt读取nf_conntrack_count
3. 读取nf_conntrack_max
4. 查找持续建立大量连接的终端

当前数长期贴近上限，先停掉下载器、P2P或异常设备，再观察新网页是否恢复。数量很低时，不必为了这个方向盲目调大上限。

找出是谁在制造大量连接

一个终端就能制造成千上万条短连接。下载软件、端口扫描、感染恶意程序的设备、频繁重试的智能家居和配置错误的代理都值得检查。按终端暂停比一次重启全网更容易定位。路由器没有统计功能时，可以先从近期新增设备和高流量设备排起。

逐个暂停这些对象：

1. BT或多线程下载任务
2. 云盘与大量小文件同步
3. 异常离线又反复重连的IoT设备
4. 自建服务的扫描与代理程序

暂停某台设备后，路由器无需重启便恢复新连接，说明这台设备的连接行为需要调整。所有终端都正常，继续检查公网地址与运营商侧限制。

家庭宽带拿到100.64.0.0/10、10.0.0.0/8等共享地址时，IPv4流量通常还会经过运营商CGNAT。运营商可能设置会话数量、超时和异常流量策略。申请公网IPv4后恢复，不一定只是“有了公网地址”，也可能同时绕开了原来的共享NAT路径。

在路由器WAN页核对：

1. 记录WAN IPv4地址
2. 与公网查询地址比较
3. 确认是否位于100.64.0.0/10
4. 记录开通公网前后的故障变化

WAN地址与外网查询地址不同，说明中间还有一层NAT。申请公网IP前可先把故障时间、设备数量和连接类型提供给运营商，避免只描述成“网速慢”。

提高conntrack上限会占用更多内存，低配路由器可能因此更不稳定。更合理的做法是处理异常终端、缩短不合理的长超时、更新固件，或者换用能够承载实际连接量的主路由。修改系统参数前保存原值，改完观察内存与CPU。

处理顺序建议：

1. 先停异常终端或应用
2. 更新路由器固件
3. 保存conntrack原值后再调整
4. 恢复正常负载并观察半天

新连接恢复、CPU和内存没有持续升高，才算修改可用。重启一次后正常几分钟，不能说明会话问题已经消失。

Wi-Fi图标只能证明设备仍与AP关联。故障时若网关可达、已有视频继续，而新网页与新登录失败，应把注意力转到新连接建立过程。

重启会清空大量临时状态，也会重新拨号并改变运营商侧路径。需要比较重启前后的会话数、WAN地址和异常终端，不能仅凭恢复时间判断。

连接跟踪记录会占用内存。低配设备在会话压力之外又增加内存压力，可能出现管理页卡顿、进程被杀或整机重启。

会话限制与带宽不足表现不同。提供故障时间、WAN地址、同时在线设备、新旧连接差异和重启后的维持时间，更容易让对方查到共享NAT或出口策略。

DNS异常通常影响域名解析，但直接访问IP、新建TCP连接和App登录的表现未必相同。先比较网关、域名解析和新连接，避免换DNS掩盖会话问题。

这类故障最有价值的对照，是“旧连接继续、新连接失败”。确认该特征后，再比较路由器会话数、异常终端和WAN地址，通常比连续重启更快找到方向。