1 背景与目标

1.1 为什么需要远程浏览器环境

在构建基于 Agent 的自动化系统时，浏览器往往是任务执行的重要入口。许多操作并没有稳定的 API 接口，例如社交媒体发帖、页面交互、账号管理等，这些行为通常需要通过浏览器完成。

在 OpenClaw 的使用场景中，Agent 会通过浏览器执行一系列操作，例如打开 Twitter 页面、输入推文内容并发布。这种方式本质上是模拟真实用户行为，而不是直接调用平台接口。

如果在本地电脑上运行浏览器自动化，短时间内是可行的，但长期运行会面临一些现实问题，例如：
• 本地机器需要持续开机
• 浏览器环境容易被打断
• 自动化流程难以长期稳定运行

因此，更合理的方式是将浏览器运行环境迁移到云服务器上，使其可以长期稳定运行。

但问题也随之出现：大多数云服务器（例如 AWS EC2）默认只提供 命令行环境，并没有图形界面。换句话说，服务器上虽然可以运行程序，但并不能像普通电脑一样打开浏览器窗口。

为了让浏览器能够在服务器上运行，并且可以被远程控制，就需要构建一个 远程浏览器环境。

⸻

1.2 OpenClaw 的运行方式

OpenClaw 本质上是一个 Agent 系统，它负责根据任务指令执行一系列操作，而浏览器则是这些操作的执行载体。

在实际运行过程中，OpenClaw 会：
1. 启动浏览器环境
2. 访问目标网站
3. 执行页面操作（例如输入、点击等）
4. 完成任务，例如发布推文

这种模式意味着浏览器需要具备几个重要特征：
• 能够长期运行
• 保持账号登录状态
• 在出现问题时可以进行人工干预

如果浏览器完全运行在 headless 模式下，一旦自动化流程出现问题，调试难度会明显增加。因此，在很多 Agent 项目中，开发者更倾向于使用 真实浏览器环境 来运行自动化任务。

⸻

1.3 为什么不直接使用 Headless Browser

在浏览器自动化领域，一个常见方案是使用 Headless Browser，例如 Puppeteer 或 Playwright 启动 headless Chrome。

Headless 模式下浏览器没有图形界面，可以直接在服务器后台运行，这在很多自动化任务中都非常高效。

然而在实际使用中，这种方式也存在一些局限：
• 一些网站会检测 headless 浏览器
• 登录状态和 Cookie 管理更复杂
• 页面行为异常时难以调试

对于像 Twitter（X）这样的社交平台来说，浏览器环境越接近真实用户环境，稳定性通常越高。

因此，与其使用完全无界面的浏览器，不如在服务器上运行一个 真实的桌面环境 + 浏览器。

⸻

1.4 整体架构说明

为了实现远程浏览器运行环境，需要构建一个简单的远程访问架构。

整体结构如下：

Mac 本地电脑
        │
    SSH Tunnel
        │
AWS EC2
        │
TigerVNC Server
        │
Linux Desktop
        │
Chrome Browser
        │
OpenClaw

在这个架构中：
• AWS EC2 提供服务器运行环境
• Linux Desktop 提供图形桌面
• TigerVNC 提供远程桌面访问能力
• SSH Tunnel 用于安全连接
• 本地电脑 作为远程控制端

通过这种方式，服务器就像一台始终在线的远程电脑，浏览器可以在其中长期运行，而开发者可以在需要时远程连接进行操作。

⸻

1.5 最终实现目标

完成环境搭建后，系统应该具备以下能力：
• 云服务器可以长期运行浏览器
• 浏览器能够保持账号登录状态
• 本地电脑可以随时远程控制服务器桌面
• OpenClaw 可以直接操作浏览器执行任务

换句话说，我们最终得到的是一个 云端长期运行的浏览器环境，既可以支持自动化任务，也可以在需要时进行人工控制。

2 服务器端环境搭建（AWS EC2）

在完成整体架构设计之后，下一步是在服务器上构建实际运行环境。本节的目标是把一台默认只有命令行的 Ubuntu 服务器，逐步变成一台可以运行浏览器并支持远程访问的 Linux 桌面环境。

