Nginx страница ошибки 404

You can setup a custom error page for every location block in your nginx.conf, or a global error page for the site as a whole.

To redirect to a simple 404 not found page for a specific location:

location /my_blog {
    error_page    404 /blog_article_not_found.html;
}

A site wide 404 page:

server {
    listen 80;
    error_page  404  /website_page_not_found.html;
    ...

You can append standard error codes together to have a single page for several types of errors:

location /my_blog {
    error_page 500 502 503 504 /server_error.html
}

To redirect to a totally different server, assuming you had an upstream server named server2 defined in your http section:

upstream server2 {
    server 10.0.0.1:80;
}
server {
    location /my_blog {
        error_page    404 @try_server2;
    }
    location @try_server2 {
        proxy_pass http://server2;
    }

The manual can give you more details, or you can search google for the terms nginx.conf and error_page for real life examples on the web.

NGINX allows you to configure custom 404 page for your website, which are automatically rendered in case a requested URL is not found on your website. This allows you to display intuitive next steps to your website visitors, when they are unable to find a page on your website. You can use these steps to configure custom error pages in NGINX, for various error codes such as 404, 403, 500, 502, etc. Here are the steps to create custom 404 page in NGINX.

Here is how to create custom 404 page in NGINX.

1. Create 404 error page

Create custom error file error404.html using text editor, or a page builder like Squarespace, WordPress, or Wix, and place it in website root folder. You can change the file name as per your requirement.

Also read : How to Limit Download Speed in NGINX

2. Open NGINX configuration file

Open terminal and run the following command to open NGINX server configuration file.

$ sudo vi /etc/nginx/nginx.conf

If you have configured separate virtual hosts for your website (e.g www.example.com), such as /etc/nginx/sites-enabled/website.conf then open its configuration with the following command

$ sudo vi /etc/nginx/sites-enabled/website.conf

Alternatively, you can also open the default virtual host configuration file.

$ sudo vi /etc/nginx/sites-enabled/default

Also read : How to Enable GZIP compression in NGINX

3. Configure Custom 404 error page

We will use the error_page directive to configure custom error page for 404 response code. You can place it in http, server, location, if server blocks.

Add the following line to your server block

server {
   ...
     error_page 404 /error404.html;
   ...
}

As per the above server block, NGINX will render error404.html page instead of returning 404:Page not found error response.

Also read : How to Enable Caching in NGINX

4. Restart NGINX Server

Run the following command to check syntax of your updated config file.

$ sudo nginx -t

If there are no errors, run the following command to restart NGINX server.

$ sudo service nginx reload #debian/ubuntu
$ systemctl restart nginx #redhat/centos

That’s it. Now NGINX will automatically return your custom error page for 404 page not found errors. Similarly, you can configure custom error pages for other error codes such as 403, 500, 502, etc. by changing error code number and response URL in error_page directive. Ubiq makes it easy to visualize data, and monitor them in real-time dashboards. Try Ubiq for free.

Каждый раз, когда NGINX сталкивается с ошибкой при попытке обработать запрос клиента, он возвращает ошибку.

Каждая ошибка включает в себя код ответа HTTP и краткое описание.

Обычно ошибка отображается пользователю с помощью простой HTML-страницы по умолчанию.

К счастью, вы можете настроить NGINX на отображение пользовательских страниц ошибок для пользователей вашего сайта или веб-приложения.

Этого можно добиться с помощью директивы error_page NGINX, которая используется для определения URI, который будет показан для указанной ошибки.

Nginx отправляет 404 на бэкэнд

Вы также можете, по желанию, использовать ее для изменения кода состояния HTTP в заголовках ответа, отправляемых клиенту.

В этом руководстве мы покажем, как настроить NGINX на использование пользовательских страниц ошибок.

Создание единой пользовательской страницы для всех ошибок NGINX

Вы можете настроить NGINX на использование одной пользовательской страницы ошибок для всех ошибок, которые он возвращает клиенту.

Начните с создания страницы ошибки.

Вот пример простой HTML-страницы, которая отображает сообщение:

 "Извините, страница не может быть загружена! Обратитесь за помощью к администратору сайта или в службу поддержки." клиенту. 

Образец кода пользовательской страницы HTML Nginx.

<!DOCTYPE html>
<html>
<head>

<style type=text/css>

* {
	-webkit-box-sizing: border-box;
	box-sizing: border-box;
}

body {
	padding: 0;
	margin: 0;
}

#notfound {
	position: relative;
	height: 100vh;
}

#notfound .notfound {
	position: absolute;
	left: 50%;
	top: 50%;
	-webkit-transform: translate(-50%, -50%);
	-ms-transform: translate(-50%, -50%);
	transform: translate(-50%, -50%);
}

.notfound {
	max-width: 520px;
	width: 100%;
	line-height: 1.4;
	text-align: center;
}

.notfound .notfound-error {
	position: relative;
	height: 200px;
	margin: 0px auto 20px;
	z-index: -1;
}

.notfound .notfound-error h1 {
	font-family: 'Montserrat', sans-serif;
	font-size: 200px;
	font-weight: 300;
	margin: 0px;
	color: #211b19;
	position: absolute;
	left: 50%;
	top: 50%;
		-webkit-transform: translate(-50%, -50%);
		-ms-transform: translate(-50%, -50%);
		transform: translate(-50%, -50%);
}

