Nginx: не стартует после правки конфига — причины и решение

MAATRIX

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

Первое действие: проверьте конфиг через nginx -t

Не гадайте и не перезапускайте сервис вслепую — попросите Nginx сам проверить конфигурацию. Эта команда указывает точный файл и строку с ошибкой:

nginx -t

Вывод либо скажет syntax is ok и test is successful, либо покажет что-то вроде [emerg] unknown directive ... in /etc/nginx/conf.d/site.conf:12. Число после двоеточия — номер строки. Это ваша отправная точка: почти всегда проблема ровно там или строкой выше. Открывайте указанный файл, смотрите на названную строку — и в большинстве случаев ошибка находится сразу. Пока nginx -t не говорит successful, перезапускать сервис бессмысленно: он не поднимется.

Причина 1: пропущена точка с запятой или скобка

Самая частая ошибка — забытая ; в конце директивы или незакрытая фигурная скобка. Nginx строг к синтаксису: каждая простая директива заканчивается точкой с запятой, а блоки (server, location) обрамляются фигурными скобками. Если nginx -t жалуется на unexpected "}" или directive is not terminated by ";", ищите пропущенный символ на указанной строке или прямо перед ней.

Часто ошибка визуально «выше», чем показывает номер строки: Nginx замечает проблему там, где натыкается на следующую директиву. Проверьте конец предыдущей строки — не хватает ли ;. После правки снова прогоните nginx -t и, только получив successful, перезапускайте:

nginx -t && systemctl reload nginx

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

Причина 2: конфликт портов или повторный listen

Если ошибка вида bind() to 0.0.0.0:80 failed (98: Address already in use), значит порт уже занят — другим процессом или дублирующимся блоком server. Сначала посмотрите, кто держит порт:

ss -tlnp | grep :80

Часто это второй экземпляр Nginx, оставшийся от неудачного перезапуска, Apache на том же порту или случайно продублированный listen 80 default_server в двух конфигах. Уберите дубль или остановите конфликтующий сервис. Если это завис старый процесс Nginx, аккуратно остановите сервис целиком и запустите заново:

systemctl stop nginx
systemctl start nginx

Две директивы default_server на одном порту тоже валят старт — default_server должен быть только один на пару адрес:порт.

Причина 3: неверный путь к файлу или сертификату

Nginx не поднимется, если в конфиге указан путь, которого нет: несуществующий корень сайта, отсутствующий файл SSL-сертификата или ключа, битый include. Ошибки выглядят как cannot load certificate ... No such file or directory или open() ... failed. Проверьте, что все указанные пути реально существуют:

ls -l /etc/letsencrypt/live/example.com/

Частый случай — переименовали или удалили сертификат, а в конфиге остался старый путь; или домен в пути не совпадает с реальным каталогом. Приведите пути в конфиге в соответствие с фактическим расположением файлов. То же касается root сайта и подключаемых через include файлов: если каталога или файла нет, старт прервётся. После исправления снова nginx -t.

Причина 4: дубликат директивы или неизвестная директива

Ошибка duplicate ... directive означает, что одна и та же директива задана дважды в одном контексте — например, два server_name или два root в одном блоке. Уберите лишнюю. Ошибка unknown directive говорит, что Nginx не понимает слово: это либо опечатка в названии директивы, либо директива из модуля, который не установлен. Проверьте написание по документации и наличие нужного модуля.

Иногда неизвестная директива появляется после копирования конфига из чужого мануала, рассчитанного на другую сборку Nginx или на дополнительный модуль. В этом случае либо установите нужный модуль, либо уберите директиву, если она не критична. Всегда сверяйтесь с выводом nginx -t — он называет и файл, и строку, так что искать вслепую не придётся. После любой правки — снова тест, потом перезагрузка.

Как быстро восстановиться, если правок было много

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

cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
nginx -t && systemctl reload nginx

Если копии нет, а сайт лежит, временно закомментируйте подозрительные блоки и добивайтесь nginx -t successful итеративно, включая директивы обратно по одной. Логи тоже помогают: смотрите journalctl -u nginx и /var/log/nginx/error.log — там причина падения написана словами. Восстановив работу, сразу сделайте резервную копию рабочего конфига, чтобы в следующий раз откат занял секунды.

Профилактика: как не ронять Nginx правками

Чтобы правки конфига не превращались в аварию, выработайте простой ритуал: сделали копию файла, внесли изменения, прогнали nginx -t, и только при successful выполнили systemctl reload nginx. Команда reload в отличие от restart применяет конфиг без разрыва текущих соединений и не уронит сайт, если конфиг вдруг невалиден. Держите конфиги под контролем версий или хотя бы с датированными бэкапами — это превращает любой сбой в мгновенный откат.

Ещё полезно разбивать конфигурацию на отдельные файлы по сайтам в conf.d или sites-available: так ошибка в одном сайте локализуется, и её проще найти и отключить, не трогая остальные. Регулярная проверка nginx -t перед каждой перезагрузкой — самая дешёвая страховка от простоя, которая входит в привычку за пару дней.

Если вы правите конфиги на боевом сервере, полезно иметь второй канал доступа на случай, когда сайт лёг: панель управления сервером или консоль провайдера. Тогда даже при неудачной правке вы спокойно откатитесь, не завися от того, что через упавший веб-сервер что-то работает. И держите под рукой команды диагностики — nginx -t, journalctl -u nginx, просмотр error.log: этой тройки хватает, чтобы найти причину практически любого отказа старта за минуту.

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