Коротко

  • Открыть панель локально — одна команда: openclaw dashboard, она сама подставит текущий токен. openclaw dashboard --no-open печатает URL, не запуская браузер. Живёт панель на loopback: 127.0.0.1:18789.
  • Удалённо 127.0.0.1:18789 не грузится: это loopback хоста gateway; с ноутбука тот же адрес ведёт на сам ноутбук, где на порту пусто. Дотянуться — SSH-туннель ssh -N -L 18789:127.0.0.1:18789 user@host или Tailscale Serve.
  • 401 значит одно: gateway не увидел токен или увидел не тот. Держи токен в gateway.auth.token; при явном --url креды из конфига и env не подтягиваются — передавай --token руками.
  • Gateway error чинится лесенкой openclaw gateway status → openclaw health → openclaw doctor → логи → openclaw gateway restart, а не обновлением вкладки.

По запросам вида «не открывается дашборд OpenClaw» и «openclaw gateway error» выдача устроена одинаково: официальная справка по командам, где всё верно, но по кусочкам, и обрывки issue-тредов с похожим симптомом и совсем другой причиной. Цельного ответа — почему 127.0.0.1:18789 не грузится, как дотянуться до панели на удалённом сервере и что делать, когда gateway лёг, — в выдаче нет. Я держу gateway и дашборд в проде, и разъезжается эта связка в трёх местах: loopback, токен, сам gateway. Статья идёт по всем трём — от «как вообще открыть панель» до «gateway падает с RangeError и не встаёт».

Дашборд — это Control UI на 127.0.0.1:18789

Первое, что надо понять: дашборд — это не веб-сайт. Это Control UI, который gateway отдаёт на loopback-адресе 127.0.0.1:18789. Корень этого адреса и есть панель. Канонический способ открыть её — команда:

openclaw dashboard

Она открывает Control UI с текущей авторизацией: сама резолвит gateway.auth.token (в том числе заданный через SecretRef) и учитывает gateway.tls.enabled: при включённом TLS напечатает https://-URL и подключится по wss://. Нужен просто адрес, без браузера:

openclaw dashboard --no-open

Если доставить токен в браузер или буфер обмена не получилось, команда печатает подсказку для ручной авторизации: называет OPENCLAW_GATEWAY_TOKEN, gateway.auth.token и fragment-ключ token — сам токен при этом не светит.

Теперь главное недоразумение этой темы. Панель однажды открылась, адрес с 127.0.0.1:18789 осел в закладках — а теперь «не грузится»: с ноутбука, с телефона, с рабочей машины. Он и не должен: 127.0.0.1 всегда означает «эта самая машина». На хосте gateway закладка ведёт на панель; на любой другой машине — на саму эту машину, где на порту 18789 пусто. Какой бы внутренний путь ни висел в адресной строке, вход один: корень 127.0.0.1:18789 на хосте gateway — или openclaw dashboard там же.

Как дотянуться до дашборда удалённо

Gateway по умолчанию слушает WebSocket на loopback, порт 18789. Так и задумано: панель не торчит наружу, значит, снаружи её никто и не трогает. Удалённый доступ строится так, чтобы этот дефолт не ломать.

Рабочая лошадка — SSH-форвард loopback-порта:

ssh -N -L 18789:127.0.0.1:18789 user@host

Пока туннель жив, 127.0.0.1:18789 на твоей машине — это gateway сервера. Открывай в браузере или запускай openclaw dashboard локально. На macOS туннель делают постоянным через LaunchAgent — упомянул, углубляться не буду.

Приятный побочный эффект: через туннель работает не только браузер. openclaw health, openclaw status --deep, openclaw gateway status, openclaw gateway health и openclaw gateway probe достают удалённый gateway через тот же ws://127.0.0.1:18789 — диагностика с ноутбука ничем не отличается от диагностики на сервере.

Альтернативы: Tailscale Serve — то же по смыслу, но внутри tailnet; либо осознанный бинд на доверенный LAN/tailnet-интерфейс. Для любого не-loopback бинда правило жёсткое: gateway-auth обязателен — токен, пароль или trusted-proxy. И gateway.auth.mode="none" наружу — никогда. Сам бокс — как поднять и что у него должно торчать наружу — разобран в гайде про OpenClaw на VPS.

401: missing authentication header / invalid bearer token

401 — самая честная ошибка в этой статье: gateway ждёт auth-токен, а ты его не предъявил или предъявил не тот. Весь вопрос — откуда токен берётся.

Порядок, в котором клиент ищет токен в local-режиме: сначала OPENCLAW_GATEWAY_TOKEN, потом gateway.auth.token, потом gateway.remote.token. Важное исключение: явный --url кредов из конфига и env не берёт вообще. Подключаешься по URL — передавай --token или --password руками.

