路由器连接数满了会怎样？挂BT那晚网页全打不开，NAT会话表这笔账我算明白了

上个月我给NAS的下载机加了一批保种任务，列表从三十来个涨到两百多个。第三天晚上十点，媳妇在卧室喊我：手机网页全在转圈，电视投屏也搜不到了。我拿她手机一看，怪就怪在微信消息还在一条条往外弹，视频号刷不动，网页打不开。

能收消息说明网没断，是「新连接建不起来」。重启路由器，全家立刻恢复。我以为完事了，结果第二天晚上十点上下，一模一样的症状又来了。这个「到点复发、重启复活」的规律，把我引到了一个绝大多数人从没听过的东西上——路由器的NAT会话表。

路由器里有本连接账本，写满了就拒客

家里每台设备上网，走的都不是「一根线」，而是一条一条的连接。手机刷一个网页，背后是DNS一条、网页服务器一条、图片和广告域名再好几条。路由器做NAT转发时，每条连接都得在内存里记一笔：谁的内网IP、从哪个端口出去、连到对面的哪个IP哪个端口、走的TCP还是UDP。这笔记录就叫一条NAT会话，也叫连接跟踪条目，Linux系统里管它叫conntrack。

这本账本有两个要命的属性。第一，页数是有限的，路由器内存多大、厂家给多少，出厂就定了。一条记录约占300字节内存，听着不多，可两百多MB内存的家用机，刨去系统占的，留给账本的空间折算下来普遍就几千到一万出头。华硕的中高端型号算厚道的，规格页直接印着NAT会话数16384或32768条；多数百元机压根不标这个数，你问客服都答不上来。第二，一笔账不是连接断了立刻销。TCP连接断开后，条目要按超时时间才从表里清走，UDP这类无连接的更是发一包记一笔，靠超时慢慢过期。车走了车位还得等管理人员来放牌，就是这个意思。

账本写满的那一瞬间，路由器的动作很直白：新来的连接，不记了，丢包。所以已经建立的老连接继续活着（微信那个长连接就是这么幸存的），一切要新建连接的请求全部石沉大海。这也解释了为什么重启路由器百试百灵——重启把整本账清空，车位全空出来，当然立刻恢复。

为什么挂BT最容易把账本写爆

我家正常状态下的连接数，晚高峰全家四五十台设备在线，也就一千五六百条，这个数字我后来在软路由上亲眼看到过，跟之前写内存那篇时对得上。问题出在保种上。

BT的连接模型天生是连接数黑洞。一个种子不是连一台服务器，是同时连几十个peer各拿一小块；两百多个种子一起做种，连接是乘着上去的。我当时为了让上传量好看，还把qBittorrent里的全局最大连接数从默认的500改成了2000，单种子上限也放开了，纯属火上浇油。再加上两笔隐性账：一是DHT，客户端自己维护一张几百上千节点的路由表，节点间的UDP通信一笔笔全记在账上；二是每个种子的tracker要定期汇报进度，两百多个种子各带两三个tracker，又是几百条短会话在那儿反复刷。TCP这边断开的连接还要在表里躺够超时时间才腾位置，进得快出得慢，账本想不满都难。

后来我在软路由上看到过保种全开时的实时数字：连接跟踪条目一万五上下，UDP占了七成。而这个量，恰好就是我那台256MB内存的AX3000T扛不住、换了好几倍的量级。顺便说一句，这事跟「路由器能带多少台设备」是两个维度——带机量说的是无线侧能挂多少台机器，会话数说的是转发侧能同时记多少条连接，62台设备怎么瘦身那篇讲的是前者，今天这篇是后者，两个都超了，症状还不一样。

三个特征，先确认是不是这个病

连接数满表的故障长得很有辨识度，但跟普通断网、WiFi卡顿容易搅在一起。我总结成三个特征，全中基本就是它：

注意跟另外两种情况区分：如果是全家彻底断网、微信也不走了，往光猫和宽带侧查，突然断网那篇的分诊顺序更对症；如果只有一台设备卡、别的都好，那是无线侧的事，跟连接数没关系。还有个加分项能帮你实锤：关掉家里最可疑的那台设备——我关了NAS的下载机，十来分钟后全家自己恢复了。源头一掐，表里的条目陆续超时释放，不重启也能活，这就是连接数满表独有的「自愈」。

想看自家账本还剩多少空位，两条路

品牌路由器的后台基本不给看会话数，这事有点遗憾，但也不是完全没招。

第一条路，路由器刷了OpenWrt或者本身是软路由的，直接看数字。SSH登进去敲两行：

cat /proc/sys/net/netfilter/nf_conntrack_count

cat /proc/sys/net/netfilter/nf_conntrack_max

第一行是当前条目数，第二行是上限，前者贴着后者就是快满了。低内存设备默认上限可能只有4096或16384，大内存机器常见65536。OpenWrt网页管理界面的「状态-实时曲线」里也有活动连接数曲线，挂着看半小时，谁在兴风作浪一目了然。系统日志里要是翻到「nf_conntrack: table full, dropping packet」这行字，那就是路由器亲口承认丢包了，铁证。

第二条路，品牌机没处看数字，用掐源对照法。把你怀疑的设备挨个断网或关后台，每关一个等十分钟看全家恢复没有，恢复了就是它。我那晚就是这么锁定NAS的。Windows电脑上还可以用netstat -ano数一下本机当前连接数做参照——单台电脑正常也就一两百条，要是某台机器自己就挂着一两千条，八成是它身上的某个软件在搞事。

处置四招：先管大户，再动配置

确认是连接数满了，按这个顺序来，从治本到换机器：

第一招，管住下载软件。qBittorrent里「工具-选项-连接」，全局最大连接数限到300上下，每个种子最大连接数给40到80，上传槽位四到八个足够。保种党可能心疼上传量，实测限到300对我这种两百多个种子的列表，上传几乎没掉，路由器先活过来了，这笔账怎么算都划算。这套设置的完整来龙去脉在NAS下载机那篇里写过。

第二招，揪出隐形连接大户。头号嫌疑是电视盒子和视频App里的「P2P加速」开关——它拿你家宽带的上传去帮平台分发视频，本质上就是一台BT机，连接数哗哗地涨。我表弟家查出来就是它，盒子上的视频App开着P2P加速，关掉之后他家路由器再没半夜罢工过。摄像头云存上传、网盘同步也是同类，挂的设备多了可以对照智能家居那篇的设备构成挨个排查。

第三招，软路由用户直接扩表。8GB内存的N100，把上限调到26万条也就多占七八十MB内存，毫无压力。命令是sysctl -w net.netfilter.nf_conntrack_max=262144，想重启不丢就写进/etc/sysctl.conf。UDP超时也可以从默认30秒压到15秒，DHT这类短会话不再常驻。小内存机器别乱调，表本身也吃内存，256MB的机器硬扩只会把内存挤爆，那还不如直接看下一招。

第四招，换机器。这不是玩笑——如果家里常年有保种、多摄像头、P2P加速关不掉这类刚性连接需求，百元机就是扛不住，这不是设置能救的。选型时盯两点：内存256MB起步、规格页敢标会话数的优先。为什么大内存才有大表、转发这件事CPU和内存怎么分工，CPU那篇和DHCP那篇正好凑成一套。

收尾给个排查顺序：症状三特征对号→掐源对照锁定大户→管下载软件连接数→关P2P加速→软路由扩表→实在不行换大内存机器。别学我一开始的反应——差点打报修电话让师傅上门，人家测一圈光衰一切正常，白跑一趟还欠个人情。