OpenClaw Gateway — это отдельный процесс, через который клиенты, каналы и устройства попадают к агенту: один порт принимает вызовы по WebSocket, HTTP-запросы и панель управления. По умолчанию он слушает только локальный адрес и требует аутентификацию, поэтому для компании вопрос звучит так: кому и каким путём открыть этот вход. Описанная ниже схема подходит команде с общим уровнем доверия; для групп, скрывающих данные друг от друга, нужны отдельные Gateway.
Узел доступа
По документации, Gateway слушает порт 18789, по умолчанию привязан к loopback и требует аутентификацию; за пределы машины его открывают только с токеном или паролем либо за шлюзом идентификации в режиме trusted-proxy.
Условный сценарий: Gateway работает на офисном сервере. Руководитель подключается из дома, менеджер — с ноутбука в командировке, а в общем чате команды агент отвечает на вопросы по базе знаний. У каждого из трёх входов свой путь и свой риск, а Gateway при этом один.
Токен для HTTP-маршрута и вызовы из внутреннего сервиса разобраны в статье про OpenClaw API. Здесь предмет другой — сам узел: где он слушает, как доказывают право войти, кто что может, что остаётся в журнале и как убедиться, что чужой клиент отвергается. Порядок пробного запуска агентной задачи описан в статье про пилот OpenClaw.
Документация по безопасности фиксирует границу доверия: один Gateway рассчитан на одного оператора или команду, участники которой доверяют друг другу. Если в компании есть группы, скрывающие данные друг от друга, каждой нужен свой Gateway с отдельными учётными данными, а лучше и отдельным пользователем системы либо хостом. Когда два Gateway работают на одном хосте, документация требует уникальных значений для порта (gateway.port), пути конфигурации (OPENCLAW_CONFIG_PATH), каталога состояния (OPENCLAW_STATE_DIR) и рабочего пространства агента, иначе узлы начнут мешать друг другу.
Контур доступа
Выбор пути определяет, где проходит граница сети. По документации, привязка loopback оставляет Gateway доступным только с той же машины, режим lan открывает его в локальной сети, а в контейнере режим auto превращается в адрес 0.0.0.0.
| Путь | Как устроен | Кому подходит | Что проверить |
|---|---|---|---|
| Loopback | Gateway слушает только локальный адрес, клиенты работают на той же машине | Один оператор на сервере или рабочем компьютере | Порт 18789 снаружи закрыт |
| Tailscale или VPN | Документация называет путь предпочтительным для удалённого доступа; вход даёт защищённая сеть между устройствами | Руководитель из дома, сотрудники в командировке | Список устройств сети и срок их доступа |
| Туннель SSH | Команда ssh -N -L 18789:127.0.0.1:18789 user@gateway-host пробрасывает порт на компьютер клиента | Редкое подключение администратора | Токен всё равно требуется: аутентификацию Gateway туннель оставляет в силе |
| Привязка lan | Gateway слушает адрес локальной сети | Офис с закрытой сетью | Правила межсетевого экрана и обязательный токен |
| Режим trusted-proxy | Идентификацию выполняет шлюз перед Gateway и передаёт имя пользователя в заголовке | Команда с корпоративным входом и браузерными клиентами | Единственный путь к Gateway идёт через этот шлюз |
Для браузерных клиентов и контейнерных окружений документация описывает режим gateway.auth.mode: "trusted-proxy". Ключи gateway.trustedProxies, userHeader, requiredHeaders и allowUsers определяют, чьи заголовки принимаются. Ошибка здесь опасна: любой путь в обход шлюза обнуляет защиту, а запросы с loopback отвергаются, пока параметр allowLoopback остаётся выключенным.
Мало выбрать путь, его нужно записать. Схему входа, владельца и перечень устройств держите в одном документе, иначе причину открытого порта через месяц восстанавливать будет некому.
Вход и пары
Аутентификация включена по умолчанию. Ключи gateway.auth.token и gateway.auth.password задают общий секрет, а переменные OPENCLAW_GATEWAY_TOKEN и OPENCLAW_GATEWAY_PASSWORD позволяют держать его вне файла конфигурации.
Клиентская сторона настраивается отдельно. Значения gateway.remote.token и gateway.remote.password служат учётными данными клиента, а серверную защиту включают другие ключи. Флаг --url в командах всегда обходит секреты из конфигурации и окружения, поэтому токен указывают явно.
- Устройство с ролью node проходит парное подключение, и до одобрения его команды отфильтрованы.
- Заявки просматривают командами
openclaw devices listиopenclaw nodes pending, одобряют командамиopenclaw devices approveиopenclaw nodes approve. - Автоодобрение подключения с той же машины отключает параметр
autoApproveLocal: false; операторские, браузерные клиенты и Control UI всегда ждут явного решения. - Токен устройства меняют командой
openclaw devices rotate, а командаopenclaw nodes removeотзывает роль node.
Автоодобрение на самой машине удобно, но решение фактически принимает любой локальный процесс. На общем сервере его лучше выключить и одобрять заявки руками.
Кто в вашей компании должен одобрять новые устройства?
Права и границы
Права на уровне Gateway выглядят как роли и области. Одобрение заявок требует области operator.pairing, команды записи добавляют operator.write, а изменение конфигурации и другие административные действия требуют operator.admin. Операторы управляют Gateway и маршрутизацией, узлы выполняют задачи.
Отдельно оцените, что умеет сам агент. Документация по безопасности предупреждает: агентам с инструментом сообщений по умолчанию доступна отправка между разговорами и каналами, пока ограничения отсутствуют. В общем чате команды такую возможность сужают заранее, а права навыков и каналов разобраны в статьях про навыки OpenClaw и канал Telegram.
- Выпишите все входы: порты, каналы, браузерные клиенты, устройства.
- Для каждого входа укажите способ аутентификации и владельца секрета.
- Для каждой роли перечислите получаемые области и обоснуйте административные.
- Отметьте действия агента, которым требуется подтверждение человека, и место, где оно даётся.
- Назначьте дату ближайшей проверки матрицы.
Подтверждение действий с последствиями остаётся за человеком, а проверка прав за сервером: просьба в чате прибавить агенту прав так и остаётся просьбой, области сервер сверяет сам. Если нужен готовый контур под вашу команду, начните со страницы про ИИ-агентов для бизнеса.
Журнал и отказ
Журнал Gateway по документации пишется JSON-строками в файл вида /tmp/openclaw/openclaw-ГГГГ-ММ-ДД.log; читают его командой openclaw logs --follow либо во вкладке Logs панели управления. Редакция секретов включена всегда, а дополнительные шаблоны задаёт logging.redactPatterns. Для хранения каталог /tmp малопригоден, поэтому копию записей выносите туда, где контролируется срок хранения.
Здоровье узла проверяют командой openclaw gateway status, а с флагом --deep она сканирует и системную службу. Нормальное состояние описано тремя признаками: Runtime: running, Connectivity probe: ok и строка Capability, совпадающая с ожидаемой. После смены контура команда openclaw security audit проверяет конфигурацию на известные риски, например пустой или слишком короткий токен.
- С компьютера вне контура обратитесь к порту 18789: соединение должно быть отклонено либо остаться без ответа.
- В разрешённой сети отправьте вызов без токена и с заведомо неверным токеном: оба получают отказ.
- Подключите новое устройство с ролью node и убедитесь, что до одобрения его команды недоступны.
- Ротируйте токен и проверьте, что прежнее значение отвергается.
- Остановите Gateway: клиенты должны получить явную ошибку подключения, без тихого переключения на прямое обращение к модели.
- Сверьте журнал: у каждого отказа есть запись со временем и источником.
Повторяйте тест отказа после любой смены привязки, режима аутентификации или списка устройств и заносите в журнал проверок дату, путь входа, версию OpenClaw и имя владельца секрета.