Сервис работает на домашней машине или на арендованной коробке без публичного адреса. Открыть его снаружи нечем: провайдер держит вас за общим адресом, порты не пробросить, белый адрес стоит денег и не везде выдаётся.
Стандартный ответ — туннель: программа на вашей машине сама устанавливает исходящее соединение с чужой инфраструктурой, и та отдаёт вам публичный адрес. Ответ правильный. Неправильна только та часть, где предполагается, что любой туннель подойдёт.
Ниже — сравнение по итогам практического перебора, включая варианты, которые не заработали. Факты о сторонних сервисах проверялись 26.08.2026 и относятся к конкретной сети конкретного сервера; проверьте актуальность и обязательно проверьте у себя — половина различий проявляется только в вашей сети.
#Что вообще сравниваем
Все туннели устроены одинаково по схеме и по-разному в деталях, которые и решают.
- Cloudflare Tunnel — агент на машине держит соединение с сетью доставки контента, публикация идёт через ваш домен, делегированный этому провайдеру.
- devtunnel (инструмент Microsoft для разработки) — агент публикует локальный порт по выданному адресу, аутентификация через учётную запись.
- Tailscale Funnel — надстройка над частной сетью на базе современного протокола: сначала все ваши устройства объединяются в собственную сеть, затем один порт публикуется наружу.
- Быстрые SSH-туннели вроде сервисов, публикующих локальный порт одной командой, — самый простой класс, ставится за секунды.
#Что туннели делают хорошо
Прежде чем говорить об ограничениях, стоит назвать то, ради чего их берут, — и это серьёзные вещи.
Работают там, где ничего другого нет. За NAT провайдера, без публичного адреса, без доступа к настройкам маршрутизатора. Соединение исходящее, поэтому входящие правила никого не волнуют.
Не публикуют ваш адрес. Наружу торчит инфраструктура провайдера туннеля. Для домашней машины это существенный плюс: адрес квартиры не попадает в публичные списки и не собирает фоновое сканирование.
Дают HTTPS без вашего участия. Сертификат выпускает и продлевает провайдер туннеля. Целый класс задач с продлением сертификата, которое ломается на третий месяц, просто не возникает.
Ставятся за минуты. Реально за минуты, а не «за минуты, если у вас уже всё настроено».
#Ключевые различия — и где мы упёрлись
Исходящий порт. Это первое, обо что можно споткнуться, и способ споткнуться самый неприятный: молча. Cloudflare Tunnel в своей основной схеме использует исходящий 7844, и на нашем арендованном сервере он оказался закрыт на сетевом уровне. Не медленно, не с ошибкой — просто нет соединения. Варианты, работающие поверх 443, проходили без проблем. Вывод, годящийся для любого выбора: сначала проверьте, какой исходящий порт нужен решению, и проходит ли он у вас, а уже потом читайте про его возможности.
Стабильность адреса. У devtunnel адрес меняется при пересоздании туннеля. Для отладки это неважно, для сервиса, ссылку на который вы кому-то дали, — это постоянный источник поддержки. Плюс сами туннели периодически отваливаются и требуют поднятия заново.
Долговечность решения. Tailscale Funnel по документации выглядел как замена: работа поверх 443, стабильное имя, служба в системе. На бумаге все ограничения снимались. На практике постоянным решением в этой конфигурации он не стал, и вместе с быстрыми SSH-туннелями остался в списке перепробованного. Рабочая связка на момент написания — devtunnel: отдельный туннель для языковой модели на домашней машине и отдельный для сайта на сервере. Это не рекомендация «берите devtunnel», это описание того, что выжило в конкретной сети.
Чей домен. Часть решений публикует вас на своём домене, часть позволяет привязать ваш. Разница не косметическая: на чужом домене вы не управляете именем, не можете переехать, не забрав ссылку, и не ставите свои записи — про которые в гайде про настройку DNS без боли.
Кто видит трафик. Туннель терминирует TLS на своей стороне, чтобы отдать вам HTTP. Это означает, что провайдер туннеля технически видит содержимое запросов. Для личного ассистента, через который проходит переписка и рабочие документы, это существенно — и это ровно тот пункт, который в рекламных материалах не обсуждается.
#Таблица
| Критерий | Cloudflare | devtunnel | Tailscale Funnel | Быстрые SSH-туннели |
|---|---|---|---|---|
| Стабильное имя | ✓ со своим доменом | ✗ меняется | ✓ | ✗ |
| Свой домен | ✓ | ✗ | ✗ | ✗ |
| Работает поверх 443 | зависит от режима | ✓ | ✓ | ✓ |
| Служба в системе | ✓ | настраивается | ✓ | ✗ |
| Провайдер видит трафик | да | да | да | да |
| Подходит для постоянной публикации | ✓ | ✗ | ✓ | ✗ |
Смотреть в этой таблице надо не на количество галочек, а на две строки: «работает поверх 443» и «стабильное имя». Первая определяет, заработает ли решение у вас вообще. Вторая — можно ли будет кому-то дать ссылку.
#Где туннель объективно лучше своего домена и белого адреса
Это раздел, который обычно пропускают, а он важнее остальных.
Туннель не публикует ваш сервер. Сервис с белым адресом получает фоновое сканирование с первого дня. Через туннель ваша машина остаётся невидимой: наружу смотрит чужая инфраструктура, а ваши порты закрыты.
Туннель снимает с вас сертификаты целиком. Ни выдачи, ни продления, ни истории с забытым перезапуском сервера. На горизонте года это заметная экономия внимания.
Туннель дешевле. Аренда белого адреса и домена стоит денег ежемесячно; базовые режимы туннелей для личного использования обычно бесплатны — но проверяйте условия, они меняются.
Туннель обратим. Не подошёл — снесли, ничего не осталось. Смена схемы публикации после того, как домен разошёлся по ссылкам, стоит гораздо дороже.
Иными словами: если сервисом пользуетесь только вы и пара близких, туннель — не «временное решение», а вполне достаточная архитектура, и переходить на домен незачем.
#Кому что подойдёт
- Пользуетесь только вы, доступ нужен с телефона → любой туннель, поверх 443, и не думайте об этом больше.
- Сервисом пользуется кто-то ещё, ссылка должна жить → решение со стабильным именем, лучше со своим доменом; при первой возможности — свой домен и обратный прокси, а туннель как запасной путь.
- Через сервис ходит чувствительная переписка → либо доступ только внутри своей частной сети без публикации наружу, либо своя публикация со своим сертификатом. Туннель с терминацией на чужой стороне здесь — осознанный компромисс, а не нейтральный выбор.
- Нужен доступ к домашней машине с языковой моделью → это отдельная задача: публиковать наружу интерфейс модели опаснее, чем интерфейс приложения, потому что у него обычно нет аутентификации. Как настроить это правильно, разобрано в статье про Ollama по сети.
#Когда туннель не подходит вовсе
Три случая, в которых надо честно останавливаться.
- Требуется гарантированная доступность. Туннель добавляет ещё одного участника, который может лежать, менять условия или закрыться. Вы не управляете этим и не узнаёте заранее.
- Трафик не должен видеть третья сторона. См. выше про терминацию TLS.
- Нужен произвольный протокол на произвольном порту. Большинство публикующих туннелей рассчитаны на HTTP; всё остальное либо не поддерживается, либо требует другого режима.
#Частые вопросы
#Насколько туннель замедляет ответы?
Добавляется путь до узла провайдера и обратно, то есть задержка растёт на величину, которая зависит от географии — от единиц до десятков миллисекунд в типовом случае. Для чата с языковой моделью это несущественно на фоне времени генерации. Померить у себя проще, чем угадать: сравните время ответа напрямую по локальному адресу и через туннель.
#Что делать, если туннель постоянно отваливается?
Сначала выяснить, отваливается ли соединение или падает агент. Первое лечится службой с автоперезапуском, второе — сменой решения. И то и другое должно попадать в проверки: туннель, который лёг ночью, ничем не отличается от лежащего сервиса.
#Можно ли привязать свой домен к туннелю?
Зависит от решения: часть провайдеров это поддерживает, часть публикует только на своём имени. Проверяйте до того, как раздадите ссылку — переезд с чужого имени на своё означает, что все старые ссылки перестанут работать.
#Безопасно ли публиковать личный сервис через туннель?
Туннель закрывает вопрос сетевого доступа, но не заменяет аутентификацию: публичный адрес есть публичный адрес, и по нему придут. Аутентификация, ограничение частоты запросов и внимание к тому, какие маршруты доступны без входа, нужны ровно так же, как при обычной публикации, — и они входят в общий список того, о чём при самостоятельном хостинге приходится думать самому. Честный перечень — в статье про риски самостоятельного хостинга.
#Стоит ли из-за туннелей отказываться от домашнего сервера?
Наоборот: туннель — главный аргумент за домашний сервер, потому что снимает вопрос публикации. Другие статьи расходов при этом остаются — электричество, шум, канал, ваше время; полный счёт с горизонтом в три года — в статье про домашний сервер под ИИ.
#Вывод
Если сервис нужен вам одному и вы готовы к тому, что раз в месяц он окажется недоступен, — берите любой туннель, работающий поверх 443, и не тратьте на это больше времени. Если сервисом пользуется кто-то ещё, ссылка должна жить и вы не хотите зависеть от чужих условий — планируйте свой домен, а туннель держите запасным путём.
И одно правило, которое стоит дороже любого сравнения: проверьте исходящий порт, который нужен решению, прежде чем читать про его достоинства. Мы потеряли на этом день, и потерять его можно ровно один раз.