chore(i18n): refresh uk translations

This commit is contained in:
openclaw-docs-i18n[bot] 2026-05-04 03:59:43 +00:00
parent a99cadda0e
commit ee1812d415
2 changed files with 87 additions and 85 deletions

View File

@ -1,29 +1,29 @@
---
read_when:
- Потрібно перевірити керовану оператором маршрутизацію через проксі перед розгортанням
- Вам потрібно локально захопити транспортний трафік OpenClaw для налагодження
- Ви хочете переглянути сеанси проксі налагодження, бінарні об’єкти або вбудовані пресети запитів
summary: Довідка CLI для `openclaw proxy`, включно з перевіркою проксі, керованого оператором, та інспектором захоплень локального налагоджувального проксі
- Потрібно перевірити маршрутизацію проксі, керовану оператором, перед розгортанням
- Потрібно локально захопити транспортний трафік OpenClaw для налагодження
- Ви хочете переглядати сеанси налагоджувального проксі, блоби або вбудовані пресети запитів.
summary: Довідник CLI для `openclaw proxy`, включно з перевіркою проксі, керованого оператором, і локальним інспектором захоплень проксі для налагодження
title: Проксі
x-i18n:
generated_at: "2026-05-01T05:23:58Z"
generated_at: "2026-05-04T03:58:53Z"
model: gpt-5.5
provider: openai
source_hash: e0820de861bfe1ec14e0c1624d636d6474b5fedd317e3ba1baaa61f6530e06e9
source_hash: 9589bedafb97c31bcb6536a04307cd0c6550e1f307693bd4401785d79f34a1eb
source_path: cli/proxy.md
workflow: 16
---
# `openclaw proxy`
Перевіряйте керовану оператором маршрутизацію проксі або запускайте локальний явний проксі для налагодження
та інспектуйте захоплений трафік.
Перевіряйте маршрутизацію проксі, керовану оператором, або запускайте локальний явний проксі для налагодження
й аналізуйте захоплений трафік.
Використовуйте `validate`, щоб попередньо перевірити керований оператором прямий проксі перед увімкненням
маршрутизації проксі OpenClaw. Інші команди є інструментами налагодження для
дослідження на транспортному рівні: вони можуть запускати локальний проксі, виконувати дочірню команду
з увімкненим захопленням, перелічувати сеанси захоплення, запитувати поширені шаблони трафіку, читати
захоплені blob-об’єкти та очищати локальні дані захоплення.
захоплені blobs і очищати локальні дані захоплення.
## Команди
@ -40,25 +40,25 @@ openclaw proxy purge
## Перевірка
`openclaw proxy validate` перевіряє ефективну URL-адресу керованого оператором проксі з
`--proxy-url`, конфігурації або `OPENCLAW_PROXY_URL`. Вона повідомляє про проблему конфігурації, коли
`openclaw proxy validate` перевіряє ефективну URL-адресу проксі, керованого оператором, з
`--proxy-url`, конфігурації або `OPENCLAW_PROXY_URL`. Він повідомляє про проблему конфігурації, коли
проксі не ввімкнено й не налаштовано; використовуйте `--proxy-url` для одноразової попередньої перевірки
перед зміною конфігурації. За замовчуванням вона перевіряє, що публічний пункт призначення успішно доступний
через проксі та що проксі не може досягти тимчасової loopback-приманки.
Користувацькі заборонені пункти призначення блокуються за замовчуванням: HTTP-відповіді та неоднозначні
транспортні збої вважаються невдачею, якщо ви не можете окремо перевірити специфічний для розгортання
перед зміною конфігурації. За замовчуванням він перевіряє, що публічне призначення успішно досягається
через проксі й що проксі не може досягти тимчасового loopback-індикатора.
Користувацькі заборонені призначення працюють за принципом fail-closed: HTTP-відповіді та неоднозначні
транспортні збої однаково вважаються невдачею, якщо ви не можете окремо перевірити специфічний для розгортання
сигнал відмови.
Параметри:
- `--json`: вивести машиночитний JSON.
- `--proxy-url <url>`: перевірити цю URL-адресу проксі замість конфігурації або змінної середовища.
- `--allowed-url <url>`: додати пункт призначення, який має успішно працювати через проксі. Повторіть, щоб перевірити кілька пунктів призначення.
- `--denied-url <url>`: додати пункт призначення, який має блокуватися проксі. Повторіть, щоб перевірити кілька пунктів призначення.
- `--json`: вивести машинозчитуваний JSON.
- `--proxy-url <url>`: перевірити цю URL-адресу проксі замість конфігурації або env.
- `--allowed-url <url>`: додати призначення, яке має успішно досягатися через проксі. Повторіть, щоб перевірити кілька призначень.
- `--denied-url <url>`: додати призначення, яке має блокуватися проксі. Повторіть, щоб перевірити кілька призначень.
- `--timeout-ms <ms>`: тайм-аут для кожного запиту в мілісекундах.
Див. [Мережевий проксі](/uk/security/network-proxy) для рекомендацій щодо розгортання та
семантики відмови.
Див. [Мережевий проксі](/uk/security/network-proxy) щодо рекомендацій із розгортання та семантики
відмови.
## Попередні набори запитів
@ -75,8 +75,9 @@ openclaw proxy purge
- `start` за замовчуванням використовує `127.0.0.1`, якщо `--host` не задано.
- `run` запускає локальний проксі для налагодження, а потім виконує команду після `--`.
- `validate` завершується з кодом 1, коли конфігурація проксі або перевірки пунктів призначення не проходять.
- Захоплення є локальними даними налагодження; використовуйте `openclaw proxy purge`, коли завершите.
- Пряме переспрямування debug proxy до upstream відкриває upstream-сокети для діагностики. Коли активний режим керованого проксі OpenClaw, пряме переспрямування для proxy requests і тунелів CONNECT за замовчуванням вимкнено; задавайте `OPENCLAW_DEBUG_PROXY_ALLOW_DIRECT_CONNECT_WITH_MANAGED_PROXY=1` лише для затвердженої локальної діагностики.
- `validate` завершується з кодом 1, коли конфігурація проксі або перевірки призначення не проходять.
- Захоплення є локальними даними налагодження; використовуйте `openclaw proxy purge` після завершення.
## Пов’язане

View File

@ -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-04T00:58:55Z"
generated_at: "2026-05-04T03:58:47Z"
model: gpt-5.5
provider: openai
source_hash: cd5594324e8c6b7da51d903e98fda0feacb8970e0b15d980f7a249d6641461c9
source_hash: fc7140c5ced0e7454a6f85d1ea8f3256bbd28cc0cb42eeafe8e5e6439b90e3f0
source_path: security/network-proxy.md
workflow: 16
---
# Мережевий проксі
OpenClaw може спрямовувати runtime HTTP- і WebSocket-трафік через керований оператором прямий проксі. Це необов’язковий додатковий рівень захисту для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща можливість аудиту мережі.
OpenClaw може маршрутизувати runtime HTTP- і WebSocket-трафік через forward-проксі, керований оператором. Це додатковий необовʼязковий рівень захисту для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща аудитованість мережі.
OpenClaw не постачає, не завантажує, не запускає, не налаштовує й не сертифікує проксі. Ви запускаєте проксі-технологію, яка підходить вашому середовищу, а OpenClaw спрямовує звичайні локальні для процесу HTTP- і WebSocket-клієнти через неї.
OpenClaw не постачає, не завантажує, не запускає, не налаштовує і не сертифікує проксі. Ви запускаєте проксі-технологію, яка підходить вашому середовищу, а OpenClaw маршрутизує через неї звичайні локальні для процесу HTTP- і WebSocket-клієнти.
## Навіщо використовувати проксі?
Проксі дає операторам одну точку мережевого контролю для вихідного HTTP- і WebSocket-трафіку. Це може бути корисно навіть поза посиленням захисту від SSRF:
- Централізована політика: підтримуйте одну політику вихідного трафіку замість покладатися на те, що кожне місце HTTP-виклику в застосунку правильно застосує мережеві правила.
- Перевірки під час підключення: оцінюйте призначення після DNS-резолюції та безпосередньо перед тим, як проксі відкриє вихідне з’єднання.
- Захист від DNS rebinding: зменшуйте проміжок між DNS-перевіркою на рівні застосунку та фактичним вихідним з’єднанням.
- Ширше покриття JavaScript: спрямовуйте звичайні `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch і подібні клієнти одним шляхом.
- Можливість аудиту: журналюйте дозволені та заборонені призначення на межі вихідного трафіку.
- Операційний контроль: застосовуйте правила призначення, сегментацію мережі, ліміти швидкості або allowlist вихідних призначень без перебудови OpenClaw.
- Централізована політика: підтримуйте одну політику вихідного трафіку замість того, щоб покладатися на правильне налаштування мережевих правил у кожному місці HTTP-виклику застосунку.
- Перевірки під час підключення: оцінюйте призначення після DNS-розвʼязання і безпосередньо перед тим, як проксі відкриє upstream-зʼєднання.
- Захист від DNS rebinding: зменшуйте проміжок між DNS-перевіркою на рівні застосунку і фактичним вихідним зʼєднанням.
- Ширше покриття JavaScript: маршрутизуйте звичайні клієнти `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch та подібні через той самий шлях.
- Аудитованість: журналюйте дозволені й заборонені призначення на межі вихідного трафіку.
- Операційний контроль: застосовуйте правила призначення, мережеву сегментацію, обмеження швидкості або allowlist-и вихідного трафіку без перебудови OpenClaw.
Маршрутизація через проксі є захисною межею на рівні процесу для звичайного вихідного HTTP- і WebSocket-трафіку. Вона дає операторам fail-closed шлях для маршрутизації підтримуваних JavaScript HTTP-клієнтів через їхній власний фільтрувальний проксі, але не є мережевою пісочницею на рівні ОС і не змушує OpenClaw сертифікувати політику призначень проксі.
Проксі-маршрутизація є процесним захисним обмеженням для звичайного вихідного HTTP- і WebSocket-трафіку. Вона дає операторам fail-closed шлях для маршрутизації підтримуваних JavaScript HTTP-клієнтів через власний фільтрувальний проксі, але це не мережевий sandbox рівня ОС і не змушує 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 та транспорти, що надають власний dispatcher undici.
- Маршрутизація `global-agent` покриває виклики ядра Node `node:http` і `node:https`, зокрема багато бібліотек, побудованих поверх `http.request`, `https.request`, `http.get` і `https.get`. Керований режим проксі примусово використовує цей глобальний агент, щоб явні Node HTTP-агенти випадково не обходили операторський проксі.
- Маршрутизація через dispatcher Undici покриває `fetch`, клієнти на базі undici і транспорти, що надають власний undici dispatcher.
- Маршрутизація `global-agent` покриває виклики ядра Node `node:http` і `node:https`, зокрема багато бібліотек, побудованих поверх `http.request`, `https.request`, `http.get` і `https.get`. Керований режим проксі примусово використовує цей глобальний агент, щоб явні HTTP-агенти Node випадково не обходили проксі оператора.
Деякі плагіни володіють власними транспортами, яким потрібне явне підключення проксі навіть за наявності маршрутизації на рівні процесу. Наприклад, транспорт Bot API Telegram використовує власний HTTP/1 undici dispatcher і тому враховує env проксі процесу плюс керований fallback `OPENCLAW_PROXY_URL` у цьому owner-specific транспортному шляху.
Деякі plugins володіють власними транспортами, яким потрібне явне підключення проксі навіть за наявності процесної маршрутизації. Наприклад, транспорт Bot API Telegram використовує власний HTTP/1 undici dispatcher і тому враховує змінні середовища процесного проксі плюс керований fallback `OPENCLAW_PROXY_URL` у цьому специфічному для власника транспортному шляху.
Сам URL проксі має використовувати `http://`. HTTPS-призначення все одно підтримуються через проксі за допомогою HTTP `CONNECT`; це лише означає, що OpenClaw очікує звичайний HTTP forward-proxy listener, наприклад `http://127.0.0.1:3128`.
Сам URL проксі має використовувати `http://`. HTTPS-призначення все одно підтримуються через проксі за допомогою HTTP `CONNECT`; це лише означає, що OpenClaw очікує звичайний слухач HTTP forward-проксі, наприклад `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 відновлює попереднє proxy environment і скидає кешований стан маршрутизації процесу.
Під час завершення роботи OpenClaw відновлює попереднє проксі-середовище і скидає кешований стан процесної маршрутизації.
## Повязані терміни проксі
## Повʼязані терміни проксі
- `proxy.enabled` / `proxy.proxyUrl`: маршрутизація вихідного forward-proxy для runtime-вихідного трафіку OpenClaw. Ця сторінка документує цю функцію.
- `gateway.auth.mode: "trusted-proxy"`: вхідна автентифікація через identity-aware reverse-proxy для доступу до Gateway. Див. [Автентифікація trusted proxy](/uk/gateway/trusted-proxy-auth).
- `openclaw proxy`: локальний debug proxy та capture inspector для розробки й підтримки. Див. [openclaw proxy](/uk/cli/proxy).
- Налаштування проксі, специфічні для каналу або провайдера: owner-specific перевизначення для конкретного транспорту. Надавайте перевагу керованому мережевому проксі, коли мета — централізований контроль вихідного трафіку в усьому runtime.
- `proxy.enabled` / `proxy.proxyUrl`: маршрутизація вихідного forward-проксі для runtime-вихідного трафіку OpenClaw. Ця сторінка документує цю функцію.
- `gateway.auth.mode: "trusted-proxy"`: вхідна identity-aware автентифікація reverse-проксі для доступу до Gateway. Див. [Автентифікація довіреного проксі](/uk/gateway/trusted-proxy-auth).
- `openclaw proxy`: локальний debug-проксі та інспектор захоплення для розробки й підтримки. Див. [openclaw proxy](/uk/cli/proxy).
- Налаштування проксі, специфічні для каналу або провайдера: специфічні для власника перевизначення для окремого транспорту. Надавайте перевагу керованому мережевому проксі, коли мета — централізований контроль вихідного трафіку в усьому 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 проксі, захищені команди завершують запуск з помилкою замість відкату до прямого мережевого доступу.
Якщо `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` у довготривале середовище сервісу, наприклад `$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, хост, контейнер або обліковий запис сервісу.
- Самостійно резолвив призначення та блокував IP-адреси призначення після DNS-резолюції.
- Привʼязувався лише до loopback або приватного довіреного інтерфейсу.
- Обмежував доступ так, щоб ним могли користуватися лише процес OpenClaw, хост, контейнер або service account.
- Самостійно розвʼязував призначення і блокував IP-адреси призначення після DNS-розвʼязання.
- Застосовував політику під час підключення як для звичайних HTTP-запитів, так і для HTTPS-тунелів `CONNECT`.
- Відхиляв обходи на основі призначення для loopback, приватних, link-local, metadata, multicast, reserved або documentation діапазонів.
- Уникав allowlist імен хостів, якщо ви повністю не довіряєте шляху DNS-резолюції.
- Журналював призначення, рішення, статус і причину без журналювання тіл запитів, заголовків авторизації, cookie або інших секретів.
- Тримав політику проксі під контролем версій і переглядав зміни як security-sensitive конфігурацію.
- Уникав allowlist-ів імен хостів, якщо ви не повністю довіряєте шляху DNS-розвʼязання.
- Журналював призначення, рішення, статус і причину без журналювання тіл запитів, authorization-заголовків, cookies або інших секретів.
- Тримав політику проксі під version control і переглядав зміни як безпеково чутливу конфігурацію.
## Рекомендовані заблоковані призначення
Використовуйте цей denylist як початкову точку для будь-якого forward proxy, firewall або політики вихідного трафіку.
Використовуйте цей denylist як відправну точку для будь-якого forward-проксі, firewall або політики вихідного трафіку.
Логіка класифікатора OpenClaw на рівні застосунку міститься в `src/infra/net/ssrf.ts` і `src/shared/net/ip.ts`. Відповідні parity hooks — це `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` і вбудована обробка IPv4 sentinel для NAT64, 6to4, Teredo, ISATAP і IPv4-mapped форм. Ці файли є корисними довідковими матеріалами під час підтримки зовнішньої політики проксі, але OpenClaw не експортує й не застосовує ці правила автоматично у вашому проксі.
Логіка класифікатора 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 не експортує і не застосовує ці правила автоматично у вашому проксі.
| Діапазон або хост | Навіщо блокувати |
| Діапазон або хост | Чому блокувати |
| ------------------------------------------------------------------------------------ | --------------------------------------------------- |
| `127.0.0.0/8`, `localhost`, `localhost.localdomain` | IPv4 loopback |
| `::1/128` | IPv6 loopback |
| `0.0.0.0/8`, `::/128` | Невказані адреси та адреси цієї мережі |
| `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.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 діапазони |
| `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 |
| `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 |
| `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 |
Якщо ваш хмарний провайдер або мережева платформа документує додаткові metadata hosts чи reserved ranges, додайте також їх.
Якщо ваш cloud provider або мережева платформа документує додаткові metadata-хости чи reserved діапазони, також додайте їх.
## Валідація
Валідуйте проксі з того самого хоста, контейнера або облікового запису сервісу, який запускає OpenClaw:
Валідуйте проксі з того самого хоста, контейнера або service account, який запускає OpenClaw:
```bash
openclaw proxy validate --proxy-url http://127.0.0.1:3128
```
За замовчуванням, коли власні призначення не надано, команда перевіряє, що `https://example.com/` успішний, і запускає тимчасовий loopback canary, до якого проксі не має дістатися. Типова заборонена перевірка проходить, коли проксі повертає non-2xx denial response або блокує canary через транспортний збій; вона провалюється, якщо успішна відповідь досягає canary. Якщо проксі не ввімкнено й не налаштовано, валідація повідомляє про проблему конфігурації; використовуйте `--proxy-url` для одноразового preflight перед зміною конфігурації. Використовуйте `--allowed-url` і `--denied-url`, щоб перевірити очікування, специфічні для розгортання. Власні заборонені призначення є fail-closed: будь-яка HTTP-відповідь означає, що призначення було доступне через проксі, а будь-яка транспортна помилка повідомляється як непереконлива, оскільки OpenClaw не може довести, що проксі заблокував доступне джерело. У разі помилки валідації команда завершується з кодом 1.
За замовчуванням, коли власні призначення не надано, команда перевіряє, що `https://example.com/` успішний, і запускає тимчасовий loopback canary, якого проксі не має досягти. Стандартна перевірка заборони проходить, коли проксі повертає не-2xx відповідь відмови або блокує canary транспортною помилкою; вона зазнає невдачі, якщо успішна відповідь досягає canary. Якщо проксі не ввімкнено і не налаштовано, валідація повідомляє про проблему конфігурації; використовуйте `--proxy-url` для одноразового preflight перед зміною конфігурації. Використовуйте `--allowed-url` і `--denied-url`, щоб тестувати очікування, специфічні для розгортання. Власні заборонені призначення є fail-closed: будь-яка HTTP-відповідь означає, що призначення було доступне через проксі, а будь-яка транспортна помилка повідомляється як непереконлива, бо OpenClaw не може довести, що проксі заблокував доступне походження. У разі невдалої валідації команда завершується з кодом 1.
Використовуйте `--json` для автоматизації. JSON-вивід містить загальний результат, ефективне джерело конфігурації проксі, будь-які помилки конфігурації та кожну перевірку призначення. Облікові дані URL проксі редагуються в текстовому та JSON-виводі:
Використовуйте `--json` для автоматизації. JSON-вивід містить загальний результат, джерело ефективної конфігурації проксі, будь-які помилки конфігурації і кожну перевірку призначення. Облікові дані URL проксі редагуються в текстовому і JSON-виводі:
```json
{
@ -170,7 +170,7 @@ openclaw proxy validate --proxy-url http://127.0.0.1:3128
}
```
Також можна перевірити вручну за допомогою `curl`:
Ви також можете перевірити вручну за допомогою `curl`:
```bash
curl -x http://127.0.0.1:3128 https://example.com/
@ -178,9 +178,9 @@ 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` вбудована canary-перевірка loopback може відрізнити відмову проксі від доступного джерела. Користувацькі перевірки `--denied-url` не мають такої canary-перевірки, тому вважайте як HTTP-відповіді, так і неоднозначні транспортні збої помилками перевірки, якщо ваш проксі не надає специфічний для розгортання сигнал відмови, який можна перевірити окремо.
Публічний запит має пройти успішно. Запити до loopback і метаданих має заблокувати проксі. Для `openclaw proxy validate` вбудований loopback canary може відрізнити відмову проксі від доступного origin. Користувацькі перевірки `--denied-url` не мають цього canary, тому вважайте як HTTP-відповіді, так і неоднозначні транспортні збої помилками перевірки, якщо ваш проксі не надає специфічний для розгортання сигнал відмови, який можна перевірити окремо.
Потім увімкніть маршрутизацію OpenClaw через проксі:
Потім увімкніть проксі-маршрутизацію OpenClaw:
```bash
openclaw config set proxy.enabled true
@ -198,10 +198,11 @@ proxy:
## Обмеження
- Проксі покращує покриття для процесно-локальних JavaScript HTTP- і WebSocket-клієнтів, але не є мережевою пісочницею рівня ОС.
- Необроблені сокети `net`, `tls` і `http2`, нативні аддони та дочірні процеси можуть обходити маршрутизацію проксі рівня Node, якщо вони не успадковують і не дотримуються змінних середовища проксі.
- IRC — це необроблений TCP/TLS-канал поза маршрутизацією через прямий проксі, керований оператором. У розгортаннях, де весь вихідний трафік має проходити через цей прямий проксі, задайте `channels.irc.enabled=false`, якщо прямий вихідний IRC-трафік не схвалено явно.
- Локальні WebUI користувачів і локальні сервери моделей за потреби слід додати до списку дозволених у політиці проксі оператора; OpenClaw не надає для них загального обходу локальної мережі.
- Обхід проксі для контрольної площини Gateway навмисно обмежено `localhost` і URL-адресами з буквальними loopback IP. Використовуйте `ws://127.0.0.1:18789`, `ws://[::1]:18789` або `ws://localhost:18789` для локальних прямих підключень до контрольної площини Gateway; інші імена хостів маршрутизуються як звичайний трафік на основі імен хостів.
- OpenClaw не перевіряє, не тестує й не сертифікує вашу політику проксі.
- Проксі покращує покриття для 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 не перевіряє, не тестує і не сертифікує вашу політику проксі.
- Розглядайте зміни політики проксі як безпеково чутливі операційні зміни.