没公网 IP 还会关机？把 Muse 虚拟机变成自己的 VPS

最近体验了下 Meta 的 Muse ，它会给每个用户分配一台独立的 Linux 虚拟机，让 Agent 在里面写代码、跑脚本和处理任务。

机器给的配置还行，系统是 Ubuntu 24.04 （ 2 核 CPU 、8G 内存、100G 磁盘），不过有两个限制：

不过好在系统里的 /home/hatch/workspace 目录是持久化的。稍微折腾一下，不仅能把它打造成一台可以随时从公网访问的 Linux VPS ，还能顺手借用其高质量出口代理上网。

思路其实很简单：放持久化目录 + 内网穿透 + 定时保活。

环境持久化：因为虚拟机重启后根目录会被重置，所以所有的工具、脚本和数据一定要放在 /home/hatch/workspace 目录下，确保机器即便被回收重建，数据依然保留。
内网穿透：机器虽然没有公网 IP ，但可以主动访问外网。利用轻量级的 rathole 隧道，把虚拟机内需要访问的端口（比如 Web 服务端口）映射到你自己的公网中继服务器上。这里有个特殊细节：由于 Muse 虚拟机的出站流量必须经过平台自带的网关代理，而 rathole 本身不支持配置上级 HTTP 代理，所以需要配合 socat 在本地搭个代理桥连上中继机。
定时保活：机器闲置被回收后，内存里的后台进程肯定不复存在。解决方案是利用 Muse 的定时任务能力，设定一个周期任务（这里选择每 5 分钟触发一次）。任务触发后会唤醒 Agent 执行任务，而 Agent 在执行任务时就会自动拉起底层的虚拟机，进而运行持久化目录下的检测与启动脚本，把穿透和控制台进程恢复并重连中继。

打通网络之后，怎么日常使用也是个问题：机器里并没有现成的 SSH 服务。

所以我顺手写了一个单文件无依赖的 Web 控制台 muse-console，直接把它变成一台在网页里开箱即用的 VPS：

至于部署也很简单：仓库里已经写好了给 Agent 看的部署文档，直接把 GitHub 仓库链接丢给 Muse，它就会在聊天框里向你询问必要的中继机信息，然后自动在虚拟机里把下载、配置、隧道和定时保活整套搞定，不需要自己手动敲命令。

打通公网访问后，能做的事情其实很多，比如拿来做 HTTP 代理上网。

前面提到的平台出站网关，系统默认直接配在环境变量里：

$ echo $http_proxy
http://hatch-runtime:2a8ce39f1c5d488dab8d1d3f5d1a61d6@hatch-egress-proxy:3128

Meta 这么设计主要是出于沙盒安全考量：虚拟机被隔离在私有沙盒网络中，一方面彻底隔绝了对 Meta 自身内网服务的未授权访问（杜绝内网横向探测与 SSRF ），另一方面所有外网请求都必须收敛到这层 Egress Proxy ，方便平台在边界做域名白名单过滤、审计和风控拦截。

实测这个出口 IP 的信誉度和纯净度很高。很多平时对普通机房 IP 拦截很死、代理检测严格的美国服务，走这个出口基本都能顺利通过。

hatch-egress-proxy:3128 只在 Muse 的私有沙盒网络里可达，外部无法直连。如果想在本地电脑或者外部服务器上借用这个出口，只需要在 Muse 虚拟机里做一次中继，再通过隧道拉出来。

这里可以用我在古法编程时代手搓的轻量 TCP 中继工具：tcp-relay（支持隧道加密模式）。

操作步骤：

服务端（ Muse 虚拟机）：启动 tcp-relay 的 server 模式，接收并解密外部隧道流量，转发到本地私网的 hatch-egress-proxy:3128。
打通隧道：通过 rathole 将虚拟机内 tcp-relay 监听的端口映射到公网中继机上。
客户端（本地设备）：本地启动 tcp-relay 的 client 模式，连接中继机映射端口并开启加密传输，本地监听一个 HTTP 代理端口。
客户端配置：将系统或浏览器代理指向本地监听端口，并带上官方自带的认证凭据：
- 用户名：hatch-runtime
- 密码：<password>

这样全程在公网上传输的都是加密流量，保护了认证凭据与数据安全；最终由 hatch-egress-proxy 出口访问目标网站，轻松绕过绝大部分服务对常见机房 IP 和商业代理的检测。