间歇性 VPN 掉线：每次该记录什么

间歇性掉线首先是数据采集问题，其次才是配置问题。每次发作都要记录同样的字段，否则事件无法比对。每次故障后改三项设置，会毁掉你手上唯一的证据。

下面的流程每次故障大约两分钟，每个事件产出一行记录。它假定你只在你所管理的设备上拥有只读权限。

在第一次故障之前把字段定下来

趁一切还正常就把字段表定好，因为故障中途临时拟定的模板总会漏掉一列。开始用五个字段就够：带时区偏移的本地时间、触发条件、断在哪一阶段、错误的原文，以及重试是否成功。

触发条件值得单独定义一套词：空闲、休眠唤醒、切换网络、负载突增、凭据轮换、未知。未知就标成未知，不要事后凭记忆补。最有价值的是阶段字段，因为它记录的是链路在哪一步停住，而不是用户的感受。错误原文要逐字抄下来，因为转述会丢掉两个相似错误码之间的区别。

空着就让它空着。强迫填写答案的模板只会招来编造，而编造的背景比空白更糟。

故障当下记录同样那五项事实

每次都按同样的顺序跑同样的命令。两分钟的输出胜过托盘图标的一张照片，而后时间戳对不上时，顺序就有意义了。

date -Is
journalctl -u wg-quick@wg0 --since "-2 min" --no-pager
wg show wg0 latest-handshakes transfer
ip route get 203.0.113.10
ping -c 3 -W 2 192.0.2.1

第一行用偏移量为这次观测打上时间戳，这是把三个不同时区的来源对齐的唯一办法。日志摘录覆盖服务生命周期，握手那一行说明对端到底有没有回应。路由查询指出某个具体目标会走哪个接口，这与接口是否存在不是同一件事。对隧道地址做 ping 只说明有没有东西越过链路，不说明对端是否可达。

每个事件在连续日志里写一行，只写这些字段，别的不写。攒到五六条之后，先按触发条件排序，再按阶段排序。模式会以重复成对的形式出现，而从不重复的那一对多半只是巧合。

定位断在哪一阶段

本地连通性、对端状态、路由和名称解析在不同地方出问题，各自留下不同的痕迹。如果接口存在却没有路由指向它，问题出在本地策略。如果接口还起着、握手时间戳却不再前进，问题在上游。

名称解析也要进同一份记录。周一跟着隧道走、周二跟着本地网走的解析器，会在应用层制造看起来随机的故障。

获授权的服务器访问，要关联同一次尝试，而不是附近的一次重连。保留原始时间戳，把任何偏移单独记下来，因为就地换算会抹掉换算本身的证据。一次尝试、一组时间戳、一个结论。

每次只比一个条件

受控对比只改一个有意义的条件，把失败的那次和成功的那次放在一起看。把设备换到另一个网络，或者关掉一条例外，同一步里别的都不要动。

失败的那次也要留在记录里。为了让位给成功那次而删掉它，等于扔掉你正在寻找的那条边界的唯一证据。

分享摘录，而不是整份配置

发送之前，先去掉密码、令牌、私钥、无关的身份信息和载荷。完整配置文件是配置机密，而不是连接摘要，不该出现在工单里。

把摘录连那五个字段一起发过去，并说明你认为哪一阶段失败。这样管理员可以去看你指出的那条边界，而不是翻一堆掉线图标的截图。如果边界仍不清楚，下一步是再做一次受控记录，而不是再改一次设置。