M 网关假活 17 天：重启好不了的故障，和一套凭证态判别的笨办法

卡住我的不是网关挂了，是重启完一秒就重新过期。进程活着、会话死了——故障分层判别法和能抄的体检提示词都在下面，改改就能用。

1. 起点：最后一条消息停在 9 月 25 日

我给自己搭了个 AI 微信助手：常驻网关桥接消息，AI 负责自动回复，定时任务的日报也从这条主通道投递，企业微信通道作副线。9 月 25 日 09:09，主通道进来最后一条真实消息，之后一片安静。

第一判断很朴素：网关进程出问题了，重启。动作本身没选错，错在把它当成了全部手段。

2. 第一个坑：Connected 是假消息

把 10 月 11 日深夜半小时的网关日志摊开：73 条日志里，微信条目全是同一对组合的循环——23:39 Connected，一秒之后 Session expired; pausing for 10 minutes；23:49、23:59 各来一轮。每 10 分钟重试一次，连上，立刻过期。

进程层体检项却全绿：CPU 稳定在 5% 上下，端口在监听，日志在滚动。一个「健康」的进程，收发全是死路。

误导性表象：Connected 像好消息，重启像生效了。

朴素判别法：别看状态词，数节拍。真恢复的 Connected 后面跟着消息收发；凭证态的 Connected 后面一秒内必跟 Session expired。节拍比状态词可信。

根因一句话：故障不在进程层，在凭证层。 网关手里攥着一份过期的会话凭证，重试一百次也是拿废票进场。23:39 那次重启就是对照实验：新进程、新端口，Connected 一秒后照旧过期，重启这条恢复路径当场证伪。

教训一句话：重启修的是进程态，修不了凭证态。

3. 方法论：先问故障住在哪一层

把接入类服务拆成三层，恢复动作一目了然：

接入服务故障分层速查（恢复动作跟层走，配错层越勤快越白费）
─────────────────────────────────────────────
进程层  指纹：进程消失 / 端口没了 / 日志停滚
        恢复：重启，秒级生效
资源层  指纹：磁盘写满 / OOM 记录 / 写入报错
        恢复：清理、扩容
凭证层  指纹：Connected 后秒级 expired / 缓存 mtime 齐冻 / 发送报会话超时
        恢复：重新认证——唯一动作是人工
─────────────────────────────────────────────
判别顺序：先进程（端口在不在）→ 再资源（磁盘内存）→ 最后凭证（节拍加缓存指纹）

进程层和资源层的指纹好认，凭证层还有个更硬的判别：缓存三件套的文件时间。会话缓存停在 9 月 25 日 11:59，上下文文件停在同日 09:09，凭证文件停在 6 月 28 日——三个本该随消息滚动的文件同时冻结。进程层故障不会让所有写入一起停，只有身份失效才会。节拍判别用十几行就够，可以直接抄：

from pathlib import Path
from datetime import datetime

def judge(log_path):
    """Connected 与 Session expired 的秒差判故障层，时间戳格式按自家日志调整"""
    events = []
    for line in Path(log_path).read_text(encoding="utf-8", errors="ignore").splitlines():
        try:
            t = datetime.strptime(line[:19], "%Y-%m-%d %H:%M:%S")
        except ValueError:
            continue
        if "Connected" in line:
            events.append((t, "up"))
        elif "Session expired" in line:
            events.append((t, "dead"))
    gaps = [(b[0] - a[0]).total_seconds()
            for a, b in zip(events, events[1:]) if a[1] == "up" and b[1] == "dead"]
    n = sum(g < 5 for g in gaps)
    return "凭证层：秒级连爆 x%d" % n if n else "非凭证层，或无配对样本"

4. 第二个坑：深睡是猜的，重燃是等的

10 月 1 日凌晨，我据窗口静默判了一次「深睡实锤」：一个多小时零条目，该死透了。1 点 58 分，日志里又冒出一轮 Connected，判定当场作废。翻全天记录才看清：凭证过期后适配器不是匀速重试，是间歇重燃——单日三次，0 点 10 分、1 点 58 分、4 点 43 分，间隔 1 小时 48 分到 2 小时 44 分不等，没有固定节拍。

教训一句话：凭证态的「彻底死了」不可跨周期外推。 判死要两个硬指纹同时成立：重试节拍消失，加缓存全冻结。「这轮没动静」只够写「本轮静默」，够不上判死。

5. 兜底：唯一恢复动作是人工的

凭证层的恢复路径只有一条：重新扫码登录。诊断一晚完成，修复动作只要五秒，中间却隔了 17 天——唯一的钥匙在一个人手里。这 17 天系统靠两条纪律撑住：告警走副通道（企业微信全程正常，提醒推送都从它走）；重启停手（每轮都白费，还制造假信号）。主通道发送侧报 -14 会话超时，定时日报全被挡回；二维码当晚推了两次，等人扫。

下面这段体检提示词可以直接抄进值守清单：

你是我的接入服务值守审计员。对指定网关执行凭证态体检，按序输出：
1. 进程与端口：进程存活、端口监听、CPU 平稳——全绿只代表进程层健康，不作结论
2. 日志节拍：统计窗口内 Connected 与 Session expired 的配对和秒差；秒级连爆即凭证层签名
3. 缓存指纹：列出会话缓存、上下文、凭证三类文件的修改时间；同时冻结超过一天即深睡嫌疑
4. 发送报错：检索会话超时类错误码；出现即确认发送通道被阻断
5. 结论三选一：进程层故障（建议重启）/ 资源层故障（建议清理扩容）/ 凭证层故障（唯一恢复动作=重新认证，需人工）
禁止把「重启有效」写进凭证层结论；重启建议只对进程层成立。

分工判断：无人值守系统里，进程态和资源态都能自愈，唯独凭证态的自愈必须留人工通道——告警要发到「能扫码的那个人」，而且要走活着的通道，不是发到已经过期的那个。

6. 总结

三条判断：

1. 接入类故障先分层再动手：进程层重启、资源层清理、凭证层重认证。动作配错层，越勤快越白费。
2. 状态词不可信，节拍可信：Connected 后秒级 expired 就是废票进场；缓存三件套同时冻结是身份失效的硬签名。
3. 无人值守的告警要冲着「唯一恢复动作」设计：恢复靠人，告警就必须送到人手里的活通道上。

最难修的故障不是进程死了，是进程活着、会话死了——进程的命，机器能救；会话的票，只能人续。