SystemdDoctor
мешает работе nginx конфигурация частое

nginx reload не применяет изменения

Если systemctl reload nginx проходит без ошибок, а поведение не меняется, почти всегда правили файл, который не участвует в итоговой конфигурации. Проверяется это одной командой: nginx -T печатает всё, что реально применено.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Файл не включён в конфигурацию

    Файл лежит в sites-available без ссылки в sites-enabled, или каталог не подключён через include. Правка есть, а nginx её не видит.

  2. Запрос обслуживает другой блок server

    При совпадении имён или при отсутствии подходящего блока nginx выбирает блок по умолчанию. Правка в «вашем» блоке при этом не действует.

  3. Ответ отдаётся из кеша

    При настроенном кеше nginx может отдавать сохранённый ответ, не обращаясь к приложению. Изменения в приложении при этом не видны.

  4. Старые рабочие процессы дорабатывают соединения

    При мягкой перезагрузке прежние процессы остаются, пока не закроют текущие соединения. Долгие соединения (websocket, загрузки) продлевают это состояние.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Итоговая конфигурация: единственный надёжный ответ на вопрос «что применено».

sudo nginx -T 2>/dev/null | head -40

Время запуска процессов: видно, заменились ли рабочие процессы.

ps -o pid,lstart,cmd -C nginx

Чем именно выполняется перезагрузка настроек.

systemctl show nginx -p ExecReload

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Файл не включён в конфигурацию
Почему происходит
Файл лежит в sites-available без ссылки в sites-enabled, или каталог не подключён через include. Правка есть, а nginx её не видит.
Как проверить
Поищите свою правку в итоговой конфигурации. 
sudo nginx -T 2>/dev/null | grep -n "ваша_директива"
Как исправить
Включите файл ссылкой или добавьте нужный include, затем перезагрузите настройки. 
sudo ln -s /etc/nginx/sites-available/site.conf /etc/nginx/sites-enabled/ && sudo nginx -t && sudo systemctl reload nginx
2. Запрос обслуживает другой блок server
Почему происходит
При совпадении имён или при отсутствии подходящего блока nginx выбирает блок по умолчанию. Правка в «вашем» блоке при этом не действует.
Как проверить
Посмотрите, какой блок отвечает на запрос. 
curl -sI -H "Host: example.org" http://127.0.0.1/ | head -5
sudo nginx -T 2>/dev/null | grep -n "server_name" | head
Как исправить
Уберите конфликт имён или задайте default_server там, где он действительно нужен.
3. Ответ отдаётся из кеша
Почему происходит
При настроенном кеше nginx может отдавать сохранённый ответ, не обращаясь к приложению. Изменения в приложении при этом не видны.
Как проверить
Посмотрите настройки кеша и заголовки ответа. 
sudo nginx -T 2>/dev/null | grep -E "proxy_cache|fastcgi_cache"
curl -sI http://127.0.0.1/ | grep -i cache
Как исправить
Очистите кеш или проверьте с обходом кеша. Настройку кеширования стоит помнить при любой отладке.
4. Старые рабочие процессы дорабатывают соединения
Почему происходит
При мягкой перезагрузке прежние процессы остаются, пока не закроют текущие соединения. Долгие соединения (websocket, загрузки) продлевают это состояние.
Как проверить
Посмотрите процессы nginx и время их запуска. 
ps -o pid,lstart,cmd -C nginx
Как исправить
Дождитесь завершения или, если это допустимо, перезапустите службу полностью.

Пример вывода

Правка в файле, который не включён в конфигурацию. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

$ sudo systemctl reload nginx
$ sudo nginx -T 2>/dev/null | grep -c "client_max_body_size 50m"
0
$ ls -l /etc/nginx/sites-enabled/
lrwxrwxrwx 1 root root 34 Sep 10 11:20 default -> /etc/nginx/sites-available/default

Файл с правкой не включён: в sites-enabled только default. Команда nginx -T показывает это сразу.

Связанные ошибки

Где встречается чаще всего

Источники