На ноутбуке OpenClaw замолкает, как только закрывается крышка: сообщения в WhatsApp копятся, запланированные задачи ждут вашего возвращения. На сервере он продолжает отвечать. Но есть нюанс: шлюз — это не чат-виджет. Он хранит доступы к вашим каналам и, если не включить песочницу, запускает инструменты прямо на хосте. Переносить его на всегда включённую машину имеет смысл, только если вместе с ним переезжает и модель безопасности.
Этот гайд делает это примерно за 20 минут на свежем VPS с Ubuntu 24.04.
Проверено 2026-10-04: OpenClaw 2026.9.8 (npm), Node 24.21 LTS, Ubuntu 24.04.
Что понадобится
- Linux VPS. Мы берём наш тариф AI-Agent: 4 vCPU, 4 ГБ RAM, 40 ГБ диска, $10 в месяц. В документации OpenClaw упоминаются 6 ГБ RAM, но это для сборки их Docker-образа из исходников; npm-пакету сборка не нужна.
- API-ключ вашего провайдера моделей и аккаунты мессенджеров, которые хотите подключить.
- SSH-ключ на ноутбуке. Если его ещё нет: вход по SSH-ключу.
NAT-тариф здесь подходит, а пожалуй, и лучше. Шлюзу вообще не нужен открытый входящий порт: WhatsApp, Discord и Telegram (по умолчанию long polling) подключаются наружу сами, а к панели вы ходите через SSH. Выделенный IPv4 берите, только если нужный канал доставляет сообщения вебхуком или вы планируете публичный reverse proxy.
1. Пользователь, который не root
OpenClaw запускает инструменты от имени пользователя, которому принадлежит шлюз. Если это root, то от root выполнится и любая команда, которую решит запустить запутавшаяся или атакованная через prompt injection модель. Документация OpenClaw прямо называет запуск шлюза от root небезопасным и неподдерживаемым. Заведите отдельного пользователя без sudo:
# от root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys # ключ, добавленный при заказе
loginctl enable-linger claw
Последняя строка важнее, чем кажется. OpenClaw ставит пользовательский сервис systemd, и без lingering он останавливается, когда вы выходите из сессии. Это самое частое «вчера же работало» на серверах.
2. Node 24 и OpenClaw
OpenClaw 2026.9.8 требует Node >=24.16.0 <25 или >=26.1.0. Пакет nodejs из Ubuntu старее, поэтому берём 24 LTS из NodeSource:
# от root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v # v24.16.0 или новее
npm install -g openclaw@latest
openclaw --version
Официальная однострочная команда (curl -fsSL https://openclaw.ai/install.sh | bash) тоже работает и сама ставит Node. На сервере мы предпочитаем два явных шага: видно, что куда ложится, и бинарник оказывается в /usr/bin, а не в домашнем каталоге, куда агент может писать.
3. Onboarding от имени агента
Заходите как claw по SSH, а не через su. Только настоящий вход поднимает пользовательский менеджер systemd, который нужен сервису:
# с ноутбука (NAT-тариф: добавьте -p <ваш SSH-порт>)
ssh claw@<server>
openclaw onboard --install-daemon
openclaw gateway status
Мастер проверит доступ к модели, запишет ~/.openclaw/openclaw.json, сгенерирует токен шлюза и установит сервис. Если systemctl --user ругается на шину, выполните export XDG_RUNTIME_DIR=/run/user/$(id -u) и повторите.
Потом закройте файлы. Рекомендация самого OpenClaw — 700 на каталог состояния и 600 на конфиг:
chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep
openclaw security audit --fix применяет безопасную часть исправлений: ужесточает права на файлы и меняет открытые групповые политики на allowlist. Ничего не перепривязывает и не закрывает файрволом — сетевая доступность остаётся вашей задачей.
4. Держите шлюз на loopback
Шлюз отдаёт WebSocket API и панель на одном порту, 18789, по умолчанию привязанном к 127.0.0.1. Так и оставьте. Минимальный конфиг, где это записано явно:
// ~/.openclaw/openclaw.json
{
gateway: {
mode: "local",
bind: "loopback",
port: 18789,
auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
},
}
Токен сгенерируйте через openssl rand -hex 32 или openclaw doctor --generate-gateway-token. Пустые токены и примеры-заглушки шлюз не принимает, а аудит предупреждает, если токен короче 24 символов.
Чего делать не надо: ставить bind в "lan" и открывать порт. Документация говорит прямо: никогда не выставляйте шлюз без аутентификации на 0.0.0.0 и не пробрасывайте порт широко даже с токеном. Тот, кто получит токен, станет оператором процесса, который умеет выполнять команды на вашем сервере.
Файрвол — только SSH и больше ничего:
# от root
ufw allow OpenSSH
ufw enable
ufw status verbose
На наших NAT-тарифах кабинет показывает внешний SSH-порт, но внутри сервера sshd по-прежнему слушает 22. Разрешайте OpenSSH (порт 22), а не номер внешнего порта, иначе ufw enable отрежет вам доступ. Подробнее — в гайде по UFW.
5. Панель через SSH
С ноутбука откройте туннель и не закрывайте его:
ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# NAT-тариф: ssh -N -p <ваш SSH-порт> -L 18789:127.0.0.1:18789 claw@<host>
Откройте http://127.0.0.1:18789/ и вставьте токен шлюза. В Ubuntu sshd по умолчанию разрешает локальный проброс; если вы его ужесточали, AllowTcpForwarding local — та настройка, которая разрешает -L и запрещает обратные пробросы. Если туннель падает с administratively prohibited, проверяйте именно эту строку.
Подойдёт и tailnet: Tailscale Serve оставляет шлюз на loopback и сам управляет доступом. Оба варианта нормальные. Публичный порт — нет.
6. Pairing, песочница и кто может с ним говорить
Мессенджеры — второй вход. По умолчанию каналы с личными сообщениями требуют от незнакомых отправителей pairing; одобряете вы на сервере:
openclaw pairing approve <channel> <code>
В группах требуйте упоминание, чтобы агент не отвечал на каждое сообщение в чате. В эталонной защищённой конфигурации OpenClaw для каждого канала стоят dmPolicy: "pairing" и groups: { "*": { requireMention: true } }.
Две честные оговорки. Первая: pairing решает, кто может запустить ход, но не что попадёт в контекст модели. Пересланное сообщение или загруженная веб-страница всё ещё могут направить ход, который запустили вы. Вторая: инструменты основной сессии выполняются на хосте, пока вы не включите песочницу (agents.defaults.sandbox.mode: "non-main" изолирует всё, кроме вашей основной сессии). По умолчанию песочница выключена, а её стандартный бэкенд — Docker, так что перед включением поставьте Docker: Docker на VPS. Если с ботом в одном канале сидят люди, которым вы не доверяете, поднимите для них отдельный шлюз, лучше на отдельном сервере.
7. Обновления и бэкапы
openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify
В ~/.openclaw лежат конфиг, доступы к каналам (включая сессию WhatsApp), профили авторизации моделей и расшифровки сессий. Потеряете — придётся всё заново связывать; утечёт — кто-то другой станет вами в WhatsApp. Бэкапьте и храните копию не на этом сервере: скачайте через scp или используйте restic с шифрованием.
Чеклист
| Проверка | Команда | Ожидаем |
|---|---|---|
| Шлюз работает не от root | ps -eo user,args | grep '[o]penclaw' | claw в первой колонке |
| Переживает выход из сессии | loginctl show-user claw -p Linger | Linger=yes |
| Слушает только loopback | ss -ltnp | grep 18789 | 127.0.0.1:18789 |
| Нет публичного порта | ufw status | только OpenSSH |
| Конфиг не читается всеми | stat -c '%a' ~/.openclaw/openclaw.json | 600 |
| Аудит чистый | openclaw security audit --deep | нет критичных замечаний |
При чём здесь EQVPS
Запустить Node-процесс может много кто. Мы добавляем оплату криптой без KYC, NAT-тариф, который как раз подходит для шлюза только на loopback, и MCP-сервер, через который агент может сам управлять своими серверами. Если подключаете к нему OpenClaw, сначала прочитайте защиту MCP: токен, которым можно заказывать серверы, заслуживает той же осторожности, что и токен шлюза. Шире про агентов на VPS — в гайде по AI-агентам.
Наше мнение: эти 20 минут — разница между ассистентом и открытым shell с чат-интерфейсом. Даже если пропустите остальное, сделайте шаги 1, 4 и 5.
Комментарии
Пока нет комментариев. Будьте первым.