VPN 上 RDP 冻结：输入仍可用，所以要测传输层

当画面不再更新、鼠标却仍在远程桌面上滑动时，显而易见的结论是 VPN 掉线了。这个结论通常是错的。输入仍然有效的冻结画面说明会话与其输入通道都还活着，这把故障推向图形传输，而不是路由或凭据。两个快速观察就能把用户用同一个词描述的三种故障分开。

冻结没有告诉你的事

远程桌面通过 TCP 3389 承载输入和屏幕更新，当前的 Windows 客户端还能为流中图形较重的部分增加一条 UDP 传输。在会分片或丢弃较大数据报的隧道上，可靠通道继续承载按键，图形通道却停滞。结果就是画面卡住、键盘仍有反应的奇怪组合。这也解释了为什么重连有时能缓解症状一分钟，之后又复发。

断开后重连的会话是另一种故障，完全打不开的会话是第三种。先给形态命名，就不会去测错层。

用两条命令分开这三种故障

排除可达性很便宜。先从客户端测 RDP 端口，再在主机上读取会话状态。

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

TCP 测试失败说明会话从未打开，所以应把它当作防火墙、作用域或服务问题，而不是冻结。在活动会话下测试成功，则确认控制通道存在，这正是画面冻结的情形。用有权查看会话的账户执行主机查询，因为权限错误看起来就像空列表。记下会话 ID 和状态，因为断开却仍保留 ID 的会话与活动会话并不相同。

关掉 UDP 传输再比较

如果只有显示停滞，就一次只改一项来比较客户端传输。内置客户端与 Store 客户端不共享同一套栈，下面的策略会把 UDP 从内置客户端上移除。

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

值为 1 表示该客户端的 UDP 已关闭，所以在这个设置下仍然冻结就不是 UDP 路径问题。值缺失时，启用策略、重连，并精确重复之前冻结的那次操作。不要合并两项改动，而要把 Store 客户端作为单独一步来测，否则你不知道是哪一项起了作用。把客户端版本记进笔记，因为传输行为在不同 Windows 版本间变过。

只有一台主机冻结、其余正常时

在其余健康子网中只有一台主机失败，说明问题不在隧道。动 VPN 设置之前，先检查路径 MTU 和远程显示栈。

ping -f -l 1472 rdp-host.example.com

有回应证明路径能在该尺寸下不分片地承载全尺寸数据包，而带禁止分片标志的失败则说明隧道的 MTU 需要留意。如果 1472 字节能通过、且只有那台主机冻结，就去看它的显卡驱动和负载，而不是网络。向同一台机器快速复制文件说明的是吞吐，不是 RDP 图形通道。每次只改一个变量，并重复同一个屏幕操作，比较才有意义。

如果会话根本打不开，就停在这里，因为那是可达性问题而不是冻结。否则保留改变了症状的传输设置，并连同客户端版本一起记录。