# 🦎 Туннели стали высокодоступными

15 октября 2026 г. · 9 мин. чтения

![Анимация: один из трёх дата-центров горит, а запросы посетителей идут через два оставшихся по туннелю в home lab, и сайт продолжает работать](/blog/img/2026-10-15-high-availability/cover.svg)

Два года Tuna работала на той конфигурации, с которой стартовала. Адрес туннеля вёл прямо на конкретный сервер, и этот сервер делал всё сразу: принимал трафик из интернета, держал подключения клиентов и передавал одно в другое. Для запуска это было разумно. Но Tuna выросла. Сегодня у нас одновременно онлайн больше тысячи туннелей, а туннельные ноды принимают десятки тысяч подключений в сутки. Для такого сервиса схема «всё на одном сервере» уже не годилась. Стоило серверу уйти на перезагрузку или потерять сеть, и все туннели на нём лежали вместе с ним.

14 октября мы закончили переезд, который готовили с лета, и **туннели наших пользователей стали по-настоящему высокодоступными**. Без преувеличения, это самое большое изменение в инфраструктуре Tuna с момента запуска. Ни один сервер и ни один дата-центр больше не является единственной точкой отказа. Делать для этого ничего не нужно. Адреса и сертификаты переехали сами.

Коротко

* Точка, где трафик входит в Tuna, и нода, к которой подключён клиент, теперь разные серверы. Отказ любого из них не роняет туннели.
* Точки входа и туннельные ноды стоят в нескольких дата-центрах двух провайдеров в России, Германии и Нидерландах.
* Запрос попадает на ближайшую к отправителю точку входа, а не туда, куда подключён клиент. Поэтому вебхуки от Telegram доходят до туннеля, где бы ни работал клиент.
* Для новых имён, портов и доменов регион больше не нужно выбирать.
* Высокая доступность работает для HTTP- и TCP-туннелей, для поддоменов в новых зонах и для собственных доменов, подключённых через CNAME.

## Как было

