Настройка обратного прокси Nginx: балансировка, SSL, WebSocket

Настройка Nginx reverse proxy: где ломается отклик

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

Типичная схема поломки выглядит так: в блоке upstream один адрес, без резервных узлов и без повтора запроса на соседний сервер при ошибке. Упал инстанс приложения — весь трафик уходит в ошибки, потому что переключаться некуда. Рядом — редиректы, собранные условными блоками внутри location, продублированные server-блоки, сертификаты, которые продлевают руками и однажды не продлевают. В логах это один всплеск пятисотых ответов на фоне падения доли успешных.

Настройка nginx reverse proxy начинается с того, что конфигурация перестаёт быть ручной: шаблоны вместо правок на живом узле, проверка синтаксиса до применения, плавная перезагрузка воркеров с таймаутом ожидания, чтобы начатые запросы доигрывались. Дальше — несколько серверов приложения за одним именем upstream, повтор на другой узел при ошибке, отдельная проверка живости, терминация TLS с автоматическим продлением сертификатов.

Длинные соединения и WebSocket идут отдельным маршрутом: свои таймауты простоя, отключённая буферизация, проброс заголовка Upgrade. Без этого чат и потоковые ответы отваливаются через минуту тишины, хотя обычные страницы при этом открываются нормально.

Разбираем, как это закрывается: от схемы маршрутизации и обработки отказов узла до автоматизации выката конфигурации.

Что даёт управляемый вход: скорость и устойчивость

Управляемый вход — единая точка, где решается, куда пойдёт запрос. Обратный прокси на nginx распределяет их по пулу приложений с учётом живости узлов: пока сервер отвечает в заданном пороге, он получает свою долю, при деградации выводится из ротации сам. Пик, который раньше укладывал сервис, теперь даёт рост времени отклика на доли секунды вместо ошибок доступа у части пользователей.

Падение отдельного узла перестаёт быть происшествием. Проверки состояния с настраиваемым интервалом замечают неответившего за секунды, недоступный экземпляр исключается, его запросы уходят на оставшиеся, а вернувшийся принимается в пул только после подтверждения готовности. Класс отказов «одна машина из пяти упала — половина страниц не открывается» уходит совсем.

Шифрование трафика закрывается на входе: сертификаты продлеваются автоматически, устаревшие протоколы отключаются, внутренние сервисы общаются внутри периметра без лишних затрат на криптографию. Уходит ручная работа с выпуском сертификатов и типовая авария «просрочили — сайт недоступен».

Эффект считается в цифрах: доля запросов, обслуженных без ручного вмешательства, приближается к единице, время отклика под пиком остаётся предсказуемым, а кэш статики и сжатие ответов снижают нагрузку на приложения. Ниже — как это собирается на практике.

Схемы балансировки: варианты, ограничения, нюансы

Один входной узел с Nginx — самая простая схема и одновременно самая хрупкая: плановое обновление конфигурации или перезапуск процесса останавливает весь внешний трафик, а вместе с ним терминацию шифрования и открытые сессии WebSocket. Пока узел один, любая правка входной конфигурации — это окно недоступности.

Выбор между схемами определяется тремя вопросами: хранит ли приложение состояние сессии, сколько входных точек готов держать контур и есть ли на периметре управляемый балансировщик.

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

Порядок внедрения: от аудита трафика до передачи

Порядок работ выстроен так, чтобы каждая следующая ступень опиралась на данные предыдущей, а не на предположения. Мы никогда не начинаем с правки конфигов: сначала нужно понять, какой трафик пойдёт через прокси и что именно ломается сейчас. Ниже — последовательность, по которой внедрение проходит предсказуемо, с сохранением возможности откатиться на любом шаге.

1. Аудит трафика. Снимаем карту: домены и поддомены, доли запросов по типам, длительность соединений, объём длительных WebSocket-сессий, пиковые окна. Отдельно фиксируем, где сейчас терминируется TLS и куда указывает DNS — это определяет схему переключения.
2. Проектирование схемы. Определяем точки терминации сертификатов, наборы серверов upstream, политику балансировки, таймауты для долгих соединений, порядок обработки заголовков. Согласуем схему с вашей командой до первой правки конфигурации.
3. Настройка в тестовом контуре. Собираем конфигурацию по блокам и проверяем синтаксис до применения. Поднимаем копию схемы на отдельном стенде, чтобы поймать ошибки без влияния на рабочие запросы.
4. Проверка под нагрузкой. Подаём профиль, близкий к боевому, включая WebSocket и медленные ответы приложения. Смотрим, как растёт задержка, держатся ли соединения при отказе одного сервера, сколько времени занимает переключение.
5. Переключение без простоя. Переносим трафик постепенно: сначала часть запросов, затем полный объём. Старая схема остаётся рабочей и готовой к возврату, пока новые метрики не подтвердят стабильность.
6. Передача в эксплуатацию. Отдаём конфигурации в репозитории, схему связей, политики обновления сертификатов, дашборды и правила алертов, инструкцию по откату. Проводим разбор с дежурной командой, чтобы типовые сбои закрывались без нас.

Конфигурации, схемы маршрутизации и политики доступа

Настройка обратного прокси не заканчивается рабочим конфигом на боевом узле. Мы передаём команде заказчика набор артефактов, по которым инфраструктуру можно воспроизвести, развивать и передать другому инженеру — без разбора «магии» прямо на сервере и без чтения истории переписки.

