OpenClaw VPS 部署

摘要

这篇文章记录一次完整的 OpenClaw VPS 部署过程：在 Ubuntu 24.04 服务器上完成 SSH 密钥登录、普通管理员用户切换、root 远程登录禁用、Tailscale 私网接入、Telegram 对接、安全审计与状态验证。整套流程的重点，不只是把 OpenClaw 装起来，而是把一个会长期在线、会接入真实账号、真实 API 和自动化能力的实例，部署到一个边界清晰、权限收敛、后续可维护的环境里。如果你也准备把 OpenClaw 从本地测试带到 VPS 长期运行，这篇文章可以作为一条相对完整的落地参考路径。

为什么要做 OpenClaw VPS 部署

如果只是本地临时测试 OpenClaw，其实不需要把部署流程做得太重。直接在本机运行，确认功能是否正常、模型是否可用，就已经够了。这一阶段的重点是体验和测试，而不是长期在线、远程管理或访问边界控制。

但只要目标变成长期运行，情况就完全不同了。尤其是当 OpenClaw 部署到 VPS 上，并且后续还要接入 Telegram、模型服务以及其他真实账号和自动化能力时，这个实例就不再只是一个“能跑起来的程序”，而是一个持续在线、具备访问价值和控制价值的远程节点。

所以，这篇 OpenClaw VPS 部署实战真正要解决的，不只是安装问题，而是整条上线链路的问题：如何先把 SSH 管理入口整理清楚，如何把公网管理入口收进私网，如何在此基础上完成 OpenClaw 安装、初始化和 Telegram 对接，并让整个实例进入一个长期可用、边界清晰的状态。

为什么本地测试阶段通常不需要 Tailscale 私网接入

这一点必须先讲清楚，否则很多人会误以为 Tailscale 是 OpenClaw 的默认必需组件。不是。

如果只是本地测试 OpenClaw，程序运行在自己的电脑上，访问范围天然受限，也没有一个长期暴露在互联网上的远程管理入口。这种场景下，核心是功能验证，而不是公网入口收口，因此通常完全不需要考虑 Tailscale。

但 OpenClaw VPS 部署不是这个逻辑。一旦实例放到远程服务器上，它就变成了一个长期在线节点；而当它继续接入 Telegram Bot、模型服务、回调能力甚至命令执行能力之后，这个实例本身就开始具备真实价值。也正因为如此，管理入口不能继续维持在公网可探测、可扫描、可持续尝试接近的状态下。

所以，在 OpenClaw VPS 部署里接入 Tailscale，重点不是“连接更方便”，而是：当实例开始承载真实账号、真实 API 和真实交互能力之后，公网管理入口就应该收缩成私网管理入口。这是安全边界变化带来的必然动作，而不是可选装饰。

OpenClaw VPS 部署的整体流程

这次 OpenClaw VPS 部署，我实际走的是一条比较完整的顺序，而不是上来先装程序。整个流程可以概括为以下几个阶段：

在本地准备 SSH 密钥，并验证 root 密钥登录打通
临时允许 root 通过密钥登录，先验证 SSH 配置没有问题
创建普通管理员用户 admin，并迁移 SSH 公钥
正式关闭 root 远程登录，只保留 admin + 密钥认证
完成系统基础加固，包括防火墙和 fail2ban
接入 Tailscale，把 SSH 管理入口从公网收进私网
安装 Node.js 22 和 OpenClaw
完成 OpenClaw 初始化、模型配置和 Telegram 对接
收紧 Telegram 访问范围
检查状态、运行安全审计，并处理不必要的半配置功能

这条顺序的核心不在于“步骤多”，而在于先整理边界，再接入价值。先把门装好，再决定谁能进门，最后再把真正有价值的账号和功能放进来。

OpenClaw VPS 部署前：先检查本地 SSH 密钥

在开始 OpenClaw VPS 部署之前，我先在本地检查是否已经有可用的 SSH 密钥。因为后面无论是登录 VPS、修改 SSH 配置，还是迁移到普通管理员用户，都建立在密钥登录已经可用的前提之上。

如果本地已经有 id_ed25519 和 id_ed25519.pub，通常可以直接复用；如果没有，再在本地生成新的 ed25519 密钥即可。

这一阶段的重点不是“生成密钥”本身，而是确保你后面真的有一条稳定的密钥登录链路。没有这条链路，就不要急着收紧 SSH。

OpenClaw VPS 部署中如何生成新的 ed25519 密钥

ls -la ~/.ssh

如果没有 id_ed25519 和 id_ed25519.pub，就生成：在本地创建密钥，我这里是mac 系统创建