整个过程包括几个主要步骤：创建 EC2 实例、安装 Linux 桌面环境、配置远程桌面服务，以及安装浏览器环境。完成这些步骤后，服务器就可以作为一个长期在线的浏览器运行节点，为 OpenClaw 提供稳定的执行环境。

⸻

2.1 创建 AWS EC2 实例

首先需要在 AWS 上创建一台 EC2 实例作为运行环境。由于需要运行桌面环境和浏览器，建议至少使用 2 vCPU + 4GB RAM 的配置，例如 t3.medium 或 t3.large。

系统镜像建议选择 Ubuntu 22.04 LTS，该版本在桌面环境和远程桌面工具方面兼容性较好。

实例启动后，可以通过 SSH 连接服务器：

ssh -i your-key.pem ubuntu@your-ec2-ip

连接成功后，建议先更新系统软件包：

sudo apt update
sudo apt upgrade -y

此时服务器仍然是一个纯命令行环境。

2.2 安装 Linux 桌面环境

云服务器默认没有图形界面，因此需要手动安装桌面环境。为了减少资源占用，这里选择 XFCE 桌面环境。

安装命令如下：

sudo apt install xfce4 xfce4-goodies -y

安装完成后，系统就具备了基本的桌面组件，例如窗口管理器、文件管理器以及终端程序。

不过服务器仍然无法直接显示桌面，因为没有连接显示器。为了远程访问桌面，需要配置远程桌面服务。

⸻

2.3 安装远程桌面服务（TigerVNC）

为了远程访问服务器桌面，需要安装一个 VNC Server。这里使用 TigerVNC。

安装命令：

sudo apt install tigervnc-standalone-server tigervnc-common -y

安装完成后，初始化 VNC Server：

vncserver

第一次运行时系统会要求设置 VNC 访问密码。

初始化完成后，可以先停止 VNC 会话以进行配置：

vncserver -kill :1

2.4 配置 VNC Session

为了让 VNC 启动时加载 XFCE 桌面，需要配置启动脚本。

编辑配置文件：

nano ~/.vnc/xstartup

写入以下内容：

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &

然后赋予执行权限：

chmod +x ~/.vnc/xstartup

重新启动 VNC Server：

vncserver :1 -geometry 1920x1080 -depth 24

此时服务器已经启动一个远程桌面会话，对应端口 5901。

2.5 安装 Chromium 浏览器（snap）

在 Ubuntu 22.04 之后，Chromium 浏览器通常通过 snap 包管理器进行安装。snap 是 Ubuntu 的一种容器化软件安装方式，每个应用都会包含完整依赖，并运行在沙盒环境中。

安装 Chromium：

sudo snap install chromium

安装完成后，Chromium 的可执行文件路径通常为：

/snap/bin/chromium

这种方式安装的浏览器与系统环境隔离度更高，在某些自动化场景下反而更稳定。

⸻

2.6 在 VNC 桌面中启动浏览器

由于浏览器需要在 VNC 桌面中运行，需要指定正确的 DISPLAY 环境变量。

首先允许本地程序访问 VNC 桌面：

DISPLAY=:1 xhost +local:

然后启动 Chromium，并开启远程调试端口：

DISPLAY=:1 /snap/bin/chromium \
--remote-debugging-port=9222 \
https://x.com/login &

这条命令包含几个关键参数：
• DISPLAY=:1
指定浏览器在 VNC 桌面上显示窗口
• --remote-debugging-port=9222
开启 Chrome DevTools 调试端口，允许自动化程序接管浏览器
• https://x.com/login
直接打开 Twitter 登录页面

浏览器启动后，可以在 VNC 桌面中看到 Chromium 窗口，并手动完成账号登录。登录成功后，OpenClaw 就可以通过 9222 调试端口接管这个浏览器实例并执行自动化任务。
完成以上步骤后，服务器已经具备以下能力：
• 运行 Linux 图形桌面环境
• 提供 VNC 远程桌面服务
• 在桌面中运行 Chromium 浏览器
• 开启 DevTools 调试端口供 OpenClaw 接管

至此，一台普通的 Ubuntu 云服务器已经被改造成一个可以远程控制的浏览器运行环境。

3 安全访问方案设计（SSH Tunnel）

在服务器端完成桌面环境和 VNC 服务的配置之后，下一步就是从本地电脑连接到服务器桌面。最直接的做法是开放 VNC 端口（例如 5901）并让客户端直接连接，但这种方式在公网环境下存在明显的安全风险。

VNC 协议本身并不是为互联网环境设计的，如果直接将 VNC 端口暴露在公网，服务器很容易被自动扫描工具发现，并遭遇暴力破解攻击。因此，在实际部署中通常不会直接开放 VNC 端口，而是通过 SSH Tunnel（SSH 隧道） 来访问远程桌面。

SSH Tunnel 的原理其实很简单：通过 SSH 建立一条加密连接，并把本地端口映射到远程服务器的某个端口。这样在本地访问某个端口时，数据会通过 SSH 连接转发到服务器，从而实现安全访问。

在本项目的架构中，VNC Server 通常运行在服务器的 5901 端口（对应 display :1）。我们可以在本地电脑上创建一个 SSH 隧道，把本地端口映射到这个远程端口。

⸻

3.1 SSH Tunnel 原理

整体数据流可以理解为下面的结构：

本地 Mac
    │
localhost:5901
    │
SSH Tunnel
    │
AWS EC2
    │
localhost:5901
    │
TigerVNC Server

从客户端的角度看，只需要连接 localhost:5901，但实际上数据已经通过 SSH 安全地转发到了服务器上的 VNC 服务。

这种方式有两个明显优势：
• VNC 端口不需要对公网开放
• 所有数据通过 SSH 加密传输

因此服务器的安全组只需要开放 22 端口（SSH） 即可。

⸻

3.2 创建 SSH Tunnel

在本地电脑上执行以下命令即可创建 SSH 隧道：

ssh -i your-key.pem -L 5901:localhost:5901 ubuntu@your-ec2-ip

这条命令包含几个关键部分：
• -L 5901:localhost:5901
将本地端口 5901 转发到服务器的 localhost:5901
• ubuntu@your-ec2-ip
服务器的登录地址
• -i your-key.pem
AWS EC2 使用的 SSH 密钥

当这条命令执行成功后，本地电脑的 5901 端口 就已经连接到服务器上的 VNC 服务。

此时不要关闭这个 SSH 终端，因为 SSH Tunnel 需要保持连接状态。

⸻

3.3 验证端口映射

在 SSH Tunnel 建立之后，可以在本地电脑验证端口是否已经打开。

例如执行：

lsof -i :5901

如果 SSH 隧道正常运行，会看到本地端口已经被 SSH 进程占用。

此时从客户端访问 localhost:5901，实际上就等价于访问服务器上的 VNC Server。

3.4 多 Display 情况

在某些情况下，服务器可能会运行多个 VNC 会话，例如：

:1 → 5901
:2 → 5902
:3 → 5903

可以通过以下命令查看当前 VNC 会话：

vncserver -list

如果浏览器运行在 :3 Display，那么对应的 VNC 端口就是 5903。此时 SSH Tunnel 的端口映射也需要调整，例如：

ssh -i your-key.pem -L 5903:localhost:5903 ubuntu@your-ec2-ip

完成 SSH Tunnel 配置之后，本地电脑就可以通过 localhost 访问服务器上的远程桌面。接下来只需要在客户端安装 VNC Viewer 并连接到这个本地端口，就可以进入服务器桌面并看到正在运行的浏览器环境。

4 客户端连接配置（Mac）

在服务器端完成桌面环境、VNC 服务以及 SSH Tunnel 配置之后，最后一步是在本地电脑上连接远程桌面。由于 SSH Tunnel 已经将服务器端口映射到了本地，因此客户端实际上只需要连接本地端口即可。

换句话说，从客户端角度来看，远程桌面其实就运行在本机的 localhost 上。

⸻

4.1 安装 VNC 客户端

首先需要在本地电脑安装一个 VNC Viewer。常见的 VNC 客户端包括：
• TigerVNC Viewer
• RealVNC Viewer
• TightVNC

在 macOS 环境中，TigerVNC Viewer 或 RealVNC Viewer 都比较常用。

例如使用 Homebrew 安装 TigerVNC：

brew install tigervnc

安装完成后，可以使用 vncviewer 命令启动客户端。

4.2 确认 SSH Tunnel 已建立

在连接远程桌面之前，需要确保 SSH Tunnel 仍然保持连接状态。例如在另一个终端窗口中运行：

ssh -i your-key.pem -L 5901:localhost:5901 ubuntu@your-ec2-ip

只要这个 SSH 连接保持打开，本地端口 5901 就会被转发到服务器。

⸻

4.3 连接远程桌面

接下来可以启动 VNC Viewer 并连接到本地端口。

连接地址为：

localhost:5901

如果使用命令行方式，可以直接运行：

vncviewer localhost:5901

连接成功后，系统会要求输入之前在服务器上设置的 VNC 密码。

验证成功后，就可以进入服务器桌面。

⸻

4.4 验证浏览器环境

成功连接后，可以看到服务器上的 Linux 桌面环境（XFCE）。此时服务器就像一台远程电脑，可以在桌面中打开终端、启动浏览器或运行其他程序。

如果前面已经启动了 Chromium 浏览器，例如：

DISPLAY=:1 /snap/bin/chromium --remote-debugging-port=9222

那么在 VNC 桌面中应该可以直接看到浏览器窗口。

此时浏览器已经运行在服务器环境中，并且开启了 DevTools 调试端口，OpenClaw 可以通过该端口接管浏览器并执行自动化任务

5 在远程桌面运行 OpenClaw

在服务器端完成桌面环境、浏览器环境以及远程访问配置之后，最后一步是让 OpenClaw 接管浏览器并执行自动化任务。

OpenClaw 并不是直接启动浏览器，而是通过 Chrome DevTools Protocol（CDP） 控制已经运行的浏览器实例。因此，在启动浏览器时需要开启 remote debugging port，这样 OpenClaw 才能连接到浏览器并进行操作。

整个流程可以理解为三步：
1. 在服务器桌面启动浏览器
2. 浏览器开启 DevTools 调试端口
3. OpenClaw 连接该端口并接管浏览器

⸻

5.1 启动浏览器并开启调试端口

在服务器终端中启动 Chromium，并开启远程调试端口。

例如：

DISPLAY=:1 /snap/bin/chromium \
--remote-debugging-port=9222 \
https://x.com/login &

5.2 手动完成账号登录

在第一次运行浏览器时，需要在 VNC 桌面中手动登录 Twitter 账号。

步骤通常包括：
• 输入账号密码
• 通过验证码验证
• 完成账号登录

完成登录后，浏览器会保存登录状态（Cookie / Session）。只要浏览器实例不被关闭，登录状态就会一直保持。

这一步实际上非常重要，因为很多社交平台会对自动化登录进行严格限制。通过手动登录，可以确保浏览器环境与真实用户行为保持一致。

⸻
5.3 OpenClaw 接管浏览器

当浏览器开启 DevTools 调试端口后，OpenClaw 就可以通过该端口接管浏览器。

OpenClaw 的运行逻辑通常是：

OpenClaw Agent
      ↓
连接 9222 DevTools
      ↓
控制 Chromium
      ↓
执行网页操作

例如：
• 打开 Twitter 页面
• 输入推文内容
• 点击发布按钮
• 浏览时间线

这些操作本质上都是通过 DevTools 协议控制浏览器执行。

6 常见问题与调试

在实际运行过程中，远程桌面环境、浏览器以及自动化程序之间可能会出现各种问题。这些问题通常并不是某一个组件单独导致的，而是多个系统之间的协作问题，例如显示环境、端口映射或权限配置。

本节整理了一些在部署过程中比较常见的问题，以及对应的排查方法。

⸻

6.1 VNC 连接成功但只有灰色屏幕

一个比较常见的情况是：VNC Viewer 可以成功连接服务器，但进入桌面后只看到灰色背景和一个鼠标指针，没有任务栏或桌面环境。

这种情况通常说明 VNC Display 已经启动，但桌面环境没有启动。

可以通过查看 VNC 配置脚本确认：

cat ~/.vnc/xstartup

如果没有正确配置桌面环境，可以写入：

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &

然后重新启动 VNC：

vncserver -kill :1
vncserver :1

重新连接后，应该可以看到完整的桌面环境。

6.2 无法连接 VNC

如果客户端无法连接远程桌面，可以从以下几个方面检查。

首先确认 VNC Server 是否已经启动：

vncserver -list

如果没有运行中的会话，可以重新启动：

vncserver :1

然后确认 SSH Tunnel 是否仍然保持连接。如果 SSH 终端已经关闭，本地端口转发也会随之失效。

可以重新建立 SSH Tunnel：

ssh -i your-key.pem -L 5901:localhost:5901 ubuntu@your-ec2-ip

6.3 浏览器无法在 VNC 桌面启动

如果 Chromium 启动时报错，例如无法打开显示环境，通常是因为没有指定正确的 DISPLAY。

可以先查看当前 VNC Display：

vncserver -list

那么浏览器需要指定：

DISPLAY=:1 /snap/bin/chromium

如果 DISPLAY 设置错误，浏览器就无法在桌面环境中显示窗口。

⸻

6.4 DevTools 调试端口无法访问

OpenClaw 需要通过 DevTools 调试端口（通常是 9222）连接浏览器。如果该端口没有成功开启，自动化程序将无法接管浏览器。

可以在服务器上检查端口是否已经监听：

lsof -i :9222

如果没有进程监听该端口，需要重新启动浏览器并开启调试端口：

DISPLAY=:1 /snap/bin/chromium \
--remote-debugging-port=9222 &

然后可以通过以下命令测试接口是否正常：

curl http://localhost:9222/json

如果返回浏览器页面信息，说明 DevTools 端口已经正常工作。

⸻

6.5 无法在 VNC 桌面打开 Chromium（Authorization 错误）

在某些情况下，snap 版本的 Chromium 会因为 X11 权限问题而无法访问桌面环境，并报出类似 Authorization required 的错误。

这种情况下需要允许本地程序访问当前 Display：

DISPLAY=:1 xhost +local:

执行后再启动浏览器，通常可以解决权限问题。

⸻

在这类远程浏览器环境中，很多问题其实都与三个核心因素有关：

DISPLAY
端口
权限

只要逐步确认这三点，大多数问题都可以比较快地定位出来。

从工程经验来看，这种远程浏览器架构虽然比 headless 自动化复杂一些，但调试能力也更强。因为所有浏览器行为都可以在桌面中直接观察到，这在处理复杂网页交互时往往非常有价值。

7 总结

通过前面的步骤，我们从一台默认只有命令行的 Ubuntu 云服务器开始，逐步搭建了一个可以远程控制的浏览器运行环境。整个系统由多个组件共同组成，每一层都承担着不同的角色。

在服务器侧，AWS EC2 提供基础计算环境；Linux 桌面环境（XFCE）负责提供图形界面；TigerVNC 用于远程桌面访问；Chromium 浏览器则作为自动化任务的执行载体。与此同时，通过 SSH Tunnel 建立安全连接，可以避免直接暴露 VNC 端口，从而提升整体安全性。

在客户端侧，本地电脑通过 SSH 建立端口转发，再使用 VNC Viewer 连接本地端口，从而进入服务器桌面。由于所有通信都通过 SSH 加密传输，因此不需要在服务器安全组中开放额外端口。

当浏览器通过 --remote-debugging-port=9222 启动后，OpenClaw 就可以通过 Chrome DevTools Protocol 接管浏览器并执行自动化任务，例如发布推文、浏览时间线或执行其他网页操作。

整个系统的运行结构可以概括为：

本地电脑
    │
SSH Tunnel
    │
AWS EC2
    │
TigerVNC Server
    │
Linux Desktop (XFCE)
    │
Chromium Browser
    │
OpenClaw Agent

这种架构的核心思路，是在云服务器上构建一个长期在线的浏览器工作环境。与传统的 headless 自动化相比，这种方式虽然稍微复杂一些，但在面对复杂网页环境时往往更加稳定，也更容易进行调试。

从工程角度来看，这种设计实际上为自动化系统保留了一条“可视化调试通道”。当自动化流程运行正常时，OpenClaw 可以直接控制浏览器完成任务；当出现异常情况时，开发者也可以通过远程桌面立即进入服务器环境，查看浏览器状态并进行人工干预。