2026 OpenClaw на Mac VPS с Docker: токен шлюза, сеть контейнера CLI и взаимная блокировка pairing

1. Болевые точки: двойной токен, loopback, pairing, bind, UID

Официальные сценарии Docker предполагают, что человек проходит onboarding в том же сетевом namespace, что и скрипты. На безлюдном Mac VPS сбои группируются в пять кластеров:

1. Тихое переопределение окружения: если внутри контейнера задан OPENCLAW_GATEWAY_TOKEN, он может перекрыть gateway.auth.token в openclaw.json, и UI показывает токен, который шлюз не проверяет.
2. Loopback CLI в раздельных стеках: по умолчанию CLI идет на ws://127.0.0.1:18789 — это loopback контейнера CLI, а не шлюза; ECONNREFUSED и резкие 1006 выглядят как сетевые флапы.
3. Взаимная блокировка pairing: при gateway.bind=lan дашборд и CLI ждут одобрения друг друга; без записанного порядка вы крутитесь на 1008.
4. Семантика bind и мост: loopback конфликтует с целями между контейнерами; после перехода на lan без обновления URL CLI остаются логи listen OK, но WebSocket не завершается.
5. Дрейф UID томов: образы часто работают от UID 1000; пути, созданные root на хосте, ломают персистентность — файлы токенов «сохранились» и исчезают после рестарта.

На безголовом Mac VPS локальный браузер не скроет ошибку: каждый повтор WebSocket виден в логах, launchd перезапустит контейнеры даже посреди pairing. Читайте docker compose logs -f openclaw-gateway и логи CLI как одну временную шкалу. При фиксации digest фиксируйте digest и отпечаток токена (первые восемь символов) в тикете изменения, чтобы откат не вернул старую модель auth тихо. Если дашборд доступен шире loopback, читайте вместе с этим материалом гайд по hardening экспозиции шлюза, чтобы дрейф токена рассматривался и как blast radius, а не только как сеть Docker.

2. Таблица triage: симптом, причина, первая команда

Вставьте таблицу в шаблон инцидента; на этапе политики добавьте статью про hardening экспозиции.

Фразу «grep обоих источников» выполняйте буквально: поиск OPENCLAW_GATEWAY_TOKEN в репозитории, просмотр openclaw.json внутри контейнера через docker compose exec openclaw-gateway cat /путь/openclaw.json (путь свой) и сравнение с env в compose. Для secret manager проверяйте значение в рантайме, а не только шаблон в Git. Для 1008 фиксируйте, показывает ли дашборд pending, а CLI — обратное: чаще это неверный GATEWAY_URL или разделенные cookie, а не настоящая ошибка авторизации.

3. Пять шагов runbook до дежурных проверок

1. Заморозить секрет: первые восемь символов токена и digest образа в тикете изменения.
2. Согласовать двойные источники: до compose up сравнить read-only gateway.auth.token и OPENCLAW_GATEWAY_TOKEN в каждом описании контейнера.
3. Починить namespace: для CLI предпочтительно network_mode: service:openclaw-gateway; если нужен bridge, зафиксировать GATEWAY_URL=ws://openclaw-gateway:18789 и проверить DNS из одноразового docker compose run.
4. Разорвать pairing: в контейнере шлюза openclaw dashboard --no-open, завершить URL с токеном, затем в CLI devices approve с записью команд в тикет.
5. Пробы и launchd: с хоста curl /healthz и /readyz с короткими таймаутами; отразить те же проверки в plist SuccessfulExit, чтобы рестарт не считался успехом при падшем WS. Лимиты ресурсов — в статье Compose 7x24 на этом сайте.

Минимальный набросок compose (перед продом слить с upstream-шаблонами):

Если network_mode: service:openclaw-gateway невозможен из-за sidecar в namespace CLI, задайте явный внутренний URL и проверьте из одноразового контейнера: docker compose run --rm busybox wget -qO- http://openclaw-gateway:18789/healthz (или curl). Задокументируйте ожидаемое имя хоста для DNS Docker; опечатки в именах сервисов — частая причина отчетов «на ноутбуке работало». Старые строки устройств удаляйте только после экспорта логов и проверки workspace.

4. Факты для ссылок: порт, UID, пробы

• Порт: слушатель по умолчанию 18789; health-скрипты должны бить по listener, а не только смотреть docker ps.
• UID: пользователь node обычно 1000; выровняйте bind на хосте, иначе персистентность ломается тихо.
• Пробы: /healthz как liveness, /readyz ближе к готовности WebSocket; порядок и таймауты — в runbook.
• Синхронизация времени: большой сдвиг между хостом и контейнерами путает сертификаты и корреляцию логов; держите NTP в порядке на VPS.
• Окно обновления: при смене образа сначала пять шагов; зеленый docker ps не равен аутентифицированной сессии CLI.

Встройте проверки в chatops-плейбук: каждая эскалация должна в одной строке нести отпечаток токена, ревизию compose и digest, чтобы постмортем не гадал. Если планируете blue/green для шлюза, явно укажите, какой стек еще держит старые записи pairing, иначе команды одобрят устройства против неверного URL. В нагрузочных тестах бейте health-эндпоинты с теми же таймаутами, что в проде; более короткие в тесте скрывают флаки. Провайдеры Mac VPS с выделенной полосой снижают риск троттлинга длинных WebSocket-сессий. Никогда не копируйте токены между staging и prod; используйте разные .env с явными суффиксами. Держите короткую схему с namespace шлюза, CLI и sidecar — иначе дежурные теряются в bridge-схеме.

Добавьте чеклист ролей: кто может выполнять devices approve, кто ротирует токены, как это фиксируется в зашифрованном тикете. Без этого одобрения pairing часто уходят людям без консоли VPS, MTTR растет. При infrastructure-as-code для Compose валидируйте изменения статическим diff к выводу docker compose config в рантайме, чтобы скрытые наложения env всплыли до merge. В длинных окнах обслуживания спровоцируйте падение healthcheck и убедитесь, что launchd действительно останавливает сервис, а не только перезапускает контейнер при живых старых клиентах. Сохраните заголовки WebSocket upgrade успешного рукопожатия как эталон для быстрых регрессий.

Если в стеке есть reverse proxy перед шлюзом, отдельно задокументируйте, какие заголовки TLS терминируются на границе и где снова начинается доверие к WebSocket. Расхождение между HTTP health и фактическим WS-путем часто дает ложное чувство готовности. Для многоарендных кластеров храните карту соответствия tenant → compose project name, чтобы команда не одобряла устройства в чужом проекте. При ночных рестартах включите уведомление до перезапуска, иначе оператор потеряет контекст half-open сессий. Наконец, синхронизируйте версии клиентских CLI с версией образа шлюза: несовпадение минорных тегов иногда проявляется именно как странные коды закрытия, а не как явный mismatch токена.

5. Порядок чтения: Compose 7x24 и нативные гиды gateway

Если рестарты compose, потолки памяти и pin digest еще не стандартизированы, сначала Compose 7x24: health, upgrade, rollback. Когда спорят, кто владеет истиной — бинарь шлюза или CLI, откройте runbook gateway install / bind / auth для границы native vs Docker. Ad-hoc docker run на ноутбуке скрывает проблемы pairing и токена, которые на безголовом Mac VPS превращаются в шум пейджера. По сравнению с одним launchd Docker добавляет слой абстракции; апгрейды и учения занимают больше времени. Когда нужны выделенный Apple Silicon, стабильный egress и предсказуемая параллельность для долгоживущих агентов, аренда узлов Mac cloud VPSMAC M4 обычно проще сводит bind-тома, политики plist и compose в одну операционную историю. Замкните цикл от таблицы к автоматизации через гайд API Mac cloud на девяносто секунд на этом сайте.