dhty@dhtydeMac-mini ~ % ssh-keygen -t ed25519 -C "ubuntu-vps-key"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/dhty/.ssh/id_ed25519): 
Enter passphrase for "/Users/dhty/.ssh/id_ed25519" (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/dhty/.ssh/id_ed25519
Your public key has been saved in /Users/dhty/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:NQHhZWi0fcc//rtdwd9paE4d4qSlHewf9br5Vj31fKI ubuntu-vps-key
The key's randomart image is:
+--[ED25519 256]--+
|       .+++      |
|       .o= . .   |
|       .o + . o  |
|         . o.....|
|        S    * **|
|            O B./|
|           o O BO|
|            E oo*|
|             .+B*|
+----[SHA256]-----+
dhty@dhtydeMac-mini ~ %

OpenClaw 部署中：把公钥复制到 VPS，并先验证 root 密钥登录

本地密钥准备好之后，下一步是把公钥复制到服务器。这里我先复制到 root，是因为 root 是前期的过渡入口，作用是先帮我完成最基础的验证和配置调整。

公钥复制完成后，我没有立刻继续下一步，而是先测试 root 是否已经能够通过密钥正常登录 VPS。只有确认 root 的密钥登录链路真的打通，后面才有资格继续修改 SSH 配置。

这里不能跳过验证。因为如果你还没确认密钥登录可用，就去关闭密码登录或者收紧 root 配置，本质上是在主动制造把自己锁死的风险。

ssh-copy-id 复制公钥到 VPS

dhty@dhtydeMac-mini ~ % ssh-copy-id root@192.168.1.91
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/dhty/.ssh/id_ed25519.pub"
The authenticity of host '192.168.1.91 (192.168.1.91)' can't be established.
ED25519 key fingerprint is: SHA256:HSyKOso7hXeP2Tblc8B9MZUKkzanS2kcQKBBJ/ZozTE
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.1.91's password: 

Number of key(s) added:       

Now try logging into the machine, with: "ssh 'root@192.168.1.91'"
and check to make sure that only the key(s) you wanted were added.

测试 root 密钥登录是否成功

dhty@dhtydeMac-mini ~ % ssh root@192.168.1.91
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar  8 13:29:27 2026 from 192.168.1.42

既然 root 的密钥登录已经通了，下一步才能改 SSH：

sudo nano /etc/ssh/sshd_config


PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin yes

检查配置和重载ssh 服务

root@ubuntu:~# sudo sshd -t
root@ubuntu:~# sudo systemctl reload ssh
root@ubuntu:~# exit

测试登录：

dhty@dhtydeMac-mini ~ % ssh -i /Users/dhty/.ssh/id_ed25519 root@192.168.1.91
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar  8 14:56:06 2026 from 192.168.1.42
root@ubuntu:~#

OpenClaw VPS 部署中：先验证 SSH 配置，再退出 root 日常运维路径

因为 root 的密钥登录已经打通，下一步才能开始动 SSH 配置文件。这一阶段我做的不是直接禁用 root，而是先让 SSH 配置进入一个可验证的过渡状态。

这里的核心思路是：先确保密钥认证可用、密码登录可以关闭、root 仍然能通过密钥进来。这样做不是为了长期保留 root，而是为了先验证当前配置方向没有问题。

到这里很多人会偷懒，觉得 root 既然已经能无密码登录，那就继续这样用。这个判断是错的。root 的问题不是“能不能用”，而是它始终处在系统最高权限上下文里。一旦发生误操作、配置错误、批量删除、错误覆盖，影响通常不是局部的，而是直接作用到整个系统。

而且在 OpenClaw VPS 部署这种场景里，后续实例可能会具备文件访问、命令执行和自动化能力。这时如果仍然长期使用 root，就等于把最高权限直接暴露给日常管理链路。只要未来有一次不够精确的操作，破坏范围就会被直接放大。

所以，root 在这里的作用只是过渡：验证链路、完成初期配置，然后尽快退出日常运维路径。

dhty@dhtydeMac-mini ~ % ssh root@192.168.1.91
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar  8 15:06:08 2026 from 192.168.1.42
root@ubuntu:~#

OpenClaw VPS 部署中：创建普通管理员用户 admin，并迁移 SSH 公钥

接下来，我正式创建普通管理员用户 admin。这里的用户名不一定非得叫 admin，也可以按自己的习惯命名，但后面所有的 SSH 登录、sudo 管理、OpenClaw 安装，都会围绕这个普通管理员账户展开，所以用户名最好一开始就定清楚。

创建完成之后，我做了三件关键事情：

把这个用户加入 sudo 组
创建这个用户自己的 .ssh 目录
把 root 已经验证可用的公钥复制给它

这一阶段的重点不是“多建了一个用户”，而是把日常运维入口从 root 迁移到普通管理员账户。这样后续所有管理动作，就不再默认带着系统最高权限执行。

OpenClaw VPS 部署中为什么要迁移到普通管理员账户

迁移到普通管理员账户，不是为了形式上的“更规范”，而是为了把日常运维入口从 root 最高权限环境里拿出来。这样后续无论是 SSH 登录、sudo 管理，还是 OpenClaw 的安装与运行，默认都不会直接落在系统最高权限上下文中。一旦未来出现误操作、配置错误或自动化执行偏差，普通管理员账户至少还能提供一层基本的缓冲。

OpenClaw VPS 部署中如何迁移 SSH 公钥到 admin

这里的核心不是重新生成一套新的密钥，而是把已经验证可用的 root 公钥登录链路迁移到 admin 账户上。这样可以在不增加额外变量的前提下，先确保普通管理员账户也具备稳定的密钥登录能力。只有 admin 的 SSH 公钥登录被验证通过，后面才适合继续收紧 root 远程登录权限。

创建 admin 用户过程，管理用户 admin ，这里的admin 可以根据自己的爱好，随意就可以，但要记住用户名

root@ubuntu:~# adduser admin
info: Adding user `admin' ...
info: Selecting UID/GID from range 1000 to 59999 ...
info: Adding new group `admin' (1001) ...
info: Adding new user `admin' (1001) with group `admin (1001)' ...
warn: The home directory `/home/admin' already exists.  Not touching this directory.
New password: 				# 输入密码					
Retype new password: 		        # 密码确认
passwd: password updated successfully
Changing the user information for admin
Enter the new value, or press ENTER for the default
	Full Name []: 			# 用户全名，随便填，也可以空着
	Room Number []: 		# 房间号/办公室号，服务器场景基本没意义
	Work Phone []: 			# 工作电话，基本没意义
	Home Phone []: 			# 家庭电话，基本没意义
	Other []: 			# 其他备注，基本没意义
Is the information correct? [Y/n] y	# 上面你输入的那些用户信息对不对？
info: Adding new user `admin' to supplemental / extra groups `users' ...
info: Adding user `admin' to group `users' ...
root@ubuntu:~#

把 admin 加入 sudo 组，赋予管理员权限

root@ubuntu:~# usermod -aG sudo admin       # 把 admin 加入 sudo 组，赋予管理员权限
root@ubuntu:~# mkdir -p /home/admin/.ssh    # 创建 admin 用户的 SSH 配置目录
root@ubuntu:~# chmod 700 /home/admin/.ssh   # 设置 .ssh 目录权限为仅用户自己可访问

创建 /home/admin/.ssh 并复制 authorized_keys

root@ubuntu:~# cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys   # 复制 root 已可用的公钥到 admin
root@ubuntu:~# chmod 600 /home/admin/.ssh/authorized_keys   # 设置公钥文件权限为仅用户自己可读写
root@ubuntu:~# chown -R admin:admin /home/admin/.ssh   # 把 .ssh 目录及文件属主改为 admin

OpenClaw VPS 部署中：测试 admin 登录和 sudo 权限

admin 用户创建好之后，不能立刻去禁用 root。正确顺序是先退出 root 会话，在本地重新登录 admin，确认它已经能稳定通过 SSH 密钥进入服务器。

登录成功之后，我又进一步检查了 admin 是否真的具备 sudo 权限。因为后面几乎所有系统级操作都要依赖 sudo，如果这一步不验证，后面又会多出一层不必要的排错。

到这里为止，admin 账户的定位就算建立起来了：它将成为后续 OpenClaw VPS 部署的主要管理入口，而 root 只保留到最后一次 SSH 收紧验证结束。

OpenClaw 部署中如何验证 admin 账户可用

admin 用户创建好之后，不能立刻去禁用 root。正确顺序是先退出 root 会话，在本地重新登录 admin，确认它已经能稳定通过 SSH 密钥进入服务器。

登录成功之后，还需要进一步检查 admin 是否真的具备 sudo 权限。因为后面几乎所有系统级操作都要依赖 sudo，如果这一步不验证，后面就会多出一层不必要的排错。

到这里为止，admin 账户的定位就算建立起来了：它将成为后续 OpenClaw VPS 部署的主要管理入口，而 root 只保留到最后一次 SSH 收紧验证结束。

### OpenClaw 部署中如何验证 admin 账户可用

首先，在本地重新通过 SSH 登录 admin，确认这个普通管理员账户已经能够稳定进入服务器。如果这一步失败，就说明前面的公钥迁移或账户权限设置仍然存在问题，后面的 SSH 收紧也不能继续。

dhty@dhtydeMac-mini ~ % ssh admin@192.168.1.91
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

为什么 VPS 部署中要确认 sudo 权限正常

确认 admin 可以登录之后，还需要再执行一次 sudo whoami，检查这个账户是否已经具备 sudo 权限。如果输出结果为 root，就说明 admin 的管理员权限已经配置正确，后面可以继续进行 SSH 收紧和系统配置。

admin@ubuntu:~$ sudo whoami		
[sudo] password for admin: 
root
admin@ubuntu:~$

为什么 OpenClaw VPS 部署更适合用 admin，而不是长期用 root

普通管理员账户的价值，不在于形式上的“更规范”，而在于它能够把日常运维入口从 root 的最高权限环境中分离出来。这样后续无论是 SSH 登录、sudo 管理，还是 OpenClaw 的安装与运行，都不会默认直接落在系统最高权限上下文里。

对于 VPS 部署来说，这种区分非常重要。root 账户拥有系统级完全控制权，一旦发生误操作、配置错误、批量删除或异常命令执行，影响通常不会停留在某个局部环节，而是会直接扩散到整台服务器。相比之下，admin 账户虽然仍然可以通过 sudo 完成系统管理，但默认状态下并不直接暴露在最高权限环境中，这本身就构成了一层必要的缓冲。

这种缓冲不只是账户层面的安全边界，也涉及文件和执行边界。系统配置文件、服务目录、敏感路径以及命令执行权限，如果始终直接绑定在 root 账户上，那么未来一旦 OpenClaw 具备更强的自动化、文件访问或命令执行能力，风险就会被放大。把日常入口切换到普通管理员账户，本质上是在给整个实例预先设定一个更可控的损害上限。

换句话说，不长期使用 root，不是因为 root “不能用”，而是因为一旦出现错误，错误不应该直接以最高权限扩散到整台 VPS。这也是为什么在 OpenClaw VPS 部署里，admin 更适合作为长期运维入口，而 root 只适合作为前期过渡账户。

OpenClaw 部署中的账户安全边界

在账户层面，root 是系统默认最高权限账户，任何登录和操作都天然带着全局控制能力。admin 则不同，它首先是普通用户，只在需要时通过 sudo 获取临时提权。这种差异决定了两者在风险暴露面上的本质区别：前者默认全局生效，后者默认局部运行。

OpenClaw 部署中的文件安全与执行边界

在文件与执行层面，root 可以直接修改系统配置、服务文件和敏感目录，也能够无约束执行高风险命令。一旦未来实例接入更多自动化能力，这种默认的最高权限就会显著放大误操作后果。使用 admin 作为常用入口，至少可以让大部分日常操作先停留在受控范围内，而不是直接落到整台服务器的最高权限环境。

OpenClaw VPS 部署中：正式收紧 SSH，禁用 root 远程登录

当 admin 登录和 sudo 都验证完成之后，才真正进入 SSH 收紧阶段。

这一步的目标非常明确：让后续远程登录只保留普通管理员账户和密钥认证，停止 root 作为远程入口继续存在。

这时我重新编辑 SSH 配置，把 root 远程登录禁掉，同时关闭密码认证和交互式认证，只保留密钥认证。保存之后，先检查配置语法，再重载 SSH。

但最重要的不是“文件已经改好了”，而是改完之后立刻做三轮验证：

admin 是否仍然能正常登录
root 是否已经被禁止
admin 是否确实是通过密钥认证登录，而不是偷偷回退到了密码认证

只有这三轮都符合预期，SSH 收口才算真正完成。

OpenClaw VPS 部署中的 SSH 收口目标

这一阶段的核心不是简单修改 sshd_config，而是把远程管理入口真正收紧到“普通管理员账户 + 密钥认证”这一条链路上。也就是说，后续 SSH 连接不再允许 root 直接远程登录，也不再接受密码认证，而是只保留已经验证通过的 admin 密钥登录。

OpenClaw 部署中如何验证 root 已被禁用

在服务器上编辑 SSH 配置文件，确保相关项至少包括以下内容：

sudo nano /etc/ssh/sshd_config

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

保存之后，先检查配置语法，再重载 SSH 服务：

sudo sshd -t
sudo systemctl reload ssh

接下来，不要只看配置文件本身，而是立刻从本地做三轮验证。

首先，重新通过 admin 登录，确认普通管理员账户仍然可以正常进入服务器：

dhty@dhtydeMac-mini ~ % ssh admin@192.168.1.91
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar  8 15:27:45 2026 from 192.168.1.42
admin@ubuntu:~$ exit
logout
Connection to 192.168.1.91 closed.

然后，直接测试 root 是否已经被禁止远程登录：

dhty@dhtydeMac-mini ~ % ssh root@192.168.1.91
root@192.168.1.91's password:
Permission denied, please try again.
root@192.168.1.91's password:
Permission denied, please try again.
root@192.168.1.91's password:
root@192.168.1.91: Permission denied (publickey,password).

最后，再强制指定只使用公钥认证登录 admin，确认当前连接没有偷偷回退到密码认证：

dhty@dhtydeMac-mini ~ % ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no admin@192.168.1.91
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar  8 15:34:24 2026 from 192.168.1.42
admin@ubuntu:~$

OpenClaw VPS 部署中的系统基础加固

在完成 SSH 收口之后，下一步不是立刻安装 OpenClaw，而是先把 VPS 的基础防护做扎实。这里的重点不是追求“高级安全方案”，而是先把一个长期在线的服务器整理成一个入口清楚、基础防护就位的运行环境。因为后面无论是 OpenClaw、本地回调、Telegram 通道，还是私网管理入口，全部都建立在这个底子之上。

这一阶段我主要做了四件事：

更新软件包索引
安装 UFW、fail2ban、curl、git 等基础依赖
启用防火墙
启动 fail2ban

为什么 OpenClaw 部署要先做基础防护

如果前面的 SSH 收口已经完成，那么后续就不应该继续把 VPS 当成一台“临时实验机”来处理。因为只要 OpenClaw 进入长期运行状态，这台机器就不再只是装了一个程序，而是会逐步承载真实账号、真实 API、真实交互入口和自动化能力的在线节点。

也正因为如此，基础防护必须先到位。UFW 负责把网络入口收紧到最小范围，fail2ban 则负责处理常见的暴力尝试和异常登录行为。它们都不是复杂方案，但在一台长期在线的 VPS 上，它们是最低限度的防护底座。

VPS 部署里 UFW 和 fail2ban 的作用

UFW 的作用是先把“哪些端口能进、哪些不能进”明确下来；fail2ban 的作用则是当某些入口被重复试探或异常访问时，及时进行封禁和干预。前者解决的是入口边界问题，后者解决的是入口被持续骚扰时的基础应对问题。

先把这两层做起来，后面再接 Tailscale，把 SSH 从公网收进私网，整条链路才是顺的。

安装基础依赖并启用防护

在服务器上先执行下面这组命令：

sudo apt update
sudo apt install -y ufw fail2ban curl ca-certificates gnupg git

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

OpenClaw VPS 部署中：安装 Tailscale，把管理入口从公网收进私网

到这里，Tailscale 才真正登场，而且这一步非常关键。

原因不是“装一个远程工具”，而是因为接下来这个 OpenClaw VPS 实例会逐步接入有价值的东西，比如：

OpenAI API
Telegram Bot
本地授权回调
控制界面
可能的自动化执行能力

这意味着这个实例已经不只是一个普通测试环境，而是一个具备真实账号、真实调用能力和真实交互入口的在线系统。

这时继续把 SSH 管理入口长期暴露在公网，就不合理了。所以我的做法是先在 VPS 上安装 Tailscale，让服务器加入 Tailnet；然后再在本地 Mac 上安装并登录 Tailscale，让本地设备也进入同一网络。

只有当本地和 VPS 都成功加入同一个 Tailnet 之后，我才开始通过 100.x.x.x 的私网地址测试 SSH 登录。

为什么 OpenClaw VPS 部署要在这个阶段接入 Tailscale

Tailscale 放在这个阶段，逻辑上是最顺的。因为前面已经完成了：

SSH 密钥登录验证
普通管理员账户迁移
root 远程登录禁用
基础防火墙与 fail2ban 防护

也就是说，远程管理链路已经具备最基本的安全边界。接下来再引入 Tailscale，就不是“补一个远程工具”，而是在已有边界基础上，把管理入口从公网进一步收缩到私网。

OpenClaw 部署中如何验证 Tailscale 私网 SSH 可用

先在 VPS 上安装并启动 Tailscale：

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

这一步的实质，是在等待你到浏览器里完成 Tailscale 设备授权。授权完成后，这台 VPS 才算真正加入 Tailnet。

浏览器里完成设备授权

接着，在本地设备上也安装并登录 Tailscale，让本地电脑进入同一个 Tailnet。这个过程中，浏览器里可能会出现 onboarding 问卷或设备选择提示，按正常流程完成即可。这些步骤不是 OpenClaw 的配置本体，只是把本地设备也拉进同一个私网。

找自己对应的系统版本下载

我这里是 Mac，一路下一步

本地登录 tailscale

将本地也加入tailscale网络

当本地和 VPS 都成功加入同一个 Tailnet 后，再从本地通过 Tailscale 分配到的 100.x.x.x 地址测试 SSH 登录：

admin@ubuntu:~$ exit
logout
Connection to 192.168.1.91 closed.
dhty@dhtydeMac-mini ~ % ssh admin@100.97.249.73
The authenticity of host '100.97.249.73 (100.97.249.73)' can't be established.
ED25519 key fingerprint is: SHA256:HSyKOso7hXeP2Tblc8B9MZUKkzanS2kcQKBBJ/ZozTE
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:7: 192.168.1.91
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '100.97.249.73' (ED25519) to the list of known hosts.
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-100-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Last login: Sun Mar  8 15:36:46 2026 from 192.168.1.42
admin@ubuntu:~$

如果能够正常登录，就说明两件事已经成立：

本地设备和 VPS 已经成功进入同一个 Tailscale 网络
后续已经可以通过这个私网地址执行 SSH 管理

为什么 OpenClaw VPS 部署要把公网管理入口转为私网入口

这一段是整篇文章里最重要的安全逻辑。

如果只是本地测试 OpenClaw，根本不需要 Tailscale，因为本地阶段没有长期公网管理入口，也没有一个值得被收口的远程暴露面。

但 VPS 部署不同。一旦实例长期在线，并且后续接入 Telegram、API Key、Bot Token 以及其他账号和自动化能力，它就开始具有真实价值。既然实例本身的价值提高了，管理入口就不能继续停留在“公网默认可探测”的状态下。

所以，把公网管理入口转为私网入口，本质上是在做三件事：

缩小暴露面
限制谁能接近管理入口
让后续的 SSH、回调和控制台访问尽量统一在同一个受控边界里

这也是为什么 Tailscale 在 OpenClaw VPS 部署里是合理的，而在本地测试阶段通常没有必要。

OpenClaw VPS 部署中公网入口的真实风险

公网入口的风险，不只在于“会不会被扫到”，而在于它意味着你的管理链路长期处在一个默认可探测、可尝试接近、可持续被试探的位置。只要实例本身开始承载真实账号、真实 API 和真实交互能力，这种暴露面就不再合理。

OpenClaw VPS 部署中私网入口带来的边界变化

私网入口带来的变化，是把“谁都能看到入口”变成“只有进入同一 Tailnet 的设备才能接近入口”。这不是绝对安全，而是更符合长期在线实例的管理边界。对于 OpenClaw 这种未来可能持续接入更多工具和能力的系统，这种收口是必要动作，而不是附加装饰。

OpenClaw VPS 部署中：确认私网 SSH 可用后，再收掉公网 22 端口

这一步顺序不能反。只有当我已经通过 Tailscale 地址成功 SSH 登录 VPS，确认私网管理路径真的可用之后，才有资格继续把公网 22 端口的常规放行规则删掉。

这一步完成后，SSH 并不是被关闭了，而是被收口了：仍然保留 SSH，但只允许来自 Tailscale 网段的访问。

这样一来，服务器的远程管理入口就从“公网可见”切换成了“私网内可达”。这也是前面安装 Tailscale 的真正落点。

为什么 OpenClaw 部署中不能过早关闭公网 SSH

如果在验证 Tailscale 私网 SSH 之前就先把公网 22 端口收掉，一旦私网链路本身没有真正打通，结果不是“更安全”，而是直接把自己锁在服务器外面。所以这一步不能靠想当然，必须先验证，再收口。

VPS 部署中如何用 UFW 收口 22 端口

只有在私网 SSH 验证通过之后，才继续执行下面这组命令

sudo ufw allow from 100.64.0.0/10 to any port 22 proto tcp
sudo ufw delete allow OpenSSH
sudo ufw status verbose

这三条命令分别表示：

允许 Tailscale CGNAT 网段访问 22 端口
删除原来的公网 SSH 放行规则
查看当前防火墙状态，确认规则已经切换成功

admin@ubuntu:~$ sudo ufw allow from 100.64.0.0/10 to any port 22 proto tcp
[sudo] password for admin: 
Rule added
admin@ubuntu:~$ sudo ufw delete allow OpenSSH
Rule deleted
Rule deleted (v6)
admin@ubuntu:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    100.64.0.0/10             

admin@ubuntu:~$

OpenClaw VPS 部署中：按需处理 80/443，而不是默认继续对公网开放（可选）

如果后面确实有 Web 管理界面需求，那么 80/443 也可以继续按需放行。但关键不是“能不能开”，而是入口边界是否和前面的私网思路保持一致。

如果 SSH 已经收进私网，而 80/443 又顺手对公网敞开，那前面的收口逻辑就被自己拆掉了一半。所以我这里的处理方式，是在有明确需要时，再把这两个端口也限制给 Tailscale 网段，而不是继续默认全网开放。

为什么 OpenClaw 部署中 Web 端口也要按需放行

只要一个端口对应的是可管理入口，它就不应该因为“可能以后会用到”而默认对外开放。前面既然已经把 SSH 收进了私网，那么后续可能出现的 Web 管理入口，也应该尽量遵循同样的边界思路：优先限制在 Tailscale 网段内，而不是重新暴露回公网。

按需放行 80/443 给 Tailscale 网段

如果后面确实有这个需求，再执行下面的命令：

sudo ufw allow from 100.64.0.0/10 to any port 80 proto tcp
sudo ufw allow from 100.64.0.0/10 to any port 443 proto tcp

这里要说明一点：放行 80/443 不是当前部署的必选步骤，而是按需保留的 Web 入口。如果后续主要还是通过 SSH、Tailscale 和 OpenClaw TUI 完成管理，那么这两个端口完全可以先不开放。

我这次部署完成后，后续大部分操作其实都仍然是在 TUI 里进行的，所以 80/443 更适合作为后续扩展时的预留选项，而不是当前阶段必须启用的默认配置。原则很简单：先只保留真正需要的入口，后面再根据实际需求逐步增加。

OpenClaw VPS 部署中：安装 Node.js 22，为 OpenClaw 准备运行环境

在开始安装 OpenClaw 之前，我先把 Node.js 22 环境准备好。这一阶段的重点不是“装了 Node 就结束”，而是确保后面 OpenClaw 的安装环境是清晰、稳定、可验证的。

环境不对，后面很多看起来像 OpenClaw 本身的问题，其实都只是依赖层没准备好。所以我会在安装完成之后，顺手验证 node 和 npm 版本，确保后续安装链路是通的。

OpenClaw 部署前为什么运行环境要先准备好

OpenClaw 依赖 Node.js 运行，如果前面的环境没有先准备好，后面一旦出现安装失败、命令不可用、依赖异常或版本不兼容，排错就会被迫往回倒。与其等到 OpenClaw 安装阶段再判断问题到底出在程序本身还是依赖层，不如先把 Node.js 运行环境单独处理干净。

VPS 部署中如何确认 Node.js 和 npm 可用

在 Ubuntu 24.04 上，我这里直接使用 NodeSource 提供的 Node.js 22 安装源。安装完成之后，再分别检查 node -v 和 npm -v，确认 Node.js 和 npm 都已经能够正常使用。

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v
npm -v

OpenClaw VPS 部署中：正式安装 OpenClaw

环境准备好之后，我才正式安装 OpenClaw。这里我先只做安装，不马上完成全部向导，这样结构更清楚，也更利于排查问题。

安装结束后，我会先确认 OpenClaw 的版本信息，再处理 PATH，把 `~/.npm-global/bin` 加入 shell 配置中。否则新终端里很容易出现 `command not found`，这类问题没技术含量，但很烦。

所以这一阶段的重点其实有两个：

确认 OpenClaw 已经正确安装
确认后续在新终端里也能直接调用 openclaw

OpenClaw VPS 部署中如何确认 OpenClaw 已安装成功

【代码预留：安装 OpenClaw】
【截图预留：OpenClaw 安装输出】
【代码预留：配置 PATH】
【代码预留：which openclaw 与 openclaw –version】
【截图预留：OpenClaw 版本确认】

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
~/.npm-global/bin/openclaw --version
~/.npm-global/bin/openclaw onboard --install-daemon

这里根据网络情况，安装速度可能会有明显差异，慢一点是正常现象，不用把安装时间本身误判成故障。

下面是我这里的实际安装输出：

admin@ubuntu:~$ curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

  🦞 OpenClaw Installer
  I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

✓ Detected: linux

Install plan
OS: linux
Install method: npm
Requested version: latest
Onboarding: skipped

[1/3] Preparing environment
✓ Node.js v22.22.1 found
· Active Node.js: v22.22.1 (/usr/bin/node)
· Active npm: 10.9.4 (/usr/bin/npm)

[2/3] Installing OpenClaw
✓ Git already installed
· Configuring npm for user-local installs
✓ npm configured for user installs
· Installing OpenClaw v2026.3.8


✓ OpenClaw npm package installed
✓ OpenClaw installed

[3/3] Finalizing setup

! PATH missing npm global bin dir: /home/admin/.npm-global/bin
  This can make openclaw show as "command not found" in new terminals.
  Fix (zsh: ~/.zshrc, bash: ~/.bashrc):
    export PATH="/home/admin/.npm-global/bin:$PATH"

🦞 OpenClaw installed successfully (OpenClaw 2026.3.8 (3caab92))!
Finally unpacked. Now point me at your problems.

· Skipping onboard (requested); run openclaw onboard later

FAQ: https://docs.openclaw.ai/start/faq
admin@ubuntu:~$

为什么 OpenClaw 部署中要处理 PATH

从安装输出里可以看到，OpenClaw 本体已经装好了，但安装器同时也明确提示：当前 shell 的 PATH 里还没有包含 npm 的全局用户目录。这意味着你在当前终端里也许还能直接调用某些路径下的命令，但一旦重新打开新终端，很可能就会遇到 command not found。

所以这里不能停在“已经装好了”这一步，而是要顺手把 openclaw 加进 PATH，确保后续所有新终端都能直接调用。

我这里的处理方式如下：

admin@ubuntu:~$ echo 'export PATH="/home/admin/.npm-global/bin:$PATH"' >> ~/.bashrc
admin@ubuntu:~$ source ~/.bashrc
admin@ubuntu:~$ which openclaw
/home/admin/.npm-global/bin/openclaw
admin@ubuntu:~$ openclaw --version
OpenClaw 2026.3.8 (3caab92)
admin@ubuntu:~$

OpenClaw VPS 部署中：进入 OpenClaw 初始化流程

OpenClaw 安装完成之后，下一步才是正式进入初始化流程。这一阶段的重点，不是单纯把向导一路点完，而是先把 OpenClaw 的基础运行方式、模型接入方式和授权链路整理清楚。

从文章结构上看，这一部分建议以截图为主，因为这里的大多数步骤本质上都是界面选择和授权确认，直接放太多命令意义不大，反而容易把读者带乱。

OpenClaw VPS 部署中初始化流程要完成什么

先在服务器上调出 OpenClaw 的终端配置向导。我这里是直接进入 TUI，再继续完成后续初始化配置：

openclaw tui

如果你前面安装时还没有完成 daemon 安装，也可以先执行：

openclaw onboard --install-daemon

这一步主要完成四件事：

调出 OpenClaw 的终端配置向导
确认当前实例是个人使用边界，而不是默认开放给多人共享
选择引导模式、模型来源和授权方式
为后续 OAuth 浏览器授权做好准备

【进入 OpenClaw 向导界面】

OpenClaw 初始化流程中的界面选择

进入终端配置向导之后，首先会看到一段安全提示，大意是：OpenClaw 目前仍然处于测试阶段，更适合在个人可信边界内使用，而不是默认拿来做共享或多用户环境。

这里我选择继续，并确认“这是默认的个人账户环境，共享 / 多用户使用需要额外锁定”。

接下来在引导模式里，我这里选择的是 快速启动。模型提供方选择 OpenAI，授权方式选择 OAuth。这样做的好处是，后面可以直接通过本地浏览器完成授权，不需要一开始就手动处理更多额外配置。

如果你不打算使用 OAuth，而是准备改用 API Key 授权，那么这里就不要继续走浏览器授权流程，而是直接打开 OpenAI 平台，提前准备好对应的 API Key，再回到 OpenClaw 向导中完成后续配置。

【模型选择 OpenAI】

【截图预留：授权方式选择 OAuth】

打开 OpenAI 平台创建 API Key

【API Key 授权入口提示】

我这里使用的是 OAuth，所以后面会进入本地浏览器授权流程；如果你选择的是 API Key 授权，那么这里只需要先到 OpenAI 平台创建 API Key，复制到向导中填写一次并保存。需要注意的是，API Key 的完整内容通常只会显示一次，关闭或离开创建页面后就不能再完整查看，所以创建后要先妥善保存，再继续后续配置

这里还需要说明一点：不同模型提供方的授权流程在结构上其实差不多，通常都是先选择模型来源，再选择授权方式，然后通过浏览器登录、API Key 或其他方式完成凭证绑定。我这里选择的是 OpenAI，只是为了把主流程讲清楚，并不代表其他模型提供方在操作逻辑上有本质区别。

也就是说，这一节更重要的不是“你必须用 OpenAI”，而是你要理解这类授权流程的共性：先确定模型来源，再完成授权绑定，最后让本地浏览器、回调地址和 VPS 上的 OpenClaw 进程正确接通。只要这一层逻辑理解了，后面即使换成别的模型提供方，整体操作路径通常也不会差太多。

OpenClaw VPS 部署中：使用 SSH 端口转发，完成本地授权回调

在初始化过程中，有些步骤需要本地浏览器参与授权或回调。这种情况下，我会先在 Mac 上新开一个终端，通过 SSH 端口转发，把本地 localhost:1455 转发到 VPS 的 127.0.0.1:1455。

这里的重点不是“会不会写这条命令”，而是理解它的作用：服务仍然在 VPS 上，本地只是借助转发参与某些授权流程。这种做法也符合前面整体的收口逻辑——不直接扩大暴露面，而是通过临时隧道完成本地交互。

为什么 OpenClaw 部署中需要本地端口转发

因为 OAuth 授权页面最终需要在本地浏览器里打开，而实际回调服务却运行在 VPS 上。如果不做端口转发，本地浏览器虽然能看到授权链接，但未必能正确访问 VPS 上等待回调的本地地址。

所以这里必须把本地 localhost:1455 和 VPS 的 127.0.0.1:1455 临时打通。这样浏览器以为自己在访问本地回调地址，实际请求却被 SSH 隧道转发到了服务器上的 OpenClaw 授权进程。

OpenClaw 授权回调的实际顺序

这里的顺序非常关键，不能写反。

当终端里出现类似 “OAuth URL 已就绪，请在本地浏览器中打开这个 URL” 的提示之后，应该按下面这个顺序来做：

先把终端里给出的 OAuth URL 复制出来
在本地浏览器里先准备好这个 URL
然后在 Mac 上新开一个终端
再执行 SSH 端口转发命令
端口转发建立成功后，回到浏览器打开刚才的 URL
按提示完成授权和重定向

这里一定要强调：先拿到 OAuth URL，并在本地浏览器中打开这个 URL；然后再在 Mac 上新开一个终端，执行 SSH 端口转发命令。只有本地 localhost:1455 和 VPS 的 127.0.0.1:1455 被打通之后，浏览器中的授权流程才能继续正常跳转。
如果顺序反了，最常见的结果就是授权页面打不开，或者回调地址无法访问。

建立本地到 VPS 的回调转发

我这里是Mac，所以在 Mac 上新开一个终端之后，执行下面的命令：

ssh -N -L 1455:127.0.0.1:1455 admin@100.97.249.73

这条命令的作用是，把本地的 localhost:1455 临时转发到 VPS 上的 127.0.0.1:1455。只要这条转发链路保持开启，本地浏览器访问对应的回调地址时，请求就会被送到服务器上的 OpenClaw 进程。

【终端显示 OAuth URL 已就绪】

【本地新终端执行端口转发】

ssh -N -L 1455:127.0.0.1:1455 admin@100.97.249.73


【浏览器授权页面】

【粘贴重定向 URL】

【回调完成】

完成这一步之后，本地浏览器授权链路就已经和 VPS 上的 OpenClaw 进程成功接通，后面就可以继续进入模型接入和通道配置阶段。

OpenClaw VPS 部署中：确认默认模型已配置完成

接下来进入模型配置确认阶段。这里的重点，不只是“已经选了一个模型”，而是确认 OpenClaw 已经真正拿到了可用的默认模型配置，后面可以继续进入实际交互和通道接入。

模型配置完成之后，OpenClaw 才从“系统里装好的框架”变成“真正能响应、能处理任务的实例”。这一阶段我会按向导确认默认模型已经设定完成，并检查当前模型链路是否已经生效。

这里需要说明一点：当前设置的是默认模型，并不代表后面必须一直固定使用这一项。随着后续使用场景变化，你仍然可以根据实际需求再调整模型提供方、默认模型或授权方式。也就是说，这一步更重要的是先把主流程打通，而不是一开始就把所有模型选择一次性定死。

为什么 OpenClaw 部署中模型配置是关键环节

如果没有模型配置，OpenClaw 就只是一个已经安装完成的外壳。只有当默认模型真正设定完成，后面的对话、测试和 Telegram 通道才有实际运行基础。

OpenClaw VPS 部署中如何确认模型配置已经生效

从当前界面可以看到，OpenClaw 已经提示 Model configured，并且默认模型已经设置为 openai-codex/gpt-5.4。这说明模型配置结果已经被成功写入，后续可以先保留当前默认模型，继续进入下一步配置；如果后面有新的需求，再回过头调整也完全来得及。

【默认模型配置完成】

OpenClaw VPS 部署中：对接 Telegram，让 OpenClaw 真正可用起来

Telegram 对接是整个 OpenClaw VPS 部署里最有“使用感”的一步。因为到这里，OpenClaw 不再只是 VPS 上运行的一个后台实例，而是变成了一个你可以通过 Telegram 直接触达和交互的在线助手。

这一步我会先按向导接入 Telegram Bot，确认 token 正常。

这一阶段的重点是：Telegram 不是附加演示功能，而是 OpenClaw 从“部署完成”进入“开始实际可用”的关键入口。

OpenClaw VPS 部署中 Telegram 对接的实际价值

对接完成之后，OpenClaw 就不再只是 VPS 上的一个后台实例，而是变成了一个真正可交互的在线入口。后续无论是状态查询、日常对话，还是继续扩展自动化能力，Telegram 都会成为最直接的使用通道之一。

OpenClaw 部署中如何接入 Telegram Bot

如果你之前已经有可用的 Telegram Bot，那么这里可以直接跳过创建过程，继续使用现有 Bot 的 token 进入接入流程。

如果你还没有 Telegram Bot，那么先到 Telegram 里的 BotFather 创建一个新的 Bot。创建完成之后，打开 BotFather，找到对应的 Bot，复制生成好的 Bot Token，再回到 OpenClaw 向导继续完成配置。

在接入过程中，我这里的处理顺序是：

提供 Telegram Bot Token
跳过供应商搜索
跳过缺失技能依赖项安装
跳过 hooks 配置
选择 Hatch in TUI (recommended)，继续在 TUI 中完成后续流程

【Telegram Bot 配置界面】

【BotFather 获取 token 过程】

【提供此 Telegram 机器人令牌】

【输入 Telegram 机器人令牌】

这里要注意，：号前的id 也是。我这里截图错误

比如完整的令牌。 67095xxxxx:AAHzxMkS-hs5JK42mfTGI-xGXB9v4Hxxxxx

【搜索供应商，选跳过】

【安装缺失的技能依赖项，选跳过】

【开启 hooks，选跳过】

【截图预留：选择 Hatch in TUI (recommended)】

这里我把供应商搜索、缺失技能依赖安装和 hooks 配置先跳过，原因不是它们不重要，而是当前阶段还没有必要提前全部装上。对这类能力，更合理的做法是：先把 OpenClaw 的主流程跑通，后续真正用到什么，再补什么。

这样做的好处很直接。第一，可以避免在主链路还没验证完成时，就把额外依赖和扩展项一起堆进来，导致排错范围变大。第二，可以避免装上一批暂时用不到的能力，增加系统复杂度和后续维护负担。对个人部署来说，先收敛、后扩展，通常比一开始全装更稳。

所以这里选择跳过，不是放弃这些能力，而是把它们留到后续真正需要时再安装。如果你后面想继续扩展更多能力，可以查看了解更多 Skills。

OpenClaw VPS 部署中：完成机器人基础设定、测试与 Telegram 通道验证

在 Telegram Bot 接入完成之后，我继续处理了一些实例层面的收尾工作，包括给机器人设定基础人格、配置 Git 身份、完成模型侧测试，以及通过 Telegram 实际完成一次通道验证。

这些内容本身不是 SSH 收口或系统加固那种安全主线，但它们决定了这个实例是不是已经从“部署完成”真正进入“可以稳定使用”的状态。也就是说，到这里 OpenClaw 不只是已经装好，而是已经开始具备持续交互和实际使用的条件。

OpenClaw 使用中基础人格配置有什么作用

基础人格配置的作用，不是做花哨设定，而是让后续交互风格、回答方式和默认行为更稳定。对于一个会长期在线、并且可能持续参与实际任务的实例来说，越早把这些基础行为边界设清楚，后面越不容易在使用过程中来回返工。

Git 身份配置也属于同一类准备工作。它本身不复杂，但如果后面真的涉及仓库操作、提交记录或自动化流程，这一步迟早都要补。与其等到实际用到时再回头排查，不如在这个阶段一次处理干净。

【人格设定界面】

参考人格设定：

Your name is Clove.
Call me admin.
You are a machine familiar.
Your vibe is calm, competent, and slightly dry.
Your emoji is 🦀.
Keep responses concise, practical, and technically precise.


Your name is Clove.
Call me admin.
You are an AI operations assistant for a self-hosted OpenClaw setup.
Your vibe is calm, sharp, practical, and concise.
Your emoji is 🦀.
Prioritize technical accuracy, clear steps, and minimal fluff.


【Git 身份配置】

Git 身份配置的作用很直接：让这台 VPS 上的 Git 知道后续提交记录应该记到谁名下。否则即使 OpenClaw 已经能够正常保存文件、修改内容，真正执行到提交这一步时，还是会因为缺少 user.name 和 user.email 而被 Git 拦住。

所以这里我顺手补上 Git 的全局身份配置，把这个基础问题先处理掉，避免后面真的用到提交功能时再回头排查。

git config --global user.name "admin"

git config --global user.email "your-email@example.com"

模型测试与 Telegram 通道验证

基础设定完成之后，我这里会先做一次模型侧测试，确认当前实例已经能够正常响应。这一步的意义，不只是“能回一句话”，而是验证前面的模型接入、权限绑定和基础设定已经真正串起来了。

在确认模型测试成功之后，我再到 Telegram 里给机器人发送 /start，拿到系统返回的验证码。然后回到服务器上输入对应验证码，完成 Telegram 配对。到这一步为止，模型链路、机器人设定和 Telegram 通道才算真正全部打通。

【测试成功界面】

【Telegram 中发送 /start ，验证码显示】

【输入验证码完成配对】

执行命令：openclaw pairing approve telegram 2EQHTMR8

【全部对接成功】

OpenClaw VPS 部署中：收紧 Telegram 访问范围

Telegram 通道打通之后，不能停在“能用”这一步。因为默认能跑，不等于默认安全。

所以接下来我做的事情，是把 channels.telegram 的访问策略从开放状态收紧到 allowlist。也就是只允许明确的 Telegram 用户 ID 访问，而不是谁加到机器人都能碰到实例。

这一阶段的重点和前面的 SSH、Tailscale 是一致的：不是只追求“接上了”，而是追求“接上了，而且边界清楚”。

为什么 OpenClaw 部署中 Telegram 也要做 allowlist

只要 Telegram 已经成为一个真实可用的交互入口，它就不应该继续保持“谁能碰到 Bot，谁就能试着接近实例”的状态。对个人部署来说，更合理的做法是先把私聊访问范围收缩到明确的用户 ID，再决定后面是否要扩展。

这样做的意义很直接：先把入口收紧，再谈后续能力扩展。否则 Telegram 虽然接上了，但边界还是松的，前面做的 SSH 收口和私网接入就只完成了一半。

OpenClaw VPS 部署中如何修改 Telegram allowlist 配置

这里我直接在终端里让 OpenClaw 修改 ~/.openclaw/openclaw.json 里的 channels.telegram 配置，要求如下：

dmPolicy 改成 "allowlist"
allowFrom 改成 ["6599683792"]
enabled 保持 true
groupPolicy 保持 "allowlist"
streaming 保持 "partial"
不修改 botToken，除非明确提供新的 token
修改完成后，只显示更新后的 Telegram 配置片段用于确认

在终端里可以直接这样下达：
请修改 ~/.openclaw/openclaw.json 里的 channels.telegram 配置：

dmPolicy 改成 “allowlist”
allowFrom 改成 [“6599683792”]
enabled 保持 true
groupPolicy 保持 “allowlist”
streaming 保持 “partial”
不要修改 botToken，除非我明确提供新 token

修改完成后，只把更新后的 telegram 配置片段显示给我确认。

修改完成后立即重载并确认配置已生效

只改配置文件还不够，还要让新策略真正生效。所以在配置修改完成之后，我会继续在终端里要求它立刻重载或重启 OpenClaw，并确认新的 Telegram allowlist 已经处于激活状态。

Now reload or restart OpenClaw so the Telegram allowlist takes effect, and then confirm the new config is active.

OpenClaw VPS 部署中：收紧配置文件权限，保护本地凭证与配置

在 OpenClaw 的基础配置完成之后，我又专门处理了一次配置目录和配置文件权限。原因很简单：这类文件里通常会包含通道设置、模型信息、令牌配置以及其他敏感连接信息。如果权限过宽，前面做的 SSH 收口和私网接入就会被自己削弱。

所以这里我只做两条最基本的权限收紧命令：

这样可以确保配置目录只对当前用户可进入，配置文件也只允许当前用户读写。

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json

OpenClaw VPS 部署中：运行安全审计，确认当前部署的真实状态

到这里，实例已经基本可用了，但不能靠感觉判断“应该差不多安全了”。所以我继续执行了 OpenClaw 的安全审计：

openclaw security audit --deep

审计结果显示：本次部署没有 critical 级问题，但仍然存在 2 个警告和 1 个信息项。这说明当前实例没有明显的致命缺口，但还不能简单理解成“已经完全收紧”，而是需要继续判断哪些提示属于预期状态，哪些才是后续还要继续处理的配置问题。

OpenClaw VPS 部署中如何理解安全审计结果

从当前结果来看，整体状态是可控的：0 critical · 2 warn · 1 info。这意味着主链路已经可以继续使用，但审计同时也明确提醒，某些配置虽然不构成立即风险，却仍然值得后续继续收敛。

admin@ubuntu:~$ openclaw security audit --deep

在完成 OpenClaw 的基础配置后，我对当前实例执行了安全审计。审计结果显示，本次部署不存在 critical 级别风险，但仍有若干需要解释和继续收敛的警告项。

首先，Control UI 当前保持为 loopback 本地绑定，仅通过 SSH 隧道访问，因此 trusted_proxies_missing 警告属于预期状态。在没有使用反向代理、也没有将 Dashboard 暴露到公网的前提下，这一项不构成实际风险。它真正提示的是：如果未来你把 Control UI 放到反向代理后面，就必须补充可信代理配置。

其次，审计指出 gateway.nodes.denyCommands 中部分命令名称无效。这说明有些限制项虽然写进了配置，但实际上并不会真正生效。这个问题比“没有写限制”更麻烦，因为它容易制造一种“已经限制住了”的错觉。因此，后续如果还要继续收紧工具权限，就不能依赖旧命令名或看起来像限制的字段，而必须严格按照 OpenClaw 当前支持的真实命令集合进行精确约束。

除此之外，审计信息还表明，当前实例仍应被视为“单一可信边界下的个人助手”，而不是适合开放给不受信任用户共享使用的多租户系统。这一点和前面的整体部署思路是一致的：本地绑定、SSH 隧道、Tailscale 私网和 Telegram allowlist，目标都不是把它做成开放平台，而是把它收敛成一个个人可控的长期在线助手。

因此，在实际部署中，我保留了本地绑定与 SSH 隧道访问方式，并将后续安全优化重点继续放在三个方向上：收紧工具权限、清理无效限制项，以及进一步控制可访问用户范围。

OpenClaw VPS 部署中：用系统状态检查，验证部署是否真正跑稳

做完安全审计之后，我又继续从系统层和 OpenClaw 层分别检查当前状态，包括：

防火墙规则
监听端口
Tailscale 状态
OpenClaw 深度状态
OpenClaw doctor 输出

这一轮检查的目的，不是重复确认，而是把“部署完成”这件事落到具体结果上：哪些端口在监听、哪些入口被放行、Telegram 是否已正常工作、OpenClaw 当前是否存在明显异常，这些都必须能被明确看见，而不是靠想象。

为什么 OpenClaw 部署后还要做系统状态复核

前面的安装、初始化、接入和配对，只能说明主流程已经打通；但一套长期在线的实例，真正要看的是当前状态是否一致。也就是说，配置文件里写了什么是一回事，运行中的服务到底在监听哪些端口、Telegram 通道是否真的正常、OpenClaw 本体有没有明显异常，又是另一回事。

所以这一步不是“多做一次检查”，而是把部署结果从配置层拉回运行层，确认这套环境现在确实处在一个能继续长期运行的状态。

OpenClaw 状态检查里哪些结果最值得关注

这里我主要按下面这组顺序检查：

sudo ufw status  
ss -tulnp  
tailscale status  
openclaw status --deep  
openclaw doctor

admin@ubuntu:~$ sudo ufw status 
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       100.64.0.0/10

admin@ubuntu:~$ openclaw doctor

🦞 OpenClaw 2026.3.8 (3caab92) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                  🦞 OPENCLAW 🦞                    
 
┌  OpenClaw doctor
│
◇  Update ──────────────────────────────────────────────────────────────────────────────────╮
│                                                                                           │
│  This install is not a git checkout.                                                      │
│  Run `openclaw update` to update via your package manager (npm/pnpm), then rerun doctor.  │
│                                                                                           │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Startup optimization ─────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM).  │
│  - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from        │
│    self-respawn.                                                                           │
│  - Suggested env for low-power hosts:                                                      │
│    export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache                               │
│    mkdir -p /var/tmp/openclaw-compile-cache                                                │
│    export OPENCLAW_NO_RESPAWN=1                                                            │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Security ─────────────────────────────────╮
│                                            │
│  - No channel security warnings detected.  │
│  - Run: openclaw security audit --deep     │
│                                            │
├────────────────────────────────────────────╯
│
◇  Skills status ────────────╮
│                            │
│  Eligible: 3               │
│  Missing requirements: 48  │
│  Blocked by allowlist: 0   │
│                            │
├────────────────────────────╯
│
◇  Plugins ──────╮
│                │
│  Loaded: 5     │
│  Disabled: 33  │
│  Errors: 0     │
│                │
├────────────────╯
│
◆  Enable bash shell completion for openclaw?
│  ● Yes / ○ No
└