Теперь ловушка, которая стоила мне живого инцидента. На 2026.6.x managed-сервис gateway читает gateway.auth.token из ~/.openclaw/openclaw.json первым, и OPENCLAW_GATEWAY_TOKEN, который ты считал главным, тихо проигрывает конфигу; прямые local-клиенты при этом предпочитают env-токен. Симптом узнаваемый: бот отвечает, всё вроде живо — а панель пишет «gateway offline», и в логах token_mismatch. Лечение скучное и надёжное: держи токен в конфиге, в gateway.auth.token. Он переживает рестарты, и все стороны читают его одинаково.

Диагностика: openclaw channels status --probe показывает живой статус транспортов по аккаунтам — 401 в нём видно сразу; openclaw doctor --fix проверяет и чинит устаревшие креды и state.

И граница темы: если вместо 401 ты видишь «pairing required» — это другая подсистема, привязка устройства или канала. Разбираю её в статье про gateway pairing.

Gateway error и RangeError: лесенка вместо F5

«Gateway error» в панели — класс, а не диагноз. За ним может стоять что угодно: gateway упал, завис, слушает не там, не может авторизовать клиента. Поэтому первым делом смотрим, что реально живо, вместо того чтобы жать F5:

openclaw gateway status --json
openclaw health
openclaw status --deep
openclaw doctor

openclaw gateway status (у него есть --json и --require-rpc) отвечает, жив ли сервис; openclaw health и openclaw status --deep копают глубже; openclaw doctor находит проблемы конфига и state, а openclaw doctor --fix часть находок чинит сам. Дальше — логи. И только потом рестарт.

Отдельной строкой — RangeError: maximum call stack size exceeded рядом со словом gateway. Скажу прямо, потому что в выдаче по этому запросу много уверенных ответов: в документации этот краш не разобран, и выдумывать причину я не буду. По классу это «gateway упал или зациклился», и путь тот же: status --json → health → doctor → логи → openclaw gateway restart. Одна закономерность из практики есть: появился такой краш ровно после обновления — вероятна регрессия версии. Откатись на заведомо рабочую версию и держи её, пока не починят; про пины и откаты — гайд по обновлению OpenClaw.

Как перезапустить gateway

Базовая команда одна:

openclaw gateway restart

Варианты по ситуации. --safe даёт gateway дренаж: аккуратно довести текущие дела и только потом перезапуститься; --force — когда процесс завис и на вежливый рестарт не реагирует; есть и связка --safe --skip-deferral. Бюджет дренажа переопределяется флагом --wait: openclaw gateway restart --wait 30s. Число без суффикса читается как миллисекунды, суффиксы s/m/h работают, --wait 0 ждёт бесконечно.

Рядом остальной набор: openclaw gateway stop, openclaw gateway start, openclaw gateway run и openclaw gateway probe (--json; --ssh user@host). Ручной рестарт работает, потому что commands.restart включён по умолчанию: SIGUSR1 даёт in-process рестарт. Выставишь commands.restart: false — ручной рестарт заблокирован; помни об этом, когда «почему-то не рестартится». А если сервис вообще не поднялся после openclaw gateway install, повтори с --force, при необходимости добавь --wrapper.

И правило, которое закрывает половину жалоб «поменял конфиг, ничего не изменилось». В доках оно сформулировано одной строкой: «Config changes require a gateway restart». Сохранил файл — изменение ещё не живо; живым его делает рестарт. Нюанс один: секция messages подхватывается на лету после сохранения, но лишь пока жив file-watcher. Отключён config-reload или watcher умер — изменения применит только рестарт. Конфиг native-плагинов — всегда через рестарт.

Gateway говорит по WebSocket, а не по сырому HTTP

Соблазн проверить gateway браузером или curl понятен, но control plane — это WebSocket на ws://127.0.0.1:18789. Голый GET к этому порту ведёт себя не как обычная веб-страница, и по его ответу нельзя судить, жив gateway или мёртв. Хочешь проверить — openclaw dashboard или openclaw health: они разговаривают с gateway на его языке.

Заметка из прода: где эта связка разъезжается

Три вещи, которые я выучил на своих инцидентах. В документации их нет.

Разъехавшиеся токены — причина №1 «внезапного» 401 и «gateway offline» при живом боте. После серии рестартов управляющий слой и gateway могут считать правильными разные токены: панель уходит в offline, а бот в Telegram отвечает как ни в чём не бывало. Панели в этот момент верить бесполезно; смотри на пару: какой токен предъявляется и какой gateway реально ждёт. Токен в gateway.auth.token эту пару склеивает.

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

И повторю из прошлого раздела, потому что это ловят все: конфиг живёт после рестарта, а не после сохранения файла. «Я же поменял» — не аргумент, пока gateway не перезапущен.

Общий итог скучный, как и положено проду: loopback плюс SSH-туннель закрывают почти всю поверхность — наружу торчит один SSH, атаковать нечего. А «обновить вкладку» не чинит gateway почти никогда; чинит лесенка status → health → doctor → restart.

