Гид по технологиям

Как исправить ошибку 404 Not Found на Nginx

• 8 min read • Nginx • Обновлено 24 Nov 2025
Исправить 404 на Nginx — практическое руководство
Исправить 404 на Nginx — практическое руководство

TL;DR

Если ваш сайт возвращает 404 Not Found на Nginx — начните с простых проверок: URL, регистр имени файла, расположение и права доступа к файлу, затем проверьте конфигурацию Nginx (root/alias, location, try_files) и логи. Включите пошаговый плейбук восстановления и тесты, чтобы быстро откатывать изменения и предотвратить повторение.

Иллюстрация ошибки 404 Not Found на сервере Nginx

Содержание

  • Что такое ошибка 404 Not Found на Nginx?
  • Почему возникает ошибка 404 на Nginx?
  • Пошаговое исправление ошибки 404 на Nginx
    • Проверки уровня URL и контента
    • Проверки файловой системы и прав
    • Настройки конфигурации Nginx
    • Правила переписывания (rewrite) и try_files
    • Логи и отладка
  • Плейбук восстановления: быстрый SOP
  • Рольовые чек-листы
  • Тесты и критерии приёмки
  • Когда перечисленные шаги не помогают — альтернативы и крайние случаи
  • Как предотвратить появление 404 в будущем
  • Безопасность и усиление Nginx
  • Часто задаваемые вопросы

Что такое ошибка 404 Not Found на Nginx?

Ошибка 404 Not Found — стандартный код HTTP, который сообщает, что сервер (в данном случае Nginx) не смог найти запрошенный ресурс (страницу, файл, путь). Это не всегда «поломка» приложения: иногда ресурс намеренно удалён. В других случаях — это следствие опечатки, неправильной конфигурации сервера или проблем с правами доступа.

Краткое определение: 404 — ответ сервера о том, что путь существует, но целевой файл или обработчик не найден.

Важно: Nginx сам по себе возвращает 404, когда ни одно правило location не отработало на существующий файл или когда конфигурация директив (root, alias, try_files) неверна.

Почему возникает ошибка 404 на Nginx?

Частые причины:

  • Неправильный или опечатанный URL.
  • Файл перемещён или удалён.
  • Неправильные права доступа или владелец файла.
  • Проблемы с регистром имени файла на файловой системе (Linux — чувствительна к регистру).
  • Неверная настройка root vs alias в блоке server/location.
  • Плохая конфигурация location/try_files/rewrite, которые перенаправляют на несуществующий путь.
  • Символические ссылки, указывающие в неверную папку или неразрешённые Nginx.
  • SELinux/AppArmor-блокировки (в системах с этими механизмами).

Пошаговое исправление ошибки 404 на Nginx

Ниже — детальный чек-лист c командами и примерами, чтобы диагностировать и исправить 404.

1. Проверьте URL и кэш

  • Скопируйте URL напрямую в адресную строку — проверьте опечатки, лишние слеши или пробелы.
  • Проверьте кодирование символов в ссылке (например, пробелы, кириллица).
  • Очистите кэш браузера или попробуйте другой браузер/инкогнито.
  • Если URL шаблонный (CMS, роутер), убедитесь, что роут действительно зарегистрирован.

2. Проверьте регистр имени файла и расширение

Linux-системы чувствительны к регистру. Проверьте наличие файла точно с тем же именем и расширением.

Пример:

# в каталоге сайта
ls -la /var/www/example.com/html
# ищем точное имя
ls -l /var/www/example.com/html | grep -i "page.html"

Если файл называется page.html, запрос Page.html вернёт 404.

3. Убедитесь, что файл находится в ожидаемом каталоге

Путь, который Nginx использует для отдачи файлов, зависит от директивы root или alias в конфигурации.

Пример проверки:

# найдём все конфиги, где упоминается домен
sudo grep -R "server_name example.com" /etc/nginx -n
# проверим директивы в нужном конфиге
sudo sed -n '1,200p' /etc/nginx/sites-enabled/example.com

Если root указывает на /var/www/example.com/html, а файл лежит в /srv/www/site, либо перенесите файл, либо обновите root.

4. Проверьте права доступа и владельца

Nginx должен иметь права чтения (и выполняемые права для директорий) на файлы и каталоги.