• Конфигурации в системе контроля версий — разбитые по смыслу: глобальные параметры, описания апстримов, отдельный блок на каждый домен. Изменения проходят ревью и сначала выкатываются на стенд.
• Схема маршрутизации — путь запроса от точки входа до конкретного сервиса: какие домены и пути куда проксируются, где терминируется TLS, при каких условиях трафик уходит на резервный апстрим.
• Политики доступа — ограничения по адресам и подсетям для административных зон, правила аутентификации, явное разделение публичных и внутренних маршрутов.
• Лимиты подключений и таймаутов — предельное число одновременных соединений на узел и на клиента, размеры буферов, время ожидания ответа апстрима, пороги защиты от всплесков трафика.
• Правила для WebSocket и длительных соединений — корректные заголовки переключения протокола, отдельный апстрим без буферизации, увеличенные таймауты для таких маршрутов.
• Регламент обслуживания — порядок продления сертификатов, ротации логов, перезагрузки конфигурации без разрыва активных соединений и отката на предыдущую версию.
• Карта мониторинга — какие метрики снимаются с прокси, какие значения считаются аварийными, куда уходят оповещения и кто их разбирает.

Каждый пункт проверяется на стенде до перевода трафика, поэтому после запуска у команды остаётся не настроенный сервер, а управляемая схема с понятными точками изменения.

Кейс: как убрали простой при выкладке релизов

До перестройки релиз выкладывали перезапуском единственного узла: каждая выкладка давала 4–6 минут полной недоступности, и окно под неё выбирали ночью, чтобы уложиться в минимум трафика. Отказ узла означал простой до прихода дежурного — восстановление занимало десятки минут и держало на связи всю команду.

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

Метрики до и после

Проверку доступности перенесли в прокси: узел не отвечает два цикла — трафик уходит на живые, а вернувшийся снова принимает нагрузку. Правила и сертификаты обновляем мягкой перезагрузкой, поэтому правки не обрывают активные соединения. Плановые работы на одном узле теперь проходят незаметно для пользователей, и релиз перестал быть событием, к которому готовятся заранее.

Чем отличается обратный прокси от балансировщика?

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

Обратный прокси отвечает за всё, что происходит до маршрутизации: терминирует TLS и продлевает сертификаты, подставляет заголовки Host и X-Forwarded-*, ограничивает размер тела и частоту запросов, сжимает ответы, кэширует статику, пропускает через себя Upgrade для WebSocket. Это управление входом, а не распределение.

Балансировка начинается там, где в конфигурации появляется upstream с несколькими серверами: алгоритм выбора (по кругу, по числу активных соединений, привязка по IP), проверки доступности, вывод упавшего узла из ротации, повтор запроса на соседний сервер, удержание сессии. Без этого списка слово «балансировка» ничего не значит — остаётся одно имя хоста.

В Nginx обе роли живут в одном конфиге: блок upstream подключается к server, и тот же узел, что терминировал TLS, начинает распределять трафик. Поэтому вопрос стоит не «прокси или балансировщик», а сколько у вас экземпляров приложения и нужна ли им общая точка входа.

Если экземпляр один, добавлять распределение бессмысленно — остаются TLS, WebSocket, лимиты и единое место для маршрутов. Если их несколько или нужен плавный выкат без простоя, туда же добавляются проверки, вывод узла из ротации и удержание сессии. Дальше разбираем, как это собирается под конкретную схему.

Сертификаты, длительные соединения и лимиты: сомнения

Перед запуском заказчики задают одни и те же вопросы: что будет, когда истечёт срок действия сертификата, выдержит ли прокси длительные соединения и не окажется ли служебный интерфейс открыт наружу. Ниже — короткие ответы, а детали закрываем на этапе проектирования конфигурации.

Как поведут себя веб-сокеты за обратным прокси?

Длительное соединение требует явных заголовков переключения протокола и увеличенного времени ожидания — иначе канал обрывается на молчании. Выносим веб-сокеты в отдельный блок маршрутизации и подбираем таймауты под реальный профиль трафика.

Что с ограничениями по числу одновременных подключений?

Считаем лимиты по числу одновременных клиентов и запасу на всплеск, а не «на глаз», и ограничиваем частоту запросов с одного адреса. При пиковой нагрузке очередь не растёт, а штатные пользователи не видят отказов.

Остаются ли открытыми служебные порты и панели управления?

Нет. Панель и метрики слушают только на локальном адресе, наружу смотрит единственный вход. Административные разделы закрыты списком разрешённых адресов и отдельной аутентификацией, остальное отсекает межсетевой экран.

Обсудим вашу схему и вернёмся с оценкой

Чтобы вернуться с оценкой и планом работ, а не с уточняющими вопросами, нам хватает нескольких входных данных по текущей схеме. Ниже — то, что чаще всего снимает неопределённость в проектах, где nginx уже стоит перед приложением или только планируется как точка входа.

• Список доменов и поддоменов, которые пойдут через прокси, и где сейчас терминируется TLS: на самом nginx, на балансировщике выше или внутри приложения.
• Пул бэкендов: адреса и порты сервисов, их количество и предпочтительный способ распределения нагрузки — по кругу, по числу активных соединений, с привязкой клиента к серверу.
• Требования к длинным соединениям: нужны ли WebSocket, стриминг ответа, события, и какой разрыв связи считается недопустимым.
• Схема отказоустойчивости: один узел, пара с плавающим адресом или несколько за внешним балансировщиком; нужен ли плавный перезапуск конфигурации без обрыва активных запросов.
• Сертификаты и порядок их выпуска: внешний или внутренний центр, автообновление, один общий или отдельный на каждый домен.
• Наблюдаемость: куда пишутся логи доступа и ошибок, какие метрики снимаются, есть ли сборщик логов и на какие пороги настроены оповещения.
• Ограничения и доступы: разрешённые сети, ограничение частоты запросов, защита от всплесков, кто выдаёт доступы к серверам и меняет конфигурацию.

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

Опишите задачу и приложите текущие конфигурации со схемой сети, если они есть, — обсудим их и вернёмся с оценкой и планом.