Simular 免费云电脑 + HTTPS MCP 接入实战：OAuth 回调够不着、CLI rsh 走不通之后

2026 年 11 月 8 日，我按 X 上 @GMNIAO 的帖子注册了 Simular box 免费云电脑，目标是拿到一台能用 MCP 直接跑命令的云端 Ubuntu。注册本身 5 分钟就通了，但真正把命令跑起来，前后踩了三个坑：OAuth 设备登录的回调够不着、CLI 的 rsh 通道走不通、唤醒按钮连点三次都失败。本文记录这条链路是怎么打通的。

一、注册与机器配置

Simular box 没有邮箱注册入口，只有 Google / GitHub 登录。我用 GitHub 账号授权登录，账号邮箱是 aliyunpanqd@foxmail.com。Free 套餐全程没要绑卡、没要付费，也没要手机号和邮箱验证码——这在免费云电脑里算是门槛很低的一档。

建好的 box 名叫 main，配置是 4 CPU、7.7GB 内存、40GB 磁盘、Ubuntu 24.04，美国出口。每天 1,000 credits，00:00 UTC 重置。Box ID 是 cb-871e3a68cb48，仪表盘在 https://box.simular.ai 。

注册环节的结论很简单：有 GitHub 账号就能开，免费套餐不用绑卡。但这只是第一步，机器建好不等于能用。

二、第一个坑：Wake 连点三次都失败

机器建好后默认是 Offline 睡着的。仪表盘上的 Wake 按钮我连点了 3 次，每次都立即失败，报错是 "Could not wake your box"。当时以为是免费档容量不足或者账号有问题。

后来在一次 OAuth 授权操作之后，机器突然变成了 Running——到底是哪一步触发的，我无法确认。Screen 页随后显示出了实时桌面，说明机器确实醒了。

这个坑的教训是：Wake 按钮失败不要立刻下结论。免费档的唤醒链路有延迟和不确定性，先走一遍 OAuth 授权流程再看状态，比反复点 Wake 更有效。如果多次唤醒都失败，检查账号授权状态，而不是怀疑机器本身。

三、第二个坑：OAuth 设备登录的回调够不着

Simular 官方推荐的接入方式之一是 npx @simular-ai/box connect，走 OAuth 设备登录。流程是：命令行给出一个授权链接，在浏览器里点 Allow，然后回调到本机的 127.0.0.1:36767 完成登录。

问题出在回调地址上。我的浏览器在云端，127.0.0.1:36767 指向的是云端浏览器那台机器的本机，而不是我跑命令的这台机器。点了 Allow 之后，回调报 ERR_CONNECTION_REFUSED，Keys 页也没有新增设备。设备登录这条路在这种环境下是死路。

判断方法是看回调地址：如果授权回调是 127.0.0.1 开头的本机地址，而你的浏览器和命令行不在同一台机器上，这条路可以直接放弃，不用反复重试。

四、第三个坑：CLI rsh 的 gRPC 走不通

OAuth 走不通之后，我试了 CLI 的 rsh 通道。结果两种走法都失败：

• 走代理时 gRPC 报 CANCELLED；
• 直连时报 invalid bearer。

CLI 这条路在代理出网的环境下基本没戏。正确的路线是 HTTPS MCP：

https://mcp.box.simular.ai/mcp

用 Bearer token 走代理直接连 MCP 端点，一共 37 个工具，包含 shell，可以直接在盒子上跑命令。helper 脚本放在 ~/workspace/custom-connectors/custom.simular/bin/simular_mcp.py。实测下来，MCP 是这台盒子唯一稳定可用的命令通道。

这里的关键区别是传输层：rsh 依赖 gRPC 长连接，对代理环境很敏感；HTTPS MCP 是普通的 HTTPS 请求，走代理毫无压力。在只有代理出网的环境里，优先选 HTTPS 接口，少碰 gRPC/长连接协议——这条经验在别的服务上也适用。

五、顺带踩的两个坑：UU 装不上也控不了

同一天我还在盒子上装了 UU 远程控制（v0.2.55），装的过程中又踩了两个盒子专属的坑：

坑一：虚拟桌面循环重启。盒子自带一个 :0 的 XFCE 会话，占了用户总线上的会话管理名，我起的 :99 会话注册不上，秒退。修法是给 uu-virtual-desktop.service 加 drop-in：

Environment=UU_VIRTUAL_BUS=private

坑二：设备注册失败。assist device registration failed——盒子直连 DNS 是死的，只有 127.0.0.1:3128 代理出口能通。修法是给 uuremote-native.service 加 drop-in：

Environment=UU_USE_PROXY=1

修完这两处，设备注册成功，信令 Socket.IO 握手也完成了。但最终远程控制还是没连上：UDP TURN 分配失败 Network is unreachable（盒子没有直连路由），走代理的 TURN/TLS 也失败 TURN proxy CONNECT refused: status=403，本地零 ICE 候选。结论是这台盒子 UU 只能在线、不能远程控——没有直连出口的机器，UDP 打洞这条路天然不通。用户据此决定删掉 UU，服务停用、包 purge、unit 和配置全部清掉。

六、总结

这次实战的结论可以浓缩成三条：

1. 注册容易，唤醒看运气：Simular box 免费档 GitHub 授权即开、不用绑卡；Wake 失败先走 OAuth 授权再看，别死磕按钮。
2. 接入走 HTTPS MCP，别走 CLI rsh：MCP 端点 https://mcp.box.simular.ai/mcp + Bearer 经代理直连，37 个工具含 shell，是唯一实测可用的命令通道；OAuth 设备登录的 127.0.0.1 回调在云端浏览器环境下够不着。
3. 没直连出口的盒子，别指望 UDP 打洞：UU 的 TURN 分配失败是网络结构问题，不是配置问题；先确认出口形态，再决定装什么远程控制工具。