Cloudflare Tunnel на сервере: частые ошибки и решения

MAATRIX

Cloudflare Tunnel подкупает простотой, пока не сталкиваешься с тем, что туннель висит в статусе down, домен отдаёт 502, а после перезагрузки сервиса нет вовсе. Почти все проблемы Cloudflare Tunnel на сервере сводятся к нескольким типовым ошибкам в конфигурации ingress, автозапуске и связке с локальным сервисом. Разберём их по порядку и починим, не открывая лишних портов.

Ошибка: туннель в статусе down

Открываете панель Cloudflare, а туннель помечен как неактивный, хотя вы его запускали. Туннель работает за счёт постоянного исходящего соединения агента cloudflared с сетью Cloudflare, поэтому статус down означает, что это соединение не установлено. Первое, что нужно проверить, — запущен ли вообще сервис на сервере:

systemctl status cloudflared
journalctl -u cloudflared --since "10 min ago"

Если сервис остановлен — запустите его. Если запущен, но в логах ошибки соединения, проверьте, выпускает ли сервер исходящий трафик к Cloudflare: чрезмерно строгий фаервол, блокирующий исходящие соединения, обрывает туннель. В отличие от классических схем, туннелю нужны именно исходящие соединения, а не входящие порты. Ещё одна причина down — неверный или устаревший файл учётных данных туннеля: если его удалили или указали не тот путь, агент не сможет авторизоваться.

Ошибка: домен отдаёт 502 Bad Gateway

Туннель онлайн, домен открывается, но вместо сайта — ошибка 502. Это классика, и означает она вот что: Cloudflare дотянулся до вашего сервера по туннелю, но cloudflared не смог связаться с локальным сервисом, на который настроен маршрут. То есть проблема не в туннеле, а в звене между агентом и вашим приложением.

Проверьте три вещи. Первая — работает ли локальный сервис вообще: обратитесь к нему прямо на сервере по тому адресу и порту, что указаны в конфигурации. Вторая — совпадает ли порт в правиле ingress с реальным портом сервиса; опечатка в номере порта даёт ровно эту ошибку. Третья — правильный ли протокол: если сервис слушает http, а в правиле указан https (или наоборот), связь не установится:

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404

Убедитесь, что localhost:8080 — это действительно адрес вашего работающего сервиса. В большинстве случаев 502 лечится исправлением порта или запуском упавшего локального приложения.

Ошибка: последнее правило ingress пропущено

Туннель запускается с ошибкой конфигурации или ведёт себя непредсказуемо, отдавая не то, что нужно. Частая причина — неверная структура правил ingress. Правила разбираются строго сверху вниз, и список обязан завершаться правилом-заглушкой без hostname, которое ловит всё остальное. Без него конфигурация некорректна.

Проверьте, что последним стоит правило-catch-all, например возвращающее 404:

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404

Также следите за порядком: если более общее правило стоит выше частного, частное не сработает, потому что запрос перехватится раньше. Проверить корректность конфигурации помогает встроенная валидация cloudflared, которая укажет на структурные ошибки до запуска. Прогоняйте её после каждой правки ingress — это экономит время на догадках.

Ошибка: туннель не поднимается после перезагрузки

Перезагрузили сервер под обновления — и сайт недоступен, потому что туннель не запустился сам. Причина в том, что cloudflared был запущен вручную командой run, а не установлен как системный сервис. Ручной запуск живёт только до закрытия сессии или перезагрузки.

Оформите туннель как сервис и включите в автозапуск:

cloudflared service install
systemctl enable --now cloudflared

После этого обязательно проверьте результат честно — перезагрузите сервер и убедитесь, что туннель поднялся без вашего участия и домен доступен. Тихо не поднявшийся после ребута туннель коварен: сервер работает, приложение работает, а снаружи всё лежит, и причина неочевидна. Привычка проверять доступность после каждой перезагрузки снимает этот риск.

Ошибка: конфликт нескольких туннелей или конфигов

Иногда на сервере оказывается несколько туннелей или конфигурационных файлов, и cloudflared запускает не тот, что вы правите. Вы меняете ingress, перезапускаете сервис, а поведение не меняется, потому что сервис читает другой конфиг. Это сбивает с толку и приводит к бесконечной отладке не того файла.

Определите однозначно, какой конфигурационный файл использует сервис, и правьте именно его. Убедитесь, что идентификатор туннеля в конфигурации совпадает с тем туннелем, на который заведена DNS-запись. Если туннелей несколько, дайте им понятные имена и держите по одному конфигу на туннель. Лишние, давно созданные, но неиспользуемые туннели лучше удалить, чтобы не путаться. Ясность в том, что и откуда запускается, — половина успеха в отладке.

Ошибка: DNS-запись указывает не туда

Домен не открывается или ведёт на чужой сервис, хотя туннель настроен верно. Причина — в Cloudflare осталась старая или ручная DNS-запись, которая перекрывает маршрут туннеля. Если раньше домен указывал на прямой IP, а теперь должен идти через туннель, но старая A-запись не удалена, приоритет может достаться ей.

Пересоздайте маршрут командой, которая сама заводит корректную запись, указывающую на туннель, и проверьте в панели Cloudflare, что для домена нет конфликтующих записей:

cloudflared tunnel route dns my-tunnel app.example.com

Убедитесь, что запись для нужного поддомена ссылается именно на туннель, а не на старый адрес. После изменения DNS дайте немного времени на распространение. Чистота DNS-записей особенно важна при переезде сервиса со схемы с открытым IP на туннель — старые записи нужно убрать, иначе они будут перехватывать трафик.

Как быстро находить причину

Сведём отладку туннеля к понятному порядку. Сначала смотрим статус в панели Cloudflare и логи cloudflared на сервере: это отвечает, установлено ли исходящее соединение. Если туннель down — чиним сервис, исходящий трафик или учётные данные. Если туннель онлайн, а домен даёт 502 — проблема между агентом и локальным сервисом: проверяем, работает ли сервис и совпадают ли порт с протоколом в ingress. Если поведение не меняется после правок — убеждаемся, что правим тот самый конфиг и что DNS-запись ведёт на туннель.

Такой маршрут — статус, затем логи, затем локальный сервис, затем DNS — локализует почти любую проблему за несколько минут. И помните: туннель почти не нагружает сервер, поэтому если тормозит само приложение, дело в его ресурсах, а не в cloudflared. У MAATRIX сервер под туннель работает даже без белого IP, оплата идёт из России удобным способом, а нарастить конфигурацию под растущий сервис можно в любой момент.

Частые вопросы