Когда OpenClaw Gateway работает только на удалённом Mac mini M4 в Канаде, а команда в APAC хочет подключить iPhone, iPad или Android как узлы (role: node), вопрос не в том, установилось ли мобильное приложение, а в том, доходит ли WebSocket телефона до корректной конечной точки wss:// на всегда включённом хосте и совпадают ли у операторов CLI-одобрения с gateway.mode: "remote". Ниже — runbook сопряжения узлов под управлением шлюза на 2026 год. Для macOS-клиентов, закладок Dashboard и 18789 по SSH/Tailnet см. OpenClaw 2026: единственный шлюз в Канаде на удалённом Mac M4 — macOS-клиент по SSH/Tailnet, Dashboard, порт 18789, токены трансокеанской команды, loopback и LaunchAgent — та статья подключает операторов; эта подключает телефоны. Если Gateway ещё не развёрнут, сначала пройдите OpenClaw 2026 на удалённом Mac: скрипты установки и onboard, Gateway 18789, Token, LaunchDaemon, таблица логов и сценарии 7×24 на M4 в Канаде.
Почему канадский M4 должен быть единственным Gateway для мобильных узлов
В удалённой модели OpenClaw на каждом хосте должен работать один процесс Gateway, если вы сознательно не изолируете профили. Gateway владеет сессиями, каналами, авторизацией и состоянием агента; приложения iOS/Android не хостят Gateway — они подключаются как периферийные узлы по WebSocket шлюза и обмениваются RPC node.*. Арендованный Mac mini M4 в Канаде подходит под роль «всегда онлайн»: ноутбуки засыпают, а очереди Telegram/Slack и сопряжения не должны. Телефоны дают камеру, сенсоры или полевые действия; M4 даёт непрерывность.
Типичная ошибка транстихоокеанских команд — поднять второй Gateway на ноутбуке в APAC, что разделяет токены, даёт истечь заявкам на сопряжение на «чужом» хосте и делает openclaw nodes pending пустым, пока телефон крутится. Лекарство: один канадский Gateway + все CLI и узлы в remote, а сотрудники в Азии управляют хостом по SSH или tailnet, а не запускают второй Gateway локально.
Сопряжение под управлением Gateway в 2026 (что изменилось)
С модели gateway-owned pairing Gateway — источник истины о том, какие узлы могут присоединиться. Цепочка: узел подключается по WebSocket → Gateway сохраняет заявку pending и шлёт node.pair.requested → оператор выполняет openclaw nodes approve <requestId> (или эквивалент в UI) → Gateway выдаёт токен → узел переподключается как сопряжённый. Записи pending истекают через пять минут; при протухании QR или setup-кода генерируйте заново, а не гоняйтесь за старыми requestId.
С 2026.3.31 команды узла остаются отключёнными, пока не одобрено node pairing — одного device pairing недостаточно для объявленных node-команд. Считайте openclaw devices approve и openclaw nodes approve связанными, но разными воротами: телефон может быть в списке устройств, а RPC узла всё ещё отвечает 1008: pairing required, пока в node store нет approved. Если openclaw nodes pending пуст после сканирования, обновитесь до сборки, которая пишет состояние WebSocket-сопряжения в node store (исправления 2026.2.28+ описаны upstream), прежде чем открывать сетевой тикет.
На уровне протокола операторы работают с node.pair.list, node.pair.approve и node.pair.reject через CLI-обёртки; UI — тонкий клиент к той же истине Gateway. Для аудита важно: лог сопряжения на канадском хосте авторитетен, а не тот ноутбук, с которого последний раз открыли приложение.
gateway.mode remote и приоритет учётных данных
На канадском хосте Gateway должен слушать 127.0.0.1:18789 (уточните порт для вашей сборки и зафиксируйте один для команды). На ноутбуках операторов в APAC задайте gateway.mode: "remote", чтобы openclaw health, openclaw nodes pending и approve били в Канаду через SSH или Tailscale, а не в пустой локальный порт.
Официальная удалённая схема: при loopback-only Gateway держите gateway.remote.url как ws://127.0.0.1:18789 и поднимайте SSH local forwarding до CLI. Для прямого доступа по tailnet используйте transport: "direct" с приватным ws:// или wss://. Критично: --url не подхватывает токен из конфига неявно — при переопределении URL передавайте --token или --password явно.
{
gateway: {
mode: "remote",
remote: {
url: "ws://127.0.0.1:18789",
token: "<gateway-token>",
sshTarget: "ca-m4-gateway",
},
},
}
{
gateway: {
mode: "remote",
remote: {
transport: "direct",
url: "wss://ca-m4.your-tailnet.ts.net",
token: "<gateway-token>",
},
},
}
| Источник учётных данных | Приоритет | Типичная ошибка |
|---|---|---|
CLI --token / --password |
Наивысший, если передан | Думать, что --url подтянет токен из конфига |
Переменная OPENCLAW_GATEWAY_TOKEN |
Перекрывает файл для одной оболочки | LaunchAgent без того же env, что у SSH |
gateway.remote.token в конфиге |
По умолчанию для remote mode | Токен сменили на хосте, не на телефонах |
| Профиль «Remote» в macOS-приложении | Отдельное хранилище UI | CLI зелёный, приложение со старым токеном |
Runbook сопряжения: от зелёного loopback до nodes approve
Предполагаем, что Gateway уже под launchd на канадском M4. Не направляйте телефоны на публичный plaintext ws://, если падает любой шаг ниже.
Шаг 1 — Здоровье loopback на хосте Gateway
По SSH на канадский Mac проверьте listen и health:
curl -fsS "http://127.0.0.1:18789/health" && echo OK lsof -nP -iTCP:18789 -sTCP:LISTEN
Шаг 2 — Безопасный WebSocket-вход для телефонов
Для межсетевого мобильного сопряжения iOS/Android отклоняют plaintext ws://. Публикуйте TLS как wss://<magicdns> через Tailscale Serve (предпочтительно, пока Gateway на loopback) или корпоративный reverse proxy с доверенной цепочкой. Отладка в офисной LAN может использовать ws://; транстихоокеанские телефоны в публичном интернете — нет.
Шаг 3 — QR / setup-код и node pending
На хосте (или на ноутбуке с активным туннелем):
openclaw qr openclaw qr --remote openclaw nodes pending openclaw nodes approve <requestId> openclaw nodes status
После сканирования телефоном убедитесь, что строка pending появилась до approve. Привязывайте одобрения к ID тикетов в общем on-call runbook, чтобы ночные подрядчики не approve чужие отпечатки.
Шаг 4 — Дымовой тест RPC узла
Запустите минимальный вызов node.* со стороны Gateway (или workflow канала, которому нужны node-tools). Высокий RTT через Тихий океан сам по себе не провал; частые обрывы указывают на путь tailnet, MTU или энергосбережение телефона — не обязательно на переустановку приложения.
Матрица безопасного входа (телефоны vs операторы)
У телефонов нет SSH-туннелей; у операторов часто есть. Держите эти пути раздельно в runbook.
| Тип входа | Протокол телефона | Типичное применение | Риск |
|---|---|---|---|
LAN ws://192.168.x.x:18789 |
Plain ws (частная LAN) | Отладка офисного Wi‑Fi | Не для транстихоокеанского интернета |
Tailscale Serve wss://*.ts.net |
wss + идентичность tailnet | Телефоны APAC + Gateway в Канаде | ACL при каждом найме; хост должен быть доверенным |
| Частный CA / корпоративный proxy wss | wss + bearer token | Политики pinning сертификатов | iOS нужен доверенный CA или pin |
Публичный IP ws:// |
Удалённое сопряжение отклонено | — | Fail-closed по замыслу; не открывайте 18789 наружу |
-L, закладки tailnet) описан в туториале «только шлюз в Канаде». Эта статья — про wss-сопряжение узлов телефона и nodes approve — не переносите порядок приёмки «сначала откройте Dashboard» на мобильные тикеты сопряжения.
Трансокеанский SSH: approve узлов, когда телефон ещё не в tailnet
Телефоны подрядчиков без Tailscale всё равно нуждаются в wss:// (Serve или корпоративный proxy). SSH помогает операторам выполнить approve на loopback после туннеля — он не заменяет TLS-путь телефона.
ssh -N -L 18789:127.0.0.1:18789 user@ca-m4-host # Новый терминал: remote-конфиг указывает на ws://127.0.0.1:18789 openclaw health --token "<gateway-token>" openclaw nodes pending openclaw nodes approve <requestId>
Для туннелей 24/7 сохраните ssh -N в LaunchAgent на Mac оператора (см. remote docs) и храните gateway.remote.token в конфиге, а не в профилях shell. Канадский хост держит Gateway только на loopback.
| Роль | Рекомендуемый путь | Команды сопряжения | Если не работает |
|---|---|---|---|
| Канада M4 (Gateway) | loopback + launchd | openclaw qr, nodes pending |
lsof -i :18789, логи Gateway |
| Mac оператора APAC | SSH -L + remote mode |
nodes approve, doctor |
Туннель жив? Токен явный? |
| iOS / Android | wss:// tailnet или Serve |
Скан в приложении, бейдж online | Публичный ws, доверие к сертификату |
Ёмкость M4: один Gateway, много телефонных узлов
24 ГБ / 512 ГБ канадского M4 спокойно держат один Gateway и несколько сопряжённых узлов при ограниченных каналах и снимках workspace. Берите 1 ТБ / 2 ТБ, когда логи, медиа каналов и экспорт workspace конкурируют за APFS. Второй арендованный M4 оправдан при изолированных профилях Gateway (prod vs staging узлов), а не потому что три телефона «перегружают» один Apple Silicon — телефоны делят сессии и квоты, а не плодят демоны Gateway.
Маркируйте каждое одобренное устройство в CMDB; сопряжение без владельца неаудируемо через часовые пояса. О диске и параллелизме при росте каналов см. OpenClaw 2026: готовность к продакшену на удалённом Mac M4 в Канаде — планирование Node и workspace на диске, продление авторизации Channels, удалённое «дрожание» Gateway и таблица разбора ошибок (HowTo + FAQ).
Playbook тикетов openclaw doctor
Считайте openclaw doctor (и --lint / --deep, если доступны) единым снимком в тикете: на SSH-сессии хоста Gateway и снова с удалённого CLI через туннель; сравните вывод. Doctor зелёный, а телефон в pending — обычно нет nodes approve или телефон бьёт не в тот wss-хост. Ошибки auth в doctor — смешение поверхностей токена local/remote.
Рекомендуемые поля тикета
Приложите: метку UTC, openclaw --version, curl health Gateway, редактированный openclaw nodes pending / nodes status, текст ошибки телефона (secure endpoint required?), и используете ли Serve, только SSH или прямой tailnet. VNC редко нужен, кроме отладки macOS TCC для node-tools с камерой.
Дерево симптом → действие
A. Телефон: «требуется защищённая конечная точка» → настройте wss:// (сначала Tailscale Serve); прекратите публиковать plaintext ws на публичный IP.
B. Pending пуст, телефон крутится → протухший QR, неверный хост Gateway или баг WebSocket-сопряжения, исправленный в 2026.2.28+ (обновитесь до глубокой отладки).
C. CLI: connection refused → проверьте loopback в Канаде, затем lsof -i :18789 на ноутбуке при SSH forward.
D. После approve сразу отвал → ACL tailnet, энергосбережение телефона, OOM Gateway; зафиксируйте версию до перезапуска.
openclaw doctor openclaw doctor --lint openclaw gateway status openclaw nodes pending openclaw nodes status curl -fsS "http://127.0.0.1:18789/health" || true
Сценарий: телефон дежурного в APAC запускает автоматизацию в Канаде
Инженер on-call в Сингапуре сопрягает iPhone-узел с канадским Gateway по wss://ca-m4.team.ts.net. Slash-команда Slack через каналы OpenClaw запрашивает снимок камеры по RPC node.*; Gateway оркестрирует на M4, телефон даёт сенсорный путь. Латентность доминирует тихоокеанское плечо, но Gateway остаётся включённым, когда MacBook инженера спит. Одобрения логируются с ID тикетов; токены ротируют ежеквартально без репоста секретов в чат.
Паттерн работает, когда сопряжение, каналы и ACL tailnet у одной платформенной команды. Если каналы уже на канадском хосте, а телефоны не прошли nodes approve, Slack доставляется, а каждый node-tool падает с pairing errors — типичный support-паттерн, который doctor быстро показывает при вложении и nodes status, и health каналов в одном тикете.
FAQ
Могут ли iOS или Android хостить Gateway?
Нет. Мобильные приложения — только узлы. Держите канадский M4 каноническим Gateway, если сознательно не изолируете профили на другом хосте.
Почему для удалённого сопряжения телефона обязателен wss?
Межсетевое мобильное сопряжение отклоняет plaintext ws://, чтобы защитить учётные данные и отпечатки устройств. Исключения LAN и симулятора — в upstream docs.
Меняет ли gateway.mode remote сам хост Gateway?
remote — настройка клиента. Канадский Mac по-прежнему запускает локальный Gateway. Не направляйте конфиг M4 на remote loopback к самому себе.
Только SSH-туннель, на телефоне нет Tailscale?
Телефону всё равно нужна достижимая wss:// (обычно Tailscale Serve или корпоративный proxy). SSH обслуживает CLI оператора и approve; он не заменяет TLS для телефона.
openclaw qr vs openclaw qr --remote?
--remote кодирует setup под URL удалённого Gateway — используйте на машине с туннелем или доступом по tailnet, чтобы QR не ссылался на loopback ноутбука по ошибке.
«Конкурируют» ли несколько телефонов за Gateway?
Они делят один процесс Gateway и квоты; дубликаты демонов не создают. Маркируйте устройства и ведите аудит одобрений.
Сопряжение есть, node-tools таймаутятся?
Разделяйте «WebSocket жив» и медленный RPC. Проверьте CPU, диск и очереди каналов Gateway до переустановки приложений.
Doctor зелёный по SSH, телефон всё равно падает?
Doctor может валидировать путь туннеля, а телефон использует другой wss-хост или протухший QR. Согласуйте wss URL телефона с конфигом Serve и снова запустите nodes pending после скана.