
Комментарии 18
Круто, а зачем? Генератор от digital ocean есть давно, а в остальном - если делаешь типовые вещи, то автоматизируй. Я лет 5 назад сделал простейший, базовый nginx.conf, сдела пару каталогов, куда напихал типовые конфиги для логов, сжатия, проксирования и всего прочего, а так же простые шаблоны, со всеми proxy_pass.
И шаблон можно инклюдить в блок server одной командой, а уже в шаблоне у вас редиректы, реверс прокси, acme клиенты, auth_basic, да что угодно, опять же через простые include и переменные. Разве что логи и серты руками прописывать, ну и апстримы
Можно и вам было давно это сделать
Спасибо!
Как раз согласен, что если ты 5+ лет живёшь в nginx и у тебя уже есть свой базовый конфиг + набор include’ов, то этот инструмент тебе вряд ли нужен. Я делал NginxForge не вместо такого подхода, а для другой ситуации:
• ты настраиваешь nginx не каждый день, а раз в несколько месяцев;
• у тебя нет “семейного” базового конфига, который кочует из проекта в проект;
• каждый раз всё начинается с трёх вкладок: дока, старый конфиг и какой‑нибудь ответ про proxy_pass со слэшем или без.
То есть по сути NginxForge = “готовый базовый конфиг + шаблоны”, только:
• они уже собраны под разные сценарии (reverse proxy, microservices, Django, Node.js и т.д.);
• каждую директиву можно подсмотреть с аннотацией на русском;
• поверх всего прогоняется реальный nginx -t в изолированном контейнере, чтобы не ловить синтаксический мусор перед деплоем.
Если у человека уже есть своя отлаженная библиотека шаблонов — это вообще лучший вариант. NginxForge скорее для тех, кто до такой библиотеки ещё не дошёл или не хочет в неё инвестировать время, но при этом не хочет каждый раз собирать конфиг с нуля и бояться, что где‑то упустил server_tokens или протоколы TLS.
Так это, я тут как специалист по автоматизации говорю, что не важно, как часто. Если пошли одни и теже настройки, то сделай шаблон и выкини куда. По сути все «базовые шаблоны» это либо реверс, либо статика (редкость в наше время). И все эти пресеты уже есть у Digital Ocean инструмента. Он даже отдельно лежит. Гонять nginx -t прикольно, а зачем? Это базовый валидатор, как и сказано. Он не покажет ни мусоры, ни работоспособность, только явные ошибки в синтаксисе.
Я о том, что это достаточно сделать единожды для большинства проектов и не ломать голову. Крайне вряд ли, что у вас будет скакать синтаксис.
Да и в целом, чаще выгоднее взять тот же traefik, так же его настроить и всё. Его задача первичная маршрутизация, хотя по хорошему он вообще должен работать только с сертами и компрессией, плюс логировать доступ, а остальным, включая заголовки, заниматься приложение.
Плюс я у вас вижу token off, ок которого мало проку (древнейшая рекомендация по сокрытию версий, хотя у многих торчит инфа о nginx 1.18 и им ничего), зато не вижу ничего о quic, о том же http3 on и прочем реально полезном в секциях main и http
Справедливо по нескольким пунктам — спасибо, что развернул.
По Traefik согласен: если проект с самого начала строится на docker-compose и оркестрации, Traefik или Caddy — более органичное решение. NginxForge заточен именно под сценарий «мне нужен nginx, и я хочу получить рабочий конфиг без боли», а не под замену оркестратора.
По server_tokens off : Директива стоит в шаблоне как базовый гигиенический минимум по CIS Benchmark, наряду с отключением лишних методов и скрытием заголовка X-Powered-By на уровне upstream.
По HTTP/3 и QUIC — согласен. Это реальный пробел: http3 on, quic, add_header Alt-Svc, listen 443 quic reuseport — всё это должно быть в секции http и в шаблонах реверс-прокси. Сейчас этого нет, и ты прав, что это уже не экзотика, а мейнстрим начиная с nginx 1.25. Возьмем в доработку, спасибо за фидбэк.
забавно что раньше на малых проектах докидывал к nginx скрипт с certbot через cron, а сейчас использую angie/traefik/caddy.
В какой-то момент стало понятно: я повторяю один и тот же процесс раз за разом, каждый раз заново выясняя то, что уже знал полгода назад.
У меня просто на гитхабе репо с шаблонами, базовыми операциями и описанием или прям в гист делиться с сообществом еще можно, так сказать шпаргалка.
Спасибо мне пригодится!
А чем это принципиально удобнее от "Ctrl+c ->Ctrl+v в чат ИИ"?
Несколько вещей:
1) структурированная форма не даст забыть про SSL, gzip, worker_processes — ИИ в чате легко упустит детали если не попросить явно;
2) конфиг сразу проверяется реальным nginx -t — ИИ может написать синтаксически неверный конфиг и не узнает об этом;
3) каждая директива с русским объяснением прямо в тексте — не надо гуглить что значит proxy_pass_header или keepalive_timeout;
4) share-ссылка — можно скинуть коллеге готовый конфиг.
Ну хз хз по факту такую проблему по большей части решает готовый конфиг на одном из серверов.
Из того что бы добавил, потому что для некоторых это реально проблема Есть фронтендеры которые отдают свою статику через nginx и Бэкенд вешают на отдельный порт, потому что не умеют в location
Собственно если делать генератор, то вот как раз для таких бы функционал добавить, потыкал и такого не нашел. Вот это бы решило проблему, давал бы ресурс с фразой “разбирайся”
А то в коде фронтенда пишут localhost и шлют запросы так, а потом удивляются почему на сервере не работает…

Не успеваю перевести курсор на ссылку, окно слишком быстро пропадет.
https://github.com/yandex/gixy
А как же gixy от Яндекса как статический локальный анализатор? Забыли за 10 лет?
Спасибо!
Я устал каждый раз гуглить одно и то же в nginx — и сделал инструмент, который объясняет конфиги на русском