先看防火墙规则，确认当前 SSH 入口是否已经收紧到预期范围；再看监听端口，确认 OpenClaw 的控制面板和相关服务是否仍然保持在本地绑定，而不是被意外暴露；然后检查 Tailscale 状态，确认私网链路本身没有掉；最后再用 openclaw status --deep 和 openclaw doctor 从实例内部角度做一次整体复核。

从这一步的结果来看，最值得关注的有四类信息：

UFW 规则是否符合预期
如果 22 端口已经只允许 Tailscale 网段访问，说明前面的 SSH 收口已经真正落地，而不是只停留在配置层面。
监听端口是否仍然保持收敛
ss -tulnp 的重点不是看“开了多少端口”，而是看 OpenClaw 的关键入口是否仍然绑定在 127.0.0.1 / ::1，而不是不小心暴露到公网。
Telegram 通道是否真的在线
在 openclaw status --deep 里，Telegram 必须明确显示为 OK，这比“之前配对成功过一次”更有价值，因为它说明当前运行态下通道依然可用。
doctor 给出的建议是风险还是优化项
openclaw doctor 里并不都是错误。像更新提醒、启动优化建议、shell completion 提示，这些更多是优化项；而真正要特别注意的是会不会出现通道异常、权限异常或模型侧明显缺失。

