Быстрый старт: как за 1 минуту узнать все модули Nginx
Чтобы получить полный список модулей Nginx, выполните два действия. Первое - команда для статических модулей, вкомпилированных в бинарный файл:
nginx -V 2>&1 | grep -o '\-\-with-[a-z_]*' | sort
Второе - поиск динамических модулей, которые загружаются отдельно:
grep -r load_module /etc/nginx/
Первый вывод покажет флаги --with-http_ssl_module, --with-stream и десятки других. Второй - директивы load_module modules/ngx_http_geoip2_module.so;. Статические модули встроены в ядро Nginx при компиляции, динамические лежат в виде .so-файлов и подключаются в конфигурации. Для полной картины нужны оба источника. Если вы обновляли Nginx или переносили конфигурацию между серверами, аудит модулей предотвратит ошибки при старте и деградацию функционала. Дальше разберем каждый метод детально, включая фильтрацию вывода, диагностику ошибок и скрипт для автоматической инвентаризации.
Статические модули: как увидеть, что вкомпилировано в Nginx
Статические модули - это код, встроенный в исполняемый файл Nginx на этапе компиляции. Они не требуют отдельных .so-файлов и всегда активны. Их список фиксирован для конкретной сборки и не меняется без перекомпиляции. Основной инструмент для просмотра - команда nginx -V. Она выводит версию Nginx, параметры компилятора и полный блок configure arguments, где перечислены все флаги --with-* и --without-*.
Выполните в терминале:
nginx -V
Вывод занимает 15-40 строк. Пример фрагмента:
nginx version: nginx/1.25.3
built by gcc 12.2.0 (Debian 12.2.0-14)
built with OpenSSL 3.0.11 19 Sep 2023
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules
--with-http_ssl_module
--with-http_v2_module
--with-http_realip_module
--with-http_gzip_static_module
--with-stream
--with-stream_ssl_module
--without-http_fastcgi_module
Флаги --with-* указывают модули, включенные при сборке. Флаги --without-* - модули, исключенные из стандартного набора. Модуль http_ssl_module присутствует в выводе - значит, HTTPS работает без дополнительных действий. Если --with-http_geoip_module отсутствует, GeoIP-функционал недоступен, пока вы не подключите динамический аналог.
Обратите внимание: некоторые модули включены по умолчанию и не отображаются в configure arguments. Например, ngx_http_core_module и ngx_http_access_module всегда присутствуют в любой сборке. Их отсутствие в выводе nginx -V не означает, что они не работают.
Фильтрация вывода nginx -V: извлекаем только названия модулей
Полный вывод nginx -V содержит пути, имена компиляторов и прочую информацию. Чтобы получить чистый список модулей, используйте фильтрацию через grep и awk.
Получить все включенные модули одной командой:
nginx -V 2>&1 | tr ' ' '\n' | grep '\-\-with-' | sed 's/--with-//' | sort
Разбор команды: 2>&1 перенаправляет stderr в stdout (вывод nginx -V идет в stderr), tr ' ' '\n' разбивает строку на отдельные слова, grep отбирает флаги --with-, sed отрезает префикс, sort сортирует по алфавиту. Результат - столбец с именами модулей: http_ssl_module, http_v2_module, stream_ssl_module.
Чтобы увидеть исключенные модули:
nginx -V 2>&1 | tr ' ' '\n' | grep '\-\-without-' | sed 's/--without-//' | sort
Для подсчета количества статических модулей:
nginx -V 2>&1 | tr ' ' '\n' | grep -c '\-\-with-'
Если вывод слишком длинный, сохраните его в файл:
nginx -V 2>&1 > nginx_build_info.txt
Что делать, если nginx -V недоступен или не показывает модули
В некоторых окружениях nginx -V недоступен: бинарный файл поврежден, права на выполнение отсутствуют, или вы работаете с минималистичным Docker-образом, где вывод урезан. Есть альтернативные методы.
Извлеките строки из бинарного файла:
strings /usr/sbin/nginx | grep -E 'with-|without-' | head -30
Команда strings вытаскивает читаемые последовательности из исполняемого файла. Среди них будут фрагменты configure arguments. Метод работает, даже если сам Nginx не запускается.
Более точный способ - использование objdump (требует binutils):
objdump -s -j .rodata /usr/sbin/nginx | grep -A50 'configure arguments'
Эта команда извлекает данные из read-only секции бинарника, где хранятся аргументы сборки. Вывод содержит полную строку configure arguments.
Для Docker-образов на базе Alpine Linux nginx -V часто выдает усеченный результат. Проверьте документацию образа на Docker Hub или выполните docker run --rm nginx:alpine nginx -V 2>&1. Если информация отсутствует, ориентируйтесь на список модулей в официальном Dockerfile сборки.
Знание статических модулей критично при планировании апгрейда Nginx. Если вы переходите с одной сборки на другую, сравните списки --with-*, чтобы не потерять функционал. Подробнее о процессе компиляции с нужными флагами читайте в руководстве по сборке Nginx с дополнительными модулями.
Динамические модули: где искать и как проверить загрузку
Динамические модули появились в Nginx 1.9.11. Это разделяемые объекты (.so-файлы), которые загружаются при старте через директиву load_module в конфигурации. Они не видны в nginx -V, потому что не вкомпилированы в бинарник. Концепция решает проблему: вы добавляете функционал без пересборки Nginx, просто установив пакет с модулем и прописав одну строку в конфиге.
Проверьте, какие динамические модули прописаны в конфигурации:
grep -r load_module /etc/nginx/
Типичный вывод:
/etc/nginx/nginx.conf:load_module modules/ngx_http_geoip2_module.so;
/etc/nginx/conf.d/modules.conf:load_module modules/ngx_stream_js_module.so;
Эта команда показывает директивы load_module во всех конфигурационных файлах, включая подключенные через include. Сама директива load_module должна находиться на верхнем уровне конфигурации, вне блоков http, stream и mail. Если она внутри блока - Nginx не запустится и выдаст ошибку при проверке конфигурации.
Стандартные пути к динамическим модулям в разных дистрибутивах
Файлы .so хранятся в разных директориях в зависимости от ОС и способа установки. Точный путь для вашей системы можно узнать из вывода nginx -V - параметр --modules-path.
| Дистрибутив / Источник пакетов | Путь к модулям |
|---|---|
| Debian/Ubuntu (официальный репозиторий nginx.org) | /usr/lib/nginx/modules/ |
| Debian/Ubuntu (стандартный репозиторий ОС) | /usr/share/nginx/modules/ |
| RHEL/CentOS/AlmaLinux/Rocky Linux (nginx.org) | /usr/lib64/nginx/modules/ |
| FreeBSD (порты/пакеты) | /usr/local/libexec/nginx/ |
| Сборка из исходников (по умолчанию) | /usr/local/nginx/modules/ |
Если путь в --modules-path отличается от таблицы, используйте его. Просмотрите содержимое директории:
ls -la /usr/lib/nginx/modules/
Вывод покажет все доступные .so-файлы. Доступные - не значит загруженные. Файл может лежать на диске, но без load_module в конфигурации он не активен.
Проверка загрузки динамического модуля через логи и nginx -T
Наличие load_module в конфигурации не гарантирует успешную загрузку. Модуль может не подхватиться из-за несовместимости версий, битых зависимостей или ошибок в самом .so-файле. Для верификации используйте два метода.
Первый - nginx -T. Эта команда выводит полную конфигурацию, которую Nginx видит после обработки всех include и подстановки переменных. Она также проверяет синтаксис и загрузку модулей:
nginx -T 2>&1 | grep -E 'load_module|error'
Если модуль не загрузился, вы увидите ошибку в выводе. Успешная загрузка не выводит сообщений - отсутствие ошибок и есть подтверждение.
Второй метод - debug-логирование при старте. Включите debug-уровень для error_log в конфигурации:
error_log /var/log/nginx/debug.log debug;
Перезапустите Nginx и проверьте лог:
grep -i module /var/log/nginx/debug.log
Пример успешной загрузки:
2026/07/26 10:15:43 [notice] 12345#0: module 'ngx_http_geoip2_module' loaded
Пример ошибки - файл не найден:
2026/07/26 10:16:01 [emerg] 12346#0: dlopen() "/etc/nginx/modules/ngx_http_geoip2_module.so" failed: No such file or directory
После диагностики отключите debug-лог, чтобы избежать быстрого роста файла на продакшн-сервере. Для постоянного мониторинга используйте stub_status и системы сбора метрик.
Полный аудит модулей Nginx: объединяем статические и динамические в один список
При миграции сервера, аудите безопасности или подготовке документации нужен полный перечень активных модулей - статических и динамических в одном списке. Ручной сбор чреват пропусками. Автоматизируем процесс скриптом.
Пример скрипта для автоматического сбора списка модулей
Скрипт извлекает статические модули из nginx -V, динамические - из конфигурационных файлов, дедуплицирует и выводит единый список. Сохраните его как nginx_modules_audit.sh и выполните с правами на чтение конфигов Nginx.
#!/bin/bash
# Аудит модулей Nginx: статические + динамические
echo "=== Статические модули (из nginx -V) ==="
STATIC=$(nginx -V 2>&1 | tr ' ' '\n' | grep '\-\-with-' | sed 's/--with-//' | sort -u)
echo "$STATIC"
echo ""
echo "=== Динамические модули (из load_module) ==="
DYNAMIC=$(grep -rh load_module /etc/nginx/ 2>/dev/null | sed "s/.*load_module\s\+\(.*\);$/\1/" | sort -u)
if [ -z "$DYNAMIC" ]; then
echo "Динамические модули не найдены в конфигурации."
else
echo "$DYNAMIC"
fi
echo ""
echo "=== Сводка ==="
STATIC_COUNT=$(echo "$STATIC" | grep -c '^' 2>/dev/null || echo 0)
DYNAMIC_COUNT=$(echo "$DYNAMIC" | grep -c '^' 2>/dev/null || echo 0)
echo "Статических модулей: $STATIC_COUNT"
echo "Динамических модулей: $DYNAMIC_COUNT"
echo "Всего активных: $((STATIC_COUNT + DYNAMIC_COUNT))"
Скрипт требует права на выполнение nginx -V и чтение /etc/nginx/. Запустите от root или пользователя с соответствующими привилегиями. Результат - готовый отчет для документации или сравнения конфигураций между серверами.
Интерпретация вывода: статические модули всегда активны, динамические - активны, если load_module присутствует в обработанной конфигурации (nginx -T подтвердит это). Файлы .so в директории модулей без соответствующей директивы в конфиге - неактивны. Они занимают место на диске, но не влияют на работу Nginx.
Для углубленного анализа логов и выявления проблем, связанных с модулями, используйте готовые команды grep и awk для анализа логов Nginx.
Типичные проблемы и их решение: когда модуль не отображается или не работает
Модуль прописан в конфигурации, .so-файл на месте, но функционал недоступен. Либо после обновления Nginx часть модулей перестала загружаться. Разберем частые причины и способы устранения.
Ошибка version mismatch: модуль собран для другой версии Nginx
Динамические модули компилируются под конкретную версию Nginx. При несовпадении бинарных интерфейсов (API) возникает ошибка:
nginx: [emerg] module "/usr/lib/nginx/modules/ngx_http_geoip2_module.so" version mismatch, expected 1.25.3 but got 1.24.0
Проверьте версию Nginx:
nginx -v
Проверьте, для какой версии собран модуль. Если модуль из пакета, посмотрите его метаданные:
# Debian/Ubuntu
apt-cache show nginx-module-geoip2 | grep Version
# RHEL/AlmaLinux
rpm -qi nginx-module-geoip2 | grep Version
Решение: устанавливайте модули из того же репозитория и той же версии, что и сам Nginx. Если вы используете официальный репозиторий nginx.org, все пакеты модулей синхронизированы с основной версией Nginx в этом репозитории. При самостоятельной сборке Nginx перекомпилируйте модули с теми же исходниками. Процесс описан в пошаговом руководстве по сборке Nginx.
Модуль не загружается: права доступа и SELinux
Nginx запускается от пользователя nginx или www-data. Если .so-файл недоступен для чтения этому пользователю, загрузка провалится. Проверьте права:
ls -l /usr/lib/nginx/modules/ngx_http_geoip2_module.so
Ожидаемый вывод: -rw-r--r-- 1 root root 245K Jul 26 10:00 ngx_http_geoip2_module.so. Файл должен быть читаем для всех (o+r). Исправьте при необходимости:
chmod 644 /usr/lib/nginx/modules/ngx_http_geoip2_module.so
На RHEL-подобных системах (CentOS, AlmaLinux, Rocky Linux) загрузку модулей может блокировать SELinux. Временная проверка - переключение SELinux в permissive mode:
setenforce 0
systemctl restart nginx
Если модуль загрузился, проблема в политике SELinux. Верните enforcing mode и настройте контекст безопасности:
setenforce 1
chcon -t httpd_modules_t /usr/lib64/nginx/modules/*.so
Для постоянного решения создайте политику через audit2allow на основе записей в audit.log. Детали выходят за рамки этой статьи, но ключевой принцип - файлы модулей должны иметь контекст httpd_modules_t.
Дополнительно проверьте зависимости модуля. Некоторые динамические модули требуют внешних библиотек. Например, ngx_http_geoip2_module зависит от libmaxminddb. Отсутствие библиотеки вызывает ошибку при загрузке:
nginx: [emerg] dlopen() "/usr/lib/nginx/modules/ngx_http_geoip2_module.so" failed:
libmaxminddb.so.0: cannot open shared object file: No such file or directory
Установите недостающую зависимость через пакетный менеджер, и модуль загрузится.
Заключение: чек-лист для быстрой проверки модулей Nginx
Сохраните этот чек-лист для регулярного аудита или экстренной диагностики:
- Статические модули:
nginx -V 2>&1 | tr ' ' '\n' | grep '\-\-with-' | sed 's/--with-//' | sort. Фиксируете список, сравниваете с ожидаемым. - Динамические модули в конфигурации:
grep -r load_module /etc/nginx/. Сверяете с файлами в директории модулей (ls /usr/lib/nginx/modules/или путь из--modules-path). - Верификация загрузки:
nginx -T 2>&1 | grep -E 'load_module|error'. Отсутствие ошибок - модули загружены. - Диагностика проблем: включаете debug-лог (
error_log /var/log/nginx/debug.log debug;), перезапускаете Nginx, анализируетеgrep -i module /var/log/nginx/debug.log. - Проверка совместимости: сверяете версию Nginx (
nginx -v) с версией модулей из пакетов. При несовпадении - обновляете из одного репозитория. - Права и SELinux:
ls -lна файлы.so(должны быть читаемы),chcon -t httpd_modules_tдля SELinux-систем.
Регулярный аудит модулей - часть поддержания безопасности сервера. Неиспользуемые динамические модули удаляйте или комментируйте load_module. Каждый активный модуль увеличивает поверхность атаки. После аудита модулей настройте мониторинг upstream и алертинг на ошибки, чтобы получать уведомления о сбоях загрузки модулей при старте Nginx.