nginxconfig.io: конфиг nginx для VPS и что проверить после

Конфиг, собранный из десяти туториалов

Типичная картина на VPS небольшого сайта. Кусок конфига из туториала 2019 года, кусок из ответа на форуме. Порт 80 отвечает без редиректа на HTTPS. В ssl_protocols остался TLSv1, шифры вставлены списком из чьего-то блога. Сжатия нет. Скрытые файлы вроде .git открываются по прямой ссылке. Каждый кусок работал по отдельности, вместе они дают слабо защищённый сервер.

С нуля такой сервер я разбирал в статье про VPS с Docker, nginx и HTTPS. Здесь про инструмент, который помогает собрать конфиг осознанно, и про проверку после него.

Что за проект и что я проверил

Проверял 17.10.2026. Репозиторий digitalocean/nginxconfig.io принадлежит организации DigitalOcean, описан как генератор конфигов NGINX. Файл LICENSE содержит текст лицензии MIT, авторство DigitalOcean. Репозиторий создан 5 января 2018 года, по данным GitHub около 28,3 тысячи звёзд, 2 тысячи форков, 71 открытая задача. Он не архивирован.

Теперь про живость. Последний коммит в ветке master от 4 октября 2024 года: обновление зависимостей. Релизов и тегов у проекта нет. То есть он стоит на месте больше двух лет. Для генератора, который описывает меняющиеся nginx и TLS, это важно. Размещённую версию README предлагает открывать по короткой ссылке do.co/nginxconfig. Локально по README: клонировать репозиторий, выполнить npm ci, затем npm run dev и открыть localhost:8080. Сборка кладёт файлы в папку dist.

Что генератор выдаёт

Я прочитал исходники. Выдача состоит из нескольких файлов: основной nginx.conf, по файлу на каждый домен в sites-available и набор общих кусочков в папке nginxconfig.io: security.conf, general.conf, letsencrypt.conf, а при выборе нужных опций ещё proxy.conf, php_fastcgi.conf, python_uwsgi.conf. Есть и заготовки Dockerfile и docker-compose.yaml. Скачать можно архивом или скопировать строку base64 и выполнить её в консоли сервера. Инструкция в самом инструменте советует сначала сделать резервную копию текущей конфигурации, потом распаковать архив через tar.

Что внутри по умолчанию. TLS-профиль Mozilla Intermediate: TLSv1.2 и TLSv1.3. Профиль Modern оставляет только TLSv1.3, профиль Old включает TLSv1 и TLSv1.1. Кеш сессий shared:SSL:10m, ssl_session_tickets выключен. Стоит HSTS с max-age на год. Закрыты точечные файлы: по шаблону location ~ /\.(?!well-known) доступ запрещён, кроме каталога well-known. Есть опции gzip и brotli, срок кеширования статики, ограничение запросов к логину, server_tokens off. Заголовки безопасности: X-Content-Type-Options, Referrer-Policy, по желанию Content-Security-Policy и Permissions-Policy.

Что в выдаче уже отстаёт от nginx

Сверял с первоисточниками, на живом nginx не запускал, поэтому формулирую осторожно.

HTTP/2. Генератор пишет listen 443 ssl http2. В документации nginx параметр http2 у listen помечен устаревшим, вместо него директива http2 (она появилась в версии 1.25.1). Предупреждение возможно, зависит от вашей версии nginx.

HTTP/3. Генератор пишет listen 443 http3. По странице про QUIC в nginx с версии 1.25.0 для этого служит параметр quic, а параметра http3 в этом описании нет. Сам инструмент предупреждает, что HTTP/3 нестандартный модуль. Эту галочку не включайте вслепую.

OCSP stapling. Генератор включает ssl_stapling. Let's Encrypt, по их объявлению, убрал OCSP из сертификатов 7 мая 2025 года и выключил респондеры 6 августа 2025 года. Подшивать нечего, опцию логично отключить. Как поведёт себя ваш nginx, покажут nginx -t и журнал ошибок.

Заголовок X-XSS-Protection. Он есть в выдаче, а MDN называет его устаревшим и нестандартным и советует вместо него Content-Security-Policy.

Профили TLS. В коде комментарий отсылает к рекомендациям Mozilla версии 5.0. Страница Mozilla сейчас сообщает, что публичная версия рекомендаций ведётся сообществом на docs.tlsref.org. Нынешние списки шифров с зашитыми я не сравнивал.

Журнал доступа в выдаче выключен (access_log off), включите, если нужны логи. А ssl_session_tickets off по умолчанию на мой взгляд для небольшого сайта нормален.

Данные и чего генератор не заменяет

Про данные. Конфиг генерирует JavaScript в браузере: серверной части с API в репозитории нет. Но в коде есть модуль аналитики. Он отправляет события в Google Tag Manager и Segment, если эти скрипты подключены на странице. При удалении сайта в событие попадает имя домена. Подключены ли они на размещённой странице, я не проверял. Для рабочих доменов проще запустить инструмент локально или подставить условное имя и заменить его в файлах.

Он не знает ваше приложение. Порт бэкенда, таймауты для долгих запросов, размер загружаемых файлов, пути админки, нужные скрипты для заголовка Content-Security-Policy: всё это вы вводите руками, и всё это ломается тихо. Включённый без проверки CSP останавливает чужие скрипты на сайте. Пути к сертификатам он пишет, а сами сертификаты не выпускает: есть шаблон для проверки ACME и подсказки по certbot, но если файлов нет, nginx не пройдёт проверку. Продление сертификатов отдельная тема, я разбирал её в статье про сертификаты на 200 дней.

Если конфиг вам тяжело сопровождать вообще, посмотрите на Caddy с автоматическим HTTPS.

Что можно сделать уже сейчас

Первое. Откройте инструмент или запустите локально и соберите конфиг на условном домене. Сравните его с тем, что стоит на сервере: редирект с 80 на 443, протоколы, сжатие, закрытые точечные файлы. Разница уже покажет, чего не хватает.

Второе. Скопируйте текущую конфигурацию, положите новую на тестовый поддомен, выполните nginx -t и перезагрузите конфигурацию только после чистой проверки.

Третье. Проверьте снаружи. curl -I http://ваш-домен должен вернуть редирект. Адреса вида /.git/config должны отдавать отказ. Откройте сайт в SSL Labs и на securityheaders.com и посмотрите, на что они ругаются.

Четвёртое. Если не хочется собирать это самому, мне можно передать настройку сервера под ключ, а проверку существующего конфига вместе со всем окружением, как ИТ-аудит.

Частые вопросы

Можно ли залить сгенерированный конфиг сразу на рабочий сервер?

Лучше нет. Сначала резервная копия, потом тестовая площадка и nginx -t. Особенно если на сервере живут несколько сайтов: основной nginx.conf генератор пишет целиком и заменит ваши настройки.

Подойдёт ли он для Docker?

В выдаче можно включить Dockerfile и docker-compose.yaml. Что именно они содержат, я не запускал, поэтому считайте их заготовкой.

Что проверять при каждом обновлении nginx?

nginx -t, предупреждения об устаревших параметрах и внешнюю проверку HTTPS.

Коротко о главном

nginxconfig.io под MIT даёт быстрый старт для конфига: HTTPS, сжатие, прокси и заголовки собираются галочками. Проект не архивирован, но стоит с октября 2024 года, и часть вывода устарела. Конфиг из него надо проверять и дорабатывать под своё приложение.

Если хотите, чтобы я проверил ваш nginx, собрал заготовку и довёл конфиг до рабочего состояния, напишите мне в Telegram кодовое слово «КОНФИГ».