Всем привет!
Вторая статья про революционный проект Vodka, где будут реальные замеры производительности nginx.exe. А ещё на этот раз я более подробно расскажу про архитектуру проекта. И даже покажу, как это, установить Windows на Linux!
При разработке веб-проектов неизбежно поднимается вопрос их размещения в интернете. Разворачивать отдельную виртуальную машину для каждого маленького сервиса иногда избыточно и экономически нецелесообразно.
Давайте пристальнее взглянем на проблему размещения множества веб-сервисов на одном виртуальном сервере и познакомимся с элегантным решением — Nginx Proxy Manager.
NGINX давно стал стандартом для базовых инфраструктурных задач: терминации HTTPS, раздачи статического контента и балансировки трафика. Однако за 2026 год веб-сервер совершил технологический рывок в своей основной ветке, который выводит его далеко за рамки классического обратного прокси.
В новых OSS-версиях появились инструменты, которые раньше требовали покупки коммерческой подписки (NGINX Plus от F5) или развертывания стороннего ПО и сложных связок с Lua. Майский релиз 1.31.0 принес нативную поддержку HTTP Forward Proxy. А сентябрьское обновление 1.31.5 окончательно закрепило этот триумф, добавив полноценный динамический Control API, модуль для нативного извлечения данных из JSON и предикатные location. Параллельно с этим произошли большие изменения в скриптовании: в июне проект njs перешагнул отметку релиза 1.0.0, полностью сменив старый кастомный движок на современный QuickJS.
Обратный SSH-туннель позволяет опубликовать домашний видеосервис без проброса портов. Но одна доверенная строка из браузера может превратить Viewer в SSRF-прокси и открыть путь во внутреннюю сеть.
Разбираю реальную ошибку и её исправление: фиксированный upstream, авторизацию HLS, loopback на обоих концах туннеля, ограниченный SSH-ключ, единственную публичную точку HTTPS и аварийное отключение доступа.
Несколько лет назад мы решили заменить legacy e‑commerce‑платформу, которая продолжала работать и принимать заказы. Новый frontend построили на Next.js, backend — на Symfony, перед ними поставили Nginx. Но после запуска выяснилось, что самое интересное только начинается.
В статье разберу реальную production‑архитектуру: SSR, восемь процессов Next.js, несколько уровней кэширования, интеграции с внешними системами и проблемы актуальности данных. А главное — какие решения спустя несколько лет эксплуатации я бы спроектировал иначе.
Сертификат сайта истёк, и 21 день каждый посетитель видел предупреждение о небезопасном соединении. При этом certbot всё это время работал правильно и показывал VALID: он знает про файл на диске, а браузер получает то, что держит в памяти процесс nginx. Разбираю, почему схема «certbot на хосте, nginx в контейнере» рвётся молча, почему мониторинг всё видел и ничего не дал, и почему починка без проверки в бою остаётся гипотезой.
Когда говорят про recon в Bug Bounty, обычно вспоминают subfinder, httpx, поиск директорий, JS-файлы и огромные списки URL. Всё это действительно используется. Но проблема в том, что сам по себе список из нескольких тысяч поддоменов почти ничего не даёт.
Главный вопрос начинается после сбора информации: что из этого действительно заслуживает внимания и почему?
Я не начинал свой путь в Bug Bounty с мысли «хочу стать security researcher».
Всё было гораздо прозаичнее: курс по информационной безопасности, несколько видео про пентест, TryHackMe и постепенно появившийся интерес к тому, как вообще устроены системы.
А потом был Bug Bounty.
Вопросы передачи видео вполне актуальны в современном вебе. Конечно, большинство видео-трафика обслуживается крупными сервисами, но и для небольших специальных решений находится место. В этой статье узнаем, какие возможности по работе с видеопотоком имеет сервер Angie.
TLS‑конфиг легко годами не трогать, пока сертификат валиден, браузеры не ругаются, а SSL Labs показывает высокий рейтинг. За это время часть привычных настроек успевает устареть, перестать работать или изменить смысл.
В статье разбираем, что произошло с OCSP stapling, возобновлением TLS‑сессий, тикетами и 0-RTT и как сегодня выглядит актуальная конфигурация nginx.
Вы наверняка знакомы с функциональностью сервера Angie в качестве обратного прокси и веб-сервера с поддержкой протокола HTTPS. Также Angie умеет проксировать и балансировать TCP и UDP-сервисы, включая DNS. Новый модуль DoH объединяет эти возможности, реализуя протокол DNS over HTTPS для клиентов. Если добавить модуль ACME с автоматическим получением TLS-сертификатов, получим готовое решение.
Один публичный IP, один 443-й порт, на нём уже работает сервис с живыми пользователями — и туда же нужно посадить второй. Менять настройки на устройствах пользователей нельзя.
Разбираю, как разделить порт между двумя TLS-сервисами, ничего не расшифровывая: SNI уходит открытым текстом в ClientHello, и nginx умеет читать его директивой ssl_preread, оставаясь для TLS прозрачным. Отдельно — почему всё держится на ветке default, чем за прозрачность платят (бэкенд перестаёт видеть реальные адреса клиентов) и когда у этого решения закончится срок годности.
Вчера переехал на свой сервер. Сегодня утром обнаружил, что сайт у меня не открывается. Ни из дома, ни с телефона.
Сервер при этом в Москве, у российского хостера. И с ним всё в порядке.
Дальше про то, как я полдня искал причину, какие шесть версий проверил и выбросил, и чем всё кончилось. Если симптомы похожие, в конце готовая методика: что запускать и как читать результат.
Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.
Денис, добрый день! После изучения вашей анкеты, к сожалению, мы не готовы пригласить вас к дальнейшему рассмотрению на обучение в компании. У нас очень большой поток кандидатов на курсы. В данный момент взяли в рассмотрение участников с показателями выше. Ваша анкета будет сохранена, возможно, вернемся к вашей кандидатуре, при наборе на следующий поток. Благодарим за внимание к нашей компании.
Хотя я даже не понял, как смогли оценить мои показатели и в чем они измерялись, если не давали ни тестового задания, ни собеседования. В анкете у них несколько вопросов и уровень образования. Но да ладно, это тема отдельной статьи.
Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.
На первый взгляд, задание кажется не таким уж и сложным, однако, дьявол кроется в деталях и есть неоднозначное право выбора, которое будет зависеть от ситуации.
Тестовое задание состоит из 4 задач, начнем с первой.
Задача звучала просто: создать ВКС с jitsi и чатом нарисовать красивый интерфейс в корп стиле.
Решение — написать собственный тонкий веб‑клиент поверх matrix-js-sdk, который разговаривает с уже существующим Synapse‑сервером и Jitsi‑сервером, но выглядит и ведёт себя как часть внутреннего портала компании.
Ниже — подробный, местами болезненный дневник того, как это строилось: от каркаса на Vite до продакшена с реальными пользователями и очень поучительных багов.
Типовую задачу проксирования трафика на базе заголовков и тела HTTP-запроса теперь можно решать напрямую с помощью предикатных локейшенов в NGINX.
До версии 1.31.5 для этого применяли тяжелые скрипты (медленно) и лабиринты из редиректов (неудобно). Теперь можно создать блоки location на базе любой переменной. В этом блоге разбираем методики чтения запроса и показываем примеры паттернов конфигурирования NGINX, которые вы можете применять для любого API или AI-трафика.
Представим ситуацию: у вас есть примитивное веб-приложение онлайн-редактора, которое уже набрало среднюю нагрузку под 100 RPS. И вы, как тимлид, дождались того самого дня, когда вся кропотливая работа над обновлением и бессонные ночи наконец завершились.
Настал момент релиза.
Вы радуетесь, что пользователи вашего приложения станут ещё счастливее. Они доверяют вашему сервису свои важные задачи, а вы расширите их возможности и сделаете их жизнь ещё немного лучше.
И вот момент.
3, 2, 1…
Релиз состоялся.
Вы рады. Ваши коллеги тоже рады. Всё прошло успешно.
Но спустя некоторое время к вам заходит начальство с максимально неприятным выражением лица...
Несколько месяцев назад я начал делать небольшой сервис для контейнерной логистики.
Изначальная идея была довольно простой: заменить бесконечную публикацию одних и тех же грузов и свободных машин в рабочих чатах нормальным поиском.
Так появился ГрузоБот это сервис для грузоотправителей, экспедиторов и перевозчиков, работающий через мессенджер MAX.
Сейчас проект уже находится в бета, но продакшене, поэтому хочу рассказать не столько о самом сервисе, сколько о том, что оказалось под капотом и с какими задачами пришлось столкнуться при разработке.
Недавно разбирал блокировку у заказчика. Сработало правило «десять неудачных входов с одного адреса - бан». Забанило адрес, с которого никто ничего не делал. Через два часа забанило ещё один, потом ещё - и все из документационного диапазона, который в интернете не маршрутизируется.
Логика правила была в порядке. Просто в качестве адреса клиента оно брало то, что клиент про себя написал сам.
В Grafana есть режим публикации дашборда наружу: генерируется токен, по нему дашборд открывается без учётной записи, только на чтение. В интерфейсе это две галочки.
Я потратил на эти две галочки несколько дней. Не потому, что там сложно нажать, а потому, что публикация мониторинга наружу ломается в местах, о которых не думаешь заранее: переменные, лимиты запросов, метки, которых ждёт дашборд. Ниже разбор всего, что я собрал по дороге — девять дашбордов, синтетический контур и один эпизод, где мою же витрину положил мой же nginx.
