九月初，宿舍的网络开始毫无规律地掉线。
正打着游戏、正看着视频，网络突然就断了。打开认证页面重新登录，页面上跳出来一个数字：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 是「结果」，不是「原因」。 真正的问题是：服务端为什么要拆掉我的会话？
结合公开的防共享检测资料，服务端会基于一段时间内的流量画像来估算 NAT 后面有多少台设备，用的指标包括：
当这些特征让它判断「这一个账号后面藏着多台设备」时，就会触发踢线。
针对这些检测维度，我一层层地补上了防御：
| 检测维度 | 应对手段 |
|---|---|
| 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，最后成了我最好的网络课老师。
]]>