2026: OpenClaw Gateway в продакшене — openclaw onboard, openclaw doctor / openclaw fix, HTTPS (Nginx/Caddy) и откат на Linux VPS

Когда шлюз OpenClaw выходит за пределы «поднял на loopback и проверил вручную», ценность дают три вещи: предсказуемый онбординг, быстрый разбор типовых поломок и воспроизводимый путь «обновил — проверил — откатился». Ниже — компактный runbook для типичного Linux VPS (Ubuntu/Debian): что спросит мастер openclaw onboard, как читать вывод openclaw doctor и когда уместен openclaw fix, как поставить TLS-терминацию перед процессом и как не потерять рабочую связку при апгрейде. Если вы только выбираете способ установки на хосте, начните с базовой матрицы curl/Docker и проверок окружения — 2026: OpenClaw на Linux VPS — curl vs Docker, проверка окружения и FAQ по типовым ошибкам.

Мастер openclaw onboard: что зафиксировать сразу

Интерактивный онбординг обычно проходит по цепочке «путь данных → сеть → секреты → автозапуск». На практике ошибки чаще всего не в «магии CLI», а в несовпадении ожиданий: сервис слушает 127.0.0.1, а панель облака открывает публичный порт; либо обратный прокси шлёт Host/X-Forwarded-* не так, и проверки подписи путей ломаются. Зафиксируйте в runbook три пункта: локальный порт процесса, каталог конфигурации и пользователь сервиса (чтобы права на сертификаты и логи не «плыли» после перезагрузки).

openclaw doctor и openclaw fix: диагностика без гаданий

doctor стоит трактовать как «сводку инвариантов»: версия рантайма, доступность порта, целостность конфигурации, права на каталоги состояния и согласованность переменных окружения unit'а. Если отчёт указывает на конкретный класс ошибок (несовместимая версия Node, занятый порт, неверный base URL), исправляйте первопричину вручную — автоматика экономит время только когда побочные эффекты предсказуемы.

fix имеет смысл как ускоритель рутины: восстановить права, пересоздать кэшированные пути, перегенерировать локальные заготовки. Перед запуском снимите копию каталога конфигурации и отметьте версию пакета — так откат займёт минуты, а не вечер. Для команд, где пики CI критичны, полезно держать отдельную политику кэша и артефактов — см. Короткий цикл облачного Mac CI в 2026: удалённый кэш сборки против локального диска узла как пример дисциплины версионирования окружения.

HTTPS: Nginx или Caddy перед локальным портом

Оба варианта сводятся к одному: терминировать TLS на edge, отдавать на loopback обычный HTTP и явно прокидывать заголовки доверия. На VPS не забудьте открыть только 80/443, а порт шлюза оставить закрытым снаружи.

server {
  listen 443 ssl http2;
  server_name gateway.example.com;

  location / {
    proxy_pass http://127.0.0.1:1787; # замените на ваш локальный порт
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

gateway.example.com {
  reverse_proxy 127.0.0.1:1787
}

Обновление и откат: воспроизводимые шаги

Шаблон, который хорошо переживает ночные релизы: (1) systemctl stop (или эквивалент), (2) архив каталога конфигурации + unit-файла, (3) обновление бинарника/образа с явным тегом версии, (4) openclaw doctor, (5) смоук-тест через локальный curl и затем через публичный HTTPS, (6) только потом systemctl start. Откат — обратная перестановка артефакта предыдущей версии и конфигурации из архива; не полагайтесь на «память терминала».

Короткий FAQ

Сертификат обновился, а сервис не подхватил цепочку. Проверьте права на файлы cert/key для пользователя unit'а и перезапуск edge-прокси; приложение за loopback обычно не должно читать PEM напрямую.

«Работало вчера» после apt upgrade. Сравните версии glibc/openssl и зависимостей Node — зафиксируйте минимальные версии ОС в runbook и откладывайте автоапдейты на окно обслуживания.

Нужен ли отдельный пользователь? Да: минимальные права, отдельный домашний каталог для состояния, без общего root на ежедневных операциях.