Когда на одном сервере работают несколько приложений, каждому необязательно выделять публичный порт. Reverse proxy принимает HTTP-запросы на 80/443, выбирает локальный сервис по имени домена и передаёт запрос ему. Это упрощает HTTPS, маршрутизацию и контроль доступа.
Как устроен путь запроса
Представим сервер с двумя внутренними приложениями: панелью мониторинга на 127.0.0.1:3000 и заметками на 127.0.0.1:8080. В DNS оба домена указывают на один публичный IP. Reverse proxy на входе читает имя хоста и направляет запрос нужному приложению.
Клиент -> HTTPS:443 -> reverse proxy
|-> notes.example.com -> 127.0.0.1:8080
`-> stats.example.com -> 127.0.0.1:3000
Внутренние приложения при этом не обязаны слушать внешний сетевой интерфейс. Локальный порт важен только самому серверу.
Минимальный пример с Caddy
Если Caddy уже установлен, конфигурация простого сайта может выглядеть так:
notes.example.com {
reverse_proxy 127.0.0.1:8080
}
При правильно настроенном DNS, доступном TCP 80/443 и рабочем ACME Caddy может получать и продлевать сертификат автоматически. Не открывайте внутренний порт в публичном firewall только ради reverse proxy.
Заголовки и реальный адрес клиента
Приложения иногда хотят знать исходный протокол и IP. Обычные HTTP reverse proxy передают подходящие forwarding-заголовки. Доверять X-Forwarded-For без ограничения доверенных прокси нельзя: прямой клиент может его подделать. В приложении настройте список доверенных прокси, а прямое обращение к его порту запретите.
Чек-лист перед публикацией
- Проверить, что backend слушает
127.0.0.1, а не0.0.0.0, если удалённый доступ ему не нужен. - Проверить DNS и сертификат именно для нужного имени хоста.
- Убедиться, что reverse proxy не выдаёт админку без аутентификации.
- Проверить WebSocket и длительные запросы, если их использует приложение.
- Сохранить конфигурацию и продумать восстановление после переустановки.
Главное правило: наружу открывается только необходимая точка входа. Внутренние порты остаются внутренними.