ChatGPT/Codex 无法开启远程控制？一次 Clash TUN 与 aTrust 网段冲突排查实录

关键词：ChatGPT 远程控制、Codex Desktop、Clash Verge Rev、TUN、Fake-IP、Sangfor aTrust、Windows 路由冲突

问题现象

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

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

图 1：允许设备控制电脑时提示"无法启用远程控制，请重试"

最开始我按照常见思路处理：重启 Clash 服务、关闭再开启 TUN，并把 TUN Stack 从 mixed 切换成 system。这些操作都正确，但问题仍然存在。

真正的原因并不是账号、权限或代理节点失效，而是电脑上同时存在 Clash Mihomo 和 Sangfor aTrust 两张虚拟网卡。它们使用了同一个网段，Windows 把 ChatGPT 的 Fake-IP 流量送错了地方。

先说结论

Clash 的 DNS 使用 fake-ip 模式，默认地址池为：

yaml 复制代码

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

与此同时，Sangfor aTrust VNIC 在 Windows 中建立了下面这条路由：

text 复制代码

198.18.0.0/16 -> 2.0.0.4 -> Sangfor aTrust VNIC

当 chatgpt.com 被 Clash 解析成 198.18.0.12 后，Windows 会优先匹配更具体的 /16 路由，把连接送入 aTrust，而不是 Mihomo TUN。结果就是普通代理仍然可用，但远程控制使用的 WebSocket 长连接一直超时。

如果必须同时使用 Clash 与 aTrust，解决办法是把 Clash Fake-IP 地址池改到当前系统没有占用的网段。本机检查后选择了：

yaml 复制代码

dns:
  fake-ip-range: 198.19.0.1/16

修改并重启后，chatgpt.com 已解析为 198.19.0.4，不再命中 aTrust 的 198.18.0.0/16 路由。

198.19.0.1/16 是根据本文电脑的实际路由表选择的。其他电脑修改前也要检查网段是否被 VPN、WSL、Docker 或其他虚拟网卡占用。

请求究竟走错在了哪里

正常情况下，TUN 模式的请求链路应该是：

flowchart LR A[ChatGPT/Codex] --> B[Clash DNS] B --> C[Fake-IP 地址] C --> D[Windows 路由] D --> E[Mihomo TUN] E --> F[代理节点] F --> G[ChatGPT 远程控制服务]

发生冲突后，链路变成：

flowchart LR A[ChatGPT/Codex] --> B[chatgpt.com = 198.18.0.12] B --> C[Windows 路由匹配 198.18.0.0/16] C --> D[Sangfor aTrust VNIC] D --> E[连接超时]

这也解释了一个很容易误判的现象：浏览器和普通 HTTPS 请求看起来能用，远程控制却始终打不开。不同组件并不一定使用同一套代理入口；系统代理能处理一部分应用流量，但不等于 TUN 路由已经正确。

常规操作为什么没有解决

排查时已经确认：

Clash Verge 主程序正在运行；
clash_verge_service 服务为 Running；
verge-mihomo 内核正在运行；
Mihomo 虚拟网卡状态为 Up；
System Proxy 已指向 127.0.0.1:7897；
TUN 已开启；
auto-route、auto-detect-interface 和 strict-route 均已开启；
TUN Stack 已从 mixed 修改为 system。

也就是说，TUN 并不是"没有启动"。问题发生在 TUN 前面的 Windows 路由选择阶段。

切换 Stack 也没有消除冲突，因为 system、mixed 和 gvisor 决定的是流量进入 TUN 后由哪套协议栈处理；而本次流量在进入 Mihomo TUN 之前，就已经被 aTrust 的 /16 路由截走了。

用直连和显式代理缩小范围

远程控制服务使用的地址为：

text 复制代码

wss://chatgpt.com/backend-api/wham/remote/control/server

应用日志中出现过 Windows os error 10060，表示连接等待一段时间后没有得到响应。

为了区分"节点不可用"和"TUN 路由异常"，我对同一个 HTTPS 端点进行了两组测试。

通过当前 TUN 路径访问

powershell 复制代码

curl.exe -sS -o NUL --connect-timeout 8 --max-time 12 -w "HTTP=%{http_code} TIME=%{time_total}s\n" https://chatgpt.com/backend-api/wham/remote/control/server

修改前结果约为：

text 复制代码

HTTP=000 TIME=8.00s
Connection timed out

显式指定 Clash 代理端口

powershell 复制代码

curl.exe -sS -o NUL --proxy http://127.0.0.1:7897 --connect-timeout 8 --max-time 12 -w "HTTP=%{http_code} TIME=%{time_total}s\n" https://chatgpt.com/backend-api/wham/remote/control/server

结果约为：

