2026 年 10 月 1 日,我在使用 Desktop Commander Remote(RDC)连接本地开发机时,遇到了一个很奇怪的问题:
设备验证可以成功,浏览器端甚至已经显示:
You're connected但终端随后却报错:
Failed to set session: fetch failed
Device startup failed: fetch failed然后 Desktop Commander Remote 自动退出。
更麻烦的是,这个问题不是偶发一次,而是连续多次重复出现。
最终找到的关键变化,是当天升级 Clash Verge 后,原本一直使用的 TUN / 虚拟网卡模式被关闭了。
重新开启 TUN 后,Desktop Commander Remote 恢复正常:
Desktop Commander Remote is connected
Status: Online这篇文章记录这次排查过程。
一、问题表现:认证成功,但 session 建立失败
Desktop Commander Remote 的启动流程一开始看起来完全正常。
执行:
npx @wonderwhy-er/desktop-commander@latest remote随后浏览器完成授权,设备验证成功,页面也显示连接完成。
但终端紧接着出现:
Failed to set session: fetch failed
Device startup failed: fetch failed也就是说:
Device verification 成功了,但真正建立 Remote session 时失败。
这也是这个问题最容易误导人的地方。
如果认证直接失败,排查方向通常比较明确;但这里却是:
认证成功
↓
设备看起来已经连接
↓
session 建立失败
↓
进程退出
fetch failed】二、重复授权并不能解决问题
一开始我自然怀疑:
是不是 RDC 授权状态异常,或者 device session 出了问题。
因此我先后尝试了重新连接、重新授权、Revoke 设备,再重新建立连接。
结果 Desktop Commander Devices 页面留下了多个设备记录,但最终都变成:
Offline相同故障可以稳定复现:
重新授权
↓
设备创建成功
↓
session 建立失败
↓
Offline
到这里以后,继续反复 Revoke 和授权已经没有太大意义。
问题显然不只是账号认证。
三、RDC CLI 版本也一度成为怀疑对象
当天 Desktop Commander CLI 也存在版本变化,因此我还怀疑过:
是否是新版本引入了兼容性问题?
于是测试了不同版本。
但结果基本一致:
Device verified
↓
Failed to set session: fetch failed因此,没有足够证据说明问题来自某一个特定 RDC CLI 版本。
这个结果反而让我把注意力转向了运行环境。
四、奇怪之处:网络并不是完全不通
看到:
fetch failed第一反应当然还是网络。
但当时浏览器可以正常访问网页,Desktop Commander 授权页面可以打开,普通 HTTPS 请求也能正常完成。
所以实际情况更像:
普通网络访问正常,但 Desktop Commander Remote 所需要的 session 无法正常建立。
这意味着:
浏览器能上网
≠
所有程序的网络路径都正常于是我开始检查本机的代理环境。
五、关键发现:Clash Verge 升级后 TUN 被关闭
当天 Clash Verge 刚刚完成升级。
继续检查以后发现:
原本一直使用的 TUN / 虚拟网卡模式处于关闭状态。
系统代理仍然开启,所以普通网页访问几乎没有明显异常。
当时的环境实际上是:
浏览器可以上网
普通 HTTPS 可以访问
授权页面可以打开
设备认证可以完成但 Desktop Commander Remote 一进入 session 建立阶段:
fetch failed
这张图是整个排查过程的转折点。
因为终于发现了一个和故障发生时间完全吻合的环境变化:
Clash Verge 升级
↓
TUN 状态改变
↓
Desktop Commander Remote session 无法建立六、重新开启 TUN
随后重新开启 Clash Verge 的:
虚拟网卡模式 / TUNClash Verge 开始重新通过服务启动网络内核。

完成以后,再次启动 Desktop Commander Remote。
这一次结果马上发生了变化。
七、Desktop Commander Remote 恢复正常
重新运行:
npx @wonderwhy-er/desktop-commander@latest remote终端最终显示:
Device marked as online
Device ready
Desktop Commander Remote is connected
Status: Online而且进程不再像之前那样在 fetch failed 后自动退出。

至此,故障链基本闭合。
八、为什么系统代理能用,RDC 还是会失败?
这次排查最值得记录的,其实就是这一点。
平时我们很容易把:
浏览器能打开网页理解成:
网络正常但对于 Desktop Commander Remote 这类 Remote Agent 来说,并不一定成立。
这次实际观察到的状态是:
系统代理:可用
普通网页:可用
普通 HTTPS:可用
设备授权:可用
Remote session:失败重新打开 TUN 后:
Remote session:恢复至少在我这台 Ubuntu + Clash Verge + Desktop Commander Remote 的环境里,系统代理足以满足普通网页访问,但不能保证 RDC 所需要的网络流量都走到正确路径上。
而 TUN / 虚拟网卡模式会在更底层接管网络流量,对那些没有显式读取代理配置的程序更加可靠。
所以:
“网页能打开”只能证明一部分网络路径正常,不能证明 Remote Agent 的运行环境也正常。
九、为什么这次故障会花这么长时间?
真正浪费时间的,不是“重新打开 TUN”这个动作。
而是我一开始根本没有意识到:
Clash Verge 升级以后,原来的运行状态已经发生变化。
升级前,这台机器一直正常工作。
所以我的默认前提一直是:
代理环境和昨天一样但实际上已经变成:
Clash Verge 更新
↓
TUN 被关闭于是我先去检查了授权、device session、RDC CLI、服务端可访问性等方向。
这些排查都不算错,只是没有击中真正变化的地方。
这也是这次最有价值的经验之一:
软件升级以后,不要只确认“升级成功没有”,还要确认原本依赖的关键运行状态有没有被重置。
对于代理软件来说,尤其应该重新确认 TUN、System Proxy、DNS、service 等关键开关。
十、完整故障链
回头看,这次问题其实可以压缩成一条非常清晰的链路:
Clash Verge 升级
↓
TUN / 虚拟网卡模式关闭
↓
Desktop Commander Remote 启动
↓
浏览器授权成功
↓
Device verified
↓
建立 session
↓
Failed to set session: fetch failed
↓
Device startup failed: fetch failed
↓
进程退出
↓
多次重新授权仍失败
↓
发现 TUN 关闭
↓
重新开启 TUN
↓
重新启动 Desktop Commander Remote
↓
Device ready
↓
Status: Online5 张图也刚好覆盖了其中几个关键节点。
十一、总结
这次故障最后并不是简单的账号认证失败,也不是通常意义上的“网络断了”。
真正关键的变化是:
Clash Verge 升级后,原本开启的 TUN / 虚拟网卡模式被关闭。
系统代理仍然让浏览器和普通 HTTPS 请求保持正常,所以问题一开始很难定位。
但对于 Desktop Commander Remote 来说:
Device verified并不代表:
Remote session 一定能建立重新开启 TUN 后,RDC 随即恢复:
Desktop Commander Remote is connected
Status: Online这次排查让我以后再遇到类似:
浏览器正常
授权正常
但 Remote Agent 一直 fetch failed时,会优先检查代理模式是否在软件升级后发生了变化。
因为很多时候,真正改变的并不是 Agent,也不是服务端,而只是本机网络环境里某个原本一直开启的开关。
🚀 推荐 VPS(WireGuard / Clash / 自建 VPN 专用)
本系列方案推荐使用 Vultr VPS 作为基础服务器环境:
✔ 支持 WireGuard / Clash / VPS 架构部署
✔ 全球多机房节点可选
✔ 稳定适合长期运行的网络服务
👉 点击访问 Vultr(推荐注册入口)
💡 新用户优惠说明
Vultr 官方可能会针对新用户提供一定的试用额度或促销活动,例如:
– 最高可能获得 $300 新用户测试额度
– 用于 VPS 部署与测试用途
– 是否生效取决于 Vultr 官方活动规则及账户条件
⚠️ 不同地区、时间或账户类型可能存在差异。
⚠️ 重要说明
本站提供的链接为 Vultr 官方联盟推广链接,用于推荐 VPS 服务。
所有优惠活动均由 Vultr 官方提供与解释,本网站不保证所有用户均可获得相同促销权益。
拒绝反复折腾|专属 WireGuard VPN 远程部署与优化服务
本系列长期记录 WireGuard、Clash、VPS、DNS、Linux 网络环境和 AI 工具访问优化等实践。如果你不想反复踩坑、折腾服务器与协议配置,可以联系我做一次远程排查或专属方案部署。
适合以下用户:
✅ ChatGPT、Claude、Gemini 等 AI 工具使用者
✅ 海外远程办公用户
✅ 技术学习与开发环境访问需求
✅ 不想长期折腾 VPS 与代理配置的用户
✅ 希望拥有专属节点而非公共机场的用户
服务内容:
✅ 远程代搭建:在你自己的服务器上部署专属 WireGuard VPN,数据完全掌控。
✅ 免费试用:可申请免费试用我的自建节点,再决定是否继续。
✅ 分流优化:针对 AI 工具、开发环境及日常使用进行优化。
✅ 问题排查:协助排查连接失败、速度慢、DNS 异常、规则配置等常见问题。
如需了解方案或申请试用,请直接联系我,并注明:VPN 咨询。
联系方式:
Telegram:@shuijingwan
微信:13980074657
邮箱:shuijingwanwq@gmail.com

