Перейти до основного вмісту

​
Мережевий проксі

OpenClaw може спрямовувати HTTP- і WebSocket-трафік середовища виконання через керований оператором прямий проксі. Це необов’язковий додатковий рівень захисту для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща аудитованість мережі. OpenClaw не постачає, не завантажує, не запускає, не налаштовує й не сертифікує проксі. Ви запускаєте технологію проксі, яка підходить для вашого середовища, а OpenClaw спрямовує через нього звичайні локальні для процесу HTTP- і WebSocket-клієнти.

​
Навіщо використовувати проксі?

Проксі дає операторам одну точку мережевого контролю для вихідного HTTP- і WebSocket-трафіку. Це може бути корисно навіть поза посиленням захисту від SSRF:
  • Центральна політика: підтримуйте одну політику вихідного трафіку замість того, щоб покладатися на правильність мережевих правил у кожному місці HTTP-виклику застосунку.
  • Перевірки під час підключення: оцінюйте призначення після DNS-розв’язання й безпосередньо перед тим, як проксі відкриє висхідне з’єднання.
  • Захист від DNS rebinding: зменшіть розрив між DNS-перевіркою на рівні застосунку та фактичним вихідним з’єднанням.
  • Ширше покриття JavaScript: спрямовуйте звичайні fetch, node:http, node:https, WebSocket, axios, got, node-fetch і подібні клієнти тим самим шляхом.
  • Аудитованість: журналюйте дозволені й заборонені призначення на межі вихідного трафіку.
  • Операційний контроль: застосовуйте правила призначень, сегментацію мережі, обмеження швидкості або дозволені списки вихідного трафіку без перебудови OpenClaw.
OpenClaw і далі зберігає захисні механізми SSRF на рівні застосунку, як-от fetchWithSsrFGuard. Маршрутизація через проксі є додатковим захисним обмежувачем на рівні процесу для звичайного вихідного HTTP- і WebSocket-трафіку, а не заміною захищених fetch-запитів чи мережевої пісочниці на рівні ОС.

​
Як OpenClaw маршрутизує трафік

Коли proxy.enabled=true і налаштовано URL проксі, захищені процеси середовища виконання, як-от openclaw gateway run, openclaw node run і openclaw agent --local, спрямовують звичайний вихідний HTTP- і WebSocket-трафік через налаштований проксі: 
OpenClaw process
  fetch                  -> operator-managed filtering proxy -> public internet
  node:http and https    -> operator-managed filtering proxy -> public internet
  WebSocket clients      -> operator-managed filtering proxy -> public internet
Публічний контракт — це поведінка маршрутизації, а не внутрішні хуки Node, використані для її реалізації. WebSocket-клієнти площини керування OpenClaw Gateway використовують вузький прямий шлях для RPC-трафіку локального Gateway через local loopback, коли URL Gateway використовує буквальну IP-адресу loopback, як-от 127.0.0.1 або [::1]. Цей шлях площини керування має мати змогу досягати loopback Gateway навіть тоді, коли операторський проксі блокує призначення loopback. Звичайні HTTP- і WebSocket-запити середовища виконання все одно використовують налаштований проксі. Сам 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 відновлює попереднє проксі-середовище й скидає кешований стан маршрутизації процесу.

​
Конфігурація

proxy:
  enabled: true
  proxyUrl: http://127.0.0.1:3128
Ви також можете передати URL через середовище, зберігши proxy.enabled=true у конфігурації: 
OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run
proxy.proxyUrl має пріоритет над OPENCLAW_PROXY_URL. Якщо enabled=true, але не налаштовано жодного дійсного URL проксі, захищені команди завершують запуск із помилкою замість того, щоб повертатися до прямого мережевого доступу. Для керованих сервісів Gateway, запущених через openclaw gateway start, бажано зберігати URL у конфігурації: 
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway install --force
openclaw gateway start
Резервний варіант через середовище найкраще підходить для запусків на передньому плані. Якщо ви використовуєте його з установленим сервісом, помістіть 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 відхиляє URL проксі loopback для команд, націлених на контейнер, якщо ви явно не перевизначите цю перевірку безпеки.

​
Вимоги до проксі

Політика проксі є межею безпеки. OpenClaw не може перевірити, що проксі блокує правильні цілі. Налаштуйте проксі так, щоб він:
  • Прив’язувався лише до loopback або приватного довіреного інтерфейсу.
  • Обмежував доступ так, щоб ним міг користуватися лише процес, хост, контейнер або сервісний обліковий запис OpenClaw.
  • Самостійно розв’язував призначення й блокував IP-адреси призначення після DNS-розв’язання.
  • Застосовував політику під час підключення як для звичайних HTTP-запитів, так і для HTTPS-тунелів CONNECT.
  • Відхиляв обходи на основі призначення для loopback, приватних, link-local, metadata, multicast, зарезервованих діапазонів або діапазонів документації.
  • Уникав дозволених списків імен хостів, якщо ви повністю не довіряєте шляху DNS-розв’язання.
  • Журналював призначення, рішення, статус і причину без журналювання тіл запитів, заголовків авторизації, cookies або інших секретів.
  • Тримав політику проксі під контролем версій і переглядав зміни як чутливу до безпеки конфігурацію.

​
Рекомендовані заблоковані призначення

Використовуйте цей список заборони як початкову точку для будь-якого прямого проксі, брандмауера або політики вихідного трафіку. Логіка класифікатора на рівні застосунку 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.localdomainIPv4 loopback
::1/128IPv6 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::/10Link-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Діапазони benchmarking
192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32Діапазони спеціального використання й документації
224.0.0.0/4, ff00::/8Multicast
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::/326to4 і Teredo із вбудованим IPv4
::/96, ::ffff:0:0/96IPv4-compatible і IPv4-mapped IPv6
Якщо ваш хмарний провайдер або мережева платформа документує додаткові хости metadata чи зарезервовані діапазони, додайте і їх.

​
Валідація

Перевірте проксі з того самого хоста, контейнера або сервісного облікового запису, який запускає OpenClaw: 
curl -x http://127.0.0.1:3128 https://example.com/
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 і metadata мають завершитися помилкою на проксі. Потім увімкніть маршрутизацію проксі OpenClaw: 
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway run
або встановіть: 
proxy:
  enabled: true
  proxyUrl: http://127.0.0.1:3128

​
Обмеження

  • Проксі покращує покриття для локальних для процесу JavaScript HTTP- і WebSocket-клієнтів, але не замінює fetchWithSsrFGuard на рівні застосунку.
  • Сирі сокети net, tls і http2, нативні додатки та дочірні процеси можуть обходити маршрутизацію проксі на рівні Node, якщо вони не успадковують і не дотримуються змінних середовища проксі.
  • Локальні WebUI користувача та локальні сервери моделей слід додавати до дозволеного списку в операторській політиці проксі, коли це потрібно; OpenClaw не надає для них загальний обхід локальної мережі.
  • Обхід проксі для площини керування Gateway навмисно обмежений URL із буквальними IP-адресами loopback. Використовуйте ws://127.0.0.1:18789 або ws://[::1]:18789 для локальних прямих підключень площини керування Gateway; імена хостів localhost маршрутизуються як звичайний трафік на основі імені хоста.
  • OpenClaw не перевіряє, не тестує й не сертифікує вашу політику проксі.
  • Розглядайте зміни політики проксі як чутливі до безпеки операційні зміни.