Очередной генератор 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 у себя перед деплоем.
Аннотации
Несколько примеров из базы:
Директива | Уровень | Что говорит аннотация |
|---|---|---|
| ⚠️ warning | Раскрывает версию nginx в заголовках. Выключите в продакшене. |
| ⚠️ warning | TLSv1.0 и TLSv1.1 устарели. Используйте TLSv1.2 и TLSv1.3. |
| ⚠️ warning | Снимает ограничение на размер запроса. Убедитесь, что это намеренно. |
| 🔴 danger | Путь к приватному ключу. Проверьте права доступа к файлу. |
| ℹ️ info | Автоматически выставляет число процессов по количеству CPU. |
Про данные и безопасность
DevOps-инструмент, поэтому вопрос закономерный.
Без создания share-ссылки конфиг на сервере не сохраняется — это просто API-запрос, ответ возвращается клиенту. При создании share-ссылки сохраняется: slug, текст конфига, сценарий, параметры формы (JSON), SHA-256 хэш IP (не сам IP), дата создания и истечения (30 дней).
AI Explain — единственная функция, при которой конфиг уходит во внешний LLM API. Только по явному нажатию кнопки.
И главное: не вставляй в параметры генератора приватные ключи, токены и пароли. Инструмент для этого не предназначен.
Чего пока нет — честно
Self-hosted версии нет. Рассматриваю как следующий шаг, если будет запрос.
Код закрыт. Фокус сейчас на продукте, не на поддержке open-source сообщества.
Мобильная версия работает, но не является основным сценарием. Основное использование — desktop.
Попробуйте и расскажите
Это первый публичный релиз. Если что-то делает не то, что должно, или не хватает сценария под ваш стек — это именно тот фидбэк, ради которого всё и затевалось.
Конкретно интересно:
Какие сценарии используете, которых здесь нет?
Что обычно приходится допиливать руками после любого генератора?
Насколько полезны аннотации — или мешают и хочется сразу чистый конфиг?