我这里实际重点确认了什么

从当前输出结果看，这套部署至少说明了几件关键事情。

首先，防火墙已经处于激活状态，22 端口只对 100.64.0.0/10 这个 Tailscale 网段放行。这意味着 SSH 管理入口已经不再维持公网默认可见，而是确实收进了私网。

其次，监听状态里 OpenClaw 的几个关键端口仍然保持在 127.0.0.1 和 ::1 上，本地控制面板没有直接对外暴露。这和前面“本地绑定 + SSH 隧道访问”的部署思路是一致的。

再次，在 openclaw status --deep 里，Telegram 通道明确显示为 OK，并且已经存在对应的 direct session。这说明 Telegram 通道不是“曾经接通过”，而是当前运行态下仍然可用。

最后，openclaw doctor 没有给出新的通道安全警告，但提示了若干优化项，比如更新方式、启动性能以及 memory search 相关状态。这类信息不代表当前实例不能用，但说明后面还有进一步收敛和整理的空间。

关于 shell completion 的提示

openclaw doctor 在最后还会询问是否开启 bash shell completion。这个选项本身不影响当前部署是否可用，它只是让你在 bash 里输入 openclaw 命令时，后续子命令能够通过 Tab 自动补全。

如果你平时确实主要在 bash 里管理这台机器，这里选 Yes 会更顺手；如果你并不依赖命令补全，这一步也不会影响实例运行。

