VPN 已关闭却仍然很慢：检查适配器绑定

客户端显示已断开，隧道接口已经消失，但日常流量仍比安装 VPN 之前更慢。一种解释是某个过滤器组件在隧道关闭后仍绑定在物理适配器上。这是一条值得核查的线索，而不是结论：同样的缓慢也可能来自驱动程序版本、卸载（offload）设置或第二个客户端的组件。在改动任何东西之前，先盘点实际连接了什么。

给组件命名，记录它的状态，然后只改一件事。

把隧道与绑定分开

VPN 接口和过滤器驱动是不同的对象。隧道关闭时接口会消失；绑定在物理适配器上的过滤器会安装进网络栈，并且可以不受隧道状态影响而保持启用。用户看到的是一个症状，操作系统保存的却是两份互不相关的状态。

正是这一区别，使得拔出客户端或删除 VPN 配置文件往往什么也改变不了。接口是可见的对象。绑定位于协议栈更深处，寿命也比接口更长。

盘点精确的组件

列出承载慢速流量的适配器上的绑定，使用它的真实名称，而不是泛泛猜测。记录组件 ID 和启用状态，然后把物理适配器与 VPN 接口以及列表中的其他虚拟适配器进行比较。

版本信息也应记在同一条记录里，因为两台显示名称相似的机器可能运行不同的驱动程序。供应商也可能用旧的显示名称发布新的过滤器组件。比较标识符，而不是名称标签。

Get-NetAdapterBinding -Name 'Ethernet' -AllBindings | Select-Object DisplayName,ComponentID,Enabled
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverVersion,Status
Get-NetAdapterStatistics -Name 'Ethernet'
pnputil /enum-drivers | Select-String -Pattern 'vpn|filter|ndis' -Context 0,2
driverquery /v | Select-String -Pattern 'vpn|filter'

写下适配器名称、组件 ID、驱动程序版本和 VPN 客户端版本。没有这四个值，下一次比较只能靠猜。把它们附在工单上，以便日后运行能与这一次对比。

只改一处已批准的地方，然后重复

用相同的工作负载、目标和接入网络建立基线。记录 VPN 是否断开、可疑绑定是否启用、是否安装了第二个 VPN 客户端，因为两个客户端都可能留下组件。

如果供应商支持为诊断而切换该绑定，就只在那块适配器上禁用那个组件，重复相同的工作负载，然后恢复原状。来自单一变量的前后对照，比把所有东西重装一遍更有价值。如果结果不明确，先恢复原状，再尝试下一个假设。同时改两处，得到的数字谁也无法归因。

然后重新连接，确认 VPN 仍然可用，包括客户端本应执行的任何策略。一项改动若改善了浏览却破坏了隧道自身的策略执行，那就是用一种故障换另一种故障，这种回归应当记入记录。

停留在供应商支持的路径上

过滤实现会随产品代际而变化。一些供应商现在记录的是 Windows Filtering Platform 路径，而早期版本使用的是另一类驱动，因此旧论坛帖子里的注册表配方对已安装版本可能完全错误。

把已安装清单和当前生效路径分开检查，因为选择更新的模式并不能证明旧组件已经消失。需要清理时，执行供应商支持的卸载或更新流程，然后再重复一次绑定清单。

让证据保持狭窄：适配器、组件、版本、受控对比以及 VPN 回归结果。这样足以支持关于驱动或兼容性的结论，而不必把每一次慢速连接都变成 MTU 实验，也不必声称所有 VPN 客户端的行为都一样。