WiFi掉线日志里的reason码是什么意思？我照着表逐个查，5和34把两次掉线彻底破案了

上个月我把家里那台闪断的手机治好了，过程写在WiFi时断时续那篇里，翻日志看到deauth和重连成对出现，算是拿到了实锤。文末我说过一句：日志里deauth后面跟着的那串数字才是真线索。这阵子家里换了个房间布置，另一台手机又开始犯病，这回我不满足于「看到掉线记录」，把那串数字一个一个查了个底朝天——查完才知道，同样一行deauth，锅的方向能差出十万八千里。

先把那行日志摆出来。OpenWrt里敲logread | grep -i deauth，出来的东西长这样：

Mon Nov 2 21:41:18 2025 daemon.info hostapd: wlan0: STA a4:c6:xx:xx:xx:xx IEEE 802.11: disassociated
Mon Nov 2 21:41:18 2025 daemon.info hostapd: wlan0: STA a4:c6:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (reason 4)

STA后头那串是手机的无线网卡MAC地址，括号里的reason 4就是今天的主角。它是802.11标准里定义的「断开原因码」，谁发起断开、为什么断开，全编码在这一个数字里。路由器踢的手机，手机自己跑的，还有那种谁也没出错纯粹走流程的，数字都不一样。知道这个码，你就不用对着「手机老掉线」这种模糊描述瞎猜了。

先立个规矩：这数字指认的是「谁提的分手」，不一定是「谁的错」

查表之前先把这个观念掰正，不然容易冤枉人。deauth这行日志里的reason码，说的是这次断开由哪一方按什么理由发起，它记录的是流程，不是审判。路由器按规矩踢掉一个不说话的设备，日志写reason 4，这不代表路由器坏了；手机觉得信号烂主动切走，写reason 3或者34，也不代表手机有毛病。我一开始就吃过这亏：看到满屏reason 4，以为路由器在欺负手机，差点下单买新机器。

类比一下，这串数字像离婚协议上的「提出方」那一栏，写了谁提的、什么理由，但感情破裂的锅在哪边，得看理由本身。所以正确的用法是两步：先看数字定位是哪边发起的，再看理由判断该往哪边修。下面按我实际碰到的顺序，把家里最常见的几个码逐个过。

reason 4：设备闷不吭声被踢，九成是省电模式

reason 4的官方名字叫「不活动超时」。关联着的设备会定期发个小数据包报平安，行话叫keep-alive，手机尤其发得勤。路由器等了半天一个包都没等到，就判定这台设备失联了，把它从关联表里清出去。注意一个细节：清出去的时候手机多半还显示连着WiFi，图标满格，它自己都不知道已经被除名了，等到要发数据才发现得重连一遍。

我家出现reason 4最多的时候，是那台旧手机开着省电模式放床头充电。锁屏之后系统把无线网卡降到极低功耗，报平安的包能拖就拖，路由器等不到就踢。你要是在自己日志里数到一串reason 4且时间点集中在深夜，先别动路由器，把那台手机的WiFi省电开关关了试试，零成本。netsh wlan show interfaces在笔记本上也能看个大概，我在解读netsh输出那篇里写过。这块的原理跟「默认网关不可用」那阵的网卡省电捣鬼是同一套，翻网卡省电那篇有细账。

reason 3和15：一对双胞胎，一个手机提的一个路由器提的

这俩码名字一样，都叫「双方协商后离开」，区别在发起方。手机主动发deauth说我要走了，路由器记reason 3；路由器主动发deauth让对方走，手机记reason 15。15和3的分界就是判断「设备走」还是「路由器赶」的第一道线索。

reason 3在手机上最常见的触发就是漫游：手机觉得当前这台路由器信号不够好，或者搜到更合适的节点，先下线再上线。碰上Mesh组网的家庭，日志里3的比重天然高，属于正常代谢，量不大别管。但要是手机死抱着一个快没信号的节点不走，那是漫游黏性，是另一码事，我在漫游不切换那篇里拆过怎么治。真正要警惕的是扎堆的reason 15：那意味着路由器在成批踢人，改了密码、开了新的访问控制、或者进了重启流程都会这样。我那次折腾就是改密码当晚，日志里15刷了一整屏，第二天每台设备回来一趟，安静了。

