2026: OpenClaw и WhatsApp на Linux VPS в облаке: сопряжение по QR, сохранение сессии и несколько каналов — воспроизводимые шаги и FAQ по обрывам и 429

WhatsApp — канал, который уже есть у клиента в кармане, но для шлюза он самый шумный адаптер: окно с QR живёт недолго, файлы сессии нельзя терять, а ограничения со стороны Meta часто выглядят как «мистический обрыв», пока вы не разделите падение транспорта и бурю HTTP 429. Здесь — воспроизводимый путь для OpenClaw на облачном Linux VPS в 2026: один раз отсканировать QR, хранить состояние под отдельным пользователем ОС, держать Telegram или Slack параллельно без общих секретов и разбирать сбои по слоям, а не вслепую перезагружать машину.

Воспроизводимая установка: подготовка VPS, QR, первое сообщение

Создайте непривилегированного пользователя (например openclaw) и один корень состояния с правами записи, например /var/lib/openclaw/whatsapp, с владельцем этим пользователем. Установите OpenClaw тем же способом, что и остальной софт на сервере — tarball или контейнер — но смонтируйте каталог сессии томом с хоста, чтобы пересборки не стирали пару. Один раз запустите шлюз на переднем плане, возьмите QR из лога, отсканируйте рабочим телефоном в отведённый таймаут, дождитесь в журнале статуса «подключено», и только потом уводите процесс в фон.

Перед продом полезно сверить окружение и типовые ошибки установки по материалу 2026: OpenClaw на Linux VPS — curl vs Docker, проверка окружения и FAQ по типовым ошибкам. Если сравниваете ожидания персистентности с облачным Mac и launchd, см. Развёртывание OpenClaw на облачном Mac в 2026: проверки macOS вместо Linux VPS, launchd и воспроизводимый FAQ.

# ~/.config/systemd/user/openclaw-whatsapp.service
[Service]
WorkingDirectory=/var/lib/openclaw/whatsapp
ExecStart=/usr/local/bin/openclaw gateway --profile whatsapp
Restart=on-failure
RestartSec=5

Включите lingering для пользователя службы, если юнит должен переживать выход из сессии; ротацию логов настройте на журнал шлюза — не крутите активные файлы сессии «на лету». После первой удачной пары намеренно перезапустите службу: если сессия поднялась без нового QR, путь персистентности выбран верно.

Персистентность сессии: что должно пережить перезагрузки и обновления образа

Относитесь к хранилищу WhatsApp как к базе паролей: шифрование на диске, если сборка это поддерживает, права 0700, зашифрованные оффсайт-бэкапы и без копий «для удобства» на ноутбуках разработчиков. Пара привязывает криптоматериал к идентичности шлюза; клон каталога на второй VPS без контролируемой миграции обычно вынуждает новый QR и на короткое время удваивает исходящий трафик регистрации — типичный триггер антиабьюз-ограничений.

Снимайте снапшот каталога только при остановленном процессе; горячее копирование чревато битыми парами и внезапными «вылетами». При blue/green смонтируйте тот же том на новый инстанс до переключения трафика и выведите старую ВМ из эксплуатации только после успешной отправки и приёма сообщений на новом узле.

Путь к корню сессии и имя unit зафиксируйте в runbook, не кладите состояние на эфемерные разделы (никаких symlink в /tmp), версию пакета шлюза привяжите к unit, чтобы откаты совпадали с изменениями формата файлов в релиз-нотах.

Несколько каналов: Telegram, Slack или другие рядом с WhatsApp

Запускайте отдельные профили или процессы на канал, у каждого — свой токен или корень сессии, и одну исходящую очередь, чтобы вызовы инструментов не перемешивали ответы между сетями. WhatsApp не должен читать переменные окружения Telegram и наоборот; одной ошибочной вставки в .env достаточно, чтобы трафик ушёл в чужой адаптер при «зелёных» health-check.

Те же принципы allowlist и дедупликации, что для двух чат-сетей к одному «мозгу», закрепляйте в политике авторизации: один номер — один основной писатель в каталог сессии, без конкурирующих мостов на тот же аккаунт.

Поуровневый разбор: простой обрыв и дросселирование 429

Слой 1 — связность: проверьте исходящий UDP/TCP до конечных точек WhatsApp с самого VPS, а не с ноутбука поверх SSH. На мелких провайдерах дрожь часто связана с агрессивными GRE или «DPI»; иногда полезнее сменить egress или стабилизировать resolver, чем гнаться за версией OpenClaw.

Слой 2 — целостность сессии: если в логах конфликт или многократный logout, убедитесь, что только один основной писатель трогает каталог. Мосты, которые логинят тот же номер, выгонят сессию шлюза без внятной строки ошибки.

Слой 3 — лимиты: при повторяющихся 429 или текстах про throttling измерьте частоту исходящих сообщений в минуту, схлопните дубли автоответов, добавьте джиттер к backoff перед тяжёлыми retry. 429 — это бюджет, а не «забыли пароль»: ротация API-ключей не спасёт сессию, которая просто шлёт слишком быстро. Если часть чатов жива, а часть нет, ищите fan-out: одно входящее событие порождает пачку исходящих — коалесцируйте уведомления и разведите человека и бота по разным лимитам в рабочие часы.