Как открыть локальный сайт из интернета, если ngrok не работает
Если вы разрабатываете веб-сервисы в России, то наверняка сталкивались с задачей: локально всё работает, а теперь нужно быстро показать результат снаружи.
Например:
- отправить клиенту ссылку на демо;
- принять webhook от Telegram-бота, CRM или платёжки;
- проверить callback от внешнего API;
- дать коллеге доступ к локальной сборке;
- временно открыть доступ к панели умного дома.
Раньше для этого многие просто запускали ngrok и получали публичный адрес за минуту. Но сейчас для пользователей с российскими IP этот сценарий на практике не работает из-за санкционных ограничений США.
Поэтому если вам нужен не очередной DevOps-квест, а просто рабочий способ открыть localhost в интернет, нужен другой инструмент.
В этой статье покажу простой вариант на примере tunyl.
Когда вообще нужен публичный доступ к localhost
Это одна из тех задач, которая появляется постоянно, но каждый раз не вовремя.
Вот типичные сценарии:
- вы делаете сайт или админку и хотите быстро показать промежуточный результат клиенту;
- вы настраиваете Telegram-бота, и ему нужен публичный webhook URL;
- вы тестируете интеграцию с платёжной системой, CRM или внешним API, который шлёт callback;
- вы разрабатываете интерфейс умного дома и хотите открыть доступ к локальной панели;
- вам нужно, чтобы QA, дизайнер или коллега посмотрел локальную версию без деплоя.
Во всех этих случаях цель обычно одна: не «развернуть инфраструктуру», а быстро открыть доступ к локальному сервису наружу.
Почему не хочется решать это через VPS, reverse proxy и проброс портов
Технически, конечно, можно:
- поднять VPS;
- развернуть nginx;
- настроить прокси;
- пробросить порты на роутере;
- собрать VPN-схему;
- временно деплоить каждый черновик на отдельный сервер.
Но для большинства задач это перебор.
Если вам нужно на 20 минут показать клиенту лендинг, принять пару webhook-запросов или проверить сценарий интеграции, вы не хотите тратить на это вечер. Нужен короткий путь: локально подняли сервис, выполнили одну команду, получили публичную ссылку.
Что я использую вместо ngrok
Для этой задачи я использую tunyl — сервис для публикации локальных веб-приложений в интернет через публичный домен.
Идея простая:
- у вас уже есть приложение, запущенное локально на каком-то порту;
- tunyl поднимает туннель;
- вы получаете внешний URL;
- весь входящий HTTP-трафик проксируется в ваше локальное приложение.
То есть вместо «поднять сервер ради теста» получается сценарий «открыть локальный порт наружу за минуту».
Быстрый старт
Допустим, у вас локально работает приложение на 3000 порту.
Например, это может быть любой dev-сервер:
или простой тестовый сервер:
Теперь открываем доступ извне (требуется установленный NodeJS на ПК):
После запуска сервис выдаст публичный адрес, через который ваш локальный сайт станет доступен из интернета.
Сценарий дальше максимально простой:
- запускаете локальный проект;
- выполняете одну команду;
- получаете ссылку;
- отправляете её тому, кому нужен доступ.
Пример 1. Показать клиенту локальный сайт
Это, пожалуй, самый частый кейс.
У вас есть почти готовый лендинг, личный кабинет или админка. Вы не хотите выкатывать промежуточную версию на прод или на staging только ради одного показа. Но и фразы «смотрите, у меня всё локально работает» обычно никого не вдохновляют.
Что делаем:
После этого отдаёте клиенту публичную ссылку.
Плюс такого сценария в том, что вы показываете реальный живой интерфейс, а не скриншоты и не запись экрана. Клиент может сам покликать страницы, проверить формы и понять, как всё выглядит в браузере.
Пример 2. Проверить webhook от внешнего сервиса
Вторая очень частая боль: нужно принять webhook, а ваш обработчик работает локально.
Например, локальный сервер слушает POST /webhook:
Дальше в настройках внешнего сервиса указываете публичный URL вида:
И webhook начинает прилетать прямо в локальное приложение.
Так удобно тестировать:
- Telegram-ботов;
- платёжные уведомления;
- callback-и от CRM;
- интеграции с внешними API;
- любые события, которые приходят только на публичный URL.
Чем такой подход удобнее обычных обходных путей
По сути, у такого инструмента есть несколько сильных сторон:
- не нужен белый IP;
- не нужно поднимать VPS;
- не нужно вручную настраивать nginx и прокси;
- не нужно пробрасывать порты на роутере;
- можно быстро открыть доступ даже для разового сценария;
- вход максимально низкий: локальный сервис + одна команда.
Для разработчика это означает простую вещь: задача перестаёт быть инфраструктурной и снова становится прикладной.
Что важно учитывать
Такой подход лучше всего подходит для:
- разработки;
- демонстрации;
- проверки интеграций;
- webhook-сценариев;
- временного удалённого доступа.
Такой подход особенно удобен для разработки, демонстрации, webhook-сценариев, тестирования интеграций и других задач, где нужен быстрый внешний доступ к локальному сервису. В этих случаях он позволяет не отвлекаться на лишнюю инфраструктурную настройку и сразу перейти к делу.