VPN 应用崩溃了：终止开关还开着吗？

从用户看到的地方开始：客户端窗口没了，托盘图标消失了，浏览器或者能打开或者不能。仅凭这一点，你判断不了阻断是否还在。答案取决于规则由哪个组件持有、该组件是否随窗口一起死掉，以及平台是否把执行放在应用之外。从窗口查到进程，再查到防火墙，最后查到实际路径。

先别重启；重启通常会毁掉证据。

从仍在运行的东西查起

动手之前先打开进程列表。桌面客户端通常分成界面进程和一项服务或守护进程，前者崩溃不一定停掉后者。在 Windows 上服务可能还在列表里，在 Linux 上单元可能还处于活动状态，而在 Android 上一旦授予同意，隧道就归系统所有。按这个顺序读这三件事。

如果守护进程还活着，隧道大概率也活着，消失的窗口只是表面现象。

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

要从执行者读阻断，而不是从应用读

如果客户端是通过插入防火墙规则来实现终止开关的，那些规则属于操作系统，会活过创建它们的进程。此时崩溃会把你留在被阻断的状态里，却没有界面可以关掉它，看起来像网络坏了，而不是一种保护。反过来，如果阻断住在客户端自己的数据包路径里，杀掉进程就会在同一瞬间解除阻断。

Android 又是另一种处理方式：带 lockdown 的 always-on VPN 是平台设置，所以阻断独立于应用进程继续存在，系统还可能把服务重新拉起来。要了解确切行为，请查平台文档，而不是假定它和桌面客户端一样。

区分正常退出与崩溃

正常 Quit 通常走客户端自己的关闭路径，会主动删除规则并关闭隧道。崩溃跳过这条路径，把执行者已经装好的东西留在原地。差异体现在规则时间戳与进程退出先后上，也体现在是否还残留一个没有属主的旧隧道接口。

这个区别决定你怎么恢复：正常退出可能需要重新连接，而崩溃可能需要对残留下来的规则走客户端支持的修复操作来清除。

恢复时别破坏其他控制

按文档流程重启客户端，然后同时检查要求的两半：隧道在承载流量，阻断该生效时仍然生效。为了恢复连通性把整个防火墙清空，会连无关的控制一起删掉，这笔交换很少值得。

如果反复崩溃，收集客户端版本、平台构建号，以及厂商要求的那部分日志。崩溃报告不需要另一个账户的客户端配置、私钥或完整连接日志，把它们附上会把一次技术支持变成数据处理问题。

一次崩溃不是泄露的证据。证据是在客户端停掉的那一刻，观察到数据包从策略本应拦住的路径离开。要有意用一个无害的目的地测一次，并记下哪一层执行守住了。