Nginx не видит изменения конфига

MAATRIX

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

Первое: перезагрузили ли вы Nginx

Самая частая причина — банальная: конфиг сохранён на диске, но Nginx работает с тем, что загрузил при старте. Он не перечитывает файлы автоматически. После любой правки нужно явно сказать ему перечитать конфиг. Правильная команда — reload, она применяет изменения без разрыва соединений:

# сначала проверить синтаксис — обязательно
nginx -t
# применить изменения без простоя
systemctl reload nginx
# либо напрямую
nginx -s reload

Именно reload, а не restart: reload мягко подхватывает новый конфиг, не роняя активные соединения. Но перед ним всегда делайте nginx -t — он проверяет синтаксис и не даёт применить сломанный конфиг, из-за которого сервер мог бы вообще не подняться. Если после reload изменения так и не видны, а nginx -t показывает syntax is ok — значит, дело не в применении, а в том, ЧТО именно вы правили. Об этом дальше.

Проверяем, тот ли файл вы редактируете

Вторая по частоте причина — правки уходят не в тот файл. У Nginx главный конфиг подключает другие через include, и реальная конфигурация сайта может лежать в sites-enabled, conf.d или отдельном файле, а вы правите то, что не подключено. Особенно коварна пара sites-available/sites-enabled: файл в sites-available не действует, пока на него нет симлинка в sites-enabled.

# что реально включено
nginx -T | grep -E 'server_name|listen|root' | head -40
# полный собранный конфиг, как его видит Nginx
nginx -T | less
# симлинки включённых сайтов
ls -l /etc/nginx/sites-enabled/

Команда nginx -T (заглавная) — ваш главный инструмент: она выводит полный собранный конфиг со всеми include, ровно как его видит сервер. Если ваших изменений в этом выводе нет — вы правите неподключённый файл. Проверьте, есть ли симлинк из sites-available в sites-enabled, и не дублируется ли server_name в двух местах. Правьте именно тот файл, что попадает в nginx -T.

Стоит пояснить, почему разделение на sites-available и sites-enabled сбивает с толку чаще всего. Логика в том, что первый каталог хранит все конфиги сайтов «про запас», а второй — только реально включённые, и связаны они символической ссылкой. Вы можете держать в sites-available десяток заготовок, но действовать будут лишь те, на которые есть симлинк в sites-enabled. Классическая ошибка — создать новый файл сайта в sites-available, тщательно его настроить и забыть сделать ссылку: Nginx о нём попросту не знает. Обратная ошибка — редактировать файл в sites-available, когда сайт уже включён копией, а не ссылкой. Вывод nginx -T снимает всю эту неоднозначность разом, показывая итоговую картину.

Виноват кэш: браузера, самого Nginx или CDN

Бывает, конфиг применился верно, а вы всё равно видите старое — потому что ответ отдаётся из кэша, а не генерируется заново. Кэш бывает на нескольких уровнях. Браузерный: старая страница или редирект (особенно постоянный, 301) прочно оседает в браузере. Проверяйте в приватном окне или с жёстким сбросом кэша, а лучше — через curl, который кэша не имеет:

# чистый запрос без кэша браузера, с заголовками
curl -I https://example.com
# проверить конкретный редирект
curl -sI https://example.com/old | grep -i location

Если curl показывает новое поведение, а браузер старое — проблема в браузерном кэше, а не в сервере. Если у вас настроен кэш самого Nginx (proxy_cache), он может отдавать сохранённый ответ, пока тот не устареет, — тогда чистят каталог кэша. А если перед сайтом стоит CDN (Cloudflare и подобные), он кэширует ответы у себя, и изменения не видны, пока не сбросить кэш на его стороне. Именно поэтому важно тестировать через curl напрямую к серверу — так вы отделяете конфиг от кэшей.

301-редирект, который «прилип»

Отдельно стоит разобрать частый случай, который выглядит как «Nginx не видит изменения», а на деле — прилипший постоянный редирект. Если вы когда-то поставили редирект с кодом 301 (Moved Permanently), браузеры и промежуточные кэши запоминают его надолго и продолжают перенаправлять, даже когда вы убрали правило из конфига. Человек меняет конфиг, а браузер упорно шлёт его на старый адрес, минуя сервер.

Диагностируется это тем же curl -I: если сервер уже не отдаёт редирект, а браузер всё равно перенаправляет — виноват кэш браузера с прилипшим 301. Лечится очисткой кэша браузера или проверкой в приватном окне. Практический вывод на будущее: для временных перенаправлений используйте код 302 (временный), который не кэшируется так агрессивно, а 301 ставьте только тогда, когда точно уверены, что переезд постоянный. Это избавляет от «неубиваемых» редиректов.

Права, синтаксис и подводные камни

Есть ещё несколько причин, по которым правка не срабатывает. Ошибка в синтаксисе: если nginx -t ругается, reload не применит конфиг, и сервер продолжит работать на старом — читайте, что именно и в какой строке не так. Права на файлы: если новый корень сайта или сокет недоступен пользователю Nginx, он не сможет отдать контент, и в логе ошибок будет permission denied. Всегда держите под рукой лог ошибок:

# что пишет Nginx при проблемах
tail -f /var/log/nginx/error.log
# проверить, что процесс перечитал конфиг (время старта воркеров)
ps -o pid,etime,cmd -C nginx

Ещё встречается путаница с несколькими server-блоками: если два блока слушают один порт и подходят под один server_name, Nginx использует первый подходящий, и ваши правки во втором игнорируются. А иногда изменения не видны из-за того, что перед Nginx стоит ещё один слой — балансировщик или второй прокси, — и правите вы не тот узел, что реально отвечает клиенту. Лог ошибок и nginx -T вместе почти всегда указывают на настоящую причину.

Профилактика: чтобы правки применялись предсказуемо

Чтобы не гадать каждый раз, заведите дисциплину работы с конфигом. Всегда прогоняйте nginx -t перед применением — это ловит синтаксис до того, как он что-то сломает. Держите структуру конфигов в порядке: один сайт — один файл в sites-available с понятным симлинком в sites-enabled, без дублей server_name. Тестируйте результат через curl напрямую, отделяя поведение сервера от кэшей.

Полный контроль над конфигурацией даёт только собственный сервер с root-доступом, где вы правите файлы напрямую и видите все уровни. У MAATRIX VPS под Nginx доступны в локациях RU, US и UK, с оплатой из России картой или криптой. Когда вы владеете всей цепочкой — от конфига до перезагрузки — «Nginx не видит изменения» превращается в понятный чек-лист из трёх пунктов, а не в загадку.

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