Nginx: открывается 404 на статических файлах (open() failed: No such file or directory)

#Как nginx формирует путь

Для root nginx добавляет URI к указанному пути: root /var/www/site; location /static/ {} при запросе /static/app.css ищет /var/www/site/static/app.css. Для alias часть URI, совпавшая с location, заменяется на путь из alias: location /static/ { alias /var/www/assets/; } ищет /var/www/assets/app.css. Путаница между ними — самая частая причина 404 на статике. Сообщение в error.log содержит точный путь, который nginx пытался открыть, и этого достаточно, чтобы увидеть расхождение.

#Типичные причины

#Порядок

1. Откройте error.log и найдите путь в сообщении open() ..Подключитесь к серверу по SSH, выполните sudo tail -n 50 /var/log/nginx/error.log и воспроизведите конкретный адрес статического файла в браузере. Скопируйте путь после open() и URL запроса: Nginx показывает файл, который он пытался открыть, — это позволяет отличить отсутствие файла от прав и неправильного правила location.
2. Проверьте, существует ли такой файлПроверьте ls -l "/фактический/путь/файла" с путём из error.log. Если файла нет, найдите его в каталоге сборки: возможно, не загружены файлы frontend или в HTML указан старый адрес. Если файл есть, дополнительно проверьте регистр имени и командой namei -l доступ к родительским каталогам.
3. Определите обработавший запрос location и путь к файлуВыполните sudo nginx -T 2>&1 | grep -nE "server_name|root|alias|location", найдите нужный виртуальный хост. При root /var/www/site; Nginx прибавляет URI запроса к корню, а при alias заменяет совпадающую часть URI указанным каталогом; прочитайте правило целиком и сопоставьте рассчитанный путь со строкой из error.log.
4. Для alias проверьте совпадение завершающих слэшей в location и aliasЕсли используется location /static/ { alias /srv/assets/; }, убедитесь, что завершающий слэш в location и alias согласован; запрос /static/app.css должен вести на /srv/assets/app.css. Перед изменением скопируйте исходный блок и проверьте его на стенде. Не меняйте на root, пока не рассчитан новый путь.
5. Проверьте регистр имён: на Linux App.css и app.cssНа Linux выполните ls -la в реальном каталоге и сравните имя файла посимвольно: App.css и app.css различаются. Исправьте либо путь в HTML/сборке, либо имя файла, избегая переименования библиотек, на которые ссылаются другие страницы. При использовании CDN проверьте, обновилась ли версия ресурсов.
6. Проверьте права на файл и родительские каталогиЕсли файл существует, а журнал сообщает Permission denied вместо No such file, проверьте процесс Nginx и namei -l /путь/файл. У пользователя Nginx должны быть права прохода через каталоги и чтения файла; если используется ACL, дополнительно посмотрите getfacl. Не применяйте массовый chmod на всё дерево сайта.
7. Проверьте порядок location и приоритет регулярных выраженийПроверьте приоритет точного location =, префиксных правил и регулярных выражений location ~; специальное правило для .css/.js может перехватывать путь, отличный от ожидаемого /static/. Измените минимальный нужный блок и проверьте sudo nginx -t перед reload.
8. Проверьте SELinux на RHEL-системахНа RHEL-подобных серверах с SELinux проверьте события sudo ausearch -m AVC -ts recent и контексты каталога ls -Z. Если блокировка подтверждена, настройте правильный тип для веб-контента по политике системы. После изменений проверьте curl -I для того же URL и убедитесь в HTTP 200 и корректном содержимом.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Последние ошибки и итоговая конфигурация сайта

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Последние ошибки и итоговая конфигурация сайта

   sudo tail -n 30 /var/log/nginx/error.log

   sudo nginx -T 2>/dev/null | grep -nE "server_name|root|alias|location" | head -40

   Вариант 2Существует ли файл и доступен ли для пользователя nginx

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Существует ли файл и доступен ли для пользователя nginx

   ls -l /var/www/example.ru/public/static/app.css

   namei -l /var/www/example.ru/public/static/app.css

   sudo -u www-data test -r /var/www/example.ru/public/static/app.css && echo "читается" || echo "нет доступа"

   Вариант 3Два корректных способа раздачи статики

   NginxКомандаКопировать всёВыделить

   Два корректных способа раздачи статики

   server {

   root /var/www/example.ru/public;

   # вариант 1: root — URI добавляется к пути

   location /static/ {

   try_files $uri =404;

   }

   # вариант 2: alias — префикс location заменяется (слэши на конце должны совпадать)

   location /media/ {

   alias /var/www/example.ru/uploads/;

   }

   }

   Вариант 4Проверить и применить конфигурацию

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Проверить и применить конфигурацию

   sudo nginx -t && sudo systemctl reload nginx

   Вариант 5Проверить ответ сервера на статику

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Проверить ответ сервера на статику

   curl -I https://example.ru/static/app.css

#Docker и проксирование

Если nginx работает в контейнере, путь в root относится к файловой системе контейнера, а не хоста. Убедитесь, что каталог смонтирован через volumes, а в контейнере виден нужный файл: docker exec nginx ls -l /usr/share/nginx/html/static/. При проксировании на приложение (proxy_pass) статика может обслуживаться самим приложением, и тогда 404 вернёт оно, а не nginx: проверьте заголовок Server в ответе.