ChatGPT/Codex 无法开启远程控制：Windows 虚拟网段冲突排查

问题现象

在 Windows 版 ChatGPT/Codex Desktop 中开启远程控制时，授权弹窗可以正常显示，但点击“允许”后，底部出现红色提示：

无法启用远程控制。请重试。

重启应用和电脑后问题仍然存在，说明故障不一定来自账号或授权按钮，还可能与 Windows 本机的网络路径有关。

原因：两张虚拟网卡使用了重叠网段

部分网络类软件会在 Windows 中创建虚拟网卡，并向系统路由表写入自己的地址范围。当电脑上安装了多个此类软件时，如果它们声明了相同或相交的虚拟网段，系统就可能把连接交给错误的接口。

本次排查发现，两张虚拟网卡同时涉及 198.18.0.0/16。远程控制建立连接时，目标地址恰好落在这个范围内，Windows 最终选择了另一张虚拟网卡，连接因此超时。

这就是问题的核心：

ChatGPT/Codex 本身能够正常启动，但远程控制连接在 Windows 路由阶段走错了虚拟网卡。

为什么 Windows 会选错路径

Windows 选择路由时会遵循“最长前缀匹配”规则，首先比较目标网段的前缀长度。前缀越长，匹配范围越具体，优先级通常越高。

例如，系统同时存在下面两条路径：

目标网段	对应接口	匹配范围
0.0.0.0/0	虚拟网卡 A	所有 IPv4 地址
198.18.0.0/16	虚拟网卡 B	198.18.*.*

当目标地址是 198.18.0.12 时，两条路径都能匹配，但 /16 比 /0 更具体，因此 Windows 会优先选择虚拟网卡 B。

这也解释了为什么普通网络访问可能正常，只有某个依赖长连接的功能持续失败：不同目标地址可能命中不同的路由规则。

如何确认是否存在虚拟网段冲突

首先查看电脑上的网卡，包括隐藏的虚拟接口：

Get-NetAdapter -IncludeHidden |
  Select-Object ifIndex, Name, InterfaceDescription, Status

然后查看 IPv4 路由表：

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, InterfaceIndex |
  Select-Object DestinationPrefix, InterfaceIndex,
    InterfaceAlias, NextHop, RouteMetric

如果已经知道异常连接对应的目标 IP，还可以直接查询 Windows 最终选择的路径：

Find-NetRoute -RemoteIPAddress 198.18.0.12

重点关注以下信息：

• DestinationPrefix：命中的目标网段；
• InterfaceIndex：系统选择的接口编号；
• InterfaceAlias：接口名称；
• NextHop：数据将被送往的下一跳。

再用接口编号对照网卡列表，就能确认这条路由由哪个本地软件创建。

处理思路

确认冲突后，可以根据实际使用场景选择一种处理方式：

1. 暂时停用不需要的虚拟网卡：适合快速验证。停用后重新查询最佳路由，确认目标地址不再走原来的错误接口。
2. 调整其中一方的虚拟地址范围：两个软件必须同时运行时，应选择不与现有路由、局域网、容器或虚拟机网络重叠的地址范围。
3. 重新加载网络状态：修改后重启相关网络组件和 ChatGPT/Codex，再刷新系统缓存。

不建议只凭网卡名称直接删除路由。很多路由由后台服务动态创建，下次启动时可能再次出现，而且误删企业网络路由还会影响其他业务。

修复后如何验证

处理完成后，建议依次确认：

• 原来的重叠路由是否已经消失或改由正确接口处理；
• Find-NetRoute 返回的接口编号是否符合预期；
• ChatGPT/Codex 能否成功启用远程控制；
• 手机端能否与电脑建立连接并完成一次实际操作。

只有应用实际启用成功，才能说明整个问题已经解决。单纯看到网卡状态正常或路由发生变化，还不能代替最终功能验证。

总结

这次 ChatGPT/Codex 无法开启远程控制，根因不是授权窗口本身，而是 Windows 多虚拟网卡之间出现了网段冲突。目标地址命中更具体的路由后，连接被交给错误接口，最终表现为超时。

遇到类似问题时，可以沿着下面的顺序排查：

目标地址 → 最佳路由 → 接口编号 → 虚拟网卡来源

只要确认目标地址实际进入了哪张网卡，就能判断问题是否来自虚拟网段重叠，而不必反复重装应用或盲目修改无关设置。