这一轮检查之后，部署状态意味着什么

经过这一轮复核，当前这套 OpenClaw VPS 部署已经不只是“流程走完了”，而是具备了下面这些可验证的运行特征：

SSH 入口已经收进 Tailscale 私网
OpenClaw 控制面仍保持本地绑定
Telegram 通道当前可用
实例本体没有出现明显的致命异常
doctor 提示更多是优化项，而不是阻断项

也就是说，到这一步，部署已经从“能装起来”进入了“能稳定跑起来”的阶段。后面要处理的重点，不再是主链路能不能通，而是如何继续收敛那些不影响运行、但会影响长期维护体验的细节问题。

OpenClaw VPS 部署中：关闭暂时无用的 memory search，保持实例状态清晰

在 openclaw doctor 的输出里，我看到了 memory search 的提醒：当前虽然启用了这项能力，但并没有配置 embedding provider 的 API Key。

这种情况下，我的处理方式不是立刻去补更多 API，而是先把这个半配置功能关掉。原因很简单：一个长期运行的实例，最怕的不是功能暂时少一点，而是很多能力挂在那里半开不开、持续报提醒，最后把整体状态搞得越来越乱。

所以这里我选择先关闭默认的 memory search，让当前实例保持一个更清晰、更可控的运行状态。等到后面真的需要语义检索或记忆搜索时，再按需求重新配置，也更合理。