@media only screen and (max-width: 767px) {
	.notfound .notfound-error h1 {
		font-size: 148px;
	}
}

@media only screen and (max-width: 480px) {
	.notfound .notfound-error {
	height: 148px;
	margin: 0px auto 10px;
}
.notfound .notfound-error h1 {
	font-size: 120px;
	font-weight: 200px;
}
.notfound .notfound-error h2 {
	font-size: 30px;
}
.notfound a {
	padding: 7px 15px;
	font-size: 24px;
}
.h2 {
	font-size: 148px;
}
}
</style>
</head>
<body>
<div id="notfound">
	<div class="notfound">
		<h1>К сожалению, страница не может быть загружена!</a></h1>
		<div class="notfound-error">
			<p>Обратитесь за помощью к администратору сайта или в службу поддержки.</p>
		</div>
	</div>
</div>
</body>
</html>

Сохраните файл с подходящим именем, например error-page.html, и закройте его.

Затем переместите файл в корневой каталог (/var/www/html/).

Если каталог не существует, вы можете создать его с помощью команды mkdir, как показано далее:

$ sudo mkdir -p  /var/www/html/
$ sudo cp error-page.html /var/www/html/

Затем настройте NGINX на использование пользовательской страницы ошибок с помощью директивы error_page.

Создайте конфигурационный файл custom-error-page.conf в каталоге /etc/nginx/snippets/, как показано ниже:

$ sudo mkdir /etc/nginx/snippets/
$ sudo vim /etc/nginx/snippets/custom-error-page.conf

Добавьте в него следующие строки:

error_page 404 403 500 503 /error-page.html;
location = /error-page.html {
        root /var/www/html;
        internal;
}

Эта конфигурация вызывает внутреннее перенаправление на URI/error-page.html каждый раз, когда NGINX встречает любую из указанных HTTP ошибок 404, 403, 500 и 503.

Контекст местоположения указывает NGINX, где найти вашу страницу ошибки.

Сохраните файл и закройте его.

Теперь включите файл в контекст http, чтобы все блоки сервера использовали страницу ошибок, в файл /etc/nginx/nginx.conf:

$ sudo vim /etc/nginx/nginx.conf

Каталог include указывает NGINX включить конфигурацию в указанный файл .conf:

include snippets/custom-error-page.conf;

В качестве альтернативы можно включить файл для конкретного блока сервера (обычно известного как vhost), например, /etc/nginx/conf.d/mywebsite.conf.

Добавьте приведенную выше директиву include в контекст server {}.

Сохраните файл конфигурации NGINX и перезагрузите службу следующим образом:

$ sudo systemctl reload nginx.service

И проверьте через браузер, все ли работает нормально.

Создание различных пользовательских страниц для каждой ошибки NGINX

Вы также можете настроить различные пользовательские страницы ошибок для каждой HTTP-ошибки в NGINX.

Мы обнаружили хорошую коллекцию пользовательских страниц ошибок nginx на Github.

Чтобы установить репозиторий на вашем сервере, выполните следующие команды:

$ sudo git clone https://github.com/denysvitali/nginx-error-pages /srv/http/default 
$ sudo mkdir /etc/nginx/snippets/
$ sudo ln -s /srv/http/default/snippets/error_pages.conf /etc/nginx/snippets/error_pages.conf
$ sudo ln -s /srv/http/default/snippets/error_pages_content.conf /etc/nginx/snippets/error_pages_content.conf

Затем добавьте следующую конфигурацию либо в контекст http, либо в каждый серверный блок/vhost:

include snippets/error_pages.conf;

Сохраните файл конфигурации NGINX и перезагрузите службу следующим образом:

$ sudo systemctl reload nginx.service

Кроме того, проверьте с помощью браузера, работает ли конфигурация так, как задумано.

Директива error_page в NGINX позволяет перенаправлять пользователей на определенную страницу, ресурс или URL при возникновении ошибки.

Она также позволяет изменять код состояния HTTP в ответе клиенту.

Для получения дополнительной информации ознакомьтесь с документацией по странице ошибки nginx.

см. также:

• 🌐 Как увеличить время ожидания запроса в NGINX
• 🌐 Как использовать преимущества динамического резолва DNS в NGINX
• Как ограничить размер загрузки файлов в Nginx

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

В этой статье рассмотрим, почему возникает ошибка «404 not found Nginx», а также способы её устранения и отладки.Мы не будем разбираться с ситуацией, когда файла действительно нет на сервере — это решение, не требующее пояснений. Мы рассмотрим проблему обработки location в 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 будет проигнорирован, а управление передастся четвёртому (~ .php$)

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

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

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

nginx -V

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

sudo yum install nginx-debug

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

nginx-debug -V

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

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

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

systemctl stop nginx
systemctl start nginx-debug

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

systemctl restart php-fpm

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

vi /etc/php-fpm.d/www.conf

pm.max_requests = 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. Как видите, может быть много проблем, но всё достаточно просто решается. А с какими проблемами, вызывающими эту ошибку, вы сталкивались? Как их решали? Напишите в комментариях!