Введение: Зачем нужны собственные HTTP-туннели?

Знакомая ситуация: вы только что набросали фичу на localhost:3000, и её срочно нужно показать дизайнеру, сидящему в другом часовом поясе, или привязать боевой вебхук от Stripe к локальному окружению (ведь на вашей машине всё работает идеально, правда?). Первая мысль — потянуться за Ngrok или аналогами. Но через пять минут выясняется, что бесплатный лимит исчерпан, сессия норовит отвалиться в самый ответственный момент, а весь ваш приватный трафик улетает через чужие прокси. Зачем отдавать контроль над данными третьим лицам, если под рукой есть собственный VPS?

Что делать, если у вас есть собственный виртуальный сервер (VPS) с белым IP-адресом и вы хотите построить аналогичный инструмент под вашим полным контролем? Ответ прост: использовать связку стандартного SSH-сервера и обратного прокси Nginx. Это решение не требует установки тяжелого софта на клиентскую машину, задействует уже имеющиеся в любой Unix-подобной системе механизмы и обеспечивает максимальную безопасность за счет использования привычных SSH-ключей.

Согласно статистике инфраструктурных опросов, более 65% разработчиков сталкиваются с необходимостью проброса локальных портов еженедельно. Настроив собственный туннель, вы получаете полный контроль над каждым байтом входящего и исходящего трафика, можете мониторить логи в реальном времени и не зависеть от лимитов сторонних SaaS-сервисов.

Архитектура решения: Как работает связка SSH и Nginx

Прежде чем прописывать первые конфигурации, давайте разберем анатомию этого процесса на простом жизненном примере. (Конфигурировать туннели — это вообще как собирать IKEA: по инструкции всё просто, но в конце почему-то остаются лишние детали в виде упавших соединений). Представьте, что ваш VPS — это швейцар на ресепшене отеля, который принимает все входящие курьерские доставки (запросы из интернета), а ваш рабочий ноутбук — номер в этом отеле, куда швейцар перенаправляет посылки по внутреннему телефону. Сама архитектура состоит из трех основных компонентов:

  • Локальная машина (клиент): Ваш рабочий ноутбук или десктоп, где запущено приложение на определенном порту.
  • Удаленный сервер (VPS): Сервер в интернете с публичным IP-адресом, на котором установлены SSH-сервер и веб-сервер Nginx.
  • Конечный пользователь: Браузер или внешний API, отправляющий запрос на ваш VPS.

Традиционный SSH-туннель с флагом -R позволяет открыть порт на удаленном сервере и перенаправить входящий на него трафик на локальную машину. Однако в чистом виде это дает лишь сырое TCP-соединение. Чтобы превратить его в полноценный HTTP-туннель с поддержкой виртуальных хостов, SSL-сертификатов (Let's Encrypt) и красивых URL, нам понадобится Nginx в качестве Reverse Proxy.

Пошаговая настройка сервера и клиента

1. Настройка SSH-сервера на VPS

Убедитесь, что ваш SSH-сервер на удаленном VPS разрешает удаленное перенаправление портов. Откройте конфигурационный файл /etc/ssh/sshd_config и проверьте наличие (или раскомментируйте) следующую директиву:

GatewayPorts yes

После изменения файла перезапустите службу SSH:

sudo systemctl restart sshd

2. Создание обратного туннеля с локальной машины

Теперь, когда швейцар на сервере готов принимать звонки, соединим его с нашей комнатой. Для проброса порта с локального сервера (например, порт 3000) на удаленный VPS (пусть это будет порт 8080), выполните следующую команду в терминале рабочей машины:

ssh -N -R 8080:localhost:3000 user@your-vps-ip

Флаг -N указывает SSH не выполнять удаленных команд (только перенаправление портов), а -R связывает порт 8080 на VPS с вашим локальным портом 3000.

3. Настройка Nginx в качестве Reverse Proxy

Остался финальный штрих: научить Nginx заворачивать красивый веб-трафик из внешней сети в наш свежепостроенный технический коридор. Настроим его на VPS, чтобы он принимал запросы на доменное имя (например, tu