From 84ffb0b3749e7e5924e25fceb859c68aaa341246 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Mon, 4 May 2026 11:10:58 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/cli/proxy.md | 62 ++--- docs/uk/help/testing-live.md | 414 +++++++++++++++--------------- docs/uk/security/network-proxy.md | 148 ++++++----- 3 files changed, 321 insertions(+), 303 deletions(-) diff --git a/docs/uk/cli/proxy.md b/docs/uk/cli/proxy.md index 458d1c946..44f0f6675 100644 --- a/docs/uk/cli/proxy.md +++ b/docs/uk/cli/proxy.md @@ -1,36 +1,36 @@ --- read_when: - - Потрібно перевірити маршрутизацію проксі, керовану оператором, перед розгортанням + - Потрібно перевірити маршрутизацію через керований оператором проксі перед розгортанням - Потрібно локально захопити транспортний трафік OpenClaw для налагодження - - Ви хочете переглядати сеанси налагоджувального проксі, блоби або вбудовані пресети запитів. -summary: Довідник CLI для `openclaw proxy`, включно з перевіркою проксі, керованого оператором, і локальним інспектором захоплень проксі для налагодження + - Ви хочете переглянути сеанси налагоджувального проксі, блоби або вбудовані пресети запитів +summary: Довідник CLI для `openclaw proxy`, включно з перевіркою проксі, керованого оператором, та інспектором захоплень локального проксі для налагодження title: Проксі x-i18n: - generated_at: "2026-05-04T03:58:53Z" + generated_at: "2026-05-04T11:08:56Z" model: gpt-5.5 provider: openai - source_hash: 9589bedafb97c31bcb6536a04307cd0c6550e1f307693bd4401785d79f34a1eb + source_hash: 092c4e946dcab5e78e37d6fc77bb067b7a649368f8571fa127e462a85fa14ce5 source_path: cli/proxy.md workflow: 16 --- # `openclaw proxy` -Перевіряйте маршрутизацію проксі, керовану оператором, або запускайте локальний явний проксі для налагодження -й аналізуйте захоплений трафік. +Перевіряйте керовану оператором маршрутизацію через проксі або запускайте локальний явний налагоджувальний проксі +та аналізуйте захоплений трафік. Використовуйте `validate`, щоб попередньо перевірити керований оператором прямий проксі перед увімкненням -маршрутизації проксі OpenClaw. Інші команди є інструментами налагодження для -дослідження на транспортному рівні: вони можуть запускати локальний проксі, виконувати дочірню команду +маршрутизації проксі в OpenClaw. Інші команди є інструментами налагодження для +дослідження транспортного рівня: вони можуть запускати локальний проксі, виконувати дочірню команду з увімкненим захопленням, перелічувати сеанси захоплення, запитувати поширені шаблони трафіку, читати -захоплені blobs і очищати локальні дані захоплення. +захоплені бінарні об’єкти та очищати локальні дані захоплення. ## Команди ```bash openclaw proxy start [--host ] [--port ] openclaw proxy run [--host ] [--port ] -- -openclaw proxy validate [--json] [--proxy-url ] [--allowed-url ] [--denied-url ] [--timeout-ms ] +openclaw proxy validate [--json] [--proxy-url ] [--allowed-url ] [--denied-url ] [--apns-reachable] [--apns-authority ] [--timeout-ms ] openclaw proxy coverage openclaw proxy sessions [--limit ] openclaw proxy query --preset [--session ] @@ -40,25 +40,29 @@ openclaw proxy purge ## Перевірка -`openclaw proxy validate` перевіряє ефективну URL-адресу проксі, керованого оператором, з -`--proxy-url`, конфігурації або `OPENCLAW_PROXY_URL`. Він повідомляє про проблему конфігурації, коли +`openclaw proxy validate` перевіряє фактичну URL-адресу керованого оператором проксі з +`--proxy-url`, конфігурації або `OPENCLAW_PROXY_URL`. Вона повідомляє про проблему конфігурації, коли проксі не ввімкнено й не налаштовано; використовуйте `--proxy-url` для одноразової попередньої перевірки -перед зміною конфігурації. За замовчуванням він перевіряє, що публічне призначення успішно досягається -через проксі й що проксі не може досягти тимчасового loopback-індикатора. -Користувацькі заборонені призначення працюють за принципом fail-closed: HTTP-відповіді та неоднозначні -транспортні збої однаково вважаються невдачею, якщо ви не можете окремо перевірити специфічний для розгортання -сигнал відмови. +перед зміною конфігурації. За замовчуванням вона перевіряє, що публічне призначення успішно доступне +через проксі, а проксі не може досягти тимчасового loopback-індикатора. +Користувацькі заборонені призначення відмовляють у безпечний бік: HTTP-відповіді та неоднозначні +транспортні збої однаково спричиняють невдачу, якщо тільки ви не можете окремо перевірити специфічний для розгортання +сигнал відмови. Додайте `--apns-reachable`, щоб також відкрити тунель APNs HTTP/2 CONNECT +через проксі та підтвердити, що пісочний APNs відповідає; перевірка використовує +навмисно недійсний токен провайдера, тому відповідь APNs `403 InvalidProviderToken` +є успішним сигналом досяжності. Параметри: -- `--json`: вивести машинозчитуваний JSON. -- `--proxy-url `: перевірити цю URL-адресу проксі замість конфігурації або env. -- `--allowed-url `: додати призначення, яке має успішно досягатися через проксі. Повторіть, щоб перевірити кілька призначень. +- `--json`: вивести машиночитний JSON. +- `--proxy-url `: перевірити цю URL-адресу проксі замість конфігурації або змінної середовища. +- `--allowed-url `: додати призначення, яке має успішно проходити через проксі. Повторіть, щоб перевірити кілька призначень. - `--denied-url `: додати призначення, яке має блокуватися проксі. Повторіть, щоб перевірити кілька призначень. +- `--apns-reachable`: також перевірити, що пісочний APNs HTTP/2 досяжний через проксі. +- `--apns-authority `: служба APNs для перевірки з `--apns-reachable` (`https://api.sandbox.push.apple.com` за замовчуванням; production — `https://api.push.apple.com`). - `--timeout-ms `: тайм-аут для кожного запиту в мілісекундах. -Див. [Мережевий проксі](/uk/security/network-proxy) щодо рекомендацій із розгортання та семантики -відмови. +Див. [Мережевий проксі](/uk/security/network-proxy), щоб отримати настанови щодо розгортання та семантики відмови. ## Попередні набори запитів @@ -73,14 +77,14 @@ openclaw proxy purge ## Примітки -- `start` за замовчуванням використовує `127.0.0.1`, якщо `--host` не задано. -- `run` запускає локальний проксі для налагодження, а потім виконує команду після `--`. -- Пряме переспрямування debug proxy до upstream відкриває upstream-сокети для діагностики. Коли активний режим керованого проксі OpenClaw, пряме переспрямування для proxy requests і тунелів CONNECT за замовчуванням вимкнено; задавайте `OPENCLAW_DEBUG_PROXY_ALLOW_DIRECT_CONNECT_WITH_MANAGED_PROXY=1` лише для затвердженої локальної діагностики. -- `validate` завершується з кодом 1, коли конфігурація проксі або перевірки призначення не проходять. -- Захоплення є локальними даними налагодження; використовуйте `openclaw proxy purge` після завершення. +- `start` за замовчуванням використовує `127.0.0.1`, якщо не задано `--host`. +- `run` запускає локальний налагоджувальний проксі, а потім виконує команду після `--`. +- Пряме переспрямування до upstream у налагоджувальному проксі відкриває upstream-сокети для діагностики. Коли активний режим керованого проксі OpenClaw, пряме переспрямування для проксі-запитів і тунелів CONNECT вимкнено за замовчуванням; задавайте `OPENCLAW_DEBUG_PROXY_ALLOW_DIRECT_CONNECT_WITH_MANAGED_PROXY=1` лише для схваленої локальної діагностики. +- `validate` завершується з кодом 1, коли перевірки конфігурації проксі або призначень зазнають невдачі. +- Захоплення є локальними налагоджувальними даними; використовуйте `openclaw proxy purge`, коли завершите. ## Пов’язане - [Довідник CLI](/uk/cli) - [Мережевий проксі](/uk/security/network-proxy) -- [Автентифікація довіреного проксі](/uk/gateway/trusted-proxy-auth) +- [Довірена автентифікація проксі](/uk/gateway/trusted-proxy-auth) diff --git a/docs/uk/help/testing-live.md b/docs/uk/help/testing-live.md index 1fb8ea75c..75002ab85 100644 --- a/docs/uk/help/testing-live.md +++ b/docs/uk/help/testing-live.md @@ -1,35 +1,35 @@ --- read_when: - - Запуск матриці live-моделей / бекенда CLI / ACP / smoke-тестів медіапровайдера - - Налагодження визначення облікових даних для живих тестів - - Додавання нового тесту в реальному середовищі для конкретного провайдера + - Запуск матриці реальних моделей / бекенду CLI / ACP / smoke-тестів медіапровайдера + - Налагодження визначення облікових даних для тестів у реальному середовищі + - Додавання нового живого тесту для конкретного провайдера sidebarTitle: Live tests -summary: 'Живі (що звертаються до мережі) тести: матриця моделей, бекенди CLI, ACP, постачальники медіа, облікові дані' -title: 'Тестування: набори тестів у реальному середовищі' +summary: 'Тести в реальному середовищі (із мережевими зверненнями): матриця моделей, бекенди CLI, ACP, медіапровайдери, облікові дані' +title: 'Тестування: тестові набори в реальному середовищі' x-i18n: - generated_at: "2026-05-03T04:51:01Z" + generated_at: "2026-05-04T11:09:03Z" model: gpt-5.5 provider: openai - source_hash: 4057d8875fa3404108e89e4381c1dd14e96abbc2af13c4934fc6c0dbf878fc00 + source_hash: 03b8ca6348137a55c8d5f67c9c166a130a75a744f6a433cb00496756b29d7016 source_path: help/testing-live.md workflow: 16 --- -Для швидкого старту, QA-запускачів, модульних/інтеграційних наборів і Docker-процесів див. -[Тестування](/uk/help/testing). Ця сторінка описує **живі** (ті, що звертаються до мережі) тестові +Для швидкого старту, QA-запускачів, модульних/інтеграційних наборів і Docker-потоків див. +[Тестування](/uk/help/testing). Ця сторінка описує **живі** (з доступом до мережі) тестові набори: матрицю моделей, CLI-бекенди, ACP і живі тести медіапровайдерів, а також -роботу з обліковими даними. +обробку облікових даних. -## Живі тести: smoke-команди локального профілю +## Живі тести: команди димової перевірки локального профілю -Перед ситуативними живими перевірками підключіть `~/.profile`, щоб ключі провайдерів і локальні шляхи інструментів -відповідали вашій оболонці: +Підключіть `~/.profile` перед спеціальними живими перевірками, щоб ключі провайдерів і шляхи +локальних інструментів відповідали вашій оболонці: ```bash source ~/.profile ``` -Безпечна smoke-перевірка медіа: +Безпечна димова перевірка медіа: ```bash pnpm openclaw infer tts convert --local --json \ @@ -37,7 +37,7 @@ pnpm openclaw infer tts convert --local --json \ --output /tmp/openclaw-live-smoke.mp3 ``` -Безпечна smoke-перевірка готовності голосового виклику: +Безпечна димова перевірка готовності голосового виклику: ```bash pnpm openclaw voicecall setup --json @@ -45,94 +45,94 @@ pnpm openclaw voicecall smoke --to "+15555550123" ``` `voicecall smoke` є пробним запуском, якщо також не вказано `--yes`. Використовуйте `--yes` лише -тоді, коли навмисно хочете здійснити реальний сповіщувальний виклик. Для Twilio, Telnyx і -Plivo успішна перевірка готовності вимагає публічної Webhook-URL; локальні -резервні варіанти loopback/private відхиляються за задумом. +тоді, коли ви свідомо хочете здійснити справжній сповіщувальний виклик. Для Twilio, Telnyx і +Plivo успішна перевірка готовності потребує публічної Webhook-URL-адреси; локальні варіанти +loopback/приватні резервні варіанти відхиляються за задумом. ## Живі тести: перевірка можливостей Android-вузла - Тест: `src/gateway/android-node.capabilities.live.test.ts` - Скрипт: `pnpm android:test:integration` -- Мета: викликати **кожну команду, яку наразі оголошує** підключений Android-вузол, і перевірити поведінку контракту команди. +- Мета: викликати **кожну команду, яку зараз оголошує** підключений Android-вузол, і перевірити поведінку контракту команди. - Обсяг: - - Попередньо підготовлене/ручне налаштування (набір не встановлює/запускає/сполучає застосунок). - - Перевірка gateway `node.invoke` окремо для кожної команди для вибраного Android-вузла. + - Попередньо налаштоване/ручне налаштування (набір не встановлює/не запускає/не спарює застосунок). + - Перевірка `node.invoke` у Gateway для кожної команди вибраного Android-вузла. - Обов’язкове попереднє налаштування: - - Android-застосунок уже підключений і сполучений із gateway. + - Android-застосунок уже підключений і спарений із Gateway. - Застосунок утримується на передньому плані. - - Дозволи/згоду на захоплення надано для можливостей, які ви очікуєте успішно пройти. + - Дозволи/згода на захоплення надані для можливостей, які мають пройти. - Необов’язкові перевизначення цілі: - `OPENCLAW_ANDROID_NODE_ID` або `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. -- Повні деталі налаштування Android: [Android App](/uk/platforms/android) +- Повні відомості про налаштування Android: [Застосунок Android](/uk/platforms/android) -## Живі тести: smoke-перевірка моделей (ключі профілю) +## Живі тести: димова перевірка моделей (ключі профілю) Живі тести розділено на два шари, щоб можна було ізолювати збої: -- «Пряма модель» показує, чи провайдер/модель узагалі може відповісти з указаним ключем. -- «Gateway smoke» показує, чи повний конвеєр gateway+agent працює для цієї моделі (сесії, історія, інструменти, політика sandbox тощо). +- «Пряма модель» показує, що провайдер/модель узагалі може відповідати з наданим ключем. +- «Димова перевірка Gateway» показує, що повний конвеєр Gateway+агент працює для цієї моделі (сеанси, історія, інструменти, політика пісочниці тощо). -### Шар 1: Пряме завершення моделі (без gateway) +### Шар 1: пряме завершення моделі (без Gateway) - Тест: `src/agents/models.profiles.live.test.ts` - Мета: - - Перерахувати виявлені моделі + - Перелічити виявлені моделі - Використати `getApiKeyForModel`, щоб вибрати моделі, для яких у вас є облікові дані - - Запустити невелике завершення для кожної моделі (і цільові регресійні перевірки, де потрібно) + - Запустити невелике завершення для кожної моделі (і цільові регресії, де потрібно) - Як увімкнути: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму) -- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб фактично запустити цей набір; інакше він пропускається, щоб `pnpm test:live` лишався зосередженим на smoke-перевірці gateway +- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб фактично запустити цей набір; інакше він пропускається, щоб `pnpm test:live` лишався зосередженим на димовій перевірці Gateway - Як вибрати моделі: - `OPENCLAW_LIVE_MODELS=modern`, щоб запустити сучасний список дозволених моделей (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3) - `OPENCLAW_LIVE_MODELS=all` є псевдонімом сучасного списку дозволених моделей - або `OPENCLAW_LIVE_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,..."` (список дозволених через кому) - - Сучасні/повні перевірки за замовчуванням мають curated high-signal ліміт; установіть `OPENCLAW_LIVE_MAX_MODELS=0` для вичерпної сучасної перевірки або додатне число для меншого ліміту. - - Вичерпні перевірки використовують `OPENCLAW_LIVE_TEST_TIMEOUT_MS` як таймаут усього тесту прямої моделі. За замовчуванням: 60 хвилин. - - Проби прямої моделі за замовчуванням запускаються з паралелізмом 20; установіть `OPENCLAW_LIVE_MODEL_CONCURRENCY`, щоб перевизначити. + - Сучасні/повні перевірки за замовчуванням мають підібрану високосигнальну верхню межу; установіть `OPENCLAW_LIVE_MAX_MODELS=0` для вичерпної сучасної перевірки або додатне число для меншої межі. + - Вичерпні перевірки використовують `OPENCLAW_LIVE_TEST_TIMEOUT_MS` як тайм-аут усього тесту прямої моделі. За замовчуванням: 60 хвилин. + - Проби прямої моделі за замовчуванням виконуються з паралелізмом 20; установіть `OPENCLAW_LIVE_MODEL_CONCURRENCY`, щоб перевизначити. - Як вибрати провайдерів: - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (список дозволених через кому) - Звідки беруться ключі: - - За замовчуванням: сховище профілю та резервні значення env - - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати лише **сховище профілю** -- Навіщо це існує: - - Відокремлює «API провайдера зламаний / ключ недійсний» від «конвеєр gateway agent зламаний» - - Містить невеликі ізольовані регресійні перевірки (приклад: OpenAI Responses/Codex Responses reasoning replay + потоки викликів інструментів) + - За замовчуванням: сховище профілів і резервні значення env + - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати лише **сховище профілів** +- Навіщо це потрібно: + - Відокремлює «API провайдера зламаний / ключ недійсний» від «конвеєр агента Gateway зламаний» + - Містить невеликі ізольовані регресії (приклад: OpenAI Responses/Codex Responses, повтор відтворення reasoning + потоки викликів інструментів) -### Шар 2: Gateway + dev agent smoke (те, що фактично робить "@openclaw") +### Шар 2: Gateway + димова перевірка dev-агента (що фактично робить "@openclaw") - Тест: `src/gateway/gateway-models.profiles.live.test.ts` - Мета: - - Підняти gateway в процесі - - Створити/виправити сесію `agent:dev:*` (перевизначення моделі для кожного запуску) - - Перебрати моделі з ключами та перевірити: + - Запустити внутрішньопроцесний Gateway + - Створити/пропатчити сеанс `agent:dev:*` (перевизначення моделі для кожного запуску) + - Перебрати моделі з ключами й перевірити: - «змістовну» відповідь (без інструментів) - - реальний виклик інструмента працює (проба читання) + - справжній виклик інструмента працює (проба читання) - необов’язкові додаткові проби інструментів (проба exec+read) - - регресійні шляхи OpenAI (лише виклик інструмента → подальша відповідь) продовжують працювати -- Деталі проб (щоб ви могли швидко пояснити збої): - - Проба `read`: тест записує nonce-файл у workspace і просить агента виконати `read` для нього та повернути nonce. - - Проба `exec+read`: тест просить агента виконати `exec`-запис nonce у тимчасовий файл, а потім виконати `read` назад. - - Проба зображення: тест прикріплює згенерований PNG (кіт + рандомізований код) і очікує, що модель поверне `cat `. + - регресійні шляхи OpenAI (лише виклик інструмента → подальше повідомлення) продовжують працювати +- Деталі проб (щоб можна було швидко пояснювати збої): + - Проба `read`: тест записує nonce-файл у робочій області й просить агента `read` його та повернути nonce. + - Проба `exec+read`: тест просить агента через `exec` записати nonce у тимчасовий файл, а потім через `read` прочитати його назад. + - Проба зображення: тест долучає згенерований PNG (кіт + випадковий код) і очікує, що модель поверне `cat `. - Посилання на реалізацію: `src/gateway/gateway-models.profiles.live.test.ts` і `src/gateway/live-image-probe.ts`. - Як увімкнути: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму) - Як вибрати моделі: - За замовчуванням: сучасний список дозволених моделей (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3) - `OPENCLAW_LIVE_GATEWAY_MODELS=all` є псевдонімом сучасного списку дозволених моделей - - Або встановіть `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або список через кому), щоб звузити - - Сучасні/повні gateway-перевірки за замовчуванням мають curated high-signal ліміт; установіть `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` для вичерпної сучасної перевірки або додатне число для меншого ліміту. -- Як вибрати провайдерів (уникати «усього OpenRouter»): + - Або встановіть `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або список через кому), щоб звузити вибір + - Сучасні/повні перевірки Gateway за замовчуванням мають підібрану високосигнальну верхню межу; установіть `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` для вичерпної сучасної перевірки або додатне число для меншої межі. +- Як вибрати провайдерів (уникаючи «усього OpenRouter»): - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (список дозволених через кому) - Проби інструментів і зображень завжди ввімкнені в цьому живому тесті: - - Проба `read` + проба `exec+read` (навантаження на інструменти) - - Проба зображення запускається, коли модель оголошує підтримку введення зображень + - проба `read` + проба `exec+read` (навантаження інструментів) + - проба зображення запускається, коли модель оголошує підтримку введення зображень - Потік (на високому рівні): - - Тест генерує крихітний PNG із “CAT” + випадковий код (`src/gateway/live-image-probe.ts`) + - Тест генерує маленький PNG із “CAT” + випадковим кодом (`src/gateway/live-image-probe.ts`) - Надсилає його через `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - Gateway розбирає вкладення в `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - - Вбудований agent пересилає multimodal повідомлення користувача до моделі - - Твердження: відповідь містить `cat` + код (допуск OCR: незначні помилки дозволено) + - Вбудований агент пересилає мультимодальне повідомлення користувача до моделі + - Перевірка: відповідь містить `cat` + код (допуск OCR: дозволені незначні помилки) Щоб побачити, що можна протестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте: @@ -144,27 +144,27 @@ openclaw models list --json -## Живі тести: smoke-перевірка CLI-бекенда (Claude, Codex, Gemini або інші локальні CLI) +## Живі тести: димова перевірка CLI-бекенду (Claude, Codex, Gemini або інші локальні CLI) - Тест: `src/gateway/gateway-cli-backend.live.test.ts` -- Мета: перевірити конвеєр Gateway + agent за допомогою локального CLI-бекенда, не торкаючись вашої конфігурації за замовчуванням. -- Значення smoke-перевірки за замовчуванням для конкретного бекенда містяться у визначенні `cli-backend.ts` Plugin-власника. +- Мета: перевірити конвеєр Gateway + агент із використанням локального CLI-бекенду, не торкаючись вашої конфігурації за замовчуванням. +- Типові значення димової перевірки для конкретного бекенду містяться у визначенні `cli-backend.ts` відповідного Plugin. - Увімкнення: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму) - `OPENCLAW_LIVE_CLI_BACKEND=1` -- Значення за замовчуванням: - - Провайдер/модель за замовчуванням: `claude-cli/claude-sonnet-4-6` - - Поведінка команди/аргументів/зображення береться з метаданих CLI-бекенда Plugin-власника. +- Типові значення: + - Типовий провайдер/модель: `claude-cli/claude-sonnet-4-6` + - Поведінка команди/аргументів/зображень надходить із метаданих Plugin відповідного CLI-бекенду. - Перевизначення (необов’язково): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.5"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, щоб надіслати реальне вкладення зображення (шляхи вставляються в prompt). Docker-рецепти за замовчуванням вимикають це, якщо явно не запитано. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, щоб передавати шляхи файлів зображень як CLI-аргументи замість вставлення в prompt. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, щоб надіслати справжнє вкладення-зображення (шляхи вставляються в prompt). Docker-рецепти за замовчуванням вимикають це, якщо явно не запитано. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, щоб передавати шляхи до файлів зображень як CLI-аргументи замість вставлення в prompt. - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`), щоб керувати тим, як передаються аргументи зображень, коли встановлено `IMAGE_ARG`. - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, щоб надіслати другий хід і перевірити потік відновлення. - - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1`, щоб увімкнути перевірку безперервності тієї самої сесії Claude Sonnet -> Opus, коли вибрана модель підтримує ціль перемикання. Docker-рецепти за замовчуванням вимикають це для сукупної надійності. - - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1`, щоб увімкнути MCP/tool loopback-пробу. Docker-рецепти за замовчуванням вимикають це, якщо явно не запитано. + - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1`, щоб увімкнути пробу безперервності того самого сеансу Claude Sonnet -> Opus, коли вибрана модель підтримує ціль перемикання. Docker-рецепти за замовчуванням вимикають це для сукупної надійності. + - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1`, щоб увімкнути пробу MCP/інструментального loopback. Docker-рецепти за замовчуванням вимикають це, якщо явно не запитано. Приклад: @@ -174,17 +174,17 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \ pnpm test:live src/gateway/gateway-cli-backend.live.test.ts ``` -Дешева smoke-перевірка конфігурації Gemini MCP: +Дешева димова перевірка конфігурації Gemini MCP: ```bash OPENCLAW_LIVE_TEST=1 \ pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts ``` -Вона не просить Gemini генерувати відповідь. Вона записує ті самі системні -налаштування, які OpenClaw дає Gemini, а потім запускає `gemini --debug mcp list`, щоб довести, що -збережений сервер `transport: "streamable-http"` нормалізується до HTTP MCP-форми -Gemini і може підключитися до локального streamable-HTTP MCP-сервера. +Це не просить Gemini генерувати відповідь. Воно записує ті самі системні +налаштування, які OpenClaw надає Gemini, а потім запускає `gemini --debug mcp list`, щоб довести, що +збережений сервер `transport: "streamable-http"` нормалізується до HTTP MCP-форми Gemini +і може підключитися до локального streamable-HTTP MCP-сервера. Docker-рецепт: @@ -201,31 +201,40 @@ pnpm test:docker:live-cli-backend:codex pnpm test:docker:live-cli-backend:gemini ``` -Нотатки: +Примітки: -- Docker-запускач міститься в `scripts/test-live-cli-backend-docker.sh`. -- Він запускає живу smoke-перевірку CLI-бекенда всередині Docker-образу репозиторію як non-root користувач `node`. -- Він визначає метадані CLI-smoke з розширення-власника, а потім встановлює відповідний Linux CLI-пакет (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`) у кешований префікс із правом запису за `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`). -- `pnpm test:docker:live-cli-backend:claude-subscription` вимагає переносний OAuth підписки Claude Code через `~/.claude/.credentials.json` із `claudeAiOauth.subscriptionType` або `CLAUDE_CODE_OAUTH_TOKEN` від `claude setup-token`. Спершу він доводить прямий `claude -p` у Docker, а потім запускає два ходи Gateway CLI-бекенда без збереження змінних env ключа Anthropic API. Ця лінія підписки за замовчуванням вимикає Claude MCP/tool і проби зображень, тому що Claude наразі маршрутизує використання стороннього застосунку через оплату додаткового використання замість звичайних лімітів плану підписки. -- Жива smoke-перевірка CLI-бекенда тепер виконує однаковий end-to-end потік для Claude, Codex і Gemini: текстовий хід, хід класифікації зображення, потім виклик інструмента MCP `cron`, перевірений через gateway CLI. -- Smoke-перевірка Claude за замовчуванням також виправляє сесію з Sonnet на Opus і перевіряє, що відновлена сесія все ще пам’ятає попередню нотатку. +- Docker-запускач розташований у `scripts/test-live-cli-backend-docker.sh`. +- Він запускає живу димову перевірку CLI-бекенду всередині Docker-образу репозиторію як некореневий користувач `node`. +- Він визначає метадані димової перевірки CLI з відповідного Plugin, а потім встановлює відповідний Linux-пакет CLI (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`) у кешований записуваний префікс за `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` потребує переносного OAuth підписки Claude Code через `~/.claude/.credentials.json` із `claudeAiOauth.subscriptionType` або `CLAUDE_CODE_OAUTH_TOKEN` з `claude setup-token`. Спочатку він доводить прямий `claude -p` у Docker, а потім запускає два ходи CLI-бекенду Gateway без збереження env-змінних API-ключа Anthropic. Ця лінія підписки за замовчуванням вимикає MCP/інструментальні проби Claude і проби зображень, оскільки Claude зараз маршрутизує використання сторонніх застосунків через оплату додаткового використання замість звичайних лімітів плану підписки. +- Жива димова перевірка CLI-бекенду тепер виконує той самий наскрізний потік для Claude, Codex і Gemini: текстовий хід, хід класифікації зображення, потім виклик інструмента MCP `cron`, перевірений через CLI Gateway. +- Типова димова перевірка Claude також патчить сеанс із Sonnet на Opus і перевіряє, що відновлений сеанс усе ще пам’ятає попередню нотатку. -## Живі тести: smoke-перевірка ACP bind (`/acp spawn ... --bind here`) +## Живі тести: досяжність HTTP/2-проксі APNs -- Test: `src/gateway/gateway-acp-bind.live.test.ts` -- Мета: перевірити реальний потік прив’язування розмови ACP з живим агентом ACP: +- Тест: `src/infra/push-apns-http2.live.test.ts` +- Мета: тунелювати через локальний HTTP CONNECT-проксі до sandbox-кінцевої точки APNs Apple, надіслати HTTP/2-запит валідації APNs і перевірити, що справжня відповідь Apple `403 InvalidProviderToken` повертається через шлях проксі. +- Увімкнення: + - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_APNS_REACHABILITY=1 pnpm test:live src/infra/push-apns-http2.live.test.ts` +- Необов’язковий тайм-аут: + - `OPENCLAW_LIVE_APNS_TIMEOUT_MS=30000` + +## Живі тести: димова перевірка прив’язки ACP (`/acp spawn ... --bind here`) + +- Тест: `src/gateway/gateway-acp-bind.live.test.ts` +- Мета: перевірити реальний потік прив’язування ACP-розмови з live ACP-агентом: - надіслати `/acp spawn --bind here` - прив’язати синтетичну розмову каналу повідомлень на місці - надіслати звичайне подальше повідомлення в тій самій розмові - - перевірити, що подальше повідомлення потрапляє до транскрипту прив’язаної сесії ACP + - перевірити, що подальше повідомлення потрапляє до транскрипту прив’язаної ACP-сесії - Увімкнення: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` - Типові значення: - - Агенти ACP у Docker: `claude,codex,gemini` - - Агент ACP для прямого `pnpm test:live ...`: `claude` + - ACP-агенти в Docker: `claude,codex,gemini` + - ACP-агент для прямого `pnpm test:live ...`: `claude` - Синтетичний канал: контекст розмови у стилі Slack DM - - Бекенд ACP: `acpx` + - ACP-бекенд: `acpx` - Перевизначення: - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex` @@ -240,9 +249,9 @@ pnpm test:docker:live-cli-backend:gemini - `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` - `OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.5` - Примітки: - - Ця смуга використовує поверхню Gateway `chat.send` із синтетичними полями маршруту походження лише для адміністраторів, щоб тести могли додавати контекст каналу повідомлень без імітації зовнішньої доставки. - - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не задано, тест використовує вбудований реєстр агентів Plugin `acpx` для вибраного агента тестового стенда ACP. - - Створення MCP bound-session Cron типово виконується за найкращим зусиллям, бо зовнішні тестові стенди ACP можуть скасовувати виклики MCP після проходження перевірки прив’язування/зображення; задайте `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1`, щоб зробити цю перевірку Cron після прив’язування суворою. + - Ця лінія використовує поверхню Gateway `chat.send` з доступними лише адміністратору синтетичними полями вихідного маршруту, щоб тести могли приєднувати контекст каналу повідомлень без імітації зовнішньої доставки. + - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не задано, тест використовує вбудований реєстр агентів Plugin `acpx` для вибраного агента ACP-стенда. + - Створення MCP для Cron прив’язаної сесії за замовчуванням виконується best-effort, бо зовнішні ACP-стенди можуть скасовувати MCP-виклики після проходження доказу прив’язування/зображення; задайте `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1`, щоб зробити цю післяприв’язувальну Cron-перевірку суворою. Приклад: @@ -270,37 +279,37 @@ pnpm test:docker:live-acp-bind:opencode Примітки Docker: -- Запускач Docker розташований у `scripts/test-live-acp-bind-docker.sh`. -- Типово він послідовно запускає димову перевірку прив’язування ACP проти агрегованих живих агентів CLI: `claude`, `codex`, потім `gemini`. +- Docker-runner розташований у `scripts/test-live-acp-bind-docker.sh`. +- За замовчуванням він послідовно запускає ACP bind smoke проти агрегованих live CLI-агентів: `claude`, `codex`, потім `gemini`. - Використовуйте `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=droid`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` або `OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode`, щоб звузити матрицю. -- Він підвантажує `~/.profile`, розміщує відповідні матеріали автентифікації CLI у контейнері, потім встановлює запитаний живий CLI (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid через `https://app.factory.ai/cli`, `@google/gemini-cli` або `opencode-ai`), якщо його бракує. Сам бекенд ACP є вбудованим пакетом `acpx/runtime` з офіційного Plugin `acpx`. -- Варіант Docker для Droid розміщує `~/.factory` для налаштувань, передає `FACTORY_API_KEY` і вимагає цей API-ключ, бо локальна автентифікація Factory через OAuth/keyring не переноситься в контейнер. Він використовує вбудований запис реєстру ACPX `droid exec --output-format acp`. -- Варіант Docker для OpenCode є суворою регресійною смугою для одного агента. Він записує тимчасову типову модель `OPENCODE_CONFIG_CONTENT` з `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (типово `opencode/kimi-k2.6`) після підвантаження `~/.profile`, а `pnpm test:docker:live-acp-bind:opencode` вимагає транскрипт прив’язаного помічника замість прийняття загального пропуску після прив’язування. -- Прямі виклики CLI `acpx` є лише ручним/обхідним шляхом для порівняння поведінки поза Gateway. Димова перевірка прив’язування ACP у Docker перевіряє вбудований бекенд виконання `acpx` OpenClaw. +- Він підвантажує `~/.profile`, розміщує відповідні матеріали автентифікації CLI у контейнері, а потім встановлює потрібний live CLI (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid через `https://app.factory.ai/cli`, `@google/gemini-cli` або `opencode-ai`), якщо він відсутній. Сам ACP-бекенд — це вбудований пакет `acpx/runtime` з офіційного Plugin `acpx`. +- Варіант Droid для Docker розміщує `~/.factory` для налаштувань, передає `FACTORY_API_KEY` і вимагає цей API-ключ, бо локальна автентифікація Factory OAuth/keyring не переноситься в контейнер. Він використовує вбудований запис реєстру ACPX `droid exec --output-format acp`. +- Варіант OpenCode для Docker — це сувора регресійна лінія з одним агентом. Він записує тимчасову типову модель `OPENCODE_CONFIG_CONTENT` з `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (за замовчуванням `opencode/kimi-k2.6`) після підвантаження `~/.profile`, а `pnpm test:docker:live-acp-bind:opencode` вимагає транскрипт прив’язаного асистента замість прийняття загального післяприв’язувального пропуску. +- Прямі виклики CLI `acpx` є лише ручним/обхідним шляхом для порівняння поведінки поза Gateway. Docker ACP bind smoke перевіряє вбудований у OpenClaw runtime-бекенд `acpx`. -## Live: димова перевірка тестового стенда Codex app-server +## Live: Codex app-server harness smoke -- Мета: перевірити тестовий стенд Codex, яким володіє Plugin, через звичайний метод Gateway +- Мета: перевірити належний Plugin стенд Codex через звичайний метод gateway `agent`: - - завантажити вбудований Plugin `codex` + - завантажити bundled Plugin `codex` - вибрати `OPENCLAW_AGENT_RUNTIME=codex` - - надіслати перший хід агента Gateway до `openai/gpt-5.5` із примусово вибраним тестовим стендом Codex - - надіслати другий хід до тієї самої сесії OpenClaw і перевірити, що потік app-server + - надіслати перший gateway agent turn до `openai/gpt-5.5` із примусово ввімкненим стендом Codex + - надіслати другий turn до тієї самої сесії OpenClaw і перевірити, що потік app-server може відновитися - - виконати `/codex status` і `/codex models` через той самий шлях команди Gateway - - необов’язково виконати дві ескальовані проби оболонки, переглянуті Guardian: одну нешкідливу + - запустити `/codex status` і `/codex models` через той самий шлях команди gateway + - необов’язково запустити дві перевірені Guardian проби escalated shell: одну безпечну команду, яку має бути схвалено, і одне фальшиве завантаження секрету, яке має бути - відхилено, щоб агент поставив уточнювальне запитання -- Test: `src/gateway/gateway-codex-harness.live.test.ts` + відхилено, щоб агент перепитав +- Тест: `src/gateway/gateway-codex-harness.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_CODEX_HARNESS=1` - Типова модель: `openai/gpt-5.5` -- Необов’язкова проба зображення: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` -- Необов’язкова проба MCP/інструмента: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` -- Необов’язкова проба Guardian: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1` -- Димова перевірка використовує `agentRuntime.id: "codex"`, щоб несправний тестовий стенд Codex не міг +- Необов’язкова перевірка зображення: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` +- Необов’язкова перевірка MCP/інструменту: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` +- Необов’язкова перевірка Guardian: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1` +- Smoke використовує `agentRuntime.id: "codex"`, тож зламаний стенд Codex не може пройти, непомітно відкотившись до PI. -- Автентифікація: автентифікація Codex app-server з локального входу в підписку Codex. Димові перевірки Docker - також можуть надавати `OPENAI_API_KEY` для не-Codex проб, коли це застосовно, +- Автентифікація: автентифікація app-server Codex з локального входу підписки Codex. Docker + smokes також можуть надавати `OPENAI_API_KEY` для не-Codex перевірок, коли це застосовно, а також необов’язково скопійовані `~/.codex/auth.json` і `~/.codex/config.toml`. Локальний рецепт: @@ -324,56 +333,55 @@ pnpm test:docker:live-codex-harness Примітки Docker: -- Запускач Docker розташований у `scripts/test-live-codex-harness-docker.sh`. -- Він підвантажує змонтований `~/.profile`, передає `OPENAI_API_KEY`, копіює файли автентифікації CLI Codex, - коли вони присутні, встановлює `@openai/codex` у змонтований префікс npm із правом запису, - розміщує дерево вихідного коду, а потім запускає лише live-тест тестового стенда Codex. -- Docker типово вмикає проби зображення, MCP/інструмента та Guardian. Задайте +- Docker-runner розташований у `scripts/test-live-codex-harness-docker.sh`. +- Він підвантажує змонтований `~/.profile`, передає `OPENAI_API_KEY`, копіює файли автентифікації Codex CLI, + коли вони присутні, встановлює `@openai/codex` у змонтований npm-префікс із правом запису, + розміщує дерево джерельного коду, а потім запускає лише live-тест стенда Codex. +- Docker за замовчуванням умикає перевірки зображення, MCP/інструменту та Guardian. Задайте `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` або - `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` або - `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0`, коли вам потрібен вужчий запуск - для налагодження. -- Docker використовує ту саму явну конфігурацію середовища виконання Codex, тому застарілі псевдоніми або - відкат до PI не можуть приховати регресію тестового стенда Codex. + `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` чи + `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0`, коли потрібен вужчий debug-запуск. +- Docker використовує ту саму явну конфігурацію runtime Codex, тож застарілі псевдоніми або fallback до PI + не можуть приховати регресію стенда Codex. ### Рекомендовані live-рецепти -Вузькі явні списки дозволених елементів є найшвидшими й найменш нестабільними: +Вузькі, явні allowlists є найшвидшими та найменш нестабільними: -- Одна модель, напряму (без Gateway): +- Одна модель, напряму (без gateway): - `OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts` -- Одна модель, димова перевірка Gateway: +- Одна модель, gateway smoke: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Виклики інструментів у кількох провайдерів: +- Виклик інструментів у кількох провайдерів: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Фокус на Google (ключ Gemini API + Antigravity): +- Фокус на Google (API-ключ Gemini + Antigravity): - Gemini (API-ключ): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Antigravity (OAuth): `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Димова перевірка адаптивного мислення Google: - - Якщо локальні ключі зберігаються в профілі оболонки: `source ~/.profile` - - Динамічне типове значення Gemini 3: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000` +- Google adaptive thinking smoke: + - Якщо локальні ключі зберігаються в профілі shell: `source ~/.profile` + - Динамічне типове Gemini 3: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000` - Динамічний бюджет Gemini 2.5: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000` Примітки: - `google/...` використовує Gemini API (API-ключ). -- `google-antigravity/...` використовує міст Antigravity OAuth (кінцева точка агента у стилі Cloud Code Assist). +- `google-antigravity/...` використовує міст Antigravity OAuth (endpoint агента у стилі Cloud Code Assist). - `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема автентифікація + особливості інструментів). - Gemini API проти Gemini CLI: - - API: OpenClaw викликає розміщений у Google Gemini API через HTTP (API-ключ / автентифікація профілю); це те, що більшість користувачів має на увазі під “Gemini”. - - CLI: OpenClaw запускає локальний двійковий файл `gemini` через оболонку; він має власну автентифікацію й може поводитися інакше (підтримка потокового передавання/інструментів/розбіжність версій). + - API: OpenClaw викликає розміщений у Google Gemini API через HTTP (API-ключ / автентифікація профілю); саме це більшість користувачів має на увазі під “Gemini”. + - CLI: OpenClaw запускає локальний бінарний файл `gemini` через shell; він має власну автентифікацію та може поводитися інакше (підтримка streaming/інструментів/розбіжність версій). ## Live: матриця моделей (що ми покриваємо) -Немає фіксованого “списку моделей CI” (live є опціональним), але це **рекомендовані** моделі для регулярного покриття на машині розробника з ключами. +Немає фіксованого “списку моделей CI” (live є opt-in), але це **рекомендовані** моделі для регулярного покриття на dev-машині з ключами. -### Сучасний набір димових перевірок (виклики інструментів + зображення) +### Сучасний smoke-набір (виклик інструментів + зображення) -Це запуск “поширених моделей”, який, як ми очікуємо, має залишатися працездатним: +Це запуск “поширених моделей”, який, як ми очікуємо, має й надалі працювати: - OpenAI (не Codex): `openai/gpt-5.5` - OpenAI Codex OAuth: `openai-codex/gpt-5.5` @@ -384,12 +392,12 @@ pnpm test:docker:live-codex-harness - Z.AI (GLM): `zai/glm-5.1` - MiniMax: `minimax/MiniMax-M2.7` -Запустіть димову перевірку Gateway з інструментами + зображенням: +Запустіть gateway smoke з інструментами + зображенням: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Базовий рівень: виклики інструментів (Read + необов’язковий Exec) +### Базовий рівень: виклик інструментів (Read + необов’язковий Exec) -Виберіть принаймні одну модель для кожної родини провайдерів: +Виберіть принаймні одну модель на кожну родину провайдера: - OpenAI: `openai/gpt-5.5` - Anthropic: `anthropic/claude-opus-4-6` (або `anthropic/claude-sonnet-4-6`) @@ -398,28 +406,28 @@ pnpm test:docker:live-codex-harness - Z.AI (GLM): `zai/glm-5.1` - MiniMax: `minimax/MiniMax-M2.7` -Необов’язкове додаткове покриття (варто мати): +Необов’язкове додаткове покриття (бажано мати): - xAI: `xai/grok-4.3` (або остання доступна) - Mistral: `mistral/`… (виберіть одну модель із підтримкою “tools”, яку у вас увімкнено) -- Cerebras: `cerebras/`… (якщо у вас є доступ) -- LM Studio: `lmstudio/`… (локально; виклики інструментів залежать від режиму API) +- Cerebras: `cerebras/`… (якщо маєте доступ) +- LM Studio: `lmstudio/`… (локально; виклик інструментів залежить від режиму API) ### Vision: надсилання зображення (вкладення → мультимодальне повідомлення) -Додайте принаймні одну модель із підтримкою зображень до `OPENCLAW_LIVE_GATEWAY_MODELS` (варіанти Claude/Gemini/OpenAI з підтримкою vision тощо), щоб виконати пробу зображення. +Додайте принаймні одну модель із підтримкою зображень до `OPENCLAW_LIVE_GATEWAY_MODELS` (варіанти Claude/Gemini/OpenAI з підтримкою vision тощо), щоб виконати перевірку зображення. -### Агрегатори / альтернативні шлюзи +### Агрегатори / альтернативні gateway Якщо у вас увімкнені ключі, ми також підтримуємо тестування через: - OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою інструментів+зображень) - OpenCode: `opencode/...` для Zen і `opencode-go/...` для Go (автентифікація через `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) -Інші провайдери, які можна додати до live-матриці (якщо у вас є облікові дані/конфігурація): +Більше провайдерів, яких можна включити до live-матриці (якщо маєте креденшіали/конфігурацію): - Вбудовані: `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot` -- Через `models.providers` (кастомні кінцеві точки): `minimax` (cloud/API), а також будь-який OpenAI/Anthropic-сумісний проксі (LM Studio, vLLM, LiteLLM тощо) +- Через `models.providers` (користувацькі endpoints): `minimax` (cloud/API), а також будь-який сумісний з OpenAI/Anthropic proxy (LM Studio, vLLM, LiteLLM тощо) Не хардкодьте "all models" у документації. Авторитетний список — це те, що `discoverModels(...)` повертає на вашій машині, плюс доступні ключі. @@ -427,24 +435,24 @@ pnpm test:docker:live-codex-harness ## Облікові дані (ніколи не комітьте) -Live-тести знаходять облікові дані так само, як це робить CLI. Практичні наслідки: +Live-тести виявляють облікові дані так само, як це робить CLI. Практичні наслідки: -- Якщо CLI працює, live-тести мають знайти ті самі ключі. -- Якщо live-тест повідомляє “no creds”, налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі. +- Якщо CLI працює, live-тести мають знаходити ті самі ключі. +- Якщо live-тест повідомляє «немає облікових даних», налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі. -- Профілі автентифікації для кожного агента: `~/.openclaw/agents//agent/auth-profiles.json` (це те, що “profile keys” означає в live-тестах) +- Профілі автентифікації для окремих агентів: `~/.openclaw/agents//agent/auth-profiles.json` (саме це означає «profile keys» у live-тестах) - Конфігурація: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`) -- Каталог застарілого стану: `~/.openclaw/credentials/` (копіюється до staged live home, коли наявний, але не є основним сховищем profile-key) -- Локальні live-запуски типово копіюють активну конфігурацію, файли `auth-profiles.json` для кожного агента, застарілий `credentials/` і підтримувані зовнішні каталоги автентифікації CLI до тимчасового тестового home; staged live homes пропускають `workspace/` і `sandboxes/`, а перевизначення шляхів `agents.*.workspace` / `agentDir` вилучаються, щоб probes не торкалися вашого справжнього робочого простору хоста. +- Застарілий каталог стану: `~/.openclaw/credentials/` (копіюється до підготовленого live-домашнього каталогу, якщо наявний, але не є основним сховищем profile-key) +- Локальні live-запуски за замовчуванням копіюють активну конфігурацію, файли `auth-profiles.json` для окремих агентів, застарілий `credentials/` і підтримувані зовнішні каталоги автентифікації CLI до тимчасового тестового домашнього каталогу; підготовлені live-домашні каталоги пропускають `workspace/` і `sandboxes/`, а перевизначення шляхів `agents.*.workspace` / `agentDir` вилучаються, щоб перевірки не торкалися вашого справжнього робочого простору на хості. -Якщо хочете покладатися на env-ключі (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile` або використовуйте Docker runners нижче (вони можуть монтувати `~/.profile` у контейнер). +Якщо ви хочете покладатися на ключі env (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile` або використовуйте Docker-запускачі нижче (вони можуть монтувати `~/.profile` у контейнер). -## Deepgram live (транскрибування аудіо) +## Deepgram live (транскрипція аудіо) - Тест: `extensions/deepgram/audio.live.test.ts` - Увімкнення: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts` -## BytePlus coding plan live +## Live-план кодування BytePlus - Тест: `extensions/byteplus/live.test.ts` - Увімкнення: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts` @@ -454,24 +462,24 @@ Live-тести знаходять облікові дані так само, я - Тест: `extensions/comfy/comfy.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` -- Обсяг: +- Область: - Перевіряє вбудовані шляхи comfy для зображень, відео та `music_generate` - Пропускає кожну можливість, якщо `plugins.entries.comfy.config.` не налаштовано - - Корисно після змін у надсиланні workflows comfy, polling, завантаженнях або реєстрації Plugin + - Корисно після змін у надсиланні workflow comfy, опитуванні, завантаженнях або реєстрації Plugin ## Image generation live - Тест: `test/image-generation.runtime.live.test.ts` - Команда: `pnpm test:live test/image-generation.runtime.live.test.ts` - Harness: `pnpm test:live:media image` -- Обсяг: +- Область: - Перелічує кожен зареєстрований Plugin провайдера генерації зображень - - Завантажує відсутні env vars провайдера з вашої login shell (`~/.profile`) перед probing - - Типово використовує live/env API keys перед збереженими профілями автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували справжні shell credentials - - Пропускає провайдерів без придатної auth/profile/model + - Завантажує відсутні env-змінні провайдера з вашої login shell (`~/.profile`) перед перевіркою + - За замовчуванням використовує live/env API-ключі перед збереженими профілями автентифікації, тож застарілі тестові ключі в `auth-profiles.json` не приховують справжні облікові дані shell + - Пропускає провайдери без придатної автентифікації/профілю/моделі - Запускає кожного налаштованого провайдера через спільний runtime генерації зображень: - `:generate` - - `:edit`, коли провайдер заявляє підтримку edit + - `:edit`, коли провайдер оголошує підтримку редагування - Поточні охоплені вбудовані провайдери: - `deepinfra` - `fal` @@ -487,9 +495,9 @@ Live-тести знаходять облікові дані так само, я - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,openrouter/google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,openrouter:generate,xai:default-generate,xai:default-edit"` - Необов’язкова поведінка автентифікації: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth зі сховища профілів і ігнорувати env-only overrides + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію через сховище профілів і ігнорувати перевизначення лише через env -Для shipped CLI path додайте smoke `infer` після успішного проходження live-тесту провайдера/runtime: +Для постачуваного шляху CLI додайте smoke `infer` після успішного проходження live-тесту провайдера/runtime: ```bash OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_INFER_CLI_TEST=1 pnpm test:live -- test/image-generation.infer-cli.live.test.ts @@ -501,75 +509,75 @@ openclaw infer image generate \ --json ``` -Це охоплює parsing аргументів CLI, розв’язання config/default-agent, активацію вбудованого Plugin, спільний runtime генерації зображень і live-запит до провайдера. Очікується, що залежності Plugin наявні до завантаження runtime. +Це охоплює розбір аргументів CLI, розв’язання конфігурації/агента за замовчуванням, активацію вбудованих Plugin, спільний runtime генерації зображень і live-запит до провайдера. Очікується, що залежності Plugin будуть наявні до завантаження runtime. ## Music generation live - Тест: `extensions/music-generation-providers.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harness: `pnpm test:live:media music` -- Обсяг: - - Перевіряє спільний шлях вбудованого провайдера генерації музики +- Область: + - Перевіряє спільний вбудований шлях провайдера генерації музики - Наразі охоплює Google і MiniMax - - Завантажує env vars провайдера з вашої login shell (`~/.profile`) перед probing - - Типово використовує live/env API keys перед збереженими профілями автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували справжні shell credentials - - Пропускає провайдерів без придатної auth/profile/model - - Запускає обидва заявлені runtime-режими, коли доступні: - - `generate` з input лише prompt - - `edit`, коли провайдер заявляє `capabilities.edit.enabled` - - Поточне покриття shared-lane: + - Завантажує env-змінні провайдера з вашої login shell (`~/.profile`) перед перевіркою + - За замовчуванням використовує live/env API-ключі перед збереженими профілями автентифікації, тож застарілі тестові ключі в `auth-profiles.json` не приховують справжні облікові дані shell + - Пропускає провайдери без придатної автентифікації/профілю/моделі + - Запускає обидва оголошені режими runtime, коли вони доступні: + - `generate` з введенням лише prompt + - `edit`, коли провайдер оголошує `capabilities.edit.enabled` + - Поточне охоплення shared-lane: - `google`: `generate`, `edit` - `minimax`: `generate` - - `comfy`: окремий Comfy live-файл, не цей спільний sweep + - `comfy`: окремий live-файл Comfy, не цей спільний sweep - Необов’язкове звуження: - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.6"` - Необов’язкова поведінка автентифікації: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth зі сховища профілів і ігнорувати env-only overrides + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію через сховище профілів і ігнорувати перевизначення лише через env ## Video generation live - Тест: `extensions/video-generation-providers.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harness: `pnpm test:live:media video` -- Обсяг: - - Перевіряє спільний шлях вбудованого провайдера генерації відео - - Типово використовує release-safe smoke path: не-FAL провайдери, один text-to-video запит на провайдера, one-second lobster prompt і ліміт операції на провайдера з `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (типово `180000`) - - Типово пропускає FAL, бо затримка provider-side queue може домінувати над часом release; передайте `--video-providers fal` або `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"`, щоб запустити його явно - - Завантажує env vars провайдера з вашої login shell (`~/.profile`) перед probing - - Типово використовує live/env API keys перед збереженими профілями автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували справжні shell credentials - - Пропускає провайдерів без придатної auth/profile/model - - Типово запускає лише `generate` - - Установіть `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, щоб також запускати заявлені transform-режими, коли доступні: - - `imageToVideo`, коли провайдер заявляє `capabilities.imageToVideo.enabled`, а вибрані provider/model приймають buffer-backed local image input у спільному sweep - - `videoToVideo`, коли провайдер заявляє `capabilities.videoToVideo.enabled`, а вибрані provider/model приймають buffer-backed local video input у спільному sweep - - Поточні заявлені, але пропущені провайдери `imageToVideo` у спільному sweep: - - `vydra`, бо вбудований `veo3` є text-only, а вбудований `kling` потребує remote image URL - - Provider-specific Vydra coverage: +- Область: + - Перевіряє спільний вбудований шлях провайдера генерації відео + - За замовчуванням використовує release-safe smoke-шлях: провайдери не FAL, один запит text-to-video на провайдера, односекундний prompt із lobster і ліміт операції на провайдера з `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` за замовчуванням) + - За замовчуванням пропускає FAL, бо затримка черги на боці провайдера може домінувати над часом релізу; передайте `--video-providers fal` або `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"`, щоб запустити його явно + - Завантажує env-змінні провайдера з вашої login shell (`~/.profile`) перед перевіркою + - За замовчуванням використовує live/env API-ключі перед збереженими профілями автентифікації, тож застарілі тестові ключі в `auth-profiles.json` не приховують справжні облікові дані shell + - Пропускає провайдери без придатної автентифікації/профілю/моделі + - За замовчуванням запускає лише `generate` + - Установіть `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, щоб також запускати оголошені режими перетворення, коли вони доступні: + - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled`, а вибраний провайдер/модель приймає локальне зображення на основі буфера у спільному sweep + - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled`, а вибраний провайдер/модель приймає локальне відео на основі буфера у спільному sweep + - Поточні оголошені, але пропущені провайдери `imageToVideo` у спільному sweep: + - `vydra`, бо вбудований `veo3` є лише text-only, а вбудований `kling` потребує віддаленої URL-адреси зображення + - Специфічне для провайдера охоплення Vydra: - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - - цей файл запускає `veo3` text-to-video плюс lane `kling`, який типово використовує fixture з remote image URL - - Поточне live-покриття `videoToVideo`: - - `runway` лише коли вибрана модель є `runway/gen4_aleph` - - Поточні заявлені, але пропущені провайдери `videoToVideo` у спільному sweep: - - `alibaba`, `qwen`, `xai`, бо ці шляхи наразі потребують remote `http(s)` / MP4 reference URLs - - `google`, бо поточна shared Gemini/Veo lane використовує local buffer-backed input, і цей шлях не приймається у спільному sweep - - `openai`, бо поточна shared lane не має гарантій org-specific доступу до video inpaint/remix + - цей файл запускає `veo3` text-to-video плюс lane `kling`, який за замовчуванням використовує fixture віддаленої URL-адреси зображення + - Поточне live-охоплення `videoToVideo`: + - `runway` лише коли вибрана модель — `runway/gen4_aleph` + - Поточні оголошені, але пропущені провайдери `videoToVideo` у спільному sweep: + - `alibaba`, `qwen`, `xai`, бо ці шляхи наразі потребують віддалених `http(s)` / MP4 reference URL + - `google`, бо поточний спільний lane Gemini/Veo використовує локальне введення на основі буфера, а цей шлях не приймається у спільному sweep + - `openai`, бо поточний спільний lane не має гарантій доступу до video inpaint/remix, специфічних для org - Необов’язкове звуження: - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="deepinfra,google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` - - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, щоб включити кожного провайдера в default sweep, включно з FAL - - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, щоб зменшити ліміт кожної операції провайдера для агресивного smoke run + - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, щоб включити кожного провайдера в стандартний sweep, включно з FAL + - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, щоб зменшити ліміт кожної операції провайдера для агресивного smoke-запуску - Необов’язкова поведінка автентифікації: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth зі сховища профілів і ігнорувати env-only overrides + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію через сховище профілів і ігнорувати перевизначення лише через env ## Media live harness - Команда: `pnpm test:live:media` - Призначення: - - Запускає спільні image, music і video live suites через одну repo-native entrypoint - - Автоматично завантажує відсутні env vars провайдера з `~/.profile` - - Типово автоматично звужує кожен suite до провайдерів, які наразі мають придатну auth - - Повторно використовує `scripts/test-live.mjs`, тож поведінка Heartbeat і quiet-mode лишається узгодженою + - Запускає спільні live-набори для зображень, музики й відео через одну repo-native точку входу + - Автоматично завантажує відсутні env-змінні провайдера з `~/.profile` + - За замовчуванням автоматично звужує кожен набір до провайдерів, які наразі мають придатну автентифікацію + - Повторно використовує `scripts/test-live.mjs`, тож поведінка Heartbeat і quiet-mode залишається узгодженою - Приклади: - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` @@ -578,4 +586,4 @@ openclaw infer image generate \ ## Пов’язане -- [Тестування](/uk/help/testing) — unit, integration, QA і Docker suites +- [Тестування](/uk/help/testing) — модульні, інтеграційні, QA- та Docker-набори diff --git a/docs/uk/security/network-proxy.md b/docs/uk/security/network-proxy.md index 71df49853..c5b556438 100644 --- a/docs/uk/security/network-proxy.md +++ b/docs/uk/security/network-proxy.md @@ -1,40 +1,40 @@ --- read_when: - - Вам потрібен багаторівневий захист від атак SSRF і переприв’язування DNS + - Вам потрібен багаторівневий захист від SSRF-атак і атак із переприв’язуванням DNS - Налаштування зовнішнього прямого проксі для трафіку середовища виконання OpenClaw -summary: Як спрямовувати HTTP- та WebSocket-трафік середовища виконання OpenClaw через фільтрувальний проксі, керований оператором +summary: Як маршрутизувати HTTP- та WebSocket-трафік середовища виконання OpenClaw через керований оператором фільтрувальний проксі title: Мережевий проксі x-i18n: - generated_at: "2026-05-04T03:58:47Z" + generated_at: "2026-05-04T11:08:46Z" model: gpt-5.5 provider: openai - source_hash: fc7140c5ced0e7454a6f85d1ea8f3256bbd28cc0cb42eeafe8e5e6439b90e3f0 + source_hash: eedbf3bac14800c34c7ca2e3b6879dac360a88d51b5b7449ddf41a4dd471648b source_path: security/network-proxy.md workflow: 16 --- # Мережевий проксі -OpenClaw може маршрутизувати runtime HTTP- і WebSocket-трафік через forward-проксі, керований оператором. Це додатковий необовʼязковий рівень захисту для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща аудитованість мережі. +OpenClaw може спрямовувати runtime HTTP- і WebSocket-трафік через керований оператором прямий проксі. Це необов'язковий додатковий рівень захисту для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща аудитованість мережі. -OpenClaw не постачає, не завантажує, не запускає, не налаштовує і не сертифікує проксі. Ви запускаєте проксі-технологію, яка підходить вашому середовищу, а OpenClaw маршрутизує через неї звичайні локальні для процесу HTTP- і WebSocket-клієнти. +OpenClaw не постачає, не завантажує, не запускає, не налаштовує й не сертифікує проксі. Ви запускаєте проксі-технологію, яка підходить для вашого середовища, а OpenClaw спрямовує через неї звичайні локальні для процесу HTTP- і WebSocket-клієнти. ## Навіщо використовувати проксі? Проксі дає операторам одну точку мережевого контролю для вихідного HTTP- і WebSocket-трафіку. Це може бути корисно навіть поза посиленням захисту від SSRF: -- Централізована політика: підтримуйте одну політику вихідного трафіку замість того, щоб покладатися на правильне налаштування мережевих правил у кожному місці HTTP-виклику застосунку. -- Перевірки під час підключення: оцінюйте призначення після DNS-розвʼязання і безпосередньо перед тим, як проксі відкриє upstream-зʼєднання. -- Захист від DNS rebinding: зменшуйте проміжок між DNS-перевіркою на рівні застосунку і фактичним вихідним зʼєднанням. -- Ширше покриття JavaScript: маршрутизуйте звичайні клієнти `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch та подібні через той самий шлях. -- Аудитованість: журналюйте дозволені й заборонені призначення на межі вихідного трафіку. -- Операційний контроль: застосовуйте правила призначення, мережеву сегментацію, обмеження швидкості або allowlist-и вихідного трафіку без перебудови OpenClaw. +- Централізована політика: підтримуйте одну політику вихідного трафіку замість того, щоб покладатися на правильність мережевих правил у кожній точці HTTP-виклику застосунку. +- Перевірки під час підключення: оцінюйте призначення після DNS-резолюції та безпосередньо перед тим, як проксі відкриє висхідне з'єднання. +- Захист від DNS rebinding: зменште проміжок між DNS-перевіркою на рівні застосунку та фактичним вихідним з'єднанням. +- Ширше покриття JavaScript: спрямовуйте звичайні `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch і подібні клієнти одним шляхом. +- Аудитованість: записуйте дозволені й заборонені призначення на межі вихідного трафіку. +- Операційний контроль: застосовуйте правила призначень, сегментацію мережі, обмеження швидкості або списки дозволених вихідних адрес без повторного збирання OpenClaw. -Проксі-маршрутизація є процесним захисним обмеженням для звичайного вихідного HTTP- і WebSocket-трафіку. Вона дає операторам fail-closed шлях для маршрутизації підтримуваних JavaScript HTTP-клієнтів через власний фільтрувальний проксі, але це не мережевий sandbox рівня ОС і не змушує OpenClaw сертифікувати політику призначень проксі. +Маршрутизація через проксі — це процесний захисний бар'єр для звичайного вихідного HTTP- і WebSocket-трафіку. Вона дає операторам шлях із закриттям у разі помилки для маршрутизації підтримуваних JavaScript HTTP-клієнтів через їхній власний фільтрувальний проксі, але це не мережевий sandbox на рівні ОС і не означає, що OpenClaw сертифікує політику призначень проксі. -## Як OpenClaw маршрутизує трафік +## Як OpenClaw спрямовує трафік -Коли `proxy.enabled=true` і налаштовано URL проксі, захищені runtime-процеси, як-от `openclaw gateway run`, `openclaw node run` і `openclaw agent --local`, маршрутизують звичайний вихідний HTTP- і WebSocket-трафік через налаштований проксі: +Коли `proxy.enabled=true` і налаштовано URL проксі, захищені runtime-процеси, як-от `openclaw gateway run`, `openclaw node run` і `openclaw agent --local`, спрямовують звичайний вихідний HTTP- і WebSocket-трафік через налаштований проксі: ```text OpenClaw process @@ -43,27 +43,27 @@ OpenClaw process WebSocket clients -> operator-managed filtering proxy -> public internet ``` -Публічний контракт — це поведінка маршрутизації, а не внутрішні хуки Node, які використовуються для її реалізації. WebSocket-клієнти керівної площини OpenClaw Gateway використовують вузький прямий шлях для local loopback Gateway RPC-трафіку, коли URL Gateway використовує `localhost` або буквальну loopback IP-адресу, як-от `127.0.0.1` чи `[::1]`. Цей шлях керівної площини має мати змогу досягати loopback Gateway навіть тоді, коли проксі оператора блокує loopback-призначення. Звичайні runtime HTTP- і WebSocket-запити все одно використовують налаштований проксі. +Публічний контракт — це поведінка маршрутизації, а не внутрішні хуки Node, які використовуються для її реалізації. Клієнти WebSocket контрольної площини OpenClaw Gateway використовують вузький прямий шлях для local loopback Gateway RPC-трафіку, коли URL Gateway використовує `localhost` або буквальну loopback IP-адресу, як-от `127.0.0.1` чи `[::1]`. Цей шлях контрольної площини має бути здатний досягати loopback Gateway, навіть коли операторський проксі блокує loopback-призначення. Звичайні runtime HTTP- і WebSocket-запити й надалі використовують налаштований проксі. -Внутрішньо OpenClaw використовує два процесні хуки маршрутизації для цієї функції: +Внутрішньо OpenClaw використовує для цієї функції два процесні хуки маршрутизації: -- Маршрутизація через dispatcher Undici покриває `fetch`, клієнти на базі undici і транспорти, що надають власний undici dispatcher. -- Маршрутизація `global-agent` покриває виклики ядра Node `node:http` і `node:https`, зокрема багато бібліотек, побудованих поверх `http.request`, `https.request`, `http.get` і `https.get`. Керований режим проксі примусово використовує цей глобальний агент, щоб явні HTTP-агенти Node випадково не обходили проксі оператора. +- Маршрутизація диспетчера Undici покриває `fetch`, клієнти на основі undici та транспорти, які надають власний диспетчер undici. +- Маршрутизація `global-agent` покриває викликачів ядра Node `node:http` і `node:https`, включно з багатьма бібліотеками, побудованими поверх `http.request`, `https.request`, `http.get` і `https.get`. Керований режим проксі примусово використовує цей глобальний агент, щоб явні HTTP-агенти Node випадково не обходили операторський проксі. -Деякі plugins володіють власними транспортами, яким потрібне явне підключення проксі навіть за наявності процесної маршрутизації. Наприклад, транспорт Bot API Telegram використовує власний HTTP/1 undici dispatcher і тому враховує змінні середовища процесного проксі плюс керований fallback `OPENCLAW_PROXY_URL` у цьому специфічному для власника транспортному шляху. +Деякі plugins володіють власними транспортами, яким потрібне явне підключення проксі навіть за наявності процесної маршрутизації. Наприклад, транспорт Telegram Bot API використовує власний HTTP/1-диспетчер undici і тому враховує змінні середовища процесного проксі плюс керований fallback `OPENCLAW_PROXY_URL` у цьому специфічному для власника транспортному шляху. -Сам URL проксі має використовувати `http://`. HTTPS-призначення все одно підтримуються через проксі за допомогою HTTP `CONNECT`; це лише означає, що OpenClaw очікує звичайний слухач HTTP forward-проксі, наприклад `http://127.0.0.1:3128`. +Сам URL проксі має використовувати `http://`. HTTPS-призначення все одно підтримуються через проксі за допомогою HTTP `CONNECT`; це лише означає, що OpenClaw очікує звичайний HTTP-слухач прямого проксі, наприклад `http://127.0.0.1:3128`. -Поки проксі активний, OpenClaw очищає `no_proxy`, `NO_PROXY` і `GLOBAL_AGENT_NO_PROXY`. Ці списки обходу залежать від призначення, тому якщо залишити там `localhost` або `127.0.0.1`, високоризикові SSRF-цілі зможуть оминути фільтрувальний проксі. +Поки проксі активний, OpenClaw очищає `no_proxy`, `NO_PROXY` і `GLOBAL_AGENT_NO_PROXY`. Ці списки обходу базуються на призначеннях, тому залишення там `localhost` або `127.0.0.1` дозволило б високоризиковим SSRF-цілям оминати фільтрувальний проксі. -Під час завершення роботи OpenClaw відновлює попереднє проксі-середовище і скидає кешований стан процесної маршрутизації. +Під час завершення роботи OpenClaw відновлює попереднє проксі-середовище й скидає кешований стан процесної маршрутизації. -## Повʼязані терміни проксі +## Пов'язані терміни проксі -- `proxy.enabled` / `proxy.proxyUrl`: маршрутизація вихідного forward-проксі для runtime-вихідного трафіку OpenClaw. Ця сторінка документує цю функцію. -- `gateway.auth.mode: "trusted-proxy"`: вхідна identity-aware автентифікація reverse-проксі для доступу до Gateway. Див. [Автентифікація довіреного проксі](/uk/gateway/trusted-proxy-auth). +- `proxy.enabled` / `proxy.proxyUrl`: маршрутизація вихідного трафіку OpenClaw runtime через прямий проксі. Ця сторінка документує цю функцію. +- `gateway.auth.mode: "trusted-proxy"`: вхідна автентифікація через identity-aware зворотний проксі для доступу до Gateway. Див. [Автентифікація через довірений проксі](/uk/gateway/trusted-proxy-auth). - `openclaw proxy`: локальний debug-проксі та інспектор захоплення для розробки й підтримки. Див. [openclaw proxy](/uk/cli/proxy). -- Налаштування проксі, специфічні для каналу або провайдера: специфічні для власника перевизначення для окремого транспорту. Надавайте перевагу керованому мережевому проксі, коли мета — централізований контроль вихідного трафіку в усьому runtime. +- Налаштування проксі, специфічні для каналу або провайдера: перевизначення, специфічні для власника, для певного транспорту. Надавайте перевагу керованому мережевому проксі, коли мета — централізований контроль вихідного трафіку в межах runtime. ## Конфігурація @@ -81,9 +81,9 @@ OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run `proxy.proxyUrl` має пріоритет над `OPENCLAW_PROXY_URL`. -Якщо `enabled=true`, але не налаштовано валідний URL проксі, захищені команди завершують запуск з помилкою замість fallback до прямого мережевого доступу. +Якщо `enabled=true`, але не налаштовано чинний URL проксі, захищені команди завершують запуск із помилкою замість fallback до прямого мережевого доступу. -Для керованих сервісів gateway, запущених за допомогою `openclaw gateway start`, краще зберігати URL у конфігурації: +Для керованих сервісів Gateway, запущених за допомогою `openclaw gateway start`, надавайте перевагу збереженню URL у конфігурації: ```bash openclaw config set proxy.enabled true @@ -92,9 +92,9 @@ openclaw gateway install --force openclaw gateway start ``` -Fallback через середовище найкраще підходить для запусків у передньому плані. Якщо ви використовуєте його з інстальованим сервісом, помістіть `OPENCLAW_PROXY_URL` у довготривале середовище сервісу, наприклад `$OPENCLAW_STATE_DIR/.env` або `~/.openclaw/.env`, а потім перевстановіть сервіс, щоб launchd, systemd або Scheduled Tasks запускали gateway з цим значенням. +Fallback через середовище найкраще підходить для запусків у передньому плані. Якщо ви використовуєте його зі встановленим сервісом, помістіть `OPENCLAW_PROXY_URL` у сталe середовище сервісу, наприклад `$OPENCLAW_STATE_DIR/.env` або `~/.openclaw/.env`, а потім перевстановіть сервіс, щоб launchd, systemd або Scheduled Tasks запускали gateway з цим значенням. -Для команд `openclaw --container ...` OpenClaw передає `OPENCLAW_PROXY_URL` у дочірній CLI, орієнтований на контейнер, коли його задано. URL має бути доступним зсередини контейнера; `127.0.0.1` посилається на сам контейнер, а не на хост. OpenClaw відхиляє loopback URL-и проксі для команд, орієнтованих на контейнер, якщо ви явно не перевизначите цю перевірку безпеки. +Для команд `openclaw --container ...` OpenClaw передає `OPENCLAW_PROXY_URL` у дочірній CLI, націлений на контейнер, коли його встановлено. URL має бути досяжним ізсередини контейнера; `127.0.0.1` вказує на сам контейнер, а не на хост. OpenClaw відхиляє loopback URL проксі для команд, націлених на контейнер, якщо ви явно не перевизначите цю перевірку безпеки. ## Вимоги до проксі @@ -102,53 +102,53 @@ Fallback через середовище найкраще підходить д Налаштуйте проксі так, щоб він: -- Привʼязувався лише до loopback або приватного довіреного інтерфейсу. -- Обмежував доступ так, щоб ним могли користуватися лише процес OpenClaw, хост, контейнер або service account. -- Самостійно розвʼязував призначення і блокував IP-адреси призначення після DNS-розвʼязання. +- Прив'язувався лише до loopback або приватного довіреного інтерфейсу. +- Обмежував доступ так, щоб ним міг користуватися лише процес OpenClaw, хост, контейнер або сервісний обліковий запис. +- Самостійно резолвив призначення та блокував IP-адреси призначень після DNS-резолюції. - Застосовував політику під час підключення як для звичайних HTTP-запитів, так і для HTTPS-тунелів `CONNECT`. - Відхиляв обходи на основі призначення для loopback, приватних, link-local, metadata, multicast, reserved або documentation діапазонів. -- Уникав allowlist-ів імен хостів, якщо ви не повністю довіряєте шляху DNS-розвʼязання. -- Журналював призначення, рішення, статус і причину без журналювання тіл запитів, authorization-заголовків, cookies або інших секретів. -- Тримав політику проксі під version control і переглядав зміни як безпеково чутливу конфігурацію. +- Уникав списків дозволених імен хостів, якщо ви повністю не довіряєте шляху DNS-резолюції. +- Записував призначення, рішення, статус і причину без логування тіл запитів, заголовків авторизації, cookies або інших секретів. +- Тримав політику проксі під контролем версій і переглядав зміни як конфігурацію, чутливу до безпеки. ## Рекомендовані заблоковані призначення -Використовуйте цей denylist як відправну точку для будь-якого forward-проксі, firewall або політики вихідного трафіку. +Використовуйте цей список заборон як відправну точку для будь-якого прямого проксі, firewall або політики вихідного трафіку. -Логіка класифікатора OpenClaw на рівні застосунку міститься в `src/infra/net/ssrf.ts` і `src/shared/net/ip.ts`. Відповідні parity-хуки — це `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` і вбудована обробка sentinel-ів IPv4 для NAT64, 6to4, Teredo, ISATAP та IPv4-mapped форм. Ці файли корисні як довідка під час підтримки зовнішньої політики проксі, але OpenClaw не експортує і не застосовує ці правила автоматично у вашому проксі. +Логіка класифікатора OpenClaw на рівні застосунку міститься в `src/infra/net/ssrf.ts` і `src/shared/net/ip.ts`. Відповідні хуки паритету — це `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` і вбудована обробка IPv4 sentinel для NAT64, 6to4, Teredo, ISATAP та IPv4-mapped форм. Ці файли є корисними довідковими матеріалами під час підтримки зовнішньої політики проксі, але OpenClaw не експортує й не застосовує ці правила у вашому проксі автоматично. -| Діапазон або хост | Чому блокувати | -| ------------------------------------------------------------------------------------ | --------------------------------------------------- | -| `127.0.0.0/8`, `localhost`, `localhost.localdomain` | IPv4 loopback | -| `::1/128` | IPv6 loopback | -| `0.0.0.0/8`, `::/128` | Невизначені адреси та адреси цієї мережі | -| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | Приватні мережі RFC1918 | -| `169.254.0.0/16`, `fe80::/10` | Link-local адреси і поширені шляхи cloud metadata | -| `169.254.169.254`, `metadata.google.internal` | Сервіси cloud metadata | -| `100.64.0.0/10` | Спільний адресний простір carrier-grade NAT | -| `198.18.0.0/15`, `2001:2::/48` | Діапазони для benchmark-тестування | -| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | Діапазони special-use і documentation | -| `224.0.0.0/4`, `ff00::/8` | Multicast | -| `240.0.0.0/4` | Reserved IPv4 | -| `fc00::/7`, `fec0::/10` | Локальні/приватні діапазони IPv6 | -| `100::/64`, `2001:20::/28` | Діапазони IPv6 discard і ORCHIDv2 | -| `64:ff9b::/96`, `64:ff9b:1::/48` | Префікси NAT64 із вбудованим IPv4 | -| `2002::/16`, `2001::/32` | 6to4 і Teredo із вбудованим IPv4 | -| `::/96`, `::ffff:0:0/96` | IPv4-compatible та IPv4-mapped IPv6 | +| Діапазон або хост | Навіщо блокувати | +| ------------------------------------------------------------------------------------ | ------------------------------------------------- | +| `127.0.0.0/8`, `localhost`, `localhost.localdomain` | IPv4 loopback | +| `::1/128` | IPv6 loopback | +| `0.0.0.0/8`, `::/128` | Невизначені адреси та адреси цієї мережі | +| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | Приватні мережі RFC1918 | +| `169.254.0.0/16`, `fe80::/10` | Link-local адреси та поширені шляхи cloud metadata | +| `169.254.169.254`, `metadata.google.internal` | Сервіси cloud metadata | +| `100.64.0.0/10` | Спільний адресний простір carrier-grade NAT | +| `198.18.0.0/15`, `2001:2::/48` | Діапазони для benchmark | +| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | Діапазони special-use і documentation | +| `224.0.0.0/4`, `ff00::/8` | Multicast | +| `240.0.0.0/4` | Зарезервований IPv4 | +| `fc00::/7`, `fec0::/10` | Локальні/приватні діапазони IPv6 | +| `100::/64`, `2001:20::/28` | IPv6 discard і ORCHIDv2 діапазони | +| `64:ff9b::/96`, `64:ff9b:1::/48` | Префікси NAT64 з вбудованим IPv4 | +| `2002::/16`, `2001::/32` | 6to4 і Teredo з вбудованим IPv4 | +| `::/96`, `::ffff:0:0/96` | IPv4-compatible та IPv4-mapped IPv6 | -Якщо ваш cloud provider або мережева платформа документує додаткові metadata-хости чи reserved діапазони, також додайте їх. +Якщо ваш cloud-провайдер або мережева платформа документує додаткові metadata-хости чи зарезервовані діапазони, додайте їх також. ## Валідація -Валідуйте проксі з того самого хоста, контейнера або service account, який запускає OpenClaw: +Перевіряйте проксі з того самого хоста, контейнера або сервісного облікового запису, який запускає OpenClaw: ```bash openclaw proxy validate --proxy-url http://127.0.0.1:3128 ``` -За замовчуванням, коли власні призначення не надано, команда перевіряє, що `https://example.com/` успішний, і запускає тимчасовий loopback canary, якого проксі не має досягти. Стандартна перевірка заборони проходить, коли проксі повертає не-2xx відповідь відмови або блокує canary транспортною помилкою; вона зазнає невдачі, якщо успішна відповідь досягає canary. Якщо проксі не ввімкнено і не налаштовано, валідація повідомляє про проблему конфігурації; використовуйте `--proxy-url` для одноразового preflight перед зміною конфігурації. Використовуйте `--allowed-url` і `--denied-url`, щоб тестувати очікування, специфічні для розгортання. Власні заборонені призначення є fail-closed: будь-яка HTTP-відповідь означає, що призначення було доступне через проксі, а будь-яка транспортна помилка повідомляється як непереконлива, бо OpenClaw не може довести, що проксі заблокував доступне походження. У разі невдалої валідації команда завершується з кодом 1. +За замовчуванням, коли не надано власні призначення, команда перевіряє, що `https://example.com/` успішно відкривається, і запускає тимчасовий loopback canary, якого проксі не має досягти. Стандартна перевірка заборони проходить, коли проксі повертає non-2xx відповідь відмови або блокує canary через транспортну помилку; вона не проходить, якщо успішна відповідь досягає canary. Якщо проксі не ввімкнено й не налаштовано, валідація повідомляє про проблему конфігурації; використовуйте `--proxy-url` для одноразового preflight перед зміною конфігурації. Використовуйте `--allowed-url` і `--denied-url`, щоб перевірити очікування, специфічні для розгортання. Додайте `--apns-reachable`, щоб також перевірити, що пряма доставка APNs HTTP/2 може відкрити тунель CONNECT через проксі й отримати відповідь sandbox APNs; probe використовує навмисно недійсний токен провайдера, тому очікується `403 InvalidProviderToken`, і це зараховується як досяжність. Власні заборонені призначення є fail-closed: будь-яка HTTP-відповідь означає, що призначення було досяжне через проксі, а будь-яка транспортна помилка повідомляється як непереконлива, оскільки OpenClaw не може довести, що проксі заблокував досяжне джерело. У разі помилки валідації команда завершується з кодом 1. -Використовуйте `--json` для автоматизації. JSON-вивід містить загальний результат, джерело ефективної конфігурації проксі, будь-які помилки конфігурації і кожну перевірку призначення. Облікові дані URL проксі редагуються в текстовому і JSON-виводі: +Використовуйте `--json` для автоматизації. JSON-вивід містить загальний результат, ефективне джерело конфігурації проксі, будь-які помилки конфігурації та кожну перевірку призначення. Облікові дані URL проксі редагуються в текстовому та JSON-виводі: ```json { @@ -165,12 +165,18 @@ openclaw proxy validate --proxy-url http://127.0.0.1:3128 "url": "https://example.com/", "ok": true, "status": 200 + }, + { + "kind": "apns", + "url": "https://api.sandbox.push.apple.com", + "ok": true, + "status": 403 } ] } ``` -Ви також можете перевірити вручну за допомогою `curl`: +Також можна перевірити вручну за допомогою `curl`: ```bash curl -x http://127.0.0.1:3128 https://example.com/ @@ -178,7 +184,7 @@ curl -x http://127.0.0.1:3128 http://127.0.0.1/ curl -x http://127.0.0.1:3128 http://169.254.169.254/ ``` -Публічний запит має пройти успішно. Запити до loopback і метаданих має заблокувати проксі. Для `openclaw proxy validate` вбудований loopback canary може відрізнити відмову проксі від доступного origin. Користувацькі перевірки `--denied-url` не мають цього canary, тому вважайте як HTTP-відповіді, так і неоднозначні транспортні збої помилками перевірки, якщо ваш проксі не надає специфічний для розгортання сигнал відмови, який можна перевірити окремо. +Публічний запит має виконатися успішно. Запити до loopback і метаданих мають бути заблоковані проксі. Для `openclaw proxy validate` вбудований loopback-канарковий тест може відрізнити відмову проксі від доступного джерела. Користувацькі перевірки `--denied-url` не мають такого канаркового тесту, тому вважайте як HTTP-відповіді, так і неоднозначні транспортні збої помилками перевірки, якщо ваш проксі не надає специфічний для розгортання сигнал відмови, який можна перевірити окремо. Потім увімкніть проксі-маршрутизацію OpenClaw: @@ -198,11 +204,11 @@ proxy: ## Обмеження -- Проксі покращує покриття для process-local JavaScript HTTP- і WebSocket-клієнтів, але не є мережевою пісочницею рівня ОС. -- Raw-сокети `net`, `tls` і `http2`, нативні доповнення та дочірні процеси можуть обходити проксі-маршрутизацію рівня Node, якщо вони не успадковують і не дотримуються змінних середовища проксі. -- IRC є raw TCP/TLS-каналом поза маршрутизацією через forward proxy, керований оператором. У розгортаннях, які вимагають, щоб увесь вихідний трафік проходив через цей forward proxy, задайте `channels.irc.enabled=false`, якщо прямий вихідний IRC-трафік явно не схвалено. -- Локальний debug-проксі є діагностичним інструментом, і його пряме пересилання upstream для проксі-запитів і тунелів CONNECT за замовчуванням вимкнене, доки активний режим керованого проксі; вмикайте пряме пересилання лише для схваленої локальної діагностики. -- Локальні WebUI користувача та локальні сервери моделей за потреби слід додати до списку дозволених у політиці проксі оператора; OpenClaw не надає для них загального обходу локальної мережі. -- Обхід проксі для control plane Gateway навмисно обмежено `localhost` і URL з буквальними loopback IP. Використовуйте `ws://127.0.0.1:18789`, `ws://[::1]:18789` або `ws://localhost:18789` для локальних прямих підключень до control plane Gateway; інші імена хостів маршрутизуються як звичайний трафік на основі імені хоста. -- OpenClaw не перевіряє, не тестує і не сертифікує вашу політику проксі. -- Розглядайте зміни політики проксі як безпеково чутливі операційні зміни. +- Проксі покращує покриття для локальних у межах процесу клієнтів JavaScript HTTP і WebSocket, але це не мережевий sandbox рівня ОС. +- Необроблені сокети `net`, `tls` і `http2`, нативні аддони та дочірні процеси можуть обходити проксі-маршрутизацію на рівні Node, якщо вони не успадковують і не дотримуються змінних середовища проксі. +- IRC — це необроблений TCP/TLS-канал поза маршрутизацією через керований оператором прямий проксі. У розгортаннях, які вимагають, щоб увесь вихідний трафік проходив через цей прямий проксі, задайте `channels.irc.enabled=false`, якщо прямий вихідний IRC-трафік не схвалено явно. +- Локальний налагоджувальний проксі є діагностичним інструментом, а його пряме переспрямування до upstream для проксі-запитів і тунелів CONNECT типово вимкнене, доки активний керований режим проксі; вмикайте пряме переспрямування лише для схваленої локальної діагностики. +- Локальні WebUI користувача та локальні сервери моделей слід додавати до списку дозволених у політиці проксі оператора, коли це потрібно; OpenClaw не надає для них загального обходу локальної мережі. +- Обхід проксі для площини керування Gateway навмисно обмежений `localhost` і URL з буквальними loopback-IP. Використовуйте `ws://127.0.0.1:18789`, `ws://[::1]:18789` або `ws://localhost:18789` для локальних прямих з’єднань із площиною керування Gateway; інші імена хостів маршрутизуються як звичайний трафік на основі імен хостів. +- OpenClaw не перевіряє, не тестує й не сертифікує вашу політику проксі. +- Розглядайте зміни політики проксі як чутливі до безпеки операційні зміни.