为什么 OpenClaw 部署中要关闭半配置功能

半配置功能的问题不在于“不能用”，而在于它会持续制造噪音，让你误以为系统还有一堆隐性故障。对个人部署来说，先把当前真正需要的主链路跑稳，再按需补功能，通常比一开始把所有能力都半开着更稳。

这里直接执行下面这条命令即可：

openclaw config set agents.defaults.memorySearch.enabled false

OpenClaw VPS 部署完成后，终端还能不能关

到了这一步，OpenClaw 已经不再依赖当前 SSH 会话或前台终端继续存在。也就是说，本地终端窗口可以关闭，SSH 会话可以退出，临时的 OAuth 或 Dashboard 端口转发也都可以停掉，而 OpenClaw 本体仍然会在 VPS 里继续运行。

这一点必须说清楚，因为很多人第一次做 OpenClaw VPS 部署时，很容易把“当前终端窗口”误当成“服务本体”。实际上，两者根本不是一回事：你当前登录的 shell 只是管理入口，真正持续运行的是后台服务。

后续如果还需要进入交互界面，可以重新 SSH 登录服务器，再执行对应命令进入 TUI；如果只是检查状态，则直接查看当前实例运行情况即可。

OpenClaw VPS 部署完成后如何重新进入 TUI

如果后面还需要重新进入交互界面，重新登录 VPS 之后直接执行下面的命令即可：