text 复制代码

HTTP=426 TIME=1.0s

HTTP=426 的含义是"需要升级协议"。这里使用的是普通 HTTP 探测，没有提供 WebSocket 的 Upgrade 请求头，所以服务器拒绝继续升级是预期行为。

在这个测试中，426 最重要的意义不是业务请求成功，而是证明 DNS、代理节点、TLS 和远端服务器均可达。相同目标通过 TUN 超时、通过 7897 很快可达，故障范围因此收敛到了本机 TUN/路由路径。

真正的冲突：aTrust 抢走了 Fake-IP 路由

首先检查 DNS：

powershell 复制代码

Resolve-DnsName chatgpt.com -Type A

修改前得到：

text 复制代码

chatgpt.com    A    198.18.0.12

这是 Clash Fake-IP 模式的正常表现。问题出在 Windows 如何处理这个 IP。

检查相关路由：

powershell 复制代码

Get-NetRoute -AddressFamily IPv4 |
  Where-Object DestinationPrefix -eq '198.18.0.0/16' |
  Select-Object DestinationPrefix,NextHop,InterfaceAlias,ifIndex,RouteMetric

实际结果指向了接口 22：

text 复制代码

DestinationPrefix : 198.18.0.0/16
NextHop           : 2.0.0.4
InterfaceAlias    : 本地连接
ifIndex           : 22

继续查看接口 22：

powershell 复制代码

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

得到：

text 复制代码

Name                 : 本地连接
InterfaceDescription : Sangfor aTrust VNIC
Status               : Up
ifIndex               : 22

至此根因完整闭环：Clash 和 aTrust 同时使用 198.18.0.0/16，而 Windows 最终把 198.18.0.12 交给了 aTrust。

方案一：暂时禁用 aTrust 虚拟网卡

如果当前不需要访问公司 aTrust 网络，可以做一个最小化验证：

按 Win + R；
输入 ncpa.cpl；
找到设备描述为 Sangfor aTrust VNIC 的"本地连接"；
右键选择"禁用"；
关闭再开启 Clash TUN；
执行 ipconfig /flushdns 后重新测试。

仅仅退出 aTrust 客户端窗口可能不够。本文环境中，退出客户端后虚拟网卡仍然是 Up，冲突路由也仍然是 Alive。

禁用虚拟网卡会暂时中断公司网络。需要使用 aTrust 时，可以在同一位置重新启用。

不建议把"删除 aTrust 路由"作为长期方案。客户端重连后可能重新创建路由，而且手工删除企业 VPN 路由可能影响内网访问。

方案二：修改 Clash Fake-IP 网段

如果 Clash 与 aTrust 必须同时使用，更稳妥的办法是修改 Clash 的地址池。

1. 先检查备用网段

本文选择 198.19.0.0/16 前，先确认系统中没有对应路由：

powershell 复制代码

Get-NetRoute -AddressFamily IPv4 |
  Where-Object DestinationPrefix -like '198.19.*'

没有输出，表示当前未发现该网段的显式路由冲突。

2. 修改 Clash Merge 配置

在 Clash Verge Rev 的"全局扩展配置""配置合并"或 Merge 配置中加入：

yaml 复制代码

# Profile Enhancement Merge Template for Clash Verge

dns:
  fake-ip-range: 198.19.0.1/16

只修改 dns.fake-ip-range 即可。下面这些配置与本次冲突无关，不必为了修复问题一起修改：

yaml 复制代码

profile:
  store-selected: true

dns:
  use-system-hosts: false

减少同时变化的配置项，出现问题时才容易判断是哪一项产生了作用。

3. 重新加载网络状态

保存 Merge 后按顺序操作：

关闭 TUN；
重启 Clash 内核或 Clash Verge Service；
重新开启 TUN；
刷新 Windows DNS 缓存。

powershell 复制代码

ipconfig /flushdns
Resolve-DnsName chatgpt.com -Type A

本文修改后得到：

text 复制代码

Name        Type TTL Section IPAddress
chatgpt.com A    1   Answer  198.19.0.4

这一步证明 Merge 已生效，而且 chatgpt.com 不会再命中 aTrust 的 198.18.0.0/16 路由。

重启与验证

不要只看到 DNS 变成 198.19.x.x 就直接宣布修复成功。完整验证至少包含三层。

第一层：DNS 地址池已切换

powershell 复制代码

Resolve-DnsName chatgpt.com -Type A

预期：返回 198.19.x.x，而不是 198.18.x.x。

第二层：远程端点可达

powershell 复制代码

curl.exe -sS -o NUL --connect-timeout 8 --max-time 12 -w "HTTP=%{http_code} TIME=%{time_total}s\n" https://chatgpt.com/backend-api/wham/remote/control/server

