2026 OpenClaw на Linux VPS в облаке: параллельные шлюзы с несколькими профилями — матрица портов, пользовательские юниты systemd, изоляция каталогов OPENCLAW_* и воспроизводимое развёртывание (FAQ по конфликтам)

На одном небольшом облачном экземпляре Linux можно держать больше одного контура в духе OpenClaw Gateway: боевой бот, staging-мост и личный эксперимент — у каждого свои токены, конфиг и адрес прослушивания. Типичный сбой здесь не в том, что «Linux не умеет многозадачность», а в столкновении портов, общих каталогов состояния и юнитах systemd, которые спорят за одного пользователя или рабочий каталог. Ниже — воспроизводимый шаблон: матрица портов, отдельные для профиля юниты systemd --user, явная изоляция каталогов OPENCLAW_* и короткий FAQ по конфликтам, которые мы всё ещё разбираем в 2026 году.

Зачем параллелить профили на одном хосте?

Отдельные виртуальные машины стоят денег и IPv4; отдельные контейнеры по-прежнему делят пространство портов ядра, если неаккуратно настроить проброс. Параллельные профили на одном VPS работают, когда у каждого есть непересекающийся bind-порт, выделенный пользователь ОС или домашний каталог для прав на файлы и задокументированный префикс окружения, чтобы операторы не вставляли токен prod в юнит stage. Считайте «профиль» операционной абстракцией: prod/stage/dev или команда A против команды B — а не три копии одного и того же пути конфигурации по умолчанию.

Матрица портов: куда биндиться до reverse proxy

Решите, loopback или публичная привязка, до того как включите TLS спереди. Чаще всего каждый Gateway сидит на 127.0.0.1, а Nginx или Caddy слушает 0.0.0.0:443; тогда параллельные профили отличаются только портом loopback. Если нужен прямой HTTP наружу, расширьте матрицу строками firewall на группу безопасности. Про схемы экспозиции и компромисс SSH против публичного HTTPS см. 2026 OpenClaw на Linux в облаке: минимальная поверхность атаки — шаблоны firewall, привязка Gateway к loopback, SSH-туннель для управления и публичный HTTPS (матрица и FAQ).

Юниты systemd для пользователя: linger, slice и границы логов

Службы systemd --user под разными пользователями Linux дают чистые границы journalctl --user -u … без засорения /etc/systemd/system. Для учётных записей, которые должны жить после выхода из сессии, включите loginctl enable-linger. К каждому юниту добавьте WorkingDirectory= и EnvironmentFile= на профильный drop-in, чтобы daemon-reload никогда не склеивал два профиля по ошибке. Если удобнее системный уровень — шаблонные юниты ([email protected]); инвариант тот же: один узел графа юнитов на профиль и одна строка в матрице портов.

# /etc/openclaw/prod.env — права 640, владелец = сервисный пользователь
OPENCLAW_STATE_DIR=/var/lib/openclaw/prod
OPENCLAW_CONFIG_PATH=/etc/openclaw/prod.yaml
# Слушать Gateway — должно совпадать с матрицей портов
OPENCLAW_GATEWAY_BIND=127.0.0.1:18789

Каталоги OPENCLAW_*: изолируйте состояние, не только конфиг

Файлы конфигурации заметны; состояние во время работы (сессии, локальный кэш, загруженные артефакты) — то место, где происходит тихое пересечение потоков. Задайте OPENCLAW_STATE_DIR (и сопутствующие переменные из документации вашей сборки) на непересекающиеся пути для каждого профиля — например /var/lib/openclaw/prod и /var/lib/openclaw/stage — и закрепите владельца за тем же сервисным пользователем. Резервные копии и квоты диска тогда совпадают с радиусом поражения: снести stage не затронет токены prod на диске.

Чеклист воспроизводимого развёртывания

Матрицу портов и env-файлы храните в том же репозитории, что Ansible или cloud-init. Меняйте конфигурацию через systemctl --user daemon-reload (или перезагрузку системных шаблонов), затем systemctl restart профилей в порядке зависимостей: сначала зависимости, в конце слушатели на периметре. Задокументируйте один откат: предыдущая ревизия env и предыдущий drop-in юнита. Персистентность отличается от macOS launchd; для сопоставимой картины, когда рядом есть облачные Mac, см. Развёртывание OpenClaw на облачном Mac в 2026: проверки macOS вместо Linux VPS, launchd и воспроизводимый FAQ.

Дымовой тест после добавления профиля

Прежде чем объявлять новый слушатель команде, пройдите короткую лестницу из трёх шагов — так тикеты останутся короткими. Сначала убедитесь, что открыты только нужные сокеты: ss -lntp и сопоставьте PID с ожидаемым юнитом из systemctl status. Затем дерните строку матрицы loopback через curl с явным health или version-путём, который отдаёт ваш Gateway, а не только корень. Наконец зайдите по публичному имени через reverse proxy и сравните заголовки ответа с прямым зондом на loopback — расхождение почти всегда означает дрейф upstream-порта, а не TLS.

ss -lntp | grep -E '18789|18790|18791'
curl -svS http://127.0.0.1:18789/health
curl -svS https://prod-gateway.example.com/health

Если всё выглядит «здоровым», но срабатывает не та автоматизация, сравните эффективное окружение, которое видит юнит: systemctl show для блока сервиса и diff с закоммиченным env. Тихий дрейф от ручных правок на хосте — главная причина, почему через месяц живой сервер перестаёт совпадать с воспроизводимым репозиторием.

FAQ: конфликты, которые мы ловим в параллельных схемах

«Address already in use» после перезагрузки — устаревшая пользовательская сессия оставила вторую копию процесса вне systemd; сопоставьте PID через ss -lntp с юнитами. В stage отвечает не тот бот — переиспользован путь к файлу токена; прогрепайте юниты на дубликаты EnvironmentFile. Один профиль забивает диск VPS — повесьте квоту или ротацию логов на уровне OPENCLAW_STATE_DIR, а не глобально. HTTPS работает только для одного hostname — блок upstream в прокси указывает на неверную строку матрицы loopback; чините матрицу, а не ACME.