openclaw tui

这一步只是重新进入当前实例的终端交互界面，不会影响已经在后台运行的 OpenClaw 服务。

OpenClaw VPS 部署完成后如何查看状态

如果不需要重新进入 TUI，而只是想确认实例当前是否正常运行，那么直接执行下面的命令即可：

openclaw status --deep

这个命令更适合用来检查当前的整体运行状态，包括服务本体、通道状态、模型配置和会话信息。

OpenClaw VPS 部署完成后如何重新进入 Web UI

如果后面还需要重新打开 Web 控制界面，可以先在 VPS 上执行：

openclaw dashboard

终端会返回类似下面的提示信息：

admin@ubuntu:~$ openclaw dashboard

🦞 OpenClaw 2026.3.8 (3caab92) — We ship features faster than Apple ships calculator updates.

Dashboard URL: http://127.0.0.1:18789/#token=e9265f50f8e81c331bbbe2157362b051b5554204aa3e5988
Copy to clipboard unavailable.
No GUI detected. Open from your computer:
ssh -N -L 18789:127.0.0.1:18789 admin@100.97.249.73
Then open:
http://localhost:18789/
http://localhost:18789/#token=e9265f50f8e81c331bbbe2157362b051b5554204aa3e5988
Docs:
https://docs.openclaw.ai/gateway/remote
https://docs.openclaw.ai/web/control-ui

