> ## Documentation Index > Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt > Use this file to discover all available pages before exploring further. # Node # `openclaw node` Запустіть **безголовий хост вузла**, який підключається до Gateway WebSocket і надає `system.run` / `system.which` на цій машині. ## Навіщо використовувати хост вузла? Використовуйте хост вузла, коли хочете, щоб агенти **виконували команди на інших машинах** у вашій мережі без установлення там повного супутнього застосунку macOS. Поширені сценарії використання: * Виконання команд на віддалених машинах Linux/Windows (сервери збірки, лабораторні машини, NAS). * Тримати exec **ізольованим у sandbox** на шлюзі, але делегувати схвалені запуски іншим хостам. * Надати легку, безголову ціль виконання для автоматизації або вузлів CI. Виконання все одно захищене **схваленнями exec** і allowlist для кожного агента на хості вузла, тож доступ до команд можна залишати обмеженим і явним. ## Проксі браузера (без конфігурації) Хости вузлів автоматично оголошують проксі браузера, якщо `browser.enabled` не вимкнено на вузлі. Це дає агенту змогу використовувати автоматизацію браузера на цьому вузлі без додаткової конфігурації. За замовчуванням проксі відкриває звичайну поверхню профілю браузера вузла. Якщо ви задасте `nodeHost.browserProxy.allowProfiles`, проксі стане обмежувальним: цільові профілі поза allowlist відхиляються, а маршрути створення/видалення постійних профілів блокуються через проксі. За потреби вимкніть це на вузлі: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { nodeHost: { browserProxy: { enabled: false, }, }, } ``` ## Запуск (передній план) ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw node run --host --port 18789 ``` Параметри: * `--host `: хост Gateway WebSocket (за замовчуванням: `127.0.0.1`) * `--port `: порт Gateway WebSocket (за замовчуванням: `18789`) * `--context-path `: шлях контексту Gateway WebSocket (наприклад, `/openclaw-gw`). Додається до URL WebSocket. * `--tls`: використовувати TLS для підключення до gateway * `--tls-fingerprint `: очікуваний відбиток TLS-сертифіката (sha256) * `--node-id `: перевизначити ідентифікатор вузла (очищає токен спарювання) * `--display-name `: перевизначити відображуване ім'я вузла ## Автентифікація Gateway для хоста вузла `openclaw node run` і `openclaw node install` визначають автентифікацію gateway з config/env (без прапорців `--token`/`--password` у командах вузла): * Спочатку перевіряються `OPENCLAW_GATEWAY_TOKEN` / `OPENCLAW_GATEWAY_PASSWORD`. * Потім локальний резервний варіант конфігурації: `gateway.auth.token` / `gateway.auth.password`. * У локальному режимі хост вузла навмисно не успадковує `gateway.remote.token` / `gateway.remote.password`. * Якщо `gateway.auth.token` / `gateway.auth.password` явно налаштовано через SecretRef і не розв'язано, визначення автентифікації вузла завершується закритою відмовою (без маскування віддаленим резервним варіантом). * У `gateway.mode=remote` поля віддаленого клієнта (`gateway.remote.token` / `gateway.remote.password`) також можуть використовуватися відповідно до правил віддаленого пріоритету. * Визначення автентифікації хоста вузла враховує лише змінні середовища `OPENCLAW_GATEWAY_*`. Для вузла, що підключається до незашифрованого Gateway `ws://`, приймаються loopback, літерали приватних IP, `.local` і хости Tailnet `*.ts.net`. Для інших довірених приватних DNS-імен задайте `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`; без цього запуск вузла завершується закритою відмовою і просить використати `wss://`, SSH-тунель або Tailscale. Це opt-in через середовище процесу, а не ключ конфігурації `openclaw.json`. `openclaw node install` зберігає його в контрольованій службі вузла, коли він присутній у середовищі команди встановлення. ## Служба (фоновий режим) Установіть безголовий хост вузла як користувацьку службу. ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw node install --host --port 18789 ``` Параметри: * `--host `: хост Gateway WebSocket (за замовчуванням: `127.0.0.1`) * `--port `: порт Gateway WebSocket (за замовчуванням: `18789`) * `--context-path `: шлях контексту Gateway WebSocket (наприклад, `/openclaw-gw`). Додається до URL WebSocket. * `--tls`: використовувати TLS для підключення до gateway * `--tls-fingerprint `: очікуваний відбиток TLS-сертифіката (sha256) * `--node-id `: перевизначити ідентифікатор вузла (очищає токен спарювання) * `--display-name `: перевизначити відображуване ім'я вузла * `--runtime `: середовище виконання служби (`node` або `bun`) * `--force`: перевстановити/перезаписати, якщо вже встановлено Керуйте службою: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw node status openclaw node start openclaw node stop openclaw node restart openclaw node uninstall ``` Використовуйте `openclaw node run` для хоста вузла на передньому плані (без служби). Команди служби приймають `--json` для машинозчитуваного виводу. Хост вузла повторює спроби після перезапуску Gateway і закриття мережевого з'єднання в межах процесу. Якщо Gateway повідомляє про термінальну паузу автентифікації токена/пароля/bootstrap, хост вузла записує деталі закриття в журнал і завершується з ненульовим кодом, щоб launchd/systemd міг перезапустити його зі свіжою конфігурацією та обліковими даними. Паузи, що потребують спарювання, залишаються в потоці переднього плану, щоб очікуваний запит можна було схвалити. ## Спарювання Перше підключення створює на Gateway очікуваний запит на спарювання пристрою (`role: node`). Схваліть його через: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw devices list openclaw devices approve ``` У суворо контрольованих мережах вузлів оператор Gateway може явно погодитися автоматично схвалювати перше спарювання вузлів із довірених CIDR: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { gateway: { nodes: { pairing: { autoApproveCidrs: ["192.168.1.0/24"], }, }, }, } ``` За замовчуванням це вимкнено. Це застосовується лише до нового спарювання `role: node` без запитаних scopes. Клієнти оператора/браузера, Control UI, WebChat, а також оновлення ролі, scope, метаданих або публічного ключа все одно потребують ручного схвалення. Якщо вузол повторює спарювання зі зміненими деталями автентифікації (роль/scopes/публічний ключ), попередній очікуваний запит замінюється, і створюється новий `requestId`. Перед схваленням знову виконайте `openclaw devices list`. Хост вузла зберігає свій ідентифікатор вузла, токен, відображуване ім'я та інформацію про підключення до gateway у `~/.openclaw/node.json`. ## Схвалення exec `system.run` керується локальними схваленнями exec: * `$OPENCLAW_STATE_DIR/exec-approvals.json`, або `~/.openclaw/exec-approvals.json`, коли змінну не задано * [Схвалення exec](/uk/tools/exec-approvals) * `openclaw approvals --node ` (редагування з Gateway) Для схваленого асинхронного exec вузла OpenClaw готує канонічний `systemRunPlan` перед запитом. Подальше схвалене переспрямування `system.run` повторно використовує цей збережений план, тому зміни полів command/cwd/session після створення запиту на схвалення відхиляються замість того, щоб змінювати те, що виконує вузол. ## Пов'язане * [Довідник CLI](/uk/cli) * [Вузли](/uk/nodes)