Cloudflare Tunnel через контейнер на MikroTik

Cloudflare Tunnel (ранее Argo Tunnel) позволяет открыть доступ к домашним или офисным сервисам из интернета без проброса портов, без статического IP и без раскрытия реального адреса маршрутизатора. Вместо классического подхода «пробросить порт на роутере» вы запускаете агент cloudflared внутри контейнера на MikroTik, который устанавливает исходящее зашифрованное соединение к ближайшему PoP Cloudflare. Cloudflare принимает входящие запросы из интернета и проксирует их через этот туннель в вашу локальную сеть. В этом руководстве подробно разберём, зачем это нужно, как подготовить окружение, развернуть контейнер cloudflared на RouterOS 7.20+ и опубликовать несколько сервисов через собственный домен.

Описание

Зачем нужен Cloudflare Tunnel

Классический доступ к домашним сервисам из интернета выглядит так: вы пробрасываете порт через NAT, покупаете статический IP (или настраиваете DDNS), открываете firewall. Это несёт множество рисков:

• Публичный IP — сканеры обнаруживают открытые порты за минуты
• Прямой доступ — атакующий видит ваш реальный IP и может нацелить DDoS
• Сертификаты — нужно самостоятельно получать и обновлять TLS
• Двойной NAT — у многих провайдеров CG-NAT, проброс портов вообще невозможен

Cloudflare Tunnel решает все эти проблемы:

Как работает Cloudflare Tunnel

Архитектура состоит из нескольких компонентов:

1. Cloudflare Edge — глобальная сеть PoP (более 300 дата-центров), принимающая запросы пользователей
2. cloudflared — лёгкий агент (демон), устанавливающий исходящие QUIC/HTTP2-соединения к Cloudflare Edge
3. Локальные сервисы — веб-приложения, API, SSH, RDP и другое в вашей локальной сети

Схема работы:

code
Копировать
Пользователь → Cloudflare Edge (myservice.mydomain.com)
                    ↕ (зашифрованный туннель, исходящее соединение)
              cloudflared (контейнер на MikroTik)
                    ↕ (локальная сеть)
              Локальный сервис (192.168.88.100:8080)

Агент cloudflared устанавливает несколько параллельных соединений к разным Cloudflare PoP для отказоустойчивости. Весь трафик зашифрован. Cloudflare не может расшифровать содержимое запросов к вашим сервисам (если используете origin certificate).

Tunnel vs Port Forward vs VPN

Вывод: Port Forward — для простых случаев со статическим IP. WireGuard — для site-to-site и доступа «своих». Cloudflare Tunnel — для публикации сервисов без публичного IP, с защитой и аутентификацией.

Требования

• RouterOS 7.20+ с поддержкой контейнеров
• Устройство с достаточными ресурсами: ARM64 (hAP ax³, RB5009, CCR2004) или x86 (CHR)
• Минимум 256 МБ свободной RAM
• Внешний USB-накопитель (рекомендуется) или достаточно встроенного хранилища
• Аккаунт Cloudflare (бесплатный тариф подходит)
• Домен, подключённый к Cloudflare (DNS управляется через Cloudflare)
• Доступ в интернет с MikroTik

Настройка

Шаг 1: Подготовка Cloudflare

Прежде чем настраивать MikroTik, нужно создать туннель в Cloudflare и получить токен.

1.1. Убедитесь, что домен подключён к Cloudflare:

• Зайдите на dash.cloudflare.com
• Добавьте домен, если ещё не сделали
• Убедитесь, что NS-записи домена указывают на Cloudflare

1.2. Создайте туннель в Zero Trust:

• Перейдите в Zero Trust Dashboard
• Networks → Tunnels → Create a tunnel
• Выберите тип: Cloudflared
• Задайте имя туннеля (например, mikrotik-home)
• На странице установки выберите Docker — вам покажут команду с токеном
• Скопируйте токен — длинную строку вида eyJhIjoiNjQ... — она понадобится при запуске контейнера

1.3. Настройте Public Hostname:

• В настройках туннеля перейдите на вкладку Public Hostname
• Добавьте запись:
  • Subdomain: myservice
  • Domain: mydomain.com
  • Service: http://192.168.88.100:8080
