Не работает nginx ubuntu
Обновлено: 07.07.2024
Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache,Memcached, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его).
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если сервис, с которым nginx работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения
Также, причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута
413 Request Entity Too Large
Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку
и заменить значение на нужное. Например, мы увеличим размер загружаеамых файлов до 30Mb
Также, можно отключить проверку тела ответа полностью значением ноль:
После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx
Как перезагрузить nginx
Для перезагрузки NGINX используйте restart или reload.
Команда в консоли:
Эти команды остановят и перезапустят сервер NGINX.
Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:
Проверить правильность конфигурации можно командой
В чём разница между reload и restart
Как происходит перезагрузка в NGINX:
Команда посылается серверу
Сервер анализирует конфигурационный файл
Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
Если конфигурация содержит ошибки, то при использовании
restart процесс перезагрузки сервера прерывается, сервер не запускается
reload сервер откатывается назад к старой конфигурации, работа продолжается
Веб-серверы 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 будет проигнорирован, а управление передастся четвёртому (
Как включить режим отладки Nginx?
Сначала нам необходимо установить версию Nginx с поддержкой отладки. Чтобы проверить, поддерживает ли ваша текущая версия этот режим, наберите:
В выводе должна быть строчка "--with-debug". Если её нет, значит отладка не поддерживается, и надо установить версию с поддержкой. В CentOS такой пакет называется nginx-debug. Для его установки наберите:
sudo yum install nginx-debug
Теперь появился ещё один исполняемый файл, и он собран уже с поддержкой отладки:
Откройте конфигурационный файл вашего сайта или глобальный конфигурационный файл, если вы не задавали настройки логов отдельно для каждого сайта, и в конце стоки error_log замените error на debug:
Останавливаем обычную версию и запускаем версию с отладкой:
systemctl stop nginx
systemctl start nginx-debug
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 решает проблему:
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. Как видите, может быть много проблем, но всё достаточно просто решается. А с какими проблемами, вызывающими эту ошибку, вы сталкивались? Как их решали? Напишите в комментариях!
Об ошибке
Поиск файла конфигурации NGINX
По умолчанию файлы конфигурации NGINX находятся в папке /etc/nginx . Если вы просмотрите этот каталог, то найдете несколько конфигурационных файлов для различных модулей сервера.
Чтобы отредактировать этот файл, используйте команду:
Некорректный индексный файл
Если ни один из этих трех файлов не будет найден в каталоге, NGINX вернет ошибку « 403 Forbidden ».
Примечание . Имена файлов чувствительны к регистру. Если nginx.conf указывает index.html , а файл называется Index.html , это приведет к ошибке « 403 Forbidden ».
Если вы хотите использовать имя индексного файла, которое ваш веб-сервер NGINX не распознает, отредактируйте nginx.conf и добавьте имя файла в строку конфигурации индекса.
Например, чтобы добавить index.py в список распознаваемых индексных файлов, отредактируйте эту строку следующим образом:
Сохраните изменения, а затем перезапустите NGINX командой:
Автоиндекс
Альтернативным решением является разрешение индекса директории. Индекс директории означает, что если индексный файл не найден, сервер отобразит все содержимое директории.
По соображениям безопасности индекс директории в NGINX по умолчанию отключен.
При « 403 forbidden NGINX », если вы хотите показать индекс директории в ситуациях, когда NGINX не может найти ( идентифицировать ) файл, отредактируйте nginx.conf , как описано выше, и добавьте в него две следующие директивы:
Эти директивы должны быть добавлены в блок location . Можно либо добавить их в существующий блок location/ , либо добавить новый. Окончательный результат должен выглядеть так:
Также можно активировать индексирование директории в определенной папке, если не хотите, чтобы она была доступна для всего сайта:
Сохраните изменения в файле, затем перезапустите NGINX командой:
Права доступа к файлам
Идентификация пользователя NGINX
Для начала нужно определить, от имени какого пользователя запущен NGINX . Для этого используйте команду:
В этом примере рабочий процесс NGINX работает от имени пользователя nginx .
Установите права собственности на файл
Измените права собственности на все файлы в директориях нижних уровней на пользователя nginx с помощью команды:
Установите права доступа
Затем перейдите в корневой каталог веб-документа:
Измените права доступа для всех файлов в этой директории с помощью команды:
Дайте знать, что вы думаете по данной теме материала в комментариях. За комментарии, лайки, дизлайки, отклики, подписки огромное вам спасибо!
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. За комментарии, подписки, отклики, лайки, дизлайки низкий вам поклон!
В этом инструкции мы установим NGINX в качестве автономного веб-сервера на Ubuntu 20.04.
Установка NGINX на Ubuntu 20.04
Прежде чем приступить к установке NGINX. Сначала запустите команду sudo apt-get update, чтобы получить информацию о новых и обновленных пакетах Ubuntu.
Nginx доступен в репозитории пакетов Ubuntu. Поэтому Nginx очень лего установить с помощью следующей команды:
Проверьте состояние службы NGINX
Давайте сделаем быструю проверку, чтобы подтвердить статус сервиса NGINX. Для этого выполните следующую команду:
Вывод приведенной выше команды подтверждает, что NGINX активен и работает.
Чтобы проверить установленную версию Nginx, запустите:
Проверьте версию Nginx на Ubuntu
Эти данные показывают, что установлен nginx версии 1.18.0. На момент написания статьи это последняя версия для Ubuntu 20.04.
Тестирование веб-сервера NGINX
Веб-страница по умолчанию NGINX
Теперь требуется, убедится, что соответствующий порт открыт в вашем брандмауэре. Например, если вы включили Брандмауэр UFW на своем сервере Ubuntu. Вы должны попытаться обновить правила брандмауэра. Для того чтобы разрешить NGINX общаться по порту 80 и/или 443 следующим образом.
Команда разрешает NGINX работать на порту 80:
Команда разрешает NGINX работать на порту 443:
Настройка серверных блоков NGINX
Если вы хотите разместить несколько веб-сайтов на одном веб-сервере NGINX, то вам нужно будет настроить серверные блоки. Серверные блоки также называются виртуальными хостами (в основном в Apache).
Выполните следующую команду, для того чтоб отобразить содержимое файла блока сервера по умолчанию.
$ sudo cat /etc/nginx/sites-available/default | more
Нажмите пробел на клавиатуре, чтобы прокрутить страницу вниз. Вы увидите сведения о конфигурации сервера по умолчанию. Например такие данные как номер порта прослушивания, корневой каталог документа (т. е. базовая папка для хранения содержимого веб-сайта), индексный файл и имя сервера.
Вы также должны увидеть раздел под названием конфигурация виртуального хоста, как показано ниже.
Вы можете настроить свой дополнительный веб-сайт здесь, но лучше создать отдельный файл блока сервера и оставить файл по умолчанию как есть.
А пока скопируйте приведенный выше пример конфигурации и сохраните его в текстовом редакторе. Так как мы будем использовать эту информацию в ближайшее время.
Создать корень сайта
Создание индексного файла
В этом примере я использую nano, но вы можете использовать свой любимый текстовый редактор. Вы можете скопировать и вставить следующий HTML код для тестирования.
<!DOCTYPE html>
<html>
<head>
<title>Welcome to Domain1!</title>
<style>
body width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
>
</style>
</head>
<body>
<h1>Welcome to Domain1!</h1>
<p>If you see this page, the Domain1 website is working!</p>
</body>
</html>
Сохраните изменения и закройте текстовый редактор.
Создание серверного блока
Следующим шагом является создание файла серверного блока. Предназначен он для хранения сведений о конфигурации дополнительного веб-сайта. Выполните следующую команду.
$ sudo nano /etc/nginx/sites-available/domain1
Сохраните изменения и закройте этот файл.
Включить серверный блок
Чтобы NGINX знал, что дополнительный веб-сайт доступен, выполните следующую команду для создания символической ссылки на файл блока сервера.
$ ln -s /etc/nginx/sites-available/domain1 /etc/nginx/sites-enabled
Проверьте свою конфигурацию
$ sudo nginx-t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Вы можете запустить sudo service nginx reload, чтобы перезагрузить файлы конфигов.
Протестируйте свой новый сайт
Откройте веб-браузер и введите свой новый адрес веб-сайта. Вы должны увидеть содержимое индексного файла, созданного для вашего нового веб-сайта. А не веб-страницу NGINX по умолчанию.
Хостинг дополнительного сайта с использованием серверного блока
Основные команды для управления NGINX сервером
Вот основные команды Nginx сервера для управления.
Команда restart остановит службу, а затем запустит ее снова.
$ sudo systemctl restart nginx
Команда reload сообщает NGINX перезагрузить конфигурационные файлы, но без остановки службы.
Команда stop остановит службу NGINX.
Включение Nginx при загрузке системы.
Примечание: служба Nginx включена по умолчанию. И автоматически стартует при загрузке сервера.
Основные файлы конфигурации и журналов NGINX
/etc/nginx этот файл содержит все конфигурационные файлы NGINX.
/etc/nginx/sites-available этот файл содержит дынные серверных блоков, в которых хранят сведения о конфигурации. Требуется это для обслуживания одного или нескольких веб-сайтов.
/etc/nginx/sites-enabled данный файл содержит конфигурации одного или нескольких включенных веб-сайтов.
/etc/nginx/nginx. conf это основной конфигурационный файл, который считывает директивы конфигурации в других файлах.
/var / log/nginx / access. log этот файл хранит данные о всех посещениях вашего сайта
/var/log/nginx/error. log этот файл предназначен для хранения ошибок NGINX
Заключение
Следуя этой инструкции, вы можете запустить NGINX с одним или несколькими веб-сайтами на вашем сервере Ubuntu 20.04. Но если вдруг у вас возникли какие-либо проблемы, то пожалуйста, не стесняйтесь сообщить мне об этом в разделе комментариев ниже. Я сделаю все возможное, чтобы помочь вам.
Читайте также: