2026 OpenClaw и Matrix на Linux VPS: включение плагина, homeserver и токен доступа, воспроизводимая маршрутизация по нескольким комнатам и поуровневая диагностика сбоев синхронизации (FAQ)

Matrix даёт федерацию комнат, опциональное сквозное шифрование и единый клиентский HTTP API — инфраструктура чата вместо зоопарка проприетарных SDK. Удерживать OpenClaw Gateway на Linux VPS в облаке рядом с Matrix — типичный паттерн: недорогой постоянно включённый CPU, предсказуемый исходящий TLS до homeserver и изоляция команд на уровне комнат. Эта заметка — воспроизводимый чеклист: включить плагин Matrix, безопасно связать URL homeserver и access token, настроить несколько комнат без «дрейфа» алиасов и затем разложить «залипшую» синхронизацию по слоям L0–L3. Общие принципы изоляции секретов и лёгкого VPS для всплесков ИИ-смежных задач см. в материале 2026: короткие циклы и пакетные всплески ИИ-инструментов — ежедневный облачный Mac и лёгкий VPS: изоляция, исходящий трафик и секреты (матрица + FAQ).

Включение плагина Matrix: воспроизводимый базис

Установите или обновите OpenClaw на VPS тем же каналом, который уже закрепили у себя (пакетный менеджер, статический бинарник или контейнер). Затем активируйте интеграцию Matrix в конфигурации Gateway так, чтобы процесс поднимал плагин при старте, а не только из интерактивного профиля оболочки. После правок перезапустите юнит супервизора (systemctl restart … или эквивалент) и убедитесь по журналу запуска, что плагин регистрируется до экспериментов с токенами. Если Gateway слушает только 127.0.0.1, это не мешает Matrix; ошибочно принимать «ещё не готов reverse proxy» за сбой синхронизации не стоит.

Для systemd разумно вынести переменные Matrix в профильный EnvironmentFile= с правами 640 и владельцем сервисным пользователем, а сам файл версионировать рядом с остальной инфой об инфраструктуре (без секретов в Git — только шаблон и путь к vault). Так восстановление машины не превращается в охоту за «где лежал токен», а смена релиза OpenClaw не смешивается со случайным export из интерактивной сессии.

# 1) Версия Gateway совпадает с документацией
openclaw version   # или команда вашего пакета

# 2) Исходящий HTTPS до homeserver (SNI + доверенные CA)
curl -sS -o /dev/null -w "%{http_code}\n" https://matrix.example.org/_matrix/client/versions

# 3) После перезапуска плагин виден в логах
sudo systemctl restart openclaw-gateway
journalctl -u openclaw-gateway -b --no-pager | tail -n 80

Homeserver, MXID и access token

Базовый URL укажите на корень Client-Server API, который объявляет сервер, обычно https://<хост> без лишних суффиксов пути. MXID бота (@bot:domain) должен принадлежать пространству имён этого сервера. Создайте отдельную учётную запись бота, один раз выполните вход через UI/API, затем перенесите долгоживущий access token в хранилище секретов (systemd credentials, Vault или запечатанные переменные у провайдера) — никогда не коммитьте его в Git. После ротации токена перезапустите Gateway, чтобы сессия в памяти не продолжала использовать старый ключ.

export MATRIX_HS_URL="https://matrix.example.org"
export MATRIX_USER_ID="@openclaw-bot:example.org"
export MATRIX_ACCESS_TOKEN="syt_..."   # из защищённого хранилища, не из history
export MATRIX_DEVICE_ID="OPENCLAW_VPS_01"  # стабильный device_id упрощает аудит

Маршрутизация по нескольким комнатам без сюрпризов

Строки-алиасы (#team:domain) могут переезжать; идентификаторы комнат (!abcdef:domain) стабильнее. В конфиге перечисляйте разрешённые комнаты явно и сопоставляйте каждую с профилем политики Gateway (модель, инструменты, лимиты). Публичный HTTPS для вебхуков вендоров и клиентский трафик Matrix логично разводить: шаблоны firewall и привязка Gateway к loopback описаны в гайде 2026 OpenClaw на Linux в облаке: минимальная поверхность атаки — шаблоны firewall, привязка Gateway к loopback, SSH-туннель для управления и публичный HTTPS (матрица и FAQ). Если с того же VPS нужно принимать обратные вызовы с TLS и туннелями, см. также 2026 OpenClaw: вебхуки каналов и динамический egress — Cloudflare Tunnel, Tailscale Funnel и reverse proxy на Linux VPS (матрица и FAQ).

FAQ по слоям: синхронизация и «тихие» сбои

Та же терминология L0–L3, что и в других заметках OpenClaw про Linux, чтобы тикеты с разных каналов складывались в один стиль разбора.

Перед включением в прод проведите короткий дымовый тест: сообщение из первой разрешённой комнаты → ожидаемый ответ в том же треде → повторите для второй комнаты с другим стабильным room_id. Если ответы «перепрыгивают» между комнатами, чаще всего виноваты два процесса Gateway с пересечением каталога состояния или один процесс с противоречивой картой маршрутизации в конфиге — это уже не «Matrix медленно синхронизируется», а локальная ошибка развёртывания.

L0 — нет HTTP-достижимости homeserver

С VPS выполните curl -v на базовый URL HS. Здесь виноваты DNS, доверие к корпоративному CA, отсутствующие корни в trust store или исходящий firewall — ещё не логика Matrix-клиента.

L1 — 401 / 403 на Client API

Отозванный token, неверный MXID или IP allow-list на стороне HS. Выпустите новый токен, сверьте формат Authorization: Bearer с библиотекой клиента и убедитесь, что бота действительно пригласили в тот room ID, который указан в конфигурации.

L2 — петли синхронизации или долгий догон после простоя

Большие разрывы since после даунтайма выглядят как зависание. Проверьте загрузку CPU процесса, лимиты со стороны HS и не фильтруете ли вы временную шкалу в плагине чрезмерно агрессивно. Предпочитайте возобновление с сохранённым на диске sync token, а не слепой сброс состояния.

L3 — «в комнате есть, ответов нет»

Power levels, модерация, недоверенные устройства в E2EE или второй экземпляр Gateway с тем же device_id. Разводите ботов по окружениям и меняйте device_id при клонировании VM из снимков.