• Cloudflare автоматически создаст CNAME-запись в DNS

Можно добавить несколько Public Hostname — каждый будет проксироваться через тот же туннель.

Шаг 2: Включение контейнеров на MikroTik

Если контейнеры ещё не включены, активируйте device-mode:

[admin@MikroTik] >
Копировать
/system/device-mode/update container=yes

После выполнения потребуется нажать кнопку reset на устройстве или перезагрузить маршрутизатор (физическое подтверждение). На CHR подтверждение не требуется.

[admin@MikroTik] >
Копировать
# Проверяем, что контейнеры включены
/system/device-mode/print
# container: yes

Шаг 3: Настройка хранилища

[admin@MikroTik] >
Копировать
# Проверяем доступные диски
/disk print

# Если есть USB-накопитель — форматируем (при необходимости)
/disk/format-drive usb1 file-system=ext4 label=containers

# Настраиваем параметры контейнеров
/container/config set ram-high=256M tmpdir=usb1/tmp

Если USB нет, контейнеры будут использовать встроенное хранилище. Проверьте свободное место:

[admin@MikroTik] >
Копировать
/system/resource print
# Смотрите free-hdd-space — нужно минимум 150 МБ для образа cloudflared

Шаг 4: Создание сетевого интерфейса для контейнера

Контейнер cloudflared инициирует исходящие соединения, поэтому ему нужен доступ в интернет. Создадим veth-интерфейс и подключим его к bridge:

[admin@MikroTik] >
Копировать
# Создаём виртуальный Ethernet
/interface/veth add name=veth-cloudflared address=172.17.0.2/24 gateway=172.17.0.1

# Создаём отдельный bridge для контейнеров (или используем существующий)
/interface/bridge add name=bridge-containers

# Добавляем veth в bridge
/interface/bridge/port add interface=veth-cloudflared bridge=bridge-containers

# Назначаем IP-адрес bridge (gateway для контейнера)
/ip/address add address=172.17.0.1/24 interface=bridge-containers

# NAT для выхода контейнера в интернет
/ip/firewall/nat add chain=srcnat src-address=172.17.0.0/24 action=masquerade \
  comment="NAT for containers"

Если у вас уже есть bridge для контейнеров из предыдущих настроек — используйте его, не создавайте дублирующий.

Шаг 5: Настройка DNS для контейнера

Контейнеру нужен DNS для разрешения адресов Cloudflare:

[admin@MikroTik] >
Копировать
# Разрешаем DNS-запросы от контейнеров
/ip/firewall/filter add chain=input src-address=172.17.0.0/24 \
  protocol=udp dst-port=53 action=accept \
  comment="Allow DNS from containers" place-before=0

/ip/firewall/filter add chain=input src-address=172.17.0.0/24 \
  protocol=tcp dst-port=53 action=accept \
  comment="Allow DNS from containers" place-before=0

Шаг 6: Добавление переменной окружения

Создадим файл с переменными окружения для контейнера. Токен передаётся через аргумент запуска, но можно также задать через envs:

[admin@MikroTik] >
Копировать
# Создаём переменную окружения (опционально)
/container/envs add name=cloudflared-env key=TUNNEL_TOKEN \
  value="eyJhIjoiNjQ..."

Шаг 7: Запуск контейнера cloudflared

Теперь скачиваем образ и создаём контейнер:

[admin@MikroTik] >
Копировать
# Указываем registry (Docker Hub используется по умолчанию)
/container/config set registry-url=https://registry-1.docker.io \
  tmpdir=usb1/tmp

# Добавляем контейнер
/container add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=eyJhIjoiNjQ..." \
  logging=yes \
  start-on-boot=yes \
  comment="Cloudflare Tunnel"

Важно: замените eyJhIjoiNjQ... на ваш реальный токен из Zero Trust Dashboard.

Параметры команды cloudflared:

• tunnel — режим туннеля
• --no-autoupdate — отключение автообновления (в контейнере обновляться через pull образа)
• run — запуск туннеля
• --token=... — токен авторизации, полученный в Cloudflare

[admin@MikroTik] >
Копировать
# Ждём скачивания образа (может занять несколько минут)
/container print
# status: stopped → extracting → stopped

