Переезд OpenClaw на арендованный канадский Mac mini M4 редко бывает «просто копированием каталога»: пока вы переносите деревья node_modules, секреты каналов и plist демона, внешний мир продолжает стучаться в Gateway на 18789. Ниже — практический сценарий с двумя узлами (источник и цель), явными фазами cutover и запасным планом, когда транстихоокеанский SSH или экранная сессия VNC дают только задержку, а не аларм. Базовые шаги установки и onboard на удалённом Mac с тем же портом и токеном описаны в OpenClaw 2026 на удалённом Mac: установка, Gateway 18789 и LaunchDaemon; если миграция затрагивает тяжёлые билды и параллельные задачи на диске, сверьтесь с матрицей диска и параллелизма для удалённого Mac в Канаде.
План cutover: окно, роли и точки невозврата
Зафиксируйте окно обслуживания, в котором допустима короткая двойная активность Gateway (старый и новый узел одновременно слушают разные адреса), либо явный простой вебхуков. Назначьте владельца runbook: он один утверждает момент переключения DNS или reverse-proxy и один раз меняет маркер «кто главный» в чате команды. До начала работ выгрузите на защищённое хранилище три артефакта: tarball или rsnap каталога workspace без секретов внутри архива (секреты вынесены отдельно), экспорт plist запуска из ~/Library/LaunchAgents или /Library/LaunchDaemons, и checksum файлов конфигурации OpenClaw. После этого любые правки на источнике до завершения миграции должны повторно попадать в журнал изменений, иначе вы получите «почти одинаковые» деревья на двух хостах.
Старая машина не уходит в офлайн сразу
Держите источник в режиме read-mostly: остановите только записывающие фоновые задачи, которые конфликтуют с финальной синхронизацией, но не роняйте SSH, пока целевой узел не докажет health на loopback. Если команда географически распределена, зафиксируйте ожидаемый RTT до Канады и предупредите про артефакты «лага терминала» при длинных сессиях VNC — это не всегда означает проблему Gateway.
Параллельно заведите простую таблицу решений «если X, то Y» для дежурных: кто имеет право открыть окно повторного cutover, кто утверждает откат DNS и где лежит последний проверенный архив workspace. Это снимает споры в чате в момент, когда секунды важны для клиентов на другом континенте.
Переключение Gateway на порту 18789
На целевом Mac после распаковки workspace выполните ту же последовательность, что и при чистой установке: единый пользователь ОС для процесса OpenClaw, согласованный PATH в plist и один слушатель на 127.0.0.1:18789 или явно описанный bind в конфигурации. Перед cutover снимите «конкуренцию»: на источнике после финального health-дрейна остановите LaunchDaemon или агент так, чтобы внешний трафик больше не попадал на старый слушатель, а интеграции временно указывали на заглушку или вторичный endpoint, если архитектура это допускает.
Порядок проб
Сначала loopback на канадском хосте, затем тот же запрос через SSH LocalForward с ноутбука оператора, затем публичный маршрут, если он включён. Расхождение между первым и вторым почти всегда SSH или политика портов; между вторым и третьим — DNS, TLS или периметр. Не публикуйте сырой gateway.remote.token в общих каналах при отладке.
curl -fsS -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" http://127.0.0.1:18789/health lsof -nP -iTCP:18789 -sTCP:LISTEN
ECONNRESET и расхождение токенов. Перед объявлением успеха обязательно покажите один PID в выводе lsof.
Упаковка и перенос workspace
Workspace переносите слоями: репозитории и скрипты отдельно от кэшей npm/pnpm и артефактов сборок. На APFS большие архивы лучше принимать через rsync с контрольными суммами или через промежуточное объектное хранилище, чтобы повторная попытка не начиналась с нуля. Исключите из синхронизации каталоги вроде .git/objects только если готовы выполнить git fetch на цели — для многих команд безопаснее перенести цельный клон. Проверьте, что пути в конфигурации OpenClaw не содержат хардкода старого пользователя или тома /Volumes/..., который не существует на новом хосте.
Секреты и Channels
Секреты каналов поднимайте из vault по двухфазной схеме: сначала запись в защищённое хранилище ключей на Mac, затем подстановка в конфиг и перезапуск только нужного адаптера. Если меняется webhook URL у внешнего провайдера, порядок должен быть зеркальным относительно DNS cutover, чтобы не было окна, когда события улетают в пустоту.
Копирование между разными поколениями macOS
При переходе со старого Intel или с локального ноутбука разработчика проверьте чувствительность регистра имён файлов и наличие symlink внутри workspace: инструменты сборки иногда полагаются на поведение по умолчанию APFS. Убедитесь, что расширенные атрибуты и флаги карантина не блокируют исполняемые скрипты после распаковки (xattr -lr на ключевых бинарниках). Если в архиве лежат артефакты, собранные под другую архитектуру, запланируйте чистую пересборку нативных модулей на Apple Silicon до включения постоянного LaunchDaemon.
Для больших деревьев зависимостей сравните время установки «с нуля» против копирования готового node_modules: на канале через океан иногда быстрее выполнить npm ci на цели при заранее закэшированном registry mirror, чем гонять гигабайты по SCP. Зафиксируйте выбранную стратегию в runbook, чтобы вторая команда не смешивала оба подхода на одном хосте.
Пересборка LaunchDaemon или LaunchAgent
На новом узле не копируйте plist вслепую: пересоберите его из актуальной команды запуска, добавив явный PATH, рабочий каталог WorkingDirectory и ключи перезапуска при сбое. Загрузите агент от имени того пользователя, которому принадлежит workspace, либо оформите системный демон только если политика безопасности это требует. После установки выполните launchctl kickstart в контролируемом порядке и сравните stderr с эталоном с источника за последние сутки.
launchctl bootout gui/$(id -u)/~/Library/LaunchAgents/com.example.openclaw.plist 2>/dev/null || true launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.plist launchctl kickstart -k gui/$(id -u)/com.example.openclaw
Приёмка через транстихоокеанский SSH и VNC
Оператор в Азии или Европе подтверждает миграцию в два шага: технический и организационный. Технический — воспроизводимый маршрут до health JSON и минимальный сценарий канала (например тестовое сообщение боту). Организационный — отметка в runbook и снимок версий Node, OpenClaw и macOS на цели. Для SSH держите разумный ServerAliveInterval и избегайте цепочек из нескольких jump host; для VNC используйте сеансы короткими итерациями, чтобы не смешивать «тормоз экрана» с реальной потерей пакетов на Gateway.
SSH LocalForward для удалённой проверки
Шаблон форварда остаётся прежним: локальный порт на ноутбуке оператора отображается на 127.0.0.1:18789 удалённого Mac. Если политика безопасности запрещает прямой доступ к loopback через туннель, используйте согласованный bastion и документируйте точку выхода.
ssh -N -L 18789:127.0.0.1:18789 user@canada-mac.example
Зафиксируйте в журнале смены две метрики RTT: до канадского хоста по SSH и до вашего публичного endpoint после cutover. Если второе значение неожиданно выше первого, ищите проблему на уровне балансировщика или гео-маршрутизации, а не в OpenClaw. Для VNC добавьте скриншот успешного входа и версию клиента — это ускоряет разбор инцидентов, когда провайдер удалённого доступа меняет кодеки или размер буфера.
Откат без потери данных и с повторным cutover
Откат имеет смысл только при явном критерии: недоступность health на новом узле после исчерпания лимита попыток перезапуска, массовые ошибки авторизации Channels после ротации секретов или регресс производительности диска при распаковке workspace. Верните DNS или reverse-proxy на источник, поднимите прежний LaunchDaemon и восстановите последний консистентный архив workspace. Зафиксируйте постмортем: какое дерево отличалось, какой PID слушал порт и какие строки лога совпали с симптомом. Повторный cutover планируйте только после устранения первопричины, иначе получите «миграцию по кругу».
Сводная таблица: источник vs канадский узел
| Область | Локально / старый узел | Цель: Mac M4 в Канаде |
|---|---|---|
| Gateway | Исторический bind, возможны экспериментальные флаги | Один слушатель 18789, токен и bind как в прод-runbook |
| Workspace | Часто смешаны кэши и проекты на одном томе | Отдельный том данных APFS, запас 15–20% свободного места |
| Launchd | Старый plist с устаревшим PATH | Пересобранный plist под текущего пользователя и Node LTS |
| Приёмка | Низкий RTT, легко перепутать сеть и приложение | Обязательное сравнение loopback vs SSH/VNC через океан |
| Откат | Может отсутствовать как процесс | Заранее описанный порядок возврата DNS и архива workspace |
Чек-лист фаз миграции
| Фаза | Ключевое действие | Критерий готовности |
|---|---|---|
| T0 подготовка | Снимок workspace, plist, версий; секреты в vault | Контрольные суммы и запись окна обслуживания согласованы |
| T1 холодная копия | Перенос дерева проекта без активного Gateway на цели | node -v и права на том совпадают с политикой узла |
| T2 прогрев | Запуск OpenClaw вручную, health на loopback | Один PID на 18789, логи без повторяющихся stack trace |
| T3 cutover | DNS/proxy/вебхук на новый endpoint | Внешняя проба и тест канала проходят из двух регионов |
| T4 наблюдение | Сравнение метрик за 24–48 ч | Нет роста ошибок OAuth/Telegram/Slack; диск стабилен |
| T5 уборка | Останов старого слушателя, архивация источника | Runbook закрыт; доступ к старому узлу только read-only |
Типичные ловушки: DNS, TLS, вебхуки и «ложный лаг»
Даже безупречный health на loopback не гарантирует успешный cutover, если внешний провайдер закэшировал старый A-запись или если CDN держит прежний origin. Зафиксируйте TTL заранее и добавьте явную пробу с хоста вне вашей сети после обновления DNS; для критичных интеграций временно опустите TTL до минутного интервала за сутки до окна. Отдельный класс проблем — цепочки TLS: если на новом узле другой набор промежуточных сертификатов или включён другой cipher suite, внешний клиент может получить «частично работает», хотя curl локально зелёный.
Вебхуки мессенджеров и SaaS часто приходят с фиксированных диапазонов IP: после миграции убедитесь, что канадский egress попадает в ваши белые списки так же, как прежний узел. Если провайдер привязывает webhook URL к конкретному сертификату или подписи запроса, пересоздавайте endpoint в том же порядке, что и DNS cutover, иначе очередь событий будет молча отбрасываться с HTTP 4xx.
Наблюдаемость в первые сутки должна включать три сигнала: задержку health с внешнего мониторинга, счётчик ошибок Channels по каждому адаптеру и свободное место APFS на томе workspace. Транстихоокеанский оператор будет жаловаться на «лаг CLI» при одновременно зелёном Gateway — это нормальный разрыв между UX терминала и приложением; зафиксируйте это в runbook, чтобы ночная смена не перезапускала сервис без причины.
Наконец, документируйте версию macOS и патчи безопасности на целевом узле: если после миграции включился более строгий SIP или новые профили сети, ваш прежний plist может требовать дополнительных entitlement. Лучше выявить это на этапе прогрева, чем в первый час после переключения прод-трафика.
FAQ
Можно ли оставить старый узел как горячий резерв ещё неделю?
Да, если он не слушает тот же публичный endpoint и вы контролируете расхождение конфигураций. Иначе дубли webhook приведут к двойным ответам и гонкам состояния.
После rsync Gateway отвечает, но Channels молчат
Сначала проверьте часы ОС и свежесть токенов, затем что адаптер запущен тем же пользователем, что и при onboard. Частая ошибка — секреты лежат в Keychain другого аккаунта.
VNC показывает лаг, а curl на loopback мгновенный
Это ожидаемый эффект удалённого экрана через большой RTT; не используйте VNC как единственный сигнал здоровья Gateway.
Нужно ли менять токен Gateway при миграции?
Не обязательно, если вы доверяете каналу переноса. Ротация при переезде — хорошая гигиена; тогда обновите секрет во всех клиентах до cutover.
Как понять, что пора откатываться, а не «ещё подождать»?
Заранее задайте порог: например три подряд неуспешных health со стороны внешнего мониторинга или невозможность отправить тестовое сообщение в основной канал за N минут после согласованных действий.
Стоит ли поднимать второй инстанс OpenClaw на одном Mac для blue-green?
Только на разных портах и с изоляцией конфигурации; для JSON Gateway чаще проще держать второй временный хост или контролируемый простой, чем бороться с двумя production-портами на одной системе.
Что делать, если после перезагрузки Mac сервис не поднимается?
Проверьте, что пользователь для LaunchAgent логинился хотя бы один раз после установки (GUI session), либо переведите сервис в формат демона с корректными правами. Сверьте launchctl print с эталонным plist.
Стоит ли параллельно менять major-версию Node в день миграции?
Нет, если можно избежать: совместите только переезд хоста и конфигурации Gateway. Обновление runtime перенесите на отдельное окно с регрессионными тестами Channels и контрольным прогоном сборки нативных модулей на Apple Silicon.
Итог
Стабильная миграция OpenClaw на канадский Mac M4 — это синхронизация трёх осей: один предсказуемый слушатель на 18789, аккуратно перенесённый workspace без «магических» путей и plist, который вы сознательно пересобрали под нового пользователя и среду Node. Транстихоокеанские SSH и VNC подтверждают доступность для людей, но истиной остаётся loopback на самом хосте плюс внешняя проба после cutover. Держите откат формализованным: он экономит часы, когда новый узел технически жив, а интеграции ведут себя иначе из-за секретов или DNS.
Выкладывайте runbook так, чтобы любой дежурный мог воспроизвести таблицу фаз и отличить сетевой шум от регресса сервиса; сохраняйте артефакты checksum и короткие выдержки лога рядом с записью об инциденте. Так следующая миграция — будь то смена региона или апгрейд диска — начинается не с расследования «что мы делали в прошлый раз», а с проверенного чек-листа и понятных критериев готовности.