一只 QQ 机器人的掉线编年史：监控瞎了、假在线、风控与两次登录死法
一、起因：2 核 2G 的机器，和一条太松的验收标准
一台 2 核 2G 的云主机，跑一个协议端加一个机器人进程：协议端负责登录，机器人负责回话。装好、扫码、在测试群里发一句"你好"，它回一句"你好"——验收通过，收工。
问题就出在这条标准上："它能回我话"是一次性判定，通过之后没人再验证，也没法证伪。10:53 它死掉时，我手上没有任何信号。
二、第一次事故：哑了 72 分钟，因为监控本身就是瞎的
10:53，机器人在群里不说话了。我是 12:05 才发现的，中间七十二分钟——而监控一直在正常运行：每分钟查一次，准时发现掉线、准时告警、准时失败。
10:53:01 掉线
10:53:01 监控检测到掉线，尝试推送 → 失败
11:03:01 第 1 次自动重启协议端 → 失败
11:13:01 第 2 次自动重启 → 失败
11:23:01 第 3 次自动重启 → 失败
11:53:01 发出"仍处于离线"告警 → 又失败
12:05 我自己发现的前四行是脚本日志，最后一行是我：脚本比我先知道，但它没法告诉我。
原因很蠢：告警走协议端接口发私聊，图省事。它有个致命前提——我想通知你的时候，出问题的那条通道还在。QQ 掉线时那个端口一并失效：发通知要接口，接口要 QQ 在线，而 QQ 正好是坏的那个。通知和故障是同一个东西，这是架构问题，不是配置。
另两个错误更隐蔽。以为重启能自愈：三次全败，日志清一色"登录态已失效"再卡在"需要验证码"——快速登录靠旧登录态换新票据，票据被吊销就必然失败。以为告警能"恢复后补发"：可补偿依赖"能恢复"，这次恢复不了，补偿永不触发。
三、更深一层：接口说 online，其实内核已死
推送修好后的第三天，机器人又不回消息了。这次微信没响，说明监控认为一切正常。
查状态：在线，端口在监听，长连接也是 ESTAB。但随手发一条测试消息，回来的是 EventChecker Failed，指向消息服务本身——发消息根本没执行。协议端日志里，某个时间点之后再没出现过一条"接收"记录。收发双向都断，只剩外壳挂着。
监控只查了状态字段、端口、长连接，因为最容易查。可 online 表达的是"登录流程走完了"，不是"消息通道能用"——正常时一致，异常时分离。
所以要发一次真需要内核响应的请求：get_status 只读字段，get_login_info 要内核算，假在线时返回不了正常数据。判定从两态变三态——都通是在线，status 不通是离线，status 通而内核不通是假在线，告警提示重启协议端。
假在线比真掉线危险：真掉线端口关了谁都能发现，假在线表面指标全正常，只有真有人发消息、真在意"为什么没回"时才暴露。它专挑你以为一切正常的时候坏。
四、二维码一直显示过期，不是手慢
那次要扫码重登：我拉一张码发过去，扫了，过期；再拉一张，还是过期；连续三张全过期。
第一反应是操作太慢，压缩传输耗时再来一轮，还是过期。查文件时间戳才发现：生成于 14:47，当前 14:54，七分钟没更新过。不是手慢，是那张码根本不会再变了。
它本该每百来秒换一张，但刷新循环在某个时刻静默退出了，没报错没日志，文件停在原地。我每次"拉取最新二维码"拿到的都是同一个死文件——拉的是文件，不是生成过程。重启服务，新码立刻生成，扫码一次成功，前后不到一分钟。
值得记的是排查顺序：我一开始假设是用户侧问题，优化了一圈传输链路，全是白费。症状在使用者一端、病因在生产者一端，先得问"这东西还在被生产吗"。
五、掉线的真实代价：重启就是一次登录尝试
机器人上线第一天被平台强制下线五次，日志清一色"登录已失效"，最短的一次只活了二十分钟。
先排除自身：内存 525MB / 1.7GB 宽裕，网络通，密码没变、手动登录正常，单实例，进程活着。剩下的只有平台侧——机房出口上跑非官方客户端，风控盯上了。
而有个变量是我自己造成的：那天为了排查，我重启了六七次协议端。每次重启都是一次新登录、一次风控评估。下午掉线间隔从四十分钟缩到二十分钟，大概率和我频繁的"抢救"有关——越救越糟，这是真实存在的正反馈。
风控看的不只是"你是什么"，更是"你做什么"：收消息读列表风险低，群里回复看频率，批量加好友是黑产动作，发说说、改资料是高风险。真人发说说有一串前置行为——打开空间、浏览、停留、编辑、发布；程序直接调发布接口，没有这条链，在风控眼里就是"无来源的写请求"，恰是养号的标准动作。我一周最多发三条、内容还有审核，但风控不看内容，只看行为模式。
于是关掉发说说，群里回复、偶尔发图、复读机保留：那些是"聊天"，说说那是"广播"。改完掉线频率会降但不会归零——机房出口加非官方协议端在风控眼里永远可疑。搬家之前策略就一条：少动、少登、少写公开内容。
六、登录的两种死法，和为什么自动重登是错的
一天之内两次掉线，都提示"需要重新登录"，处理方式却完全不同——区分不了就会在错误的路上浪费时间。
第一种：密码改了。报错写密码已修改，快速登录跟一句登录态失效，再跳"需要验证码"。本质是凭据失效：密码不匹配，旧票据也不被承认。更新凭据即可，下次重启自己登回来，这次从掉线到恢复用了十八分钟。
第二种：登录态被吊销。报错是下线通知加"登录态已失效"，密码没变、凭据没问题，是平台主动把会话作废了。三条自动路全堵死：
| 路径 | 结果 | 原因 |
|---|---|---|
| 快速登录 | 必败 | 拿旧登录态换新票据，旧的已作废 |
| 密码回退 | 卡在验证码 | 凭据没错，平台要再验一次"你是不是人" |
| 扫码 | 唯一出路 | 走的是另一条独立授权通道 |
这次掉了将近一小时，因为走了弯路：脚本反复试密码，每次都撞验证码墙。而那些尝试不只白费——每次失败都在加重风控，撞几次后平台上调等级，下次连扫码都可能多一道验证。
两种死法共用同一个表象"登录失败，请重新登录"——只看表象就会用同一套流程，把需要人工介入的事交给脚本硬撞。
七、现在的做法：只告警，不硬闯
核心改动一句话：删掉自动重启，只告警。登录态失效时重启没用，还会加重风控。正确做法是收到告警、等十到三十分钟冷却期、人工扫码——等待很反直觉，但实测有效：立刻重登会被踢得更快。
告警必须走独立通道：一个第三方推送服务，走 HTTP 接口，不依赖任何本地服务。这一步是决定性的，它把"能不能通知到你"从概率问题变成确定问题。坑是这类服务多半要实名，未实名每日额度 0 次，密钥拿到了也发不出去。
告警还得带操作入口：光说"掉线了"没用，脚本会从协议端日志抓出扫码授权和短信验证两条链接塞进告警，手机上点一下就能验证。更隐蔽的坑是推送发出去了我没收到——服务端在密钥为空时把新密钥私聊发给发起登录的那个身份，机器人发给自己，自聊不进对话列表，日志却显示"发送成功"。
八、三句话教训
验收标准要能证伪。 通过一次就没人再验证的东西等于没有标准；标准得是能持续、自动、独立打出来的信号。
监控要打在消息链路上，不是端口上。 端口、进程、状态字段最容易查，却不是最该查的；探活要主动发起并有明确返回。
不要跟风控博弈。 频繁重启、反复试密码、无来源的写请求，每一条都在把这个号推向更严的那一档。有时候最好的抢救，是不抢救。