# Запускаем контейнер
/container start 0

Номер контейнера (0) может отличаться — проверьте через /container print.

[admin@MikroTik] >
Копировать
# Проверяем статус
/container print
# status: running

# Смотрим логи контейнера
/log print where topics~"container"

Шаг 8: Публикация нескольких сервисов

Одно из главных преимуществ Cloudflare Tunnel — возможность публиковать несколько сервисов через один туннель. Все настройки выполняются в Cloudflare Zero Trust Dashboard.

Примеры публикации:

Для каждого сервиса в Zero Trust Dashboard:

1. Tunnels → ваш туннель → Public Hostname → Add a public hostname
2. Укажите subdomain, domain и адрес локального сервиса
3. Cloudflare автоматически создаст DNS-запись

Для не-HTTP сервисов (SSH, RDP) клиенту понадобится cloudflared access на своей стороне или Cloudflare WARP.

Шаг 9: Защита через Cloudflare Access

Публикация сервиса без аутентификации — плохая идея. Cloudflare Access позволяет добавить слой аутентификации перед вашим сервисом:

1. В Zero Trust Dashboard → Access → Applications → Add an application
2. Тип: Self-hosted
3. Укажите домен приложения (например, grafana.mydomain.com)
4. Создайте политику доступа:
   • Allow — Email ends in @mydomain.com
   • Или: Allow — конкретные email-адреса
   • Или: Allow — Identity provider (Google, GitHub, Okta)
5. Метод аутентификации: One-Time PIN (OTP на email), Google SSO, GitHub и другие

Теперь при открытии grafana.mydomain.com пользователь сначала проходит аутентификацию через Cloudflare Access, и только после этого запрос проксируется в вашу сеть.

code
Копировать
Пользователь → Cloudflare Edge → Access (проверка аутентификации)
                                       ↓ (авторизован)
                                  Cloudflare Tunnel → Локальный сервис

Проверка

Проверка статуса контейнера

[admin@MikroTik] >
Копировать
# Статус контейнера
/container print
# Flags: X - disabled
# 0   interface=veth-cloudflared root-dir=usb1/cloudflared
#     remote-image=cloudflare/cloudflared:latest status=running

# Логи контейнера — ищем строку "Connection registered"
/log print where topics~"container"
# Должны увидеть: "Connection <ID> registered connIndex=0 ..."
# Успешный туннель устанавливает 4 соединения (connIndex 0-3)

Проверка сетевой связности контейнера

[admin@MikroTik] >
Копировать
# Пингуем контейнер с MikroTik
/ping 172.17.0.2 count=3

# Проверяем, что контейнер имеет выход в интернет
# (смотрим в логах — cloudflared сам проверяет связь)
/log print where message~"cloudflared"

Проверка туннеля в Cloudflare Dashboard

1. Zero Trust Dashboard → Networks → Tunnels
2. Статус туннеля должен быть Healthy (зелёный)
3. Если Down (красный) — смотрите логи контейнера

Проверка доступности сервиса

С внешнего устройства (не из вашей локальной сети):

[admin@MikroTik] >
Копировать
# С телефона через мобильный интернет или VPN
curl -I https://myservice.mydomain.com
# HTTP/2 200 — сервис доступен через туннель

# Проверка DNS
nslookup myservice.mydomain.com
# Должен резолвиться в IP Cloudflare (не ваш реальный)

Проверка Cloudflare Access

[admin@MikroTik] >
Копировать
# Попробуйте открыть защищённый сервис в браузере
# Должна появиться страница аутентификации Cloudflare Access
# После ввода email → OTP-код на почту → доступ к сервису

Типичные ошибки

1. Контейнер не запускается — статус "error"

Причина: неправильная архитектура образа. Образ cloudflare/cloudflared:latest по умолчанию может скачаться для другой архитектуры.

Решение:

[admin@MikroTik] >
Копировать
# Проверяем архитектуру маршрутизатора
/system/resource print
# architecture-name: arm64 (или arm, x86)

# Удаляем контейнер и пересоздаём с указанием платформы
/container stop 0
/container remove 0