Стандартные права и владельцы:

  • Файлы: 644 (rw-r–r–)
  • Папки: 755 (rwxr-xr-x)
  • Владелец чаще всего: пользователь процесса Nginx (например, www-data или nginx)

Команды для проверки и исправления:

# проверить
ls -l /var/www/example.com/html/index.html
# исправить права
sudo chmod 644 /var/www/example.com/html/index.html
sudo chmod 755 /var/www/example.com/html
# изменить владельца
sudo chown -R www-data:www-data /var/www/example.com/html

На системах с SELinux необходимо проверить контекст:

ls -Z /var/www/example.com/html
# если контекст неверный, можно временно назначить корректный
sudo chcon -R -t httpd_sys_content_t /var/www/example.com/html

(Используйте chcon только если SELinux у вас включён; в противном случае команда ничего не даст.)

5. Проверка конфигурации Nginx: root, alias, index, location

Ключевые моменты, которые часто приводят к 404:

  • Разница между root и alias. alias заменяет весь путь, root добавляет путь запроса к значению root.
  • Порядок и приоритет блоков location (точные совпадения =, префиксные, регулярные).
  • Неверный путь index (index index.html index.php;).

Пример ошибочного использования alias:

location /static/ {
    alias /var/www/example.com/static; # Нужен слеш в конце для корректного сопоставления
}

Если забыть слеши или неправильно указать alias, запросы будут смотреть не туда.

Команды для проверки конфигурации и перезагрузки:

sudo nginx -t
sudo systemctl reload nginx
# или
sudo systemctl restart nginx

Всегда сначала проверяйте конфигnginx -t перед перезагрузкой.

6. Проверьте правила переписывания и try_files

Директива try_files — один из самых надёжных способов избежать 404 при правильной настройке. Часто 404 появляется, если try_files указывает на несуществующий файл или на внутреннюю ошибку.

Типичный пример для статического сайта:

location / {
    try_files $uri $uri/ =404;
}

Для приложений на PHP с фронт-контроллером:

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

Если правило переписывания неверно, попробуйте временно закомментировать rewrite/try_files и проверять прямой доступ к файлам.

7. Анализ логов

Логи — главный источник правды.

  • Ошибки: /var/log/nginx/error.log
  • Доступ: /var/log/nginx/access.log

Примеры команд:

sudo tail -n 200 /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log | grep "404"

Если в error.log есть сообщения о permission denied, no such file or directory или неправильном root — действуйте в соответствии с текстом ошибки.

8. Включение подробной отладки (временно)

Для локального дебага можно включить более подробный лог:

# в nginx.conf
error_log /var/log/nginx/error.log notice; # или info, debug

Отладочный уровень debug может быть очень подробным и снижать производительность — включайте только кратковременно.

9. Проверьте сторонние факторы

  • CDN/кеширующий прокси может отдавать устаревшую страницу 404 — очистите кеш.
  • Балансировщик или reverse-proxy может перенаправлять запрос на неправильный upstream.
  • Проблемы с правами на симлинках — убедитесь, что nginx имеет доступ к целевой папке симлинка.

Плейбук восстановления: быстрый SOP

  1. Сохраните текущий конфиг:
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup-$(date +%F-%T)
  1. Проверка состояния сервера и доступа к файлу:

  1. Быстрая диагностика (10 минут): URL → файл → права → config test → reload.

  2. Если изменяли конфиг: nginx -t → systemctl reload nginx.

  3. Если изменения вызвали регресс: вернуть бэкап и reload.

  4. Протоколирование: зафиксируйте сделанные изменения в системе управления изменениями (CM).

Ролевые чек-листы

  • Администратор / DevOps:

    • Проверить nginx -t
    • Проверить права и владельца
    • Просмотреть логи error.log и access.log
    • Перезагрузить сервис безопасно

  • Разработчик фронтенда:

    • Убедиться, что маршруты зарегистрированы правильно
    • Проверить ссылки и относительные пути
    • Убедиться, что сборка деплоится в правильный каталог

  • Контент-редактор / менеджер сайта:

    • Проверить внутренние ссылки CMS
    • Использовать 301 для перемещённых страниц
    • Обновить sitemap и robots.txt при перемещении контента

Тесты и критерии приёмки

Критерии приёмки для успешного исправления:

  • Запрос конкретного URL возвращает 200 (или перенаправление 301/302, если ожидается).
  • В access.log больше не появляются 404 для данного пути в течение заданного периода тестирования.
  • При изменении конфигурации — nginx -t проходит без ошибок и сервис перезагружается.
  • Права и владелец соответствуют политике безопасности (нет лишних 777).

Тестовые случаи:

  • Запрос к index.html → 200
  • Запрос к несуществующему файлу → 404 (если это ожидаемо)
  • Запрос к маршруту приложения → 200
  • Проверка через curl с заголовками хоста (Host) и cookie, если маршруты зависят от них

Когда описанные шаги не помогают — альтернативы и крайние случаи

  • Приложение использует внутренний фреймворк/роутер и возвращает 404 уже на уровне приложения: проверьте логи приложения.
  • Если у вас несколько Nginx в цепочке (LB + origin), убедитесь, что запрос доходит до правильного бэкенда.
  • В средах с контейнерами проверьте тома и точки монтирования: файл может отсутствовать в контейнере.
  • SELinux/AppArmor: стандартные права могут быть корректны, но доступ блокируется политиками безопасности.

Как предотвратить появление 404 в будущем

  • Внедрите процесс резервного копирования конфигураций (git для конфигов).
  • Применяйте соглашения об именовании файлов и директорий.
  • Настройте мониторинг и алерты (порог по числу 404 за минуту).
  • Автоматически тестируйте основные URL после деплоя (smoke tests).
  • Используйте 301-редиректы при перемещении страниц и поддерживайте актуальную карту сайта.
  • Регулярно проверяйте и обновляйте правила rewrite/try_files при изменениях приложения.

Безопасность и усиление Nginx

Несколько рекомендаций для защиты и стабильности (коротко):

  • Отключите server_tokens для скрытия версии Nginx.
  • Настройте rate limiting (limit_req_zone/limit_req) для защиты от простых DDoS.
  • Используйте TLS с современными наборами шифров; включите HSTS.
  • Включите HTTP/2 при наличии нагрузки для ускорения загрузки.
  • Логи и мониторинг: храните и анализируйте access/error логи, интегрируйте с SIEM при необходимости.

Пример простых директив:

server_tokens off;
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

Шаблоны конфигураций и сниппеты (cheat sheet)

  1. Базовый сервер для статического сайта:
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}
  1. Фронт-контроллер для PHP (NGINX + PHP-FPM):
server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
  1. Правильное использование alias:
location /media/ {
    alias /var/storage/media/; # слеш в конце важен
    try_files $uri $uri/ =404;
}

Часто задаваемые вопросы

Что делать, если nginx -t выдаёт “no such file or directory”?

Проверьте путь, указанный в директивах root/alias, и наличие включаемых файлов (include). Убедитесь, что у пользователя, запускающего nginx, есть право читать конфиг и доступ к файловой системе.

Нужен ли try_files для всех сайтов?

Нет, но try_files — надёжный способ обеспечить корректную отдачу статических файлов и fallback на фронт-контроллер. Для простых статических сайтов достаточно try_files $uri $uri/ =404.

Как быстро понять, откуда приходит 404 — от Nginx или приложения?

Проверьте access.log: если код 404 отмечен в access.log Nginx, посмотрите upstream логи (если есть) и error.log. Если Nginx проксирует запросы на бэкенд, 404 может приходить от него — проверьте ответ от upstream (X-Served-By, заголовки, логи приложения).

Итог

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

Image credit: Error 404 by DepositPhotos. Все скриншоты — Danish Ghafoor.

Поделиться: X/Twitter Facebook LinkedIn Telegram
Автор
Редакция

Похожие материалы

Как быстро включить фонарик на Android
Android.

Как быстро включить фонарик на Android

Как делиться экраном в Discord — руководство
Руководство

Как делиться экраном в Discord — руководство

Установка Microsoft Teredo в Windows 10
Windows

Установка Microsoft Teredo в Windows 10

Красный индикатор CPU: причины и исправления
Аппаратное обеспечение

Красный индикатор CPU: причины и исправления

Исправить ошибку xapofx1_5.dll — руководство
Windows

Исправить ошибку xapofx1_5.dll — руководство

GPU scaling на AMD: как включить и устранить проблему
Руководства

GPU scaling на AMD: как включить и устранить проблему