Assistant Control: тот же контроль, но без терминала

Дальше — про мой продукт, не про фичу OpenClaw; помечаю прямым текстом. Cain построен на открытых рантаймах OpenClaw и Hermes, а поверх работает Assistant Control — общая панель управления: агенты, память, Life Feed, брифинги и системные настройки в одном месте. Повседневное общение при этом живёт в Telegram; панель — для настройки и тонкого контроля.

Смысл её в том, чтобы содержание этой статьи не было твоей заботой. В моём Assistant Control Hermes ставится одной кнопкой, а подписка и Telegram привязываются следом. Токен и gateway заведены за тебя — token_mismatch, о котором тут столько сказано, там просто не всплывает. И до панели не надо пробрасывать SSH-туннель: доступ идёт по личной ссылке за zero-trust-доступом (Cloudflare Access) — войти можешь только ты, а наружу у сервера не открыт ни один порт. Тот самый loopback-принцип из этой статьи, только заведённый за тебя. Подписку, на которой работает рантайм, — ChatGPT/Codex или Claude/Anthropic — можно переключить прямо из панели; запросы уходят напрямую тому провайдеру, которому ты и так платишь. Telegram, включая групповые чаты, подключается из панели, без ручного пейринга через CLI — что у пейринга под капотом, разбирал в статье про Telegram-бот. Терминал не нужен: ни конфигов, ни серверного администрирования.

Теперь честно, без прикрас: это выделенный под клиента сервер, один клиент на сервер. Версия рантайма — пин, прогнанный через нашу матрицу обновлений, а не «всегда самая свежая». И это один из вариантов: всё, что делает панель, можно сделать руками по шагам этой статьи.

Когда дело не в OpenClaw

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

  • Умер SSH-туннель. На ноутбуке панель «отвалилась», на сервере всё живо. Первым делом проверь, жив ли процесс ssh -N -L …: порвалась сеть, уснул ноутбук — туннель молча умирает, и 127.0.0.1:18789 снова указывает на пустое место.
  • Второй gateway на том же порту. Конфликт за 18789 выглядит как мигающая панель. Один хост — один gateway.
  • Не тот токен. После ручных правок конфига и серии рестартов легко предъявлять токен, который gateway уже не ждёт. Симптом — 401 или offline при живом боте; разбор выше.
  • Сеть и фаервол. Если ты сознательно биндил gateway шире loopback, проверь, что порт вообще достижим с твоей машины и правила фаервола не съели соединение.

Частые вопросы

Почему дашборд OpenClaw на `127.0.0.1:18789` не грузится? Потому что это loopback-WebSocket Control UI на хосте gateway: с другой машины 127.0.0.1 указывает не на сервер, а на неё саму. Локально — openclaw dashboard. Удалённо — пробрось порт SSH-туннелем ssh -N -L 18789:127.0.0.1:18789 user@host и открой 127.0.0.1:18789 уже у себя.

Как открыть Control UI OpenClaw? Командой openclaw dashboard — она открывает панель с текущей авторизацией и сама подставляет токен. openclaw dashboard --no-open печатает URL, не запуская браузер.

Как подключиться к дашборду на удалённом сервере или VPS? Держи gateway на loopback и пробрасывай порт 18789: SSH-форвард ssh -N -L 18789:127.0.0.1:18789 user@host или Tailscale Serve. Наружу без gateway.auth.token не биндить, а gateway.auth.mode="none" в интернет — никогда.

Что значит «401 missing authentication header / invalid bearer token»? Gateway ждёт свой auth-токен, а прилетел пустой или чужой. На 2026.6.x сервис первым читает gateway.auth.token из конфига, и OPENCLAW_GATEWAY_TOKEN может ему проиграть. openclaw channels status --probe покажет 401 по транспортам, openclaw doctor --fix проверит устаревшие креды. Держи токен в gateway.auth.token.

Как перезапустить gateway OpenClaw? openclaw gateway restart: --safe аккуратно доведёт текущие дела, --force — если завис. Есть stop, start и status. И помни: изменения конфига применяются на рестарте.

С чего начать при «openclaw gateway error» или «RangeError: maximum call stack size exceeded»? С проверки, что живо: openclaw gateway status --json, openclaw health, openclaw doctor, логи — затем openclaw gateway restart. Появился краш ровно после обновления — вероятна регрессия версии: откатись на заведомо рабочую, детали в гайде по обновлению.

Можно подключиться к дашборду через `--url` без токена? Нет. --url не берёт креды из конфига и env — передавай --token или --password явно. И никогда не выставляй gateway наружу с auth.mode="none".

Илья Прудников держит приватные инстансы OpenClaw и Hermes. Это заметки оператора про то, как открывать панель и оживлять gateway, а не документация проекта; точные команды, флаги и дефолты сверяй по свежим докам OpenClaw.