# Для ARM64 устройств (hAP ax³, RB5009)
/container add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=YOUR_TOKEN" \
  logging=yes start-on-boot=yes

Если проблема сохраняется, скачайте образ на компьютере для нужной архитектуры и загрузите tar-архив:

[admin@MikroTik] >
Копировать
# На компьютере (Linux/Mac)
docker pull --platform linux/arm64 cloudflare/cloudflared:latest
docker save cloudflare/cloudflared:latest -o cloudflared-arm64.tar
# Загрузите .tar на USB-накопитель MikroTik через Files

[admin@MikroTik] >
Копировать
/container add file=usb1/cloudflared-arm64.tar \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=YOUR_TOKEN" \
  logging=yes start-on-boot=yes

2. Туннель не устанавливается — "failed to connect"

Причина: контейнер не может достучаться до серверов Cloudflare. Нет выхода в интернет или firewall блокирует.

Решение:

[admin@MikroTik] >
Копировать
# Проверяем, что NAT для контейнеров работает
/ip/firewall/nat print where comment~"container"

# Проверяем маршрутизацию
/ip/route print where dst-address=0.0.0.0/0

# Проверяем, что bridge-containers имеет IP
/ip/address print where interface=bridge-containers

# Проверяем DNS — MikroTik должен резолвить DNS для контейнеров
/ip/dns print
# Должен быть настроен upstream DNS

# Проверяем firewall — не блокирует ли forward из контейнерной подсети
/ip/firewall/filter print where chain=forward

# Добавляем разрешающее правило, если нужно
/ip/firewall/filter add chain=forward src-address=172.17.0.0/24 \
  action=accept comment="Allow containers forward" place-before=0

3. Токен истёк или недействителен

Причина: токен был создан давно и истёк, или был скопирован с ошибкой.

Решение:

1. В Zero Trust Dashboard → Tunnels → ваш туннель → Configure
2. Нажмите Regenerate Token
3. Скопируйте новый токен полностью (он длинный, убедитесь, что копируете целиком)
4. Обновите контейнер:

[admin@MikroTik] >
Копировать
/container stop 0
/container remove 0
/container add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=NEW_TOKEN_HERE" \
  logging=yes start-on-boot=yes
/container start 0

4. Сервис недоступен через туннель — "Bad Gateway" (502)

Причина: туннель работает, но cloudflared не может достучаться до локального сервиса.

Решение:

[admin@MikroTik] >
Копировать
# Проверяем, что локальный сервис запущен и отвечает
/tool/fetch url="http://192.168.88.100:8080" mode=http

# Проверяем маршрутизацию от контейнера до сервиса
# Контейнер в 172.17.0.0/24, сервис в 192.168.88.0/24
# Нужен маршрут между ними

# Проверяем, что firewall не блокирует трафик от контейнера к сервису
/ip/firewall/filter add chain=forward src-address=172.17.0.0/24 \
  dst-address=192.168.88.0/24 action=accept \
  comment="Cloudflared to LAN" place-before=0

Также проверьте настройку Public Hostname в Cloudflare — адрес и порт должны точно совпадать с реальными параметрами сервиса.

5. DNS-запись не появилась после настройки Public Hostname

Причина: DNS-пропагация может занимать до 5 минут, или домен не управляется Cloudflare.

Решение:

1. Проверьте, что домен в Cloudflare имеет статус Active
2. Убедитесь, что NS-записи домена указывают на Cloudflare
3. Подождите 5-10 минут и проверьте:

bash
Копировать
dig myservice.mydomain.com CNAME
# Должен показать CNAME на <tunnel-uuid>.cfargotunnel.com

4. Если CNAME не появился — создайте вручную в DNS Cloudflare:
   • Type: CNAME
   • Name: myservice
   • Target: <tunnel-uuid>.cfargotunnel.com
   • Proxy status: Proxied (оранжевое облако)

6. Контейнер не перезапускается после перезагрузки маршрутизатора

Причина: параметр start-on-boot не установлен.

Решение:

[admin@MikroTik] >
Копировать
/container set 0 start-on-boot=yes

# Проверяем
/container print detail where interface=veth-cloudflared
# start-on-boot: yes

7. Высокое потребление RAM контейнером

