chore(i18n): refresh uk translations

2026-05-04 11:10:58 +00:00 · 2026-05-04 11:10:58 +00:00 · 84ffb0b374
commit 84ffb0b374
parent 8a911eafe4
3 changed files with 321 additions and 303 deletions
--- 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 <host>] [--port <port>]
 openclaw proxy run [--host <host>] [--port <port>] -- <cmd...>
-openclaw proxy validate [--json] [--proxy-url <url>] [--allowed-url <url>] [--denied-url <url>] [--timeout-ms <ms>]
+openclaw proxy validate [--json] [--proxy-url <url>] [--allowed-url <url>] [--denied-url <url>] [--apns-reachable] [--apns-authority <url>] [--timeout-ms <ms>]
 openclaw proxy coverage
 openclaw proxy sessions [--limit <count>]
 openclaw proxy query --preset <name> [--session <id>]
@ -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>`: перевірити цю URL-адресу проксі замість конфігурації або env.
- `--allowed-url <url>`: додати призначення, яке має успішно досягатися через проксі. Повторіть, щоб перевірити кілька призначень.
+- `--json`: вивести машиночитний JSON.
+- `--proxy-url <url>`: перевірити цю URL-адресу проксі замість конфігурації або змінної середовища.
+- `--allowed-url <url>`: додати призначення, яке має успішно проходити через проксі. Повторіть, щоб перевірити кілька призначень.
 - `--denied-url <url>`: додати призначення, яке має блокуватися проксі. Повторіть, щоб перевірити кілька призначень.
+- `--apns-reachable`: також перевірити, що пісочний APNs HTTP/2 досяжний через проксі.
+- `--apns-authority <url>`: служба APNs для перевірки з `--apns-reachable` (`https://api.sandbox.push.apple.com` за замовчуванням; production — `https://api.push.apple.com`).
 - `--timeout-ms <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)
--- 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 <CODE>`.
+    - регресійні шляхи OpenAI (лише виклик інструмента → подальше повідомлення) продовжують працювати
+- Деталі проб (щоб можна було швидко пояснювати збої):
+  - Проба `read`: тест записує nonce-файл у робочій області й просить агента `read` його та повернути nonce.
+  - Проба `exec+read`: тест просить агента через `exec` записати nonce у тимчасовий файл, а потім через `read` прочитати його назад.
+  - Проба зображення: тест долучає згенерований PNG (кіт + випадковий код) і очікує, що модель поверне `cat <CODE>`.
  - Посилання на реалізацію: `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: "<base64>" }]`
    - Gateway розбирає вкладення в `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
-    - Вбудований agent пересилає multimodal повідомлення користувача до моделі
-    - Твердження: відповідь містить `cat` + код (допуск OCR: незначні помилки дозволено)
+    - Вбудований агент пересилає мультимодальне повідомлення користувача до моделі
+    - Перевірка: відповідь містить `cat` + код (допуск OCR: дозволені незначні помилки)

 <Tip>
 Щоб побачити, що можна протестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте:
@ -144,27 +144,27 @@ openclaw models list --json

 </Tip>

-## Живі тести: 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 <agent> --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 тощо)

 <Tip>
 Не хардкодьте "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/<agentId>/agent/auth-profiles.json` (це те, що “profile keys” означає в live-тестах)
+- Профілі автентифікації для окремих агентів: `~/.openclaw/agents/<agentId>/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.<capability>` не налаштовано
-  - Корисно після змін у надсиланні 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 генерації зображень:
    - `<provider>:generate`
-    - `<provider>:edit`, коли провайдер заявляє підтримку edit
+    - `<provider>: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-набори
--- 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 не перевіряє, не тестує й не сертифікує вашу політику проксі.
+- Розглядайте зміни політики проксі як чутливі до безпеки операційні зміни.