Пару лет назад я помогал знакомому поднимать инфраструктуру для небольшого маркетплейса. Сорок с лишним сервисов, у каждого свой порт, и все торчат в интернет. Бухгалтерия, склад, личный кабинет, API для партнёров. Когда он показал список открытых портов, я выдохнул и сказал: «Ставим обратный прокси, иначе поседеешь раньше, чем вырастет трафик».
Через неделю у него был один вход, один сертификат и внятные логи. И он перестал бояться, что кто-то дёрнет напрямую внутренний сервис, которому в интернете делать нечего. Дальше - как эта штука устроена и где она ломается.
Обратный прокси стоит на входе, а прямой - на выходе
Прямой прокси вы, скорее всего, представляете. Сидите в кафе, включаете прокси в настройках телефона, и трафик идёт наружу через чужой сервер. Клиент решает, куда идти, прокси его слушается.
С обратным всё наоборот. Клиент не знает, что перед ним прокси. Он стучится на домен, а DNS указывает не на сервер приложения, а на адрес входного узла. Узел сам решает, куда отправить запрос. Внутренняя кухня остаётся внутри.
Разница в модели доверия. Прямой прокси защищает клиента от внешнего мира. Обратный защищает инфраструктуру от клиентов.
Когда у вас десятки серверов с доступом к конфиденциальным данным, давать каждому прямой выход в интернет опасно. Хватит одной дыры, и вы прощаетесь с данными. Поэтому на вход ставят один или несколько прокси-серверов, на них настраивают защиту, а бэкенды прячут за ними.
Запрос проходит пять шагов, и на каждом можно всё сломать
Разберём путь обычного запроса. Пользователь вводит адрес в браузере. DNS отдаёт IP-адрес прокси. Браузер устанавливает TCP-соединение. Дальше TLS-рукопожатие, и вот первый важный момент: сертификат может жить на прокси, а не на каждом бэкенде.
После расшифровки прокси смотрит на HTTP-запрос. Метод, путь, заголовки, cookie, тело. Здесь можно принять кучу решений: отправить запрос на конкретный сервис, отдать из кэша, отклонить по лимиту, добавить служебные заголовки вроде X-Forwarded-For и X-Real-IP.
Потом прокси открывает соединение с внутренним сервером, передаёт запрос, получает ответ и возвращает клиенту. Звучит просто, пока не начинаешь считать нюансы. Таймауты, keepalive, размер буферов, обработка ошибок upstream, повторные попытки. Каждый пункт даёт странное поведение, которое вы будете искать неделю.
В практике я видел, как прокси отдавал 502, потому что внутренний сервис отвечал дольше дефолтного таймаута. Пользователи видели ошибку, а в логах приложения было пусто. Запрос до приложения доходил, но ответ уже никто не ждал.
Маршрутизация на седьмом уровне решает то, что балансировщик не умеет
На обратном прокси настраивают логику, недоступную простому сетевому балансировщику. Отправить все запросы с путём /api на один пул серверов, а /images на другой. Посмотреть на заголовок Host и развести два сайта по разным бэкендам на одном IP.
С сессиями интереснее. Пользователь авторизовался на одном сервере, и следующая страница должна открыться там же. Иначе корзина опустеет, а форма уйдёт в никуда. Обратный прокси смотрит на cookie и прибивает клиента к конкретному веб-серверу. Это липкие сессии, и без них многие приложения разваливаются.
Логика маршрутизации опирается на URL, заголовки, cookie, регион или версию клиента. Внутри одного домена спокойно живут старый и новый интерфейс, разные API для партнёров и мобильных приложений. Снаружи это один аккуратный вход.
SSL termination: сертификаты в одном месте, а не на сорока серверах
Когда я предлагаю перенести сертификаты на обратный прокси, слышу один и тот же вопрос про шифрование внутри. Не обязательно оставаться без него. Есть два подхода. Первый: прокси расшифровывает трафик и ходит к бэкенду по HTTP внутри защищённой сети. Второй: расшифровывает, проверяет и заново шифрует соединение до бэкенда.
Первый вариант проще и быстрее. Второй нужен, когда среда между прокси и сервисом не очень доверенная. Выбор зависит от размещения компонентов.
Плюс SSL termination в одном месте: продление сертификатов, выбор шифров, обновление конфигурации. Не нужно бегать по сорока серверам и надеяться, что на одном не забыли старый ключ. Команде без отдельного человека на сертификаты это экономит нервы и деньги.
Обратная сторона тоже есть. Трафик внутри становится видимым для того, кто смотрит на прокси. Логи, отладка, инспекция запросов. Если есть требования по защите данных, к этому относятся серьёзно. Шифрование до бэкенда и разграничение доступа к логам никто не отменял.
Кэш и сжатие дают прирост, который видно в метриках
Обратный прокси кэширует ответы. Статика, картинки, публичные страницы, которые не меняются каждую секунду. При разумной настройке часть запросов вообще не долетает до приложения. Время ответа падает, нагрузка на бэкенд тоже.
Я начинаю с малого: кэширую только статику и явно помеченные публичные ответы. Потом смотрю на графики и решаю, что добавить. Слепое кэширование всего подряд - верный способ показать пользователю чужие данные или устаревшую цену. Особенно там, где есть авторизация и персонализация.
Сжатие gzip или brotli тоже часто вешают на прокси. Экономия трафика заметна на мобильных, нагрузка на процессор обычно не критична. Главное - не сжимать уже сжатые форматы и не включать всё подряд без замера.
DDoS-защита начинается с того, что реальный IP знают только вы
Схема простая. DNS-запись домена указывает на проксирующий сервер. Настоящий адрес вашего сервера держится в тайне. Во время атаки весь поток приходит на прокси, там трафик дешифруется, анализируется и фильтруется. Легитимные запросы уходят на бэкенд, мусор отбрасывается.
На этом уровне работают лимиты запросов, геоблокировки, чёрные и белые списки, правила против ботов. Если один узел фильтрации не справляется, запросы идут через другие узлы. Anycast-маршрутизация размазывает нагрузку по точкам присутствия.
Границу понимать нужно. Обратный прокси не делает сервер неуязвимым. Он принимает удар на себя и даёт время среагировать. Если приложение отдаёт базу по одному запросу, прокси это не исправит.
Внутренние сервисы не должны светить реальные адреса. Проверьте, что бэкенд не отвечает напрямую по IP, что порты закрыты, что в DNS нет лишних записей. Прокси скрывает инфраструктуру только тогда, когда вы сами её прячете.
Липкие сессии: почему пользователь не должен прыгать между бэкендами
Балансировка на прикладном уровне умнее простого round-robin. Прокси учитывает, сколько соединений висит на сервере, как быстро он отвечает, жив ли он вообще. Проверки здоровья, health checks, убирают из пула упавший бэкенд до того, как пользователь увидит ошибку.
С сессиями сложнее. Если приложение хранит состояние на сервере, а не в общей базе или Redis, нужны липкие сессии. Прокси смотрит на cookie или другой признак и отправляет клиента на тот же сервер. Иначе получается классика: залогинился, перешёл в корзину, а там снова просят пароль.
Я предпочитаю другой путь - выносить состояние из приложения, чтобы любой бэкенд обслужил любого пользователя. Тогда балансировка становится честной и предсказуемой. Но если приложение уже написано и переписывать его никто не будет, липкие сессии на прокси остаются рабочим компромиссом.
Где обратный прокси только мешает
Есть сценарии, где его ставят зря. Один маленький сервис с одним бэкендом и низким трафиком. Прокси добавляет точку отказа, усложняет отладку и требует обновлений. Иногда проще настроить TLS на самом приложении и не плодить сущности.
Второй случай - прокси поставили, но не настроили. Забыли про X-Forwarded-For, и приложение видит все запросы с одного IP. Включили кэш и удивляются, почему пользователи видят чужие страницы. Не ограничили размер тела запроса, и кто-то заливает гигабайты. На Reddit в тредах про инфраструктуру этот набор ошибок всплывает с завидной регулярностью - люди месяцами ищут причину в коде, а она в трёх забытых директивах.
Третий случай - двойная балансировка без понимания зачем. Снаружи облачный балансировщик, внутри ещё один прокси, оба делают похожие вещи. Запрета нет, но нужна ясность. Внешний уровень распределяет трафик по простым алгоритмам, внутренний занимается тонкой маршрутизацией на прикладном уровне. Если такой логики нет, второй слой просто добавляет задержку.
Клиентские прокси в Telegram, WhatsApp и браузере: куда нажимать
Обратный прокси не защищает трафик ноутбука в кафе. На клиенте работает прямой прокси или корпоративный шлюз. Настройка в приложениях выглядит примерно так.
В Telegram: «Настройки», затем «Данные и память», далее «Прокси». Нажмите «Добавить прокси», выберите тип SOCKS5, введите хост, порт, при необходимости логин и пароль. Сохраните и включите переключатель.
В WhatsApp: «Настройки», затем «Хранилище и данные», далее «Прокси». Нажмите «Настроить прокси», введите адрес сервера и порт, укажите логин и пароль, если они есть. Сохраните. Интерфейс отличается по версиям, логика та же.
В браузере на компьютере: откройте настройки, найдите раздел про систему или сеть, нажмите кнопку настройки прокси. Вручную укажите адрес и порт для HTTP и HTTPS. В некоторых сборках настройки берутся из системы, тогда менять нужно там.
Всё это прямые прокси для клиента. С обратным такая история не работает: он стоит на стороне сервера, и клиентские приложения о нём ничего не знают.
SOCKS5 и MTProto: что реально происходит внутри туннеля
SOCKS5 работает на уровне сессии и не обязан понимать HTTP. Он пропускает TCP-соединения, поддерживает аутентификацию и умеет работать с UDP. Для приложений, которым нужен именно сетевой туннель, это удобный вариант. Обратный прокси на HTTP-уровне решает другие задачи: маршрутизация, кэш, заголовки, сертификаты.
MTProto - протокол со своим шифрованием пакетов и оптимизацией под мобильные сети. Для архитектуры важно, что шифрование и маршрутизация разделены. Пакеты шифруются, задержка снижается за счёт выбора ближайших узлов, балансировка распределяет нагрузку между ними. Понимание этой схемы помогает не путать прокси с VPN и не ждать от одного инструмента чужих функций.
Прямые прокси для парсинга и тестов: где брать
Когда я собираю данные для анализа цен или проверяю, как выглядит выдача из разных регионов, мне нужен пул прямых прокси. Задача отдельная и с обратным прокси на входе в инфраструктуру не связана. Для неё я открываю каталог прокси 3seller. Там есть фильтры по стране, типу и протоколу. Выбираешь под задачу, а не собираешь адреса по форумам и сомнительным спискам.
Для парсинга важна стабильность и скорость ротации. Для тестов хватает небольшого пула, чтобы посмотреть, как ведёт себя приложение. Для распределённых задач нужна география. Каталог удобен тем, что параметры видны сразу.
С чего начать на этой неделе
Возьмите один тестовый домен и поставьте перед ним обратный прокси. Подойдёт nginx, Caddy или то, что уже есть в инфраструктуре. Включите access log с X-Forwarded-For и посмотрите на реальные запросы. Через неделю вы будете знать про свой трафик больше, чем за год чтения документации.
Дальше добавьте health checks, ограничения на размер тела запроса и таймауты. Проверьте, что бэкенд не отвечает напрямую по IP. Настройте один сертификат на прокси и убедитесь, что продление работает. Только после этого переносите остальные сервисы.
И про вторую сторону не забывайте: для сбора данных, тестов и распределённых задач нужны прямые прокси - начните с каталога 3seller. Обратный прокси держит ваш вход, прямые решают задачи на выходе. Один инструмент не заменяет другой, и это нормально.