Причина: cloudflared при высокой нагрузке может потреблять значительное количество RAM.

Решение:

[admin@MikroTik] >
Копировать
# Ограничиваем RAM для контейнеров
/container/config set ram-high=256M

# Мониторим потребление
/system/resource print
# Если free-memory критически мала — уменьшите количество
# публикуемых сервисов или используйте устройство с большей RAM

Рекомендации по эксплуатации

• Обновление образа: периодически обновляйте cloudflared для получения исправлений безопасности:

[admin@MikroTik] >
Копировать
/container stop 0
/container remove 0
# Удалите старый root-dir
/file remove usb1/cloudflared
# Пересоздайте контейнер с тем же remote-image — скачается свежий образ

• Мониторинг: настройте netwatch для проверки доступности контейнера:

[admin@MikroTik] >
Копировать
/tool/netwatch add host=172.17.0.2 interval=60s \
  up-script="" \
  down-script="/log warning \"Cloudflared container is down\""

• Бэкап токена: храните токен туннеля в безопасном месте. При сбросе маршрутизатора токен потеряется, и вам придётся пересоздавать контейнер.

• Несколько туннелей: для разделения сервисов по зонам безопасности можно создать несколько туннелей (каждый — отдельный контейнер с отдельным токеном). Однако для большинства случаев одного туннеля достаточно.

Пользователь → Cloudflare Edge (myservice.mydomain.com)
                    ↕ (зашифрованный туннель, исходящее соединение)
              cloudflared (контейнер на MikroTik)
                    ↕ (локальная сеть)
              Локальный сервис (192.168.88.100:8080)
/system/device-mode/update container=yes
# Проверяем, что контейнеры включены
/system/device-mode/print
# container: yes
# Проверяем доступные диски
/disk print

# Если есть USB-накопитель — форматируем (при необходимости)
/disk/format-drive usb1 file-system=ext4 label=containers

# Настраиваем параметры контейнеров
/container/config set ram-high=256M tmpdir=usb1/tmp
/system/resource print
# Смотрите free-hdd-space — нужно минимум 150 МБ для образа cloudflared
# Создаём виртуальный Ethernet
/interface/veth add name=veth-cloudflared address=172.17.0.2/24 gateway=172.17.0.1

# Создаём отдельный bridge для контейнеров (или используем существующий)
/interface/bridge add name=bridge-containers

# Добавляем veth в bridge
/interface/bridge/port add interface=veth-cloudflared bridge=bridge-containers

# Назначаем IP-адрес bridge (gateway для контейнера)
/ip/address add address=172.17.0.1/24 interface=bridge-containers

# NAT для выхода контейнера в интернет
/ip/firewall/nat add chain=srcnat src-address=172.17.0.0/24 action=masquerade \
  comment="NAT for containers"
# Разрешаем DNS-запросы от контейнеров
/ip/firewall/filter add chain=input src-address=172.17.0.0/24 \
  protocol=udp dst-port=53 action=accept \
  comment="Allow DNS from containers" place-before=0

/ip/firewall/filter add chain=input src-address=172.17.0.0/24 \
  protocol=tcp dst-port=53 action=accept \
  comment="Allow DNS from containers" place-before=0
# Создаём переменную окружения (опционально)
/container/envs add name=cloudflared-env key=TUNNEL_TOKEN \
  value="eyJhIjoiNjQ..."
# Указываем registry (Docker Hub используется по умолчанию)
/container/config set registry-url=https://registry-1.docker.io \
  tmpdir=usb1/tmp

# Добавляем контейнер
/container add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=eyJhIjoiNjQ..." \
  logging=yes \
  start-on-boot=yes \
  comment="Cloudflare Tunnel"
# Ждём скачивания образа (может занять несколько минут)
/container print
# status: stopped → extracting → stopped

# Запускаем контейнер
/container start 0
# Проверяем статус
/container print
# status: running

# Смотрим логи контейнера
/log print where topics~"container"
Пользователь → Cloudflare Edge → Access (проверка аутентификации)
                                       ↓ (авторизован)
                                  Cloudflare Tunnel → Локальный сервис
# Статус контейнера
/container print
# Flags: X - disabled
# 0   interface=veth-cloudflared root-dir=usb1/cloudflared
#     remote-image=cloudflare/cloudflared:latest status=running