reason 5和34：这俩把我家两次掉线彻底破案

到重点了。标题里说的两次破案，就是这两个码。

reason 34，官方名「缺乏确认帧」。无线传输里，手机发出去的每个数据包都要求路由器回一个很小的ACK确认帧，手机收到了才认为这个包送到。路由器连着好几个该回的ACK没回上，手机判定这段链路不可靠，自己发deauth走人。什么情况路由器会回不上ACK？多数是手机那头的信号其实已经烂到路由器听不清它说什么了——注意方向，34是手机嫌这条路差自己跑，但病根往往是双向的信号衰减。我家那台犯病手机的点位我后来拿去读了，稳定在-78dBm上下，临界线附近反复横跳，难怪34隔三差五出现。这个读数怎么看、低于多少算病，-65dBm那篇里有完整的挡位表。挪了路由器位置之后，-78变-66，34基本绝迹。

reason 5，官方名「AP过载」。路由器觉得自己忙不过来了，主动踢掉一部分设备减负。这个码我特意打电话跟开网吧的朋友求证过，他店里几十台机器时见过；家用一般碰不着。但有一种例外：家里挂着一台抢带宽的老设备时，路由器处理压力会集中放大，先看老设备拖慢全网那篇排查，别急着怀疑路由器本身。顺带一句，5偶尔混在别的码里零星出现可以忽略，成串出现才是真的过载。

一张表把常见码收拢，对号入座再动手

把我查过的和家里日志里真正出现过的码收成一张表，没碰到过的极冷门码就不列了，列了也是唬人：

用法说穿了就一句：先统计哪个码出现最多，再按「谁发起」那一栏决定往设备侧修还是往路由器侧修。满屏4往手机省电去，满屏3配扎堆时段往漫游去，成串15回头想自己改过什么，34就老老实实读信号。

数分布有个笨办法，比盯单行靠谱

单看一行deauth意义不大，掉线这事的真相藏在分布里。我的做法是把一晚上的日志抓下来数频次，OpenWrt一行命令就够：

logread | grep -o "reason [0-9]*" | sort | uniq -c | sort -rn

出来的就是一张频次表，比如我那晚是4出现23次、34出现9次、3出现2次——4和34两个码加起来占九成，省电加信号临界的组合拳，跟后来实测-78dBm、关省电后掉线立减的结论严丝合缝。频次表比肉眼扫日志强的地方在于，偶发的流程性掉线（1、2、7那种）会被自然稀释掉，真凶的码会自己浮上来。

数完频次别忘了对照时间戳。4集中在深夜、34集中在晚高峰信号挤的时候、15集中在某个具体时刻之后——时间规律跟码一交叉，锅基本跑不了。这套「先取证再动手」的路数，跟我在三段ping定位丢包那篇里写的是同一种思路：别看到掉线就重启就换机，先把证据链搭起来。

原厂路由器看不到码，怎么办

不是人人用OpenWrt。原厂固件的日志页多数只给「设备离线/上线」，不给码，这没办法，各家裁剪程度不一。将就着也有两条路。一是看行为侧写：锁屏后掉、点亮屏幕立刻回=大概率4（省电）；在某个房间掉、挪回客厅就稳=大概率34（信号）；全家同时掉=压根不是deauth层面的事，去查光猫和宽带。二是拿笔记本装个能翻无线日志的工具顶一晚，Windows事件查看器的WLAN-AutoSource里也留着断开记录，颗粒度虽粗，配着时间戳够交叉验证了。

还有一个容易踩的误区收尾提一嘴：日志里deauth的时间戳如果突然清零跳变，那不是手机掉线，是路由器自己重启了，事件等级比掉线高一级，先按家里断网五关排查的顺序从供电查起。看码先看表，动手前先数分布，这两步走完，大部分「手机老掉WiFi」的糊涂账都能算清楚。