大文件上传时 VPN 断开：先读队列

隧道一整天都稳定，可一旦开始大文件上传就断开。交互请求最先卡住，客户端报告超时，传输结束后连接又恢复。这一现象指向排队和处理，而不是远端服务器宕机，因为服务器根本没机会及时回应。要做的是在受控负载下复现，并读对计数器。

每次运行只改一个变量，并保持端点不变。

搭建可重复的负载对比

在链路空闲时记录基线：往返时延、几个应用请求，以及隧道自身的事件日志。然后开始一次已知大小的上传，并在其运行期间重复完全相同的测量。端点、客户端和测试目标都不要动，因为同时改两项什么也说明不了。

留意哪个事件先出现。任何错误之前往返时延就上升，说明在排队；时延稳定却出现硬超时，说明是别的原因，比如密钥轮换或账户操作。两种模式导向不同的下一步。先写下观察，再动手改动。

把输出带时间戳保存下来，好让有负载与空闲的两次运行逐行对比。

读队列，而不是读速度

家用链路会在运营商设备里缓存分组，上行队列满了就会拖慢一切，包括维持隧道存活的小控制分组。报告高数值的测速几乎说明不了这种延迟，所以空闲时测速通过，而饱和链路失败。

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

把有负载的延迟数字与空闲时对比。丢包为零却从几十毫秒跳到几百毫秒，就是排队；延迟稳定却出现丢失，则指向别的故障。

检查设备与控制路径

加密和转发都要消耗处理器时间，小型路由器或散热受限的笔记本在忙时可能丢包。看总体负载，而不是单个进程的百分比，因为内核转发和中断处理并不出现在大家常看的地方。

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

客户端超时也可能与计划内的密钥轮换或会话策略事件重合。要按事件顺序排查，读客户端自己的日志，而不只看应用的报错。

只改一处，再复测

在平台支持的地方，限制上传速率，或把批量流量归类到交互流量之下，让队列永远不满。然后重复同样的工作负载，比较同样的三个数字。改善了测速却仍留下超时的改动，什么都没修好。

一律调高超时、削弱加密，是两种让症状消失却说不清哪条边界失效的做法。两者都不是修复。它们都把故障推到更晚、更难归因的地方。

最后测试一个新请求，以及用户真正依赖的重连行为。在引发投诉的那种负载下保持稳定，才是唯一值得记录的结果。