В первой версии архитектуры было два региона, `ru` и `nl`. Имя туннеля в DNS указывало прямо на IP туннельной ноды. На ней же работал фронтенд на [Traefik](https://traefik.io/traefik), который принимал запросы из интернета и отдавал их в туннель.

![Анимация старой схемы: CLI получает адрес сервера у API и поднимает туннель до tuna-node; запросы посетителей идут через Traefik на том же сервере; при отказе сервера недоступны все туннели](/blog/img/2026-10-15-high-availability/before.svg)

Раньше Traefik и tuna-node жили на одном сервере. Если он падал, туннели на нём становились недоступны.

У такой схемы три слабых места, и все три мы ощущали на себе:

* **Отказ сервера бил по всем его клиентам.** Обновление ядра, сбой у провайдера или проблемы в дата-центре делали недоступными все туннели на ноде, пока она не вернётся.
* **Регион приходилось выбирать.** Вход трафика и подключение клиента были жёстко связаны: туннель в регионе `ru` принимал трафик только через российский сервер.
* **Доступность зависела от маршрута до одного сервера.** Если путь от отправителя до ноды ломался, туннель становился для него недоступен. Так весной [вебхуки от Telegram](https://tuna.am/blog/tunnel-location.md) перестали доходить до туннелей в регионе `ru`. Обойти это можно было только одним путём: переключить туннель в другой регион и поменять адрес вебхука.

## Почему именно сейчас

Слабые места старой схемы мы понимали давно, но по-настоящему ощутили их летом. В июне и июле в дата-центре в Нидерландах, где стояла наша нода региона `nl`, несколько раз случались крупные аварии. Нода была недоступна по несколько дней, и вместе с ней лежали сайты всех клиентов, чьи туннели работали через неё. Перенести туннели на другой сервер технически было можно, но проблему это решало лишь частично. Туннели на наших поддоменах переехали бы сразу. А больше половины туннелей на этой ноде работали на собственных доменах вида `example.com`, подключённых через A-запись. У нового сервера был бы новый IP-адрес, и каждому такому клиенту пришлось бы менять DNS у себя. Скорее всего, это заняло бы больше времени, чем восстановление дата-центра, поэтому разумнее было ждать.

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

А потом, с 8 по 11 октября, беспилотники повредили три дата-центра Яндекса, и работу площадки во Владимире [пришлось полностью остановить](https://www.kommersant.ru/doc/9023925). Вместе с сервисами Яндекса легли сайты компаний, которые жили в его облаке. Стало понятно, что откладывать больше нельзя, тем более что решение к тому моменту было уже хорошо проверено. Переключение 14 октября заняло почти целый день и закончилось ночью, а туннели за всё это время были недоступны около пяти минут.

## Как стало

Мы разделили сервис на два слоя, и каждый из них теперь живёт на своих серверах.

**Точки входа** принимают трафик из интернета и терминируют TLS. Вместо Traefik здесь теперь [Envoy](https://www.envoyproxy.io/). Точки входа собраны в российскую и европейскую группы. DNS отправляет запросы из России в российскую группу, а из остальных стран в европейскую и внутри группы выбирает ближайшую исправную точку.

**Туннельные ноды** держат подключения клиентов. Их тоже несколько, они стоят в России и Европе. Клиента сервер подключает к ноде поближе к нему и с учётом загрузки, а точки входа знают, где сейчас находится каждый туннель, и доставляют запрос туда.

![Анимация новой схемы: точки входа RU и EU отдельно от туннельных нод; запрос из России и вебхук Telegram входят через разные точки входа и приходят на ноду с туннелем; при отказе ноды CLI переподключается к соседней, при отказе точки входа трафик уходит на соседнюю](/blog/img/2026-10-15-high-availability/after.svg)

Теперь точки входа отделены от нод, и отказ любой из них означает переподключение за секунды, а не простой.

Что это даёт на практике:

* **Отказ точки входа почти незаметен.** DNS исключает неработающую точку, и трафик уходит на соседнюю за несколько секунд.
* **Отказ туннельной ноды больше не означает простой.** Клиент сам переходит на другую ноду, адрес туннеля при этом не меняется. Обычно на это уходят секунды, а при массовом переезде сотен туннелей до минуты.
* **Где работает клиент, больше не важно.** Вебхук от Telegram попадает на ближайшую к Telegram точку входа, а оттуда на ноду, к которой подключён ваш клиент, хоть в России, хоть за её пределами. Проблема из весеннего поста решена архитектурой, а не обходным путём.

## Регионы больше не нужно выбирать

Раз вход трафика не привязан к ноде подключения, выбор региона потерял смысл. Случайные и закреплённые имена теперь выдаются в зоне `a.2na.am`, TCP-адреса выглядят как `a.2na.am:<порт>`. Бесплатный постоянный поддомен теперь один, в зоне `a.tuna.free`, а не пара в `ru` и `nl`. Регион для новых адресов выбирать не нужно, в личном кабинете этого выбора больше нет.

Старые адреса в `ru.tuna.am` и `nl.tuna.am` продолжают работать и теперь тоже идут через новые точки входа. Флаг `--location` и переменная `TUNA_LOCATION` теперь нужны только для них и указывают, в какой из старых зон искать закреплённое имя или порт. На новые зоны они не влияют.

## Где работает высокая доступность

* **Поддомены в зонах `a.2na.am` и `a.tuna.free`** и TCP-порты, в том числе SSH, Postgres и Redis поверх TCP. WebSocket, HTTP/2 и SSE мы тоже проверили.
* **Старые адреса в зонах `ru.tuna.am` и `nl.tuna.am`**, включая TCP-порты. Сами эти зоны теперь указывают на `a.2na.am` через CNAME.
* **Собственные поддомены** вроде `app.example.com` или `www.example.com`, подключённые через CNAME на `a.2na.am` или на старые зоны `ru.tuna.am` и `nl.tuna.am`. Так же это устроено у ngrok и Cloudflare Tunnel. CNAME указывает на инфраструктуру целиком, а не на конкретный сервер.
* **Собственная зона команды**, подключённая через CNAME `*.<зона>` на `a.2na.am`, `ru.tuna.am` или `nl.tuna.am`.

Если ваш домен или зона уже подключены через CNAME на `ru.tuna.am` или `nl.tuna.am`, менять ничего не нужно.

## Где высокой доступности нет

Высокой доступности нет у доменов, подключённых через A-запись, потому что она указывает на конкретные адреса. Поддомен для этого достаточно перевести на CNAME. А корневой домен вроде `example.com`, то есть сам домен без `www` и других поддоменов, так не перевести, потому что CNAME на него по стандарту DNS не поставить. Такой домен работает, но полной отказоустойчивости у него нет, и личный кабинет об этом предупреждает.

Мы рекомендуем перенести сайт на поддомен с CNAME: лендинг на `www.example.com`, личный кабинет или веб-приложение на `app.example.com` или `my.example.com`. С корневого домена настройте постоянный редирект с кодом 301 или 308 через [шлюз](https://tuna.am/docs/gateways.md) с действием [`redirect`](https://tuna.am/docs/traffic-policy.md#redirect). Сам редирект останется без отказоустойчивости, но сайт за ним будет отказоустойчивым. Браузеры запоминают постоянный редирект, поэтому посетители, которые уже заходили на сайт, дальше идут сразу на поддомен.

## Что ещё ушло в прошлое

Минимальная конфигурация копила проблемы два года, и переезд закрыл многие из них разом:

* падение одного сервера больше не роняет туннели всех его клиентов;
* вебхуки от Telegram доходят до туннелей независимо от того, где работает клиент;
* собственный домен через CNAME больше не привязан к одному IP;
* если проверка DNS для своего домена не прошла, личный кабинет сразу называет причину, например чужой адрес, лишнюю запись AAAA или отсутствие записи, а не молчит до следующих суток;
* регион не нужно выбирать, а бесплатный поддомен один вместо двух.

## Теперь можно держать сервер дома

История с дата-центром Яндекса хорошо напоминает, что любой дата-центр может однажды исчезнуть целиком и без предупреждения. Если ваш проект доступен из интернета через сервис, который живёт на одном сервере в одном дата-центре, доступность проекта ровно такая же, как у этого сервера.

У Tuna так больше не получится. Точки входа и туннельные ноды разнесены по разным дата-центрам и странам, и потеря одного из них не остановит трафик наших пользователей.

Поэтому, если у вас не высоконагруженный проект и вы давно хотели держать его дома в home lab, на мини-ПК или старом ноутбуке, сейчас для этого хорошее время. Со стороны Tuna ваш сайт будет доступен. От настоящей высокой доступности вас отделяют только электричество дома и интернет-провайдер, а они от нас не зависят. От перебоев с электричеством спасает ИБП, а от проблем у провайдера резервный канал.

## Что нужно сделать вам

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

* **Обновите клиент** до свежей версии. Версии старше 0.28 не замечают зависшую ноду и ждут её возвращения вместо того, чтобы переподключиться. В версии 0.35.0 есть ошибка, которая мешает переподключению.
* **Переведите свой домен с A-записи на CNAME** `a.2na.am`. Старые A-записи продолжают работать, но отказоустойчивость даёт только CNAME. Что делать с доменом вроде `example.com`, мы описали [выше](#%D0%B3%D0%B4%D0%B5-%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%BE%D0%B9-%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%BD%D0%B5%D1%82).
* **Обновите списки разрешённых IP**, если вы прописывали у себя адрес ноды или туннеля. У TCP-адреса теперь несколько IP.

Если что-то работает не так, как вы ожидаете, напишите нам в [Telegram-сообщество](https://telegram.me/+Kgbtt0_gJwI5ZmEy) или на <info@tuna.am>.

## Оставьте отзыв

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста [оставьте отзыв](https://my.tuna.am/?show_feedback=1).

![](/blog/img/2024-08-22/feedback.gif)

## Новости

Анонсы новых функций и статей публикуем в [Telegram-канале](https://t.me/tuna_am). Подписывайтесь, чтобы ничего не пропустить.

## Помощь

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

* [Электронная почта](mailto:info@tuna.am)
* [Telegram сообщество](https://telegram.me/+Kgbtt0_gJwI5ZmEy)

**Теги:**

* [release](https://tuna.am/blog/tags/release)
* [tuna](https://tuna.am/blog/tags/tuna)