# Логи контейнера — ищем строку "Connection registered"
/log print where topics~"container"
# Должны увидеть: "Connection <ID> registered connIndex=0 ..."
# Успешный туннель устанавливает 4 соединения (connIndex 0-3)
# Пингуем контейнер с MikroTik
/ping 172.17.0.2 count=3

# Проверяем, что контейнер имеет выход в интернет
# (смотрим в логах — cloudflared сам проверяет связь)
/log print where message~"cloudflared"
# С телефона через мобильный интернет или VPN
curl -I https://myservice.mydomain.com
# HTTP/2 200 — сервис доступен через туннель

# Проверка DNS
nslookup myservice.mydomain.com
# Должен резолвиться в IP Cloudflare (не ваш реальный)
# Попробуйте открыть защищённый сервис в браузере
# Должна появиться страница аутентификации Cloudflare Access
# После ввода email → OTP-код на почту → доступ к сервису
# Проверяем архитектуру маршрутизатора
/system/resource print
# architecture-name: arm64 (или arm, x86)

# Удаляем контейнер и пересоздаём с указанием платформы
/container stop 0
/container remove 0

# Для ARM64 устройств (hAP ax³, RB5009)
/container add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=YOUR_TOKEN" \
  logging=yes start-on-boot=yes
# На компьютере (Linux/Mac)
docker pull --platform linux/arm64 cloudflare/cloudflared:latest
docker save cloudflare/cloudflared:latest -o cloudflared-arm64.tar
# Загрузите .tar на USB-накопитель MikroTik через Files
/container add file=usb1/cloudflared-arm64.tar \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=YOUR_TOKEN" \
  logging=yes start-on-boot=yes
# Проверяем, что NAT для контейнеров работает
/ip/firewall/nat print where comment~"container"

# Проверяем маршрутизацию
/ip/route print where dst-address=0.0.0.0/0

# Проверяем, что bridge-containers имеет IP
/ip/address print where interface=bridge-containers

# Проверяем DNS — MikroTik должен резолвить DNS для контейнеров
/ip/dns print
# Должен быть настроен upstream DNS

# Проверяем firewall — не блокирует ли forward из контейнерной подсети
/ip/firewall/filter print where chain=forward

# Добавляем разрешающее правило, если нужно
/ip/firewall/filter add chain=forward src-address=172.17.0.0/24 \
  action=accept comment="Allow containers forward" place-before=0
/container stop 0
/container remove 0
/container add remote-image=cloudflare/cloudflared:latest \
  interface=veth-cloudflared \
  root-dir=usb1/cloudflared \
  cmd="tunnel --no-autoupdate run --token=NEW_TOKEN_HERE" \
  logging=yes start-on-boot=yes
/container start 0
# Проверяем, что локальный сервис запущен и отвечает
/tool/fetch url="http://192.168.88.100:8080" mode=http

# Проверяем маршрутизацию от контейнера до сервиса
# Контейнер в 172.17.0.0/24, сервис в 192.168.88.0/24
# Нужен маршрут между ними

# Проверяем, что firewall не блокирует трафик от контейнера к сервису
/ip/firewall/filter add chain=forward src-address=172.17.0.0/24 \
  dst-address=192.168.88.0/24 action=accept \
  comment="Cloudflared to LAN" place-before=0
dig myservice.mydomain.com CNAME
# Должен показать CNAME на <tunnel-uuid>.cfargotunnel.com
/container set 0 start-on-boot=yes

# Проверяем
/container print detail where interface=veth-cloudflared
# start-on-boot: yes
# Ограничиваем RAM для контейнеров
/container/config set ram-high=256M

# Мониторим потребление
/system/resource print
# Если free-memory критически мала — уменьшите количество
# публикуемых сервисов или используйте устройство с большей RAM
/container stop 0
/container remove 0
# Удалите старый root-dir
/file remove usb1/cloudflared
# Пересоздайте контейнер с тем же remote-image — скачается свежий образ
/tool/netwatch add host=172.17.0.2 interval=60s \
  up-script="" \
  down-script="/log warning \"Cloudflared container is down\""