VPN 总掉线：先测无线电，再查服务器

VPN 掉线可能在任何流量到达服务器之前很久就已开始。Wi-Fi 丢失、从 Wi-Fi 切换到蜂窝网络、本地接入点拥塞，以及手机休眠，都可能在隧道软件报告干净失败的同时中断外部路径。从设备向外走：先看链路，再看客户端自身的事件，然后做受控对比，最后才查服务器。这个顺序能避免你为了一个就在房间里发生的问题去换出口节点。

看链路，而不是信号图标

看链路切换，而不是信号格。接入点已经饱和、漫游切换正在进行，或者省电策略在熄屏时停掉无线电，此时设备仍可能显示很强的信号。

记录接口状态、当前网关以及每次变化的时间。然后检查掉线是否与那次切换吻合。手机在房间之间移动时每次都掉的，就是链路问题，除非能证明相反，无论应用显示的是哪个服务器。

读客户端自己的重连事件

大多数客户端会记录掉线原因和下一次尝试的时间戳。几秒内重新协商随后恢复的隧道，与一直断到你手动开关才恢复的隧道，是两种不同的事件。

反复出现短暂重连，指向外部路径，因为客户端不断够到服务器又丢掉会话。隧道持续断开则指向认证、端点变更或策略，因为客户端根本没走到会丢掉东西的地方。动配置之前，把这两种模式分开读。

谨慎比较第二个端点

第二个端点是有用的对比，但它本身不是受控实验。它会改变路由、基础设施，往往还改变国家，因此两个端点之间的差异并不能证明第一台服务器有故障。

把设备、接入网络和工作负载固定住，并记录切换时还有哪些变化。如果两个端点在同一时间同一地点同时失败，本地路径就是共同因素。如果只有一个失败，服务器或通往它的路由就成为主要线索。把混淆因素写下来，别让结论跑到证据前面。

和你实际运营的服务器做对照

如果你管理该端点，把尝试时间与监听和关联记录对照。多个互不相关的客户端在同一网关失败，与一部手机一移动就掉，是完全不同的证据。

一次对端响应并不能证明应用持续健康。恢复之后，要测你真正需要的那个资源，因为握手成功、服务器可达，完全可能与一条断掉的应用路径并存。

写下能缩小范围的报告

把四件事分开：本地链路丢失、外部可达性、隧道协商，以及应用自身状态。每一件都有自己的证据，把它们分开的报告会告诉下一个人该看哪里。

也要记录对比的局限。如果策略阻止了直连路径测试，就照说，而不要把端点对比当作证明。应用里的国家标签并不代表完整路由，地理位置很近的服务器同样可能要经过拥塞路径才能到达。

WireGuard 项目关于已知局限的页面提醒我们：协议可以是正确的，却仍把链路行为留给操作系统。下次掉线后再重跑同一套测试作为收尾，因为单个事件只是一个数据点，模式才是诊断。