判断方法：

HTTP=426：端点可达，普通 HTTP 探测缺少 WebSocket Upgrade 头；
HTTP=401 或 403：端点同样可达，只是当前探测没有应用身份；
HTTP=000：网络链路仍未打通，需要继续检查路由、防火墙或其他虚拟网卡。

第三层：应用实际启用

从系统托盘完全退出 ChatGPT/Codex；
在任务管理器确认旧进程已经结束；
重新启动应用；
打开设置中的远程控制；
再次点击"允许"。

本文已经确认 DNS 冲突解除：解析结果从 198.18.0.12 变为 198.19.0.4。最终功能状态仍应以上述端点测试或应用实际启用结果为准，不能只凭界面开关状态判断。

mixed、system、gvisor 有什么区别

这三个选项只决定 TUN 内部使用哪套网络协议栈，不等同于首页的 System Proxy。

TUN Stack	TCP	UDP	特点	建议场景
`system`	Windows 系统栈	Windows 系统栈	通常更稳定、占用较低，但会受系统防火墙和网卡环境影响	Windows 长连接、WebSocket、开发工具
`gvisor`	Mihomo 用户态栈	Mihomo 用户态栈	隔离性较强，可绕开部分系统栈行为	`system` 存在兼容问题时测试
`mixed`	Windows 系统栈	gVisor 用户态栈	TCP 与 UDP 的折中方案	没有异常时的日常默认选择

远程控制的 WebSocket 主要使用 TCP，而 mixed 的 TCP 本来就使用系统栈。因此本案例从 mixed 切到 system 后仍然失败并不意外：根因不是 TCP 实现，而是流量根本没有进入 Mihomo TUN。

Mihomo 官方文档也说明，system、gvisor、mixed 的差异发生在 TUN 协议栈层；使用 system 或 mixed 时，还需要注意 Windows 防火墙是否放行 Mihomo 内核。

通用排查清单

以后再遇到"系统代理能用，但 TUN 中某个应用超时"，可以按下面的顺序检查。

1. 确认服务和网卡

powershell 复制代码

Get-Service |
  Where-Object { $_.Name -match 'clash|mihomo' -or $_.DisplayName -match 'Clash|Mihomo' }

Get-NetAdapter -IncludeHidden |
  Where-Object { $_.Name -match 'Mihomo|Clash|TUN' -or $_.InterfaceDescription -match 'Mihomo|Clash|TUN' }

2. 检查域名解析结果

powershell 复制代码

Resolve-DnsName chatgpt.com -Type A

如果返回 Fake-IP，继续检查该网段最终由哪张网卡接管。

3. 检查更具体的路由

powershell 复制代码

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

重点关注 VPN、企业安全客户端、游戏加速器、WSL、Hyper-V、VMware、VirtualBox、Tailscale、ZeroTier 等虚拟网卡。

4. 对比 TUN 与显式代理

对同一个地址分别测试默认路径和 --proxy http://127.0.0.1:7897。如果显式代理快速成功，而默认路径超时，优先检查本机 TUN、DNS 和路由，不要先怀疑订阅节点。

5. 每次只改变一个变量

建议顺序：

text 复制代码

重启服务
→ 关闭再开启 TUN
→ 验证
→ 切换 TUN Stack
→ 验证
→ 检查 Fake-IP 与虚拟网卡路由
→ 修改冲突网段
→ 再验证

一次同时修改 Stack、IPv6、DNS、节点和防火墙，即使问题恢复，也很难知道真正原因。

总结

这次故障最有价值的线索不是"远程控制打不开"，而是同一个远端地址出现了两种完全不同的结果：

默认 TUN 路径：8 秒超时，HTTP=000；
显式 Clash 代理：约 1 秒返回 HTTP=426。

这个差异证明节点和远端服务并没有整体失效。继续向本机路由追踪后，最终发现 chatgpt.com 的 198.18.0.12 命中了 Sangfor aTrust VNIC 的 198.18.0.0/16 路由。

因此，真正有效的处理不是继续反复重启，而是消除两个虚拟网络之间的地址冲突：暂时禁用 aTrust 网卡，或者把 Clash fake-ip-range 调整为本机未占用的 198.19.0.1/16。

排查 Agent、VPN 和代理工具的网络问题时，不要只看"开关是否已开启"。更可靠的办法是沿着 DNS、路由、TUN、代理节点和远端服务逐层验证，请求在哪一层偏离，根因通常就在哪一层。

参考资料

Mihomo 官方文档：DNS configuration
Mihomo 官方文档：TUN configuration and stack
Clash Verge Rev 官方文档：名词解释：系统代理与 TUN
Clash Verge Rev 官方文档：Windows 常见问题