我和校园网 146 错误斗了两个月

一切从频繁掉线开始

九月初，宿舍的网络开始毫无规律地掉线。

正打着游戏、正看着视频，网络突然就断了。打开认证页面重新登录，页面上跳出来一个数字：146。

没有解释，没有说明。能查到的只有「请稍后再试」。

更要命的是，这不是偶发——最严重的时候，一天能被踢下来 5 次以上。时间也不固定，有时是深夜，有时是下午，完全摸不着规律。

我决定搞清楚它到底是什么。

第一个误区：以为是「设备太多」

最初的猜测很朴素：是不是我连的设备太多了？

手机、电脑、平板都走同一个账号，直觉上像是被「多端登录」挤下来的。于是开始减设备、关后台、甚至怀疑是某个硬件坏了。

没用。该掉还是掉。

后来我翻了大量校园网认证系统（dr.com / eportal）的资料才意识到，错误码 146 在任何公开文档里都查不到定义。厂商的错误码表里有电信侧的 221xxxxx、移动侧的 RDxxx，唯独没有 146。

这意味着靠猜是没用的，只能靠自己取证。

开始搭取证系统

既然没有现成答案，那就把每次踢线的现场都记录下来。

我在宿舍的迷你主机（GK41）上做了这么几件事：

1. 踢线抓拍（kickcap）

写了一套监控，一旦检测到 146，就立刻把当时的网络状态、连接表、日志全部打包存档。每一次踢线都留下一对证据：检测瞬间 + 重新登录的完整回合。

2. 统一日志归集

把所有网络日志集中写到 /var/log/146/，按时间切片，方便事后回溯。

3. 长期频率统计

用 journald 里的 kickcap 记录做配对去重，得出踢线的真实频率，而不是凭感觉。

这一步最关键的收获是：人的感觉会骗人，但数据不会。 攒了几十份快照之后，规律才慢慢浮现。

推翻自己的结论

排查过程中，我不止一次得出错误结论，然后被新的数据推翻。

有一段时间统计下来「54 小时零踢线」，我以为问题解决了，在报告里写了进去。结果报告定稿 56 分钟后，又被踢了。

类似的事发生了好几次。我逐渐学会了一件事：

样本太少时，任何「规律」都可能只是巧合。两次踢线都落在 :16 分，不代表有什么周期机制——那可能纯粹是偶然。

146 到底是什么

综合几十份取证数据，我对 146 的理解是这样的：

它更像是会话被服务端主动拆除后，重新认证时给出的一个阻塞应答，而不是某个具体的「错误」。

换句话说，146 是「结果」，不是「原因」。 真正的问题是：服务端为什么要拆掉我的会话？

结合公开的防共享检测资料，服务端会基于一段时间内的流量画像来估算 NAT 后面有多少台设备，用的指标包括：

DNS 查询数量、TCP SYN 新建连接的速率
同一出口 IP 下的 TTL、IPID、TCP 指纹是否「跳变」
明文 HTTP 里的 User-Agent 是否出现多种系统
TCP timestamp 的时钟偏移能否聚类出多台主机

当这些特征让它判断「这一个账号后面藏着多台设备」时，就会触发踢线。

我做的防御

针对这些检测维度，我一层层地补上了防御：

检测维度	应对手段
TTL 不统一	nftables 统一改写为固定值
User-Agent 暴露多系统	部署 UA3F 做 UA 终结改写
明文 DNS 噪声大	切换到加密 DNS（dnscrypt），大幅降低查询离散度
踢线后无法恢复	watchdog 自动检测 + 冷却 + 自动重登
规则意外丢失	nft 自愈脚本每 5 分钟检查重建

其中有个意外发现：我之前挂着的几个公共 DNS 兜底上游（114.114.114.114、119.29.29.29）质量极差，**重试率高达 80%~95%**。dnsmasq 的多上游并发重试机制，反而抬高了 DNS 查询离散度和新建速率——这恰好就是 146 的两个风控指标。

砍掉这些劣质上游后，踢线率明显下降。

结果

经过两个月、上百次取证，踢线频率从最严重时的 5.2 次/天，降到了 **0.9 次/天左右，降幅约 82%**。

更重要的是，剩下的踢线 100% 由 watchdog 自动恢复——冷却 5 分钟、重新登录，全程不需要人工干预。很多时候我甚至感觉不到自己被踢过。

最后的话

我必须诚实地说：146 无法被「根治」。

公开资料里没有任何能彻底绕过校园网共享检测的通用方案。只要还是一个账号带多台设备，「同一出口存在多种系统特征」这个事实就抹不掉。我能做到的上限，是把触发频率压到足够低，并让每一次踢线都自动愈合。

但这个过程本身，比「解决问题」更有价值。

我学会了用数据而不是直觉下判断，学会了在样本不足时保持怀疑，也亲手搭起了一套从检测、取证到自愈的完整系统。

那串冷冰冰的 146，最后成了我最好的网络课老师。