Кому актуально: вы поднимаете через Docker Compose Gateway и контейнеры CLI или агентов; в логах Gateway «как будто работает», но дочерние сессии выдают gateway closed (1008): pairing required, либо RPC healthy, а pairing не завершается. Вывод: редко это чинится «ещё раз переустановить образ» — чаще это сочетание поверхности bind, токена, доверенных proxy-подсетей (trustedProxies) и URL между контейнерами; статья даёт матрицу симптомов, фрагмент Compose, шестишаговый runbook и три KPI. Разделение с другими материалами: параллельно читайте официальный docker-setup.sh + GHCR, pairing и токен и сетевой triage для Docker.
Gateway OpenClaw отвечает за долгие соединения и маршрутизацию; когда CLI или инструменты «подсессий/субагентов» общаются с Gateway по WebSocket/HTTP, одного запущенного процесса мало — с точки зрения Gateway вызывающая сторона должна быть доверенной в сетевом смысле, а pairing должен быть действительным. Docker помещает каждый сервис в своё сетевое пространство имён: если внутри контейнера CLI указать http://127.0.0.1:18789, трафик попадёт только в этот контейнер, а не в хост или другой сервис.
http://openclaw-gateway:18789 (пример).172.16.0.0/12, 10.0.0.0/8 и CIDR вашей кастомной сети), чтобы корректно определять клиента.В отличие от обзора установки на три ОС, для Compose важнее не «какая ОС», а какая сеть доверена в каком контейнере.
При воспроизведении сохраните рядом три следа в логах: строки старта Gateway, стек субагента и Subnet attachable-сети из docker inspect — многие 1008 после сравнения сводятся к «не объявлен доверенный диапазон», а не к модели или каналу.
| Снимок симптома | Сначала проверить (по порядку) | Типичная причина |
|---|---|---|
| Контейнер A не достаёт 127.0.0.1:18789 | Сначала URL с именем сервиса, затем publish портов и адрес прослушивания | Неверная семантика localhost |
| RPC healthy, sessions_spawn даёт 1008 | Список pairing → trustedProxies → тройка bind | Путь субагента считается внешним / не сопряжённым |
| В логах trusted proxy / pairing | Согласовать CIDR compose и конфиг gateway.auth | Подсеть вне доверенного множества |
| Только после смены версии | Сравнить старые/новые defaults bind/auth и мигрированный том .openclaw | Ужесточение defaults или устаревший pairing |
Подсказка: даже при официальном docker-setup.sh перепроверьте имена сервисов и тома через эту сетевую призму — см. runbook GHCR и Control UI.
| gateway.bind (концепция) | Когда подходит | Трение с Compose |
|---|---|---|
| loopback | Один all-in-one контейнер или только хост | Другие сервисы не могут трактовать это как локальный loopback |
| lan / свой listen | Несколько сервисов, RPC между контейнерами | Нужны токен/auth и сужение экспозиции |
| trusted reverse proxy | Спереди Nginx/Caddy | Должно совпадать с чеклистом reverse proxy по downstream-источникам |
trustedProxies (примеры CIDR)Ниже учебный пример: реальную подсеть берите из docker network inspect, не копируйте слепо.
| Тип сети | Пример CIDR | Что сделать |
|---|---|---|
| Стандартный Docker bridge | 172.17.0.0/16 (зависит от среды) | Проверить, попадает ли исходный IP, который видит Gateway, в этот диапазон |
| Кастомная сеть Compose | например 172.18.0.0/16–172.30.x.x | Добавить всю подсеть в trustedProxies (не отдельные IP контейнеров) |
| overlay / swarm | выдаёт оркестратор | Тот же принцип: подсети, а не список pod-IP |
OPENCLAW_GATEWAY_URL=http://openclaw-gateway:18789 (имя как в compose).OPENCLAW_GATEWAY_TOKEN одинаков с обеих сторон; для файлового токена — читаемость mount.openclaw gateway status → openclaw doctor → воспроизвести действие субагента и искать в логах 1008 / pairing.# Фрагмент-пример (имена сервисов и плейсхолдеры env — заменить перед продом)
services:
openclaw-gateway:
environment:
- OPENCLAW_CONFIG_DIR=/config
- OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
volumes:
- ./config:/config
networks: [oc-net]
openclaw-cli:
environment:
- OPENCLAW_CONFIG_DIR=/config
- OPENCLAW_GATEWAY_URL=http://openclaw-gateway:18789
- OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
volumes:
- ./config:/config
networks: [oc-net]
networks:
oc-net: { driver: bridge }
gateway.auth.token или хэш env между контейнерами; при расхождении блокировать релиз.Эти KPI — инженерные рекомендации по наблюдаемости, не SLA апстрима.
«Образ поднялся» мало: субагентам и сессионным инструментам нужны стабильный Gateway, предсказуемая сетевая идентичность и согласованные тома конфигурации. Крутить один контейнер docker run на ноутбуке — иной профиль сбоев, чем фиксированный Compose с постоянными томами на выделенном удалённом Mac: последнее ближе к безнадзорным и по расписанию задачам.
Эфемерный VPS или общий десктоп могут показать демо, но часто без ровной дисковой и сетевой базовой линии; когда Gateway, reverse proxy и автоматизация должны жить в одной зоне доверия и масштабироваться, мультирегиональные узлы Apple Silicon с помесячными и поквартальными тарифами часто удобнее, чем вручную наращивать временные Docker-хосты. MACCOME даёт физическую изоляцию и выбор из шести регионов, чтобы разделять «всегда включённый Gateway» и «сборку/подпись»; откройте тарифы и центр помощи, затем подключайте переменные по этому runbook.
Порядок внедрения: сначала закрыть шесть шагов в одном проекте Compose, затем решать, не вынести ли Gateway и остальные нагрузки на отдельные удалённые узлы.
Частые вопросы
При коде 1008 сразу менять bind на LAN?
Сначала таблица 1: часто дело в URL с именем сервиса или trustedProxies, а не в слепом расширении прослушивания. Расширяя экспозицию, согласуйте токен и фаервол. Pairing: чеклист pairing и токен.
Можно ли на хосте curl к 127.0.0.1:18789 вместо проверки из контейнера?
Как проверка с хоста — да, но не заменяет проверку до Gateway по имени сервиса из контейнера — разные сетевые пространства имён. Справка: центр помощи Mac mini.
Не дублирует ли это материал «Сетевой triage Docker»?
Сетевой triage — про пространства имён Compose и доступ CLI; официальная Docker-статья — про пути образов. Здесь явно связываются pairing субагентов и trustedProxies. Далее: проверка MCP и Skills.