Очередной генератор nginx-конфигов? Нет. Ну, почти нет.

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

Через час конфиг есть. Работает ли он правильно — непонятно. nginx -t говорит OK, но это означает только то, что синтаксис не сломан. Не то, что я не забыл server_tokens off, не оставил TLSv1.0 и не написал client_max_body_size 0, что по факту снимает ограничение на размер запроса.

В какой-то момент стало понятно: я повторяю один и тот же процесс раз за разом, каждый раз заново выясняя то, что уже знал полгода назад. Готовые инструменты закрывали часть задачи, но не давали трёх вещей, которых мне не хватало: объяснений на русском прямо рядом с конфигом, внятных предупреждений по спорным настройкам и проверки через реальный nginx -t, а не эвристический синтаксический анализ.

Так я сделал NginxForge.

Почему nginx — это боль

nginx — отличный инструмент. Документация у него тоже хорошая. Но в ней около 150 директив только в ngx_http_core_module, и понять с первого раза, почему proxy_pass http://localhost:8000 и proxy_pass http://localhost:8000/ ведут себя по-разному — не всегда очевидно.

Несколько классических граблей, на которые наступают снова и снова:

proxy_pass со слэшем и без — это принципиально разное поведение. proxy_pass http://backend:8000 оставляет путь запроса как есть. proxy_pass http://backend:8000/ — обрезает prefix. Если пишешь location /api/ + proxy_pass http://backend:8000/, запросы пойдут без /api/ префикса. Это может быть то, что нужно, а может сломать всё.

server_tokens on — это дефолт. nginx будет отдавать свою версию в заголовках ответа и на страницах ошибок. Полезно на локалке, в проде лучше выключить.

TLS версии — TLSv1.0 и TLSv1.1 считаются устаревшими с 2020 года. Если скопировал конфиг со StackOverflow образца 2016 года, там скорее всего они есть.

client_max_body_size 0 — снимает все ограничения на размер тела запроса. Иногда это нужно (MinIO, загрузка файлов), чаще — нет.

WebSocket Upgrade — забыть proxy_set_header Upgrade $http_upgrade или proxy_set_header Connection "upgrade" означает, что WebSocket-соединение молча не заработает.

Это не экзотика. Это то, что всплывает в почти каждом конфиге для нового проекта.

Что получилось

NginxForge — веб-инструмент для генерации конфигов nginx. Выбираешь сценарий (FastAPI, Django, WordPress, WebSocket и ещё 12 штук), заполняешь параметры, получаешь рабочий nginx.conf. Пока звучит как «очередной генератор» — но дальше начинается то, из-за чего я вообще это делал.

75 директив с аннотациями на русском. Каждая строка конфига объясняется: что делает, почему здесь, что значит конкретное значение. Три уровня: info, warning, danger. Включаются переключателем — по умолчанию выключены, чтобы не мешать копированию чистого конфига.

Реальный nginx -t. Конфиг прогоняется через настоящий nginx в изолированном Docker-контейнере. Синтаксические ошибки и неправильные значения директив ловятся до того, как скопируешь конфиг на сервер.

AI Explain. По кнопке — объяснение всего конфига на русском. Конфиг отправляется во внешний API только по явному запросу, не автоматически.

Дополнительно: экспорт ZIP с nginx.conf, docker-compose.yml, .env.example и README.md под твой стек, и share-ссылки с TTL 30 дней — удобно кинуть в PR или в чат команде.

Без регистрации. Бесплатно.

Как это работает внутри

Стек: FastAPI + Vue.js 3 + SQLite + Docker Compose. Без сложностей — всё то, что хорошо известно и предсказуемо.

Pipeline генерации

параметры формы
    ↓
Jinja2-шаблон (специфичный для сценария)
    ↓
nginx.conf
    ↓
статический анализ (10 типов проверок)
    +
реальный nginx -t (Docker sidecar)
    ↓
конфиг + предупреждения + аннотации

Для каждого сценария — отдельный .conf.j2 шаблон с проверенными паттернами. FastAPI получает правильные таймауты и буферизацию. WordPress — PHP-FPM socket, блокировку xmlrpc.php, rate limiting на wp-login.php. WebSocket — правильные заголовки Upgrade/Connection и большие таймауты.

Реальный nginx -t

Многие валидаторы конфигов делают статический анализ — проверяют синтаксис эвристиками. Реальный nginx -t делает именно то, что он делает на твоём сервере: загружает конфиг, парсит его, проверяет корректность директив.

Для этого поднят отдельный sidecar-контейнер с nginx. Конфиг передаётся туда, запускается nginx -t, результат возвращается в ответе. Контейнер изолирован: нет доступа к сети хоста, нет прав на выход за пределы, нет bind-маунтов в production-директории. Единственная его задача — принять конфиг, запустить проверку и вернуть результат.

Важная оговорка: реальный nginx -t не знает о твоей сетевой топологии, upstream-адресах и путях к сертификатам. Синтаксические ошибки и неправильные значения директив — поймает. «Нет маршрута до upstream» — нет. После генерации всё равно запускай nginx -t у себя перед деплоем.

Аннотации

Несколько примеров из базы:

Про данные и безопасность

DevOps-инструмент, поэтому вопрос закономерный.

Без создания share-ссылки конфиг на сервере не сохраняется — это просто API-запрос, ответ возвращается клиенту. При создании share-ссылки сохраняется: slug, текст конфига, сценарий, параметры формы (JSON), SHA-256 хэш IP (не сам IP), дата создания и истечения (30 дней).

AI Explain — единственная функция, при которой конфиг уходит во внешний LLM API. Только по явному нажатию кнопки.

И главное: не вставляй в параметры генератора приватные ключи, токены и пароли. Инструмент для этого не предназначен.

Чего пока нет — честно

• Self-hosted версии нет. Рассматриваю как следующий шаг, если будет запрос.

• Код закрыт. Фокус сейчас на продукте, не на поддержке open-source сообщества.

• Мобильная версия работает, но не является основным сценарием. Основное использование — desktop.

Попробуйте и расскажите

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

Конкретно интересно:

• Какие сценарии используете, которых здесь нет?

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

• Насколько полезны аннотации — или мешают и хочется сразу чистый конфиг?

nginxforge.ru