结论先行:问题不是 ChatGPT,不是代理软件,甚至不是网络本身------是我机器上 VMware 卸载后留下的一个残破桥接协议组件,它让 Windows 再也创建不出任何新的虚拟网卡。而 ChatGPT 桌面版的 app-server websocket 恰恰依赖全流量 TUN 隧道才能绕过校园网的 DNS 污染和 SNI 阻断。链条一环扣一环,断点却在最想不到的地方。
症状
ChatGPT 桌面版(Store 版,主进程 ChatGPT.exe)每次启动都要「重新连接」好几次才勉强能用。查应用日志(~/.codex/logs_2.sqlite),里面是对 wss://chatgpt.com/backend-api/wham/remote/control/server 的无限重连,清一色 os error 10060(连接超时),历史上从未成功过一次。
这层原因很快定位:这个 websocket 是应用 Rust 内核直连 的,不读系统代理(聊天 Tab 是 webview,走系统代理所以正常)。而校园网环境里,chatgpt.com 被 DNS 污染 100%(解析到 Twitter/Facebook 假 IP),即使拿到真 IP,SNI=chatgpt.com 的 TLS 握手也有约 90% 概率被 RST。
结论:必须让应用的全部流量进隧道------即 yepfast(Flutter + mihomo 内核的代理客户端)的 TUN 模式。
第一层墙:TUN 网卡永远创建不出来
TUN 开关一直是开的,内核也以 SYSTEM 身份跑着(yepfastHelperService 服务拉起的),但系统里从来没有出现过 TUN 网卡。setupapi.dev.log 里有个诡异的现象:内核每 15 秒对同一个设备 SWD\WINTUN\{A654C402-...} 执行一次"Delete Device",每次都失败:
! dvi: Query-and-Remove failed: 0x05: CR_INVALID_DEVNODE而唯一一次完整的设备安装日志显示,驱动安装本身成功了(驱动包入 DriverStore、wintun.sys 落盘、服务创建),但设备启动时卡住:
! dvi: Device 'SWD\WINTUN\{A654C402-...}' pending start:
Device has problem: 0x38 (CM_PROB_NEED_CLASS_CONFIG)0x38 的意思是"设备等待类配置"------对网卡来说,就是网络类安装器(netclass)还没来得及给它分配 NetCfgInstanceId、在系统里登记成一块真正的网卡。类配置不完成,设备就是一块僵尸。
第二层墙:僵尸节点删不掉
顺着常规思路先清残留:删设备节点、删 NetClass 键、sc delete wintun、pnputil 移除驱动包,然后让客户端重装。结果遇到一个离谱的事:
那个僵尸设备节点,连管理员权限都删不掉。 提升的 PowerShell 里 reg delete 报"删除请求已部分完成",Remove-Item 报"子项不存在"------但 Test-Path 明明说键还在。最后祭出杀招:建一个 SYSTEM 身份的计划任务去执行删除,秒删。ACL 显示 Administrators 有 FullControl,但就是删不动,怀疑是驱动类安装的中间态把节点锁住了。
清干净后让客户端全新重装驱动------还是 0x38,一模一样。到这里排除了"残留导致失败"的假设,说明类配置失败是系统性的。
转折点:一个 NTSTATUS 和一次巧合的搜索
重看安装日志,失败后设备状态是:
! dvi: Device Status: 0x01802400 [0x1c - 0xc0000490]用 RtlNtStatusToDosError 解码 0xC0000490,得到 Win32 错误 1169 = ERROR_ELEMENT_NOT_FOUND(「元素没有与指定的值匹配的项」)。这是 NetCfg 网络配置接口的经典报错。
搜索这个错误码,撞到一条几乎量身定做的已知问题:Windows 11 Build 26200 系列上,VMware Bridge Protocol 状态异常会破坏网络设备类安装流程,导致任何新的虚拟网卡都无法创建------症状原文"客户端进程正常、端口正常监听,但 Get-NetAdapter 里永远没有 TUN 网卡",和我的机器一字不差。
对照我的机器,两条全中:
- 系统版本正是 10.0.26200
- 装了 VMware Workstation,而且------查证发现
C:\Windows\System32\drivers\vmnetbridge.sys和E:\vmnetbridge.dll都已经不存在了 !这是 VMware 被半卸载(或某次清理误删)留下的状态:桥接协议的注册表组件还在网络栈里,其Ndi配置写着ComponentDll: vmnetbridge.dll,还有一个通知对象 CLSID{3d09c1ca-...}。Windows 每次做网络配置变更(包括创建新网卡)都会去加载这个组件,DLL 没了,整个 INetCfg 操作随之失败------于是所有新网卡,包括 wintun,全部胎死腹中。
vmnetbridge 服务最后一次启动的退出码是 2(文件不存在),就是铁证。
修复
摘除这个残破组件(它本来就已损坏,而且没绑定任何网卡):
- 删协议组件键
HKLM\SYSTEM\CurrentControlSet\Control\Network\{4d36e974-...}\{49444745-4252-4554-79AC-EA6CADE4227F}及其 Descriptions 条目 - 删残破服务
Services\vmnetbridge - 删通知对象 CLSID
{3d09c1ca-2bcc-40b7-b9bb-3f3ec143a87b} - 全量备份后操作,随后在 yepfast 里切一次 TUN(关→开)
网卡一次创建成功:
Name: yepfast | yepfast Tunnel | Status: Up | 198.18.0.1/30
默认路由 0.0.0.0/0 → 198.18.0.2 (metric 0) # 全流量进隧道验证
重启 ChatGPT 桌面版,查应用日志:
12:20:11 remote control websocket status changed
previous_status=Errored → next_status=Connected历史首次 Connected,之后零断线、零重连。界面上的"重新连接"提示彻底消失。
几点教训
- 「半卸载」比「卸载」危险得多。 软件卸载不干净不是小事------残留的注册表组件 + 丢失的 DLL,能让操作系统层面的功能(这里是网络设备类安装)整体瘫痪,而且症状出现在完全不相干的软件(ChatGPT)上。
- 错误码要一路解码到底。
0x38只是"设备没配好"的表象,0xC0000490 → 1169 ELEMENT_NOT_FOUND才指向 NetCfg 层,再结合 Kernel-PnP 事件日志(Event 400/420)和 build 号,才锁定了那个已知问题。 - 常规排查工具链 :
setupapi.dev.log(设备安装全流程)、pnputil(驱动包管理)、Kernel-PnP/Configuration 事件通道、RtlNtStatusToDosError解码 NTSTATUS,再配合有针对性的搜索------这套组合拳这次帮了大忙。 - 顽固的僵尸设备节点,试试 SYSTEM 计划任务。 管理员权限不等于万能,有些系统中间态只认 SYSTEM 本人。
*附:本次修复全程由 Claude Code 协作排查,备份与可复用的修复脚本保留在 C:\Users\22842\scripts\(fix-vmware-bridge.ps1 幂等可重跑)。若日后重装/卸载 VMware 后 TUN 再次罢工,大概率是同一个坑。