Кілька Gateway

Більшість налаштувань мають використовувати один Gateway, оскільки один Gateway може обробляти кілька підключень до месенджерів і агентів. Якщо потрібна сильніша ізоляція або надмірність (наприклад, бот-рятівник), запускайте окремі Gateways з ізольованими профілями/портами.

Найкраще рекомендоване налаштування

Для більшості користувачів найпростіше налаштування бота-рятівника таке:

• залиште основного бота на профілі за замовчуванням
• запустіть бота-рятівника з --profile rescue
• використовуйте повністю окремого Telegram-бота для облікового запису рятівника
• тримайте бота-рятівника на іншому базовому порту, наприклад 19789

Це ізолює бота-рятівника від основного бота, щоб він міг налагоджувати або застосовувати зміни конфігурації, якщо основний бот не працює. Залишайте щонайменше 20 портів між базовими портами, щоб похідні порти browser/canvas/CDP ніколи не конфліктували.

Швидкий старт бота-рятівника

Використовуйте цей шлях за замовчуванням, якщо немає вагомої причини робити щось інше:

# Бот-рятівник (окремий Telegram-бот, окремий профіль, порт 19789)openclaw --profile rescue onboardopenclaw --profile rescue gateway install --port 19789

Якщо ваш основний бот уже запущений, зазвичай це все, що потрібно.

Під час openclaw --profile rescue onboard:

• використайте окремий токен Telegram-бота
• залиште профіль rescue
• використайте базовий порт щонайменше на 20 більший, ніж у основного бота
• прийміть робочий простір рятівника за замовчуванням, якщо ви вже не керуєте ним самостійно

Якщо onboarding уже встановив службу рятівника для вас, фінальна команда gateway install не потрібна.

Чому це працює

Бот-рятівник залишається незалежним, оскільки має власні:

• профіль/конфігурацію
• каталог стану
• робочий простір
• базовий порт (плюс похідні порти)
• токен Telegram-бота

Для більшості налаштувань використовуйте повністю окремого Telegram-бота для профілю рятівника:

• легко залишити доступ лише для операторів
• окремий токен і ідентичність бота
• незалежність від встановлення каналу/застосунку основного бота
• простий шлях відновлення через DM, коли основний бот зламаний

Що змінює --profile rescue onboard

openclaw --profile rescue onboard використовує звичайний потік onboarding, але записує все в окремий профіль.

На практиці це означає, що бот-рятівник отримує власні:

• файл конфігурації
• каталог стану
• робочий простір (за замовчуванням ~/.openclaw/workspace-rescue)
• назву керованої служби

Підказки в іншому такі самі, як під час звичайного onboarding.

Загальне налаштування кількох gateway

Описана вище схема з ботом-рятівником є найпростішим варіантом за замовчуванням, але той самий шаблон ізоляції працює для будь-якої пари або групи Gateways на одному хості.

Для загальнішого налаштування надайте кожному додатковому Gateway власний іменований профіль і власний базовий порт:

# main (профіль за замовчуванням)openclaw setupopenclaw gateway --port 18789 # додатковий gatewayopenclaw --profile ops setupopenclaw --profile ops gateway --port 19789

Якщо хочете, щоб обидва Gateways використовували іменовані профілі, це також працює:

openclaw --profile main setupopenclaw --profile main gateway --port 18789 openclaw --profile ops setupopenclaw --profile ops gateway --port 19789

Служби дотримуються того самого шаблону:

openclaw gateway installopenclaw --profile ops gateway install --port 19789

Використовуйте швидкий старт бота-рятівника, коли потрібен резервний операторський шлях. Використовуйте загальний шаблон профілів, коли потрібні кілька довготривалих Gateways для різних каналів, орендарів, робочих просторів або операційних ролей.

Контрольний список ізоляції

Тримайте ці елементи унікальними для кожного екземпляра Gateway:

• OPENCLAW_CONFIG_PATH — файл конфігурації для кожного екземпляра
• OPENCLAW_STATE_DIR — сеанси, облікові дані, кеші для кожного екземпляра
• agents.defaults.workspace — корінь робочого простору для кожного екземпляра
• gateway.port (або --port) — унікальний для кожного екземпляра
• похідні порти browser/canvas/CDP

Якщо вони спільні, ви зіткнетеся з гонками конфігурації та конфліктами портів.

Відображення портів (похідні)

Базовий порт = gateway.port (або OPENCLAW_GATEWAY_PORT / --port).

• порт служби керування браузером = базовий + 2 (лише local loopback)
• хост canvas обслуговується на HTTP-сервері Gateway (той самий порт, що й gateway.port)
• CDP-порти профілю браузера автоматично виділяються з browser.controlPort + 9 .. + 108

Якщо ви перевизначаєте будь-яке з цих значень у конфігурації або env, потрібно зберігати їх унікальними для кожного екземпляра.

Примітки щодо Browser/CDP (поширена помилка)

• Не закріплюйте browser.cdpUrl за однаковими значеннями на кількох екземплярах.
• Кожному екземпляру потрібен власний порт керування браузером і діапазон CDP (похідний від його порту gateway).
• Якщо потрібні явні CDP-порти, задайте browser.profiles.<name>.cdpPort для кожного екземпляра.
• Віддалений Chrome: використовуйте browser.profiles.<name>.cdpUrl (для кожного профілю, для кожного екземпляра).

Приклад ручного env

OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \OPENCLAW_STATE_DIR=~/.openclaw \openclaw gateway --port 18789 OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \OPENCLAW_STATE_DIR=~/.openclaw-rescue \openclaw gateway --port 19789

Швидкі перевірки

openclaw gateway status --deepopenclaw --profile rescue gateway status --deepopenclaw --profile rescue gateway probeopenclaw statusopenclaw --profile rescue statusopenclaw --profile rescue browser status

Інтерпретація:

• gateway status --deep допомагає виявити застарілі служби launchd/systemd/schtasks від старіших встановлень.
• Текст попередження gateway probe, наприклад multiple reachable gateway identities detected, очікуваний лише тоді, коли ви навмисно запускаєте більше ніж один ізольований gateway, або коли OpenClaw не може довести, що доступні цілі перевірки є тим самим gateway. SSH-тунель, proxy URL або налаштований віддалений URL до того самого gateway — це один gateway із кількома транспортами, навіть коли порти транспортів відрізняються.

Пов’язане

• Runbook Gateway
• Блокування Gateway
• Конфігурація