因为 VPS 本身没有图形界面，所以这里的正确做法不是直接在服务器上“打开网页”，而是回到你自己的电脑，在本地新开一个终端，建立 SSH 端口转发：

ssh -N -L 18789:127.0.0.1:18789 admin@100.97.249.73

这条命令的作用，是把本地的 18789 端口临时转发到 VPS 上的 127.0.0.1:18789。转发建立成功之后，再在本地浏览器里访问下面这个地址：

http://127.0.0.1:18789/#token=e9265f50f8e81c331bbbe2157362b051b5554204aa3e5988

也可以直接访问：

http://localhost:18789/

如果需要直接带着登录 token 进入，就用带 #token=... 的完整地址。

这一节真正要说明什么

OpenClaw VPS 部署完成之后，你可以把当前 SSH 会话关掉，也可以把临时端口转发停掉，因为它们都只是“进入实例”的方式，不是实例本体本身。真正持续运行的是 VPS 上的后台服务，而不是你眼前这个终端窗口。

所以，到这里为止，这套部署已经进入了一个更像正式运行环境的状态：你可以随时断开管理入口，也可以在需要的时候再重新接回去，而 OpenClaw 本体会继续留在服务器上运行。

OpenClaw VPS 部署总结：这次部署真正完成了什么

回过头看，这次 OpenClaw VPS 部署真正完成的，不只是把 OpenClaw 装到 Ubuntu 24.04 上。

真正完成的是这样一条链路：

在本地准备 SSH 密钥，先打通密钥登录
通过 root 完成过渡阶段验证
创建普通管理员用户，迁移日常管理入口
正式关闭 root 远程登录，只保留 admin + 密钥认证
完成 UFW、fail2ban 等基础防护
使用 Tailscale 把管理入口从公网收进私网
安装 Node.js 和 OpenClaw
完成 OpenClaw 初始化、模型配置和 Telegram 对接
将 Telegram 访问收紧为 allowlist
运行安全审计和系统检查
关闭当前不需要的半配置功能，保持实例状态清晰

所以，这篇 OpenClaw VPS 部署实战真正想讲清楚的，不是“怎么多装几个组件”，而是下面这件事：

当 OpenClaw 从本地测试走向长期在线，并开始承载真实账号、真实 API、真实交互入口和自动化能力之后，部署思路就必须从“先跑起来”升级为“先把边界收清楚，再让它长期运行”。

到这里，这只龙虾就不只是“装上了”，而是真的开始能用了。

前面折腾 SSH、Tailscale、Telegram、权限和配置，看起来都是些麻烦事，但本质上是在做同一件事：别把它只当成一个能跑起来的小玩具，而是把它养成一个长期在线、边界清楚、关键时候真能帮你处理事情的助手。

这里还需要补充说明一点：虽然我这次是在 Ubuntu 虚拟机里完成安装和配置，但这套 OpenClaw VPS 部署流程本身，与公网 VPS 的实际部署逻辑并没有本质区别。无论是 SSH 收口、普通管理员账户迁移、防火墙与 fail2ban 配置、Tailscale 私网接入，还是 OpenClaw 本体安装、模型配置与 Telegram 对接，核心步骤都是一致的。真正的差别，更多只体现在网络环境、外部访问路径和宿主机资源条件上，而不在 OpenClaw 的部署主链路本身。

也就是说，如果你现在不是直接在公网 VPS 上操作，而是先用 Ubuntu 虚拟机搭环境、跑流程、做验证，这条路同样成立。等你后面迁移到真正的云服务器时，整体部署顺序和关键配置思路基本不用重写。

如果你还没有先把 Ubuntu 虚拟机环境搭起来，可以先看我前面的安装文章：

也希望大家在养龙虾的过程中，少一点“先跑起来再说”，多一点“先把入口和权限收清楚”。这样后面无论是接更多工具、加更多能力，还是让它替你做一点真正有用的自动化，都不会越养越乱。

愿你的龙虾，能活着，能干活，别拆家。

如果你在养龙虾的过程中遇到卡点，也欢迎在下面留言交流。

Book Flights Worldwide with Ease

Book Airport Transfers & Car Rentals Easily

Buy Travel Insurance with Ease

OpenClaw VPS 部署实战：Ubuntu 24.04 上完成 SSH 收口、Tailscale 私网接入与 Telegram 对接

摘要