Nginx Linux

Nginx: try_files не работает для вложенных маршрутов

  • Обновлено
  • Чтение ≈ 4 минуты
  • Нужны права администратора

Краткий ответ

Если главная страница приложения открывается, а обновление вложенного адреса приводит к 404, Nginx может искать физический файл вместо передачи запроса маршрутизатору приложения.

В этой статье
  1. Что означает и когда возникает ошибка
  2. Причины и как их различить
  3. Пошаговая диагностика и исправление
  4. Проверка результата
  5. Если проблема осталась

#Что означает и когда возникает ошибка

Решение зависит от архитектуры: для одностраничного приложения допустима передача отсутствующих файлов на index.html, а для PHP-приложения часто нужен внутренний переход на index.php. Нельзя смешивать оба подхода без проверки.

#Причины и как их различить

Возможная причинаКак узнатьЧто делать
Одностраничное приложение управляет маршрутами в браузереПри переходе по ссылке маршрут работает, а при прямом обновлении выдаётся 404 от Nginx.Вложенный маршрут существует только в JavaScript, физического каталога на диске нет.Направлять неизвестные пути на index.html при сохранении обработки статических файлов.
Серверный PHP-маршрутизатор получает не тот URLФреймворку нужен index.php и строка запроса, но Nginx возвращает 404.В access.log 404 для /account/settings/, при этом PHP-код не запускался.Применить конфигурацию front controller именно используемого фреймворка.
location или root/alias перекрывают правилоБолее приоритетное регулярное или точное location отрабатывает раньше ожидаемого.Правило try_files есть в конфигурации, но срабатывает другой блок.Проверить порядок location и фактический root/alias.

#Пошаговая диагностика и исправление

  1. Установите, кто должен обрабатывать URLВозьмите два адреса: рабочий / и сбойный вложенный, например /account/settings/. Откройте вложенный адрес через меню приложения, затем обновите страницу и откройте тот же URL в новой вкладке. Если после внутренней навигации всё работает, а при обновлении 404 — это типичная проблема маршрутизации. Если 404 выдаёт само приложение даже без обновления, исправление try_files может не помочь.
  2. Выясните тип приложения до правкиПосмотрите документацию сборки сайта или спросите разработчика: React/Vue со статическим index.html, PHP-фреймворк с index.php либо обычные файлы. По SSH проверьте фактический root и содержимое публичного каталога безопасной командой ls -la по существующему пути. Не переименовывайте index.php в index.html и не меняйте обработчик PHP для решения 404.
  3. Найдите соответствующий server и locationЗапустите sudo nginx -T и найдите server_name, root, alias, все location, try_files, error_page для домена. Учитывайте, что location = имеет особый приоритет, а регулярные выражения могут перехватывать запросы. Проверьте именно путь вложенного URL: совпадение location / ещё не означает, что его обслуживает этот блок.
  4. Для статического одностраничного приложения используйте fallbackЕсли это подтверждённый статический SPA, в основном location / уместна логика try_files $uri $uri/ /index.html;. Она сначала проверяет реальный файл/каталог, иначе отдаёт индекс. Перед применением проверьте, что index.html существует внутри верного root. Исключите из такой подстановки API, приватные маршруты и отсутствующие файлы ресурсов, если они должны возвращать честный 404.
  5. Для PHP-фреймворка используйте его правила маршрутизацииЕсли приложение использует front controller, изучите пример конфигурации конкретного фреймворка. Типовой подход try_files $uri $uri/ /index.php?$query_string; передаёт маршрут в PHP, но корректность требует действующего location ~ \.php$, безопасного SCRIPT_FILENAME и правильно настроенного PHP-FPM. Не вставляйте PHP-блок из интернета без учёта действующего root и защиты от исполнения загруженных файлов.
  6. Сохраните копию и примените только подходящий вариантСкопируйте реальный конфигурационный файл с отметкой даты, измените одно правило, выполните sudo nginx -t. Если тест успешен, выполните sudo systemctl reload nginx; если нет — поправьте ошибку, не перезапуская службу. Если 404 сменился на неожиданное выполнение PHP или выдачу приватных файлов, немедленно верните исходный файл и повторите тест и reload.
  7. Проверьте вложенные страницы и настоящие ошибкиОткройте 3–4 вложенных маршрута напрямую и после обновления, проверьте загрузку CSS/JS и API во вкладке «Сеть». Заведомо несуществующий статический ресурс должен сохранять корректный 404, если так предусмотрено архитектурой. Для SPA убедитесь, что JavaScript-приложение показывает собственную страницу «не найдено», не скрывая серверные ошибки.
  8. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1Сервер Linux, доступ по SSH с sudo; конфигурация может содержать секреты, смотрите локально.
    Linux · Терминал (Bash)КомандаНужен sudo
    Сервер Linux, доступ по SSH с sudo; конфигурация может содержать секреты, смотрите локально.
    sudo nginx -t
    sudo nginx -T 2>&1 | grep -nE "server_name|try_files|root |alias |location"
    Вариант 2Пример только для статического SPA; не подходит автоматически для PHP-сайтов и API.
    Nginx
    Пример только для статического SPA; не подходит автоматически для PHP-сайтов и API.
    location / {
    try_files $uri $uri/ /index.html;
}
    Вариант 3Иллюстрация маршрутизации через PHP; необходима отдельно корректная и защищённая настройка PHP-FPM.
    Nginx
    Иллюстрация маршрутизации через PHP; необходима отдельно корректная и защищённая настройка PHP-FPM.
    location / {
    try_files $uri $uri/ /index.php?$query_string;
}

#Проверка результата

Успех: прямое открытие и обновление существующего вложенного маршрута дают ожидаемую страницу, а несуществующие пути обрабатываются предсказуемо.

#Если проблема осталась

Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.

Так эту ошибку тоже называют

502 502 Bad Gateway в Nginx: причины и быстрый способ найти виновника Ответ `502 Bad Gateway` означает, что Nginx, выступая шлюзом, не смог получить корректный ответ от backend-сервера — чаще всего PHP-FPM или приложения за `proxy_pass`. С… Сайты, серверы и хостинг Nginx NginxLinux Nginx: 502 Bad Gateway с PHP-FPM — причины и решение Проверьте, запущен ли php-fpm, путь к сокету и права. Сайты, серверы и хостинг Nginx Linux 504 Nginx 504 Gateway Time-out — причины и как исправить Ошибка `504 Gateway Time-out` значит, что Nginx отправил запрос приложению (PHP-FPM, Node.js, другому серверу), но не дождался ответа за отведённое время. Чаще всего при… Сайты, серверы и хостинг Nginx NginxLinuxPHP-FPM Nginx: ERR_TOO_MANY_REDIRECTS — цикл редиректов http/https и www — причины и решение Найдите петлю редиректов в конфиге и CMS, проверьте Cloudflare и proxy. Сайты, серверы и хостинг Nginx Linux 504 Nginx: 504 Gateway Time-out — upstream не отвечает вовремя — причины и решение Nginx выдаёт 504 Gateway Time-out, когда backend (PHP-FPM, Node.js, прокси) не успевает ответить за отведённое время. Увеличьте proxy_read_timeout или fastcgi_read_timeo… Сайты, серверы и хостинг Nginx Linux

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.