Nginx не работает 404

Nginx — Ошибка 404 при загрузке некоторых файлов

Nginx последней версии — 1.17.8 Debian 10 Ссылка — https://ustim.ru/soft

В конфиге домена root директория и alias расположены в разных местах

А вопрос собственно такой… Почему некоторые файлы скачиваются норм, а некоторые выдают 404 ошибку? Например этот скачивается… файл ISO, размер 3ГБ А этот выдает ошибку… файл RAR, размер 800МБ.

Права на все файлы 775 www-data:www-data

а что в error логе nginx?

Ну т.е. ты показываешь сервер конфиг для 80 и кидаешь ссылки на 443. На кого это расчтитано

В логе пишет что файл в директории не найден.

*2020/03/05 09:43:48 [error] 5302#5302: 7965 open() «/var/www/ustim.ru/htdocs/soft/test.rar» failed (2: No such file or directory), client: 78.107.254.14, server: www.ustim.ru, request: «GET /soft/test.rar HTTP/1.1», host: «ustim.ru», referrer: «https://ustim.ru/soft/»

Ну т.е. ты показываешь сервер конфиг для 80 и кидаешь ссылки на 443. На кого это расчтитано

Зачем вам смотреть на лишний мусор в конфиге? Это не имеет абсолютно никакого значения.

Зачем вам смотреть на лишний мусор в конфиге? Это не имеет абсолютно никакого значения.

Да ладно? Совершенно две разные настройки и никакого значения?
/var/www/ustim.ru/htdocs/soft/test.rar
и
/mnt/fs-soft/

Да ладно? Совершенно две разные настройки и никакого значения?

Господи, да чем вам редирект от Certbot?? Вы бы лучше по сути ответили… Если вам интересно, то ниже в секцию сервера добавлено только:

Это путь по location

Это алиас, который (как все утверждают) можно указывать ВНЕ директории root.

Это алиас, который (как все утверждают) можно указывать ВНЕ директории root.

Кто ВСЕ эти люди?!

Сcылки, пароли, явки.

На самом деле нет не совсем так, как хотелось бы

Читать до наступления просветления 😉

Это алиас, который (как все утверждают) можно указывать ВНЕ директории root. Кто ВСЕ эти люди?! Сcылки, пароли, явки. На самом деле нет не совсем так, как хотелось бы

А чем вам офф документация мешает? Там вроде написано…

Синтаксис: alias путь; Умолчание: — Контекст: location

Задаёт замену для указанного location’а. Например, при такой конфигурации

на запрос “/i/top.gif” будет отдан файл /data/w3/images/top.gif.

В значении параметра путь можно использовать переменные, кроме $document_root и $realpath_root.

Я же вроде по-русски написал, что какие-то файлы открываются, а какие-то нет

Я документацию читаю первым делом, как правило.

Она мне не мешает.

Но заметьте, что там нигде не явно сказано, что alias может указывать вне корневого каталога веб-сервера.

Вы это домыслили, но на самом деле это не так, почему и возникла эта тема =)

Сам пока думаю над этим вопрос, но времени тестить нету)

Я же вроде по-русски написал, что какие-то файлы открываются, а какие-то нет

Тогда бы у него ни один файл не открывался.

Всем спасибо, методом экспериментов проблема была найдена. Все дело в подключенном PHP, который по сути для файлопомойки совсем не нужен.

А теперь таки сходите по моей ссылке, там не на 100% , но нечто подобное)

Тогда бы у него ни один файл не открывался.

Не факт, test.rar лежит в корне и например могут быть другие права от вышестоящей директории с acl. Да вариантов много.

Но заметьте, что там нигде не явно сказано, что alias может указывать вне корневого каталога веб-сервера.

И тем не менее он может

И, тем не менее, кажись, что фокус в этом

nginx first searches for the most specific prefix location given by literal strings regardless of the listed order. In the configuration above the only prefix location is “/” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific prefix location found earlier.

ТС, поставь не теме отметку «Решено».

который not-a-bug. Т.е. с алиасом все не так однозначно)

Источник

WordPress и Nginx: исправление ошибки 404 при открытии любых страниц

Как настроить Nginx так, чтобы посты и страницы при включённых ЧПУ открывались корректно.

В WordPress можно использовать человеко-понятные url (ЧПУ), чтобы из адреса страниц и людям, и поисковым системам сразу становилось понятно, о чём содержимое. Например, взглянув на tx8.ru/kak-podruzhit-tt-rss-i-fail2ban/, видно, что на странице информация про настройку fail2ban. ЧПУ включаются в админке сайта, раздел «Настройки постоянных ссылок».

Настройки постоянных ссылок в WordPress

Так вот, любой режим именования ссылок, кроме простого (простой — это не ЧПУ), в стандартной конфигурации веб-сервера Nginx не работает. Все страницы, кроме главной, будут выдавать ошибку с кодом 404.

Ошибка 404 — такой страницы нет

Решение простое. Нужно настроить Nginx так, чтобы все запросы к страницам обрабатывались через index.php. Найдите файл конфигурации сайта (скорее всего, это будет nginx.conf или какой-то другой *.conf в каталоге /etc/nginx) и поищите такой блок:

Замените его на:

Строки «try_files $uri $uri/ =404;» и/или блока «location / < >» может не быть (отсутствие второго маловероятно, без него сайт вообще не должен работать), тогда просто добавьте правильный вариант.

После перезапустите службу nginx, чтобы настройки вступили в силу, затем зайдите в админку сайта — Настройки — Постоянные ссылки и нажмите «Сохранить». Готово, страницы должны открываться корректно!

Совет: когда нужно быстро запустить сайт на WordPress с работающим ЧПУ, я использую такой шаблон:

Для работы на «постоянке» не рекомендую, так как не указано хранение логов и нет никаких настроек безопасности, но если намудрили с настройкой Nginx, можете начать с него.

Источник

Ошибка 404 not found Nginx

Веб-серверы Nginx и Apache мало похожи друг на друга, и их отличия касаются не только особенностей подключения пользователей, но и обработки URL на сервере. Очень часто новые пользователи Nginx получают ошибку 404 для URL, которые, по сути, должны были бы работать.

В этой статье рассмотрим, почему возникает ошибка «404 not found Nginx», а также способы её устранения и отладки.Мы не будем разбираться с ситуацией, когда файла действительно нет на сервере — это решение, не требующее пояснений. Мы рассмотрим проблему обработки location в Nginx.

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

Давайте сначала разберёмся, как обрабатываются URL в Nginx. Когда веб-сервер определил, к какому блоку server (сайту) нужно передать запрос пользователя, просматриваются все префиксные блоки location и выбирается тот, который подходит лучше всего. Например, рассмотрим стандартную конфигурацию для WordPress. Здесь префиксные location отмечены зелёным, а с регулярным выражением — оранжевым:

index index.html index.php;

Префиксные локейшены всегда начинаются с символа /. Регулярные же содержат символы регулярных выражений:

$ ^ * и так далее. Если пользователь запрашивает favicon.ico, то будет выбран второй location, так как он лучше всего соответствует запросу, при любом другом запросе будет выбран location /, так как он соответствует всем запросам, а других префиксных location у нас нет. Это просто, а дальше начинается магия. После того, как был найден нужный location, Nginx начинает проверять все регулярные выражения в порядке их следования в конфигурационном файле.

При первом же совпадении Nginx останавливает поиск и передаёт управление этому location. Или, если совпадений не было найдено, используется ранее обнаруженный префиксный location. Например, если запрос заканчивается на .php, то первый location будет проигнорирован, а управление передастся четвёртому (

Таким образом, любое неверно составленное регулярное выражение в любой части конфигурационного файла может полностью всё сломать. Поэтому разработчики рекомендуют по минимум использовать регулярные выражения. Что касается вложенных location, то обрабатываются они так же как и основные, только уже после передачи управления в нужный location. Путём чтения конфигурационного файла понять, какой location вызывает 404 сложно, поэтому, чтобы исправить ошибку, нам понадобиться режим отладки Nginx.

Как включить режим отладки Nginx?

Сначала нам необходимо установить версию Nginx с поддержкой отладки. Чтобы проверить, поддерживает ли ваша текущая версия этот режим, наберите:

В выводе должна быть строчка «—with-debug». Если её нет, значит отладка не поддерживается, и надо установить версию с поддержкой. В CentOS такой пакет называется nginx-debug. Для его установки наберите:

Теперь появился ещё один исполняемый файл, и он собран уже с поддержкой отладки:

Откройте конфигурационный файл вашего сайта или глобальный конфигурационный файл, если вы не задавали настройки логов отдельно для каждого сайта, и в конце стоки error_log замените error на debug:

Останавливаем обычную версию и запускаем версию с отладкой:

Как исправить «404 Not Found Nginx»?

1. Регулярные выражения

Как я уже сказал выше, самой частой проблемой, которая вызывает 404, являются регулярные выражения. Смотрим, что происходит в лог файле:

Видим, что серверу пришёл запрос /vstats. Дальше он проверяет location: /, /robots.txt, /vatsts/, /site-control/. Здесь уже можем понять, в чём проблема — промазали на один слеш. Дальше проверяются все регулярные выражения, и, так как в них ничего найдено не было, выбирается location /.

Далее директива try_files пытается найти файл /vstats, не находит и ищет index.php, который, в свою очередь, возвращает 404.

Если мы наберём, то что ожидает видеть Nginx — /vstats/, то откроется наша страница статистики.

Если мы добавим к конфигурационному файлу ещё один location с регулярным выражением, например:

То абсолютно все запросы будут обрабатываться именно этим регулярным выражением и, естественно, что ничего работать не будет. Видим, что приходит запрос /vstats/:

Он совпадает с префиксным location, но потом Nginx видит наше регулярное выражение и передаёт управление ему.

Поэтому будьте очень осторожны с регулярными выражениями, если они вам нужны, то размещайте их только внутри префиксных location, чтобы ограничить их область действия этим location, иначе может возникнуть ошибка 404 nginx.

2. Недостаточно памяти

Если php-скрипту не хватило оперативной памяти для выполнения, и его процесс был убит операционной системой, то Nginx тоже может вернуть ошибку 404. Такое поведение вы будете наблюдать, когда скрипт очень долго выполняется, а потом появляется «404 Not Found» или страница ошибки вашего движка. Обычно эта неисправность тоже видна в отладочном логе.

Решить такую проблему можно, освободив память на сервере, часто такое может возникать из-за утечек памяти в php, когда процессы php-fpm занимают почти всю память на сервере. Поэтому перезапуск php-fpm решает проблему:

Чтобы избежать этой проблемы в будущем, можно настроить автоматический перезапуск процессов после обработки определённого количества запросов. Например каждые 200 запросов:

3. Не найден index

Если вы запрашиваете URL вида /vstats/, но в настройках Nginx не указан файл index, который нужно использовать для этой ссылки, то у вас ничего не выйдет, и вы получите 404. Вы можете добавить директиву index в ваш location:

Или сразу в server, в Nginx все location наследуют директивы, установленные в server.

4. Другие проблемы

Подобных проблем, вызывающих 404 в Nginx, может быть очень много, но все они решаемы, и всё, что нужно для их решения, есть в отладочном логе Nginx. Просто анализируйте лог и на основе этого вносите исправления.

Выводы

В этой статье мы рассмотрели основные причины, из-за которых может возникнуть ошибка 404 not found Nginx. Как видите, может быть много проблем, но всё достаточно просто решается. А с какими проблемами, вызывающими эту ошибку, вы сталкивались? Как их решали? Напишите в комментариях!

Источник

Ошибка 404 not found Nginx

Веб-серверы Nginx и Apache мало похожи друг на друга, и их отличия касаются не только особенностей подключения пользователей, но и обработки URL на сервере. Очень часто новые пользователи Nginx получают ошибку 404 для URL, которые, по сути, должны были бы работать.

В этой статье рассмотрим, почему возникает ошибка «404 not found Nginx», а также способы её устранения и отладки.Мы не будем разбираться с ситуацией, когда файла действительно нет на сервере — это решение, не требующее пояснений. Мы рассмотрим проблему обработки location в Nginx.

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

Давайте сначала разберёмся, как обрабатываются URL в Nginx. Когда веб-сервер определил, к какому блоку server (сайту) нужно передать запрос пользователя, просматриваются все префиксные блоки location и выбирается тот, который подходит лучше всего. Например, рассмотрим стандартную конфигурацию для WordPress. Здесь префиксные location отмечены зелёным, а с регулярным выражением — оранжевым:

location / <
index index.html index.php;
>
location /favicon.ico <
access_log off;
>
location

* \.(gif|jpg|png)$ <
expires 30d;
>
location

\.php$ <
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
>

Префиксные локейшены всегда начинаются с символа /. Регулярные же содержат символы регулярных выражений:

$ ^ * и так далее. Если пользователь запрашивает favicon.ico, то будет выбран второй location, так как он лучше всего соответствует запросу, при любом другом запросе будет выбран location /, так как он соответствует всем запросам, а других префиксных location у нас нет. Это просто, а дальше начинается магия. После того, как был найден нужный location, Nginx начинает проверять все регулярные выражения в порядке их следования в конфигурационном файле.

При первом же совпадении Nginx останавливает поиск и передаёт управление этому location. Или, если совпадений не было найдено, используется ранее обнаруженный префиксный location. Например, если запрос заканчивается на .php, то первый location будет проигнорирован, а управление передастся четвёртому (

Таким образом, любое неверно составленное регулярное выражение в любой части конфигурационного файла может полностью всё сломать. Поэтому разработчики рекомендуют по минимум использовать регулярные выражения. Что касается вложенных location, то обрабатываются они так же как и основные, только уже после передачи управления в нужный location. Путём чтения конфигурационного файла понять, какой location вызывает 404 сложно, поэтому, чтобы исправить ошибку, нам понадобиться режим отладки Nginx.

Как включить режим отладки Nginx?

Сначала нам необходимо установить версию Nginx с поддержкой отладки. Чтобы проверить, поддерживает ли ваша текущая версия этот режим, наберите:

В выводе должна быть строчка «—with-debug». Если её нет, значит отладка не поддерживается, и надо установить версию с поддержкой. В CentOS такой пакет называется nginx-debug. Для его установки наберите:

sudo yum install nginx-debug

Теперь появился ещё один исполняемый файл, и он собран уже с поддержкой отладки:

Откройте конфигурационный файл вашего сайта или глобальный конфигурационный файл, если вы не задавали настройки логов отдельно для каждого сайта, и в конце стоки error_log замените error на debug:

error_log /var/log/nginx/domains/test.losst.ru.error.log debug

Останавливаем обычную версию и запускаем версию с отладкой:

systemctl stop nginx
systemctl start nginx-debug

Как исправить «404 Not Found Nginx»?

1. Регулярные выражения

Как я уже сказал выше, самой частой проблемой, которая вызывает 404, являются регулярные выражения. Смотрим, что происходит в лог файле:

tail -f /var/log/nginx/domains/test.losst.ru.error.log

Видим, что серверу пришёл запрос /vstats. Дальше он проверяет location: /, /robots.txt, /vatsts/, /site-control/. Здесь уже можем понять, в чём проблема — промазали на один слеш. Дальше проверяются все регулярные выражения, и, так как в них ничего найдено не было, выбирается location /.

Далее директива try_files пытается найти файл /vstats, не находит и ищет index.php, который, в свою очередь, возвращает 404.

Если мы наберём, то что ожидает видеть Nginx — /vstats/, то откроется наша страница статистики.

Если мы добавим к конфигурационному файлу ещё один location с регулярным выражением, например:

То абсолютно все запросы будут обрабатываться именно этим регулярным выражением и, естественно, что ничего работать не будет. Видим, что приходит запрос /vstats/:

Он совпадает с префиксным location, но потом Nginx видит наше регулярное выражение и передаёт управление ему.

Поэтому будьте очень осторожны с регулярными выражениями, если они вам нужны, то размещайте их только внутри префиксных location, чтобы ограничить их область действия этим location, иначе может возникнуть ошибка 404 nginx.

2. Недостаточно памяти

Если php-скрипту не хватило оперативной памяти для выполнения, и его процесс был убит операционной системой, то Nginx тоже может вернуть ошибку 404. Такое поведение вы будете наблюдать, когда скрипт очень долго выполняется, а потом появляется «404 Not Found» или страница ошибки вашего движка. Обычно эта неисправность тоже видна в отладочном логе.

Решить такую проблему можно, освободив память на сервере, часто такое может возникать из-за утечек памяти в php, когда процессы php-fpm занимают почти всю память на сервере. Поэтому перезапуск php-fpm решает проблему:

systemctl restart php-fpm

Чтобы избежать этой проблемы в будущем, можно настроить автоматический перезапуск процессов после обработки определённого количества запросов. Например каждые 200 запросов:

3. Не найден index

Если вы запрашиваете URL вида /vstats/, но в настройках Nginx не указан файл index, который нужно использовать для этой ссылки, то у вас ничего не выйдет, и вы получите 404. Вы можете добавить директиву index в ваш location:

location / <
index index.php index.html index.htm;
>

Или сразу в server, в Nginx все location наследуют директивы, установленные в server.

4. Другие проблемы

Подобных проблем, вызывающих 404 в Nginx, может быть очень много, но все они решаемы, и всё, что нужно для их решения, есть в отладочном логе Nginx. Просто анализируйте лог и на основе этого вносите исправления.

Выводы

В этой статье мы рассмотрели основные причины, из-за которых может возникнуть ошибка 404 not found Nginx. Как видите, может быть много проблем, но всё достаточно просто решается. А с какими проблемами, вызывающими эту ошибку, вы сталкивались? Как их решали? Напишите в комментариях!

Источник