Как посмотреть установленные модули Nginx: полный гайд по командам | AdminWiki

Как посмотреть установленные модули Nginx: полный гайд по командам

26 июля 2026 10 мин. чтения

Быстрый старт: как за 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

Сохраните этот чек-лист для регулярного аудита или экстренной диагностики:

  1. Статические модули: nginx -V 2>&1 | tr ' ' '\n' | grep '\-\-with-' | sed 's/--with-//' | sort. Фиксируете список, сравниваете с ожидаемым.
  2. Динамические модули в конфигурации: grep -r load_module /etc/nginx/. Сверяете с файлами в директории модулей (ls /usr/lib/nginx/modules/ или путь из --modules-path).
  3. Верификация загрузки: nginx -T 2>&1 | grep -E 'load_module|error'. Отсутствие ошибок - модули загружены.
  4. Диагностика проблем: включаете debug-лог (error_log /var/log/nginx/debug.log debug;), перезапускаете Nginx, анализируете grep -i module /var/log/nginx/debug.log.
  5. Проверка совместимости: сверяете версию Nginx (nginx -v) с версией модулей из пакетов. При несовпадении - обновляете из одного репозитория.
  6. Права и SELinux: ls -l на файлы .so (должны быть читаемы), chcon -t httpd_modules_t для SELinux-систем.

Регулярный аудит модулей - часть поддержания безопасности сервера. Неиспользуемые динамические модули удаляйте или комментируйте load_module. Каждый активный модуль увеличивает поверхность атаки. После аудита модулей настройте мониторинг upstream и алертинг на ошибки, чтобы получать уведомления о сбоях загрузки модулей при старте Nginx.

Поделиться:
Сохранить гайд? В закладки браузера