Канальные интеграции OpenClaw упираются в две разные оси: исходящий трафик шлюза (динамический egress к API мессенджеров, LLM, веб-поиску) и входящие HTTPS-колбэки от облачных платформ к вашему процессу. Первая ось ломается прокси и DNS, вторая — маршрутизацией с интернета до сокета, на котором слушает Gateway. Ниже — сжатая матрица трёх типовых способов опубликовать колбэк без «дырявого» периметра и пошаговый FAQ, который можно копировать в тикеты.
Колбэки и egress — не путать слои
Egress — это когда ваш узел сам устанавливает TCP к внешнему API; достаточно маршрута, корректного DNS и политик HTTP(S)_PROXY / NO_PROXY. Ingress для вебхука — когда чужой сервер в интернете должен достучаться до вашего URL по стабильному имени и валидному TLS. Если вы отладили только curl с самой машины, это не гарантирует, что Slack или Telegram увидят тот же путь: у них другие исходные IP, жёсткие таймауты и проверки цепочки сертификатов.
Матрица: Cloudflare Tunnel · Tailscale Funnel · VPS + reverse proxy
Выберите модель до настройки DNS и сертификатов — смена «на лету» почти всегда дороже, чем кажется.
| Вариант | Достижимость колбэка | TLS | Привязка порта шлюза |
|---|---|---|---|
Cloudflare Tunnel (cloudflared) |
Публичное имя в зоне Cloudflare; входящий трафик приходит в туннель, белый IP VPS не обязателен | Обычно терминируется на edge Cloudflare; до origin — другой слой (часто HTTP на loopback) | Gateway на 127.0.0.1:PORT; tunnel мапит hostname → localhost |
| Tailscale Funnel | Публичный URL в экосистеме Tailscale; удобен для личных/внутренних PoC | TLS на стороне Funnel; проверяйте совместимость с требованиями вендора вебхука | Локальный listener + Funnel как фронт; следите за тем, кто может включить публикацию |
| Linux VPS + Nginx/Caddy | Прямой A/AAAA на публичный IP; классика для продакшена с полным контролем | Let’s Encrypt на пограничном сервере; upstream до Gateway по HTTP на loopback | Gateway только на loopback; 443 слушает reverse proxy (см. также материал про onboard, HTTPS и откат на Linux VPS) |
TLS, Host и проброс до шлюза
Публичный вебхук почти всегда шлёт Host:, совпадающий с URL в панели. Если reverse proxy отвечает дефолтным vhost или отдаёт самоподписанный сертификат на внутреннем hop, провайдер событий разорвёт соединение ещё до вашего приложения. Зафиксируйте в конфиге отдельный server_name / site block, прозрачные заголовки X-Forwarded-Proto и X-Forwarded-For, и убедитесь, что health-check совпадает с реальным путём вебхука, а не только с /.
Привязка Gateway: loopback против всех интерфейсов
Если edge уже слушает 443 на публичном интерфейсе, держите OpenClaw Gateway на 127.0.0.1 и проксируйте только нужные location'ы. Публикация того же порта на 0.0.0.0 без фильтра превращает админ-поверхность в мишень для сканеров. Для сценариев с несколькими профилями и параллельными процессами полезно заранее развести каталоги конфигурации и токены — см. заметку про MCP Server, белые списки и изоляцию сессий.
Динамический egress и «двойной NAT»
Исходящие запросы шлюза могут уходить через корпоративный прокси или облачный egress с динамическими IP. Это не мешает вебхукам, пока провайдер не требует фиксированный allow-list для исходящих запросов вашего приложения к их API. Если требует — выделите отдельный egress (отдельный NAT/VPC endpoint) или документируйте пул адресов; не смешивайте это с путём входящего колбэка.
Поуровневая диагностика (воспроизводимо)
L0 — DNS и сертификат снаружи: внешний резолвер, срок действия cert, цепочка до доверенного корня. L1 — порт 443 на edge (firewall, security group). L2 — reverse proxy: совпадение server_name, лимиты размера тела, таймауты. L3 — сам процесс Gateway: слушает ли нужный порт, нет ли второго инстанса, совпадает ли путь HTTP с настройкой канала.
curl -svI https://hooks.example.com/openclaw/webhook # подставьте свой публичный URL # Смотрите: HTTP/2 или 1.1, код ответа, заголовки server/cf-ray и т.д.
Короткий FAQ
Вебхук приходит, но Gateway отвечает 502
Сначала убедитесь, что upstream в Nginx/Caddy указывает на тот же порт, что слушает процесс (частая ошибка после смены профиля). Затем проверьте лимиты тела запроса и таймауты — провайдеры шлют крупные JSON.
Локально работает, из облака провайдера — таймаут
Проверьте, не фильтрует ли хостинг входящие страны или ASN источника. Для туннелей убедитесь, что агент онлайн и маршрут hostname не указывает на старый origin.
Нужны ли два разных URL для staging и prod?
Да: разные hostname'ы, разные секреты вебхука и разные systemd unit'ы или контейнеры с изолированными каталогами данных — так вы не смешиваете очереди событий и токены.
Стабильный сетевой контур и облачный Mac
Когда входящие вебхуки и исходящие API должны жить в одном предсказуемом контуре, удобнее держать «тяжёлую» macOS-часть (подпись, скрипты, локальные инструменты) на выделенном облачном Mac mini M4: нативный Unix-стек, Homebrew и SSH без сюрпризов WSL, низкий шум и типичное потребление около 4W в простое — узел можно оставить включённым для дежурных колбэков.
По сравнению с типичными Windows-ПК того же класса цены Apple Silicon даёт выше энергоэффективность и предсказуемую стабильность macOS; Gatekeeper и SIP снижают класс риска вредоносного ПО относительно Windows, а компактный корпус без вентиляторного гула снижает совокупную стоимость владения для круглосуточных сценариев.
Если вы выстраиваете постоянный периметр для ботов и шлюзов, VPSSpark: облачный Mac mini M4 — разумная база для macOS-нагрузок рядом с Linux VPS — ознакомьтесь с тарифами и зафиксируйте железо так же явно, как фиксируете edge для вебхуков.