#Симптом и границы применимости
В конфигурационном файле изменена директива, но HTTP-ответ остаётся прежним. Причины: изменён не тот файл/server/location, конфигурация не перечитана либо более специфичное правило перекрывает настройку.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Изменён неиспользуемый файлПанель может генерировать активные конфигурации в другом каталоге. | nginx -T не содержит отредактированную директиву | Проверить include и фактический conf-path |
| Изменение не применилосьРабочая конфигурация продолжает действовать. | nginx -t падает, reload не выполнен | Проверить вывод теста и журнал службы |
| Наследование и выбор locationБолее специфичный блок может иметь собственное значение. | Новая директива присутствует, но для URL работает другой location | Сопоставить server_name, listen и маршруты |
#Пошаговая диагностика и исправление
- Определите проверяемую настройкуЗапишите название директивы, путь файла и ожидаемый эффект: например, конкретный заголовок или размер запроса. Выберите безопасный запрос, результат которого можно повторять. Не используйте только кэш браузера как доказательство применения конфигурации.
- Узнайте текущий бинарный файл и расположение конфигурацииПо SSH выполните nginx -V. Ищите параметры --conf-path и --prefix, затем проверьте, как запускается служба. Если Nginx работает в контейнере или установлен из панели, команда хоста может относиться не к тому экземпляру.Linux · Терминал (Bash)КомандаДля systemctl доступно в Linux с systemd.
nginx -V 2>&1systemctl show nginx -p ExecStart -p ExecReload
- Убедитесь, что изменение попало в действующую конфигурациюВыполните nginx -T и найдите нужную директиву в контексте нужного домена; вывод содержит комментарии с именами включённых файлов. Если редактор менял файл, которого нет среди include, возвращайтесь к реальному источнику конфигурации. Не правьте автоматически генерируемые конфиги напрямую, не изучив панель.Linux · Терминал (Bash)КомандаНужен sudoПример поиска; замените имена директив своим случаем.
sudo nginx -T 2>&1 | grep -nE "configuration file|server_name|location |client_max_body_size|add_header"
- Проверьте синтаксис и журнал перечитыванияЕсли nginx -t неуспешен, прочтите строку с именем файла и номером строки, исправьте конкретную ошибку. Затем выполните reload только при успешном тесте и убедитесь, что systemctl не сообщил об ошибке. На некоторых системах команда reload называется иначе.Linux · Терминал (Bash)С осторожностьюНужен sudoПри неуспешном тесте reload не запускается; данные конфигурации сохраните заранее.
sudo nginx -t && sudo systemctl reload nginxsudo systemctl status nginx --no-pagerКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- Проверьте выбор виртуального хоста и locationСравните запрошенное имя, IP и порт. У Nginx может быть default_server для неподходящего имени, а location /api/ перекрывает параметры location /. При тесте локального IP сохраняйте правильный Host и для HTTPS — SNI. Не отключайте чужие сайты ради проверки.
- Исключите кэш и вторую точку обслуживанияПроверьте прямой ответ origin и ответ через CDN по возможности. Для изменения HTTP-заголовка используйте curl -I, для изменений тела — браузер с отключённым кэшем. Если изменения сохраняются только до перезагрузки, панель хостинга может перегенерировать конфиг — меняйте параметры её штатными средствами.
#Как проверить результат
Повторите тот же тестовый запрос с тем же Host и URL, зафиксируйте изменившийся HTTP-ответ или поведение. Выполните nginx -t и убедитесь, что на соседних сайтах нет регрессий.
#Если проблема не устранена
Если nginx -T показывает нужное значение и reload успешен, но эффекта нет, исследуйте более специфичные location, наследование директив и кэш; если после перезагрузки изменения пропадают — изучите конфигурационный генератор.