Сценарий с обратным SSH — отдельная статья. Там loopback и бастион: OpenClaw, loopback и SSH-туннель на vpshalo. Здесь же мы опираемся на Named Tunnel в Cloudflare: ingress описан в файле, публичное имя стабильно, а OpenClaw по-прежнему слушает только 127.0.0.1. Дальше — как слить логи и синтетический health из нескольких PoP в одно пятиминутное окно, чтобы пейджер не дублировал один и тот же инцидент.

Грань с периметром Halo и Worker — в материале Cloudflare Worker, SSH p95 и чеклист на vpshalo. Если вам ближе overlay и имена в tailnet, смотрите OpenClaw, MagicDNS и мультирегион. Ниже предполагается, что вы уже выбрали зону в Cloudflare и готовы держать один туннель на регион, без «быстрых» случайных URL.

Опорные правила: loopback и зафиксированный ingress

HTTP-интерфейс OpenClaw не должен появляться на 0.0.0.0. Рабочий контракт: 127.0.0.1:PORT (пример ниже — 18080), отдельный OPENCLAW_HOME на каждый PoP, без общего NFS между континентами. В config.yml для cloudflared список ingress задаёт единственный допустимый путь от hostname к upstream; последняя строка — catch-all с http_status:404, чтобы случайный хост не уехал в ваш сервис. Поверх публичного hostname имеет смысл включить Cloudflare Access (или эквивалент), иначе любой, кто угадает путь, дойдёт до того же upstream, что и легитимный клиент.

Один именованный туннель на регион упрощает расследование: в логах видно, какой tunnel_id отвалился, а карта DNS не смешивает Сингапур и Западное побережье США в одной записи.

Воспроизводимые шаги (повторить на каждом региональном узле)

  • Шаг 1 — изоляция состояния и bind. Задайте OPENCLAW_HOME=/var/lib/openclaw/<region> (на удалённом Mac — аналог в пределах диска инстанса). Поднимите HTTP только на 127.0.0.1:18080. Проверка с самого хоста: curl -fsS --max-time 2 http://127.0.0.1:18080/healthz. Пока этот запрос не зелёный, не подключайте cloudflared.
  • Шаг 2 — учётная запись Cloudflare и туннель. На машине с правами на зону выполните cloudflared tunnel login, затем cloudflared tunnel create openclaw-<region>. Создайте CNAME на целевой поддомен по инструкции Cloudflare для вашего туннеля.
  • Шаг 3 — зафиксируйте ingress в файле. В config.yml сопоставьте, например, hostname: oc.<region>.example.com с service: http://127.0.0.1:18080; добавьте отдельные пути для метрик или вебхуков, если они отделены. Завершите блок правилом - service: http_status:404.
  • Шаг 4 — токен и unit. Выпустите TUNNEL_TOKEN для этого туннеля и положите его в файл, подключаемый через EnvironmentFile= в systemd, либо в секрет-менеджер вашей платформы. Юнит вызывает cloudflared tunnel run с Restart=on-failure и разумным RestartSec, чтобы при флапе не забить лимиты API.
  • Шаг 5 — сквозная проверка. С внешней сети: curl -fsS https://oc.<region>.example.com/healthz. Если ответ не 200, параллельно смотрите журнал cloudflared и локальный curl к loopback: так вы отделяете проблему «туннель умер» от «упал сам OpenClaw».
# Локально на узле vpshalo
curl -fsS --max-time 2 http://127.0.0.1:18080/healthz

# После публикации DNS (с внешней машины)
curl -fsS --max-time 5 https://oc.<region>.example.com/healthz
Не пользуйтесь «quick tunnel» для постоянного контура: именованный туннель плюс DNS даёт предсказуемый ingress, который можно код-ревьюить и откатывать из git.

Слияние синтетического вывода и health

Каждый регион пишет однострочный JSON в общий поток (stdout агента, syslog или метрики). Поля держите узкими и стабильными: region, lane (loopback, tunnel, edge_https), rtt_ms, error_class, опционально tunnel_id. Воркер слияния скользит пятиминутным окном: внутри региона пейдж только если все полосы lane за окно красные; мультирегиональная эскалация — если минимум два региона потеряли полосу tunnel в том же окне. События переподключения cloudflared нормализуйте в тот же error_class, иначе дежурный не отличит обрыв QUIC от падения модели.

Такой merge снижает шум: одна карточка инцидента вместо трёх дублей про один flap. Пороги и backoff согласуйте с внутренним ранбуком; публичные ориентиры по сопутствующим темам — в разделе помощи на сайте.

FAQ: сертификаты, порты, токены

Где «сертификаты туннеля» и что бэкапить? TLS для публичного HTTPS терминируется на стороне Cloudflare; для upstream на localhost отдельный серверный сертификат обычно не нужен. У cloudflared есть собственный кэш материалов для связи с edge — храните путь по умолчанию или заданный вами в резервной копии вместе с unit-файлом. При полной потере диска достаточно заново положить config.yml, актуальный TUNNEL_TOKEN и доверенный корень системы; туннель поднимется с чистым кэшем.

Какой порт выбрать и как не промахнуться? Зафиксируйте один порт на весь флот документации (например 18080), чтобы runbook и ingress не расходились. На узле выполните ss -lntp и убедитесь, что слушатель только на 127.0.0.1. Если процесс «ползёт» на другой интерфейс — это отдельный инцидент безопасности, а не задача сетевой команды.

Утечка TUNNEL_TOKEN — что делать? Немедленно отзовите токен в Zero Trust / Tunnel settings, создайте новый, раскатайте файл окружения на все узлы этого туннеля в одном окне изменений. Не храните токен в git; для CI используйте OIDC или краткоживущие секреты. Долгоживущий токен в корпоративном чате равносилен компрометации всего ingress-дерева этого региона.

Нужен ли отдельный токен на каждый PoP? Да: один туннель и один токен на регион. Общий токен на Токио и Франкфурт смешивает журналы и усложняет отзыв при локальном инциденте.

Оговорка: флаги cloudflared и поля health в OpenClaw меняются между релизами. Сверяйте команды с документацией вашей версии; смысл шагов остаётся прежним.
Публичные страницы vpshalo

Согласуйте PoP туннеля с арендой Mac

Откройте главную, сравните регионы и лимиты на странице тарифов, затем оформите аренду удалённого Mac в том же географическом кольце, где крутятся узлы с OpenClaw и cloudflared. Когда RTT до edge, SSH и артефактов CI сходятся, фиксированный ingress и объединённые алерты читаются без «магии» в дашбордах.

Арендовать Mac Тарифы Помощь Другие статьи

Сначала короткий контракт на пилот, затем после выбора PoP — переход к покупке и раскатке «боевых» токенов. Так вы не привязываете долгоживущие секреты к лабораторным именам хостов.