Как сделать чтобы все запросы шли на index nginx
Добавил пользователь Владимир З. Обновлено: 04.10.2024
В одной из прошлых статей мы говорили о том, как выполняется установка и первоначальная настройка веб-сервера Nginx в CentOS 7. Этот веб-сервер завоевал огромную популярность благодаря высокой производительности и удачной архитектуре самой программы, из-за которой такая производительность и стала возможной.
Одна из основных возможностей веб-сервера - обслуживание нескольких сайтов на одном IP-адресе и в одной программе. Эта функция реализована с помощью виртуальных хостов. В этой статье мы разберём, как выполняется настройка виртуальных хостов в Nginx. Прежде чем читать статью дальше, я рекомендую просмотреть статью настройка Nginx, чтобы понять общий синтаксис конфигурационного файла.
Настройка виртуального хоста Nginx
Вообще, у Nginx только один конфигурационный файл - это /etc/nginx/nginx.conf. Все остальные файлы из папки /etc/nginx/* подключаются в этот файл с помощью директивы include. Поэтому теоретически все виртуальные хосты или только часть из них могут быть размещены в этом файле. Однако так делать не рекомендуется.
Для этого уже существует папка /etc/nginx/sites-available/ и /etc/nginx/sites-enabled. Первая просто содержит файлы конфигурации, в каждом из которых находится отдельный виртуальный хост. Вторая папка содержит ссылки на файлы из /etc/nginx/sites-available и подключена к основному конфигурационному файлу. Даже если в вашей системе пока такая структура не используется, я рекомендую её создать, чтобы в конфигурации всегда был порядок.
1. Синтаксис виртуального хоста
Каждый виртуальный хост представляет из себя такой блок кода:
server
listen ip_адрес:порт;
server_name доменные_имена;
root /путь/к/файлам/сайта/;
index index.php index.html;
.
location / <>
.
>
Кроме того, здесь могут использоваться и другие инструкции, но эти основные и обязательные.
- listen - указывает на IP-адрес и порт, на котором программа будет ожидать соединения от этого сайта. Чтобы выбрать любой IP-адрес, можно указать звёздочку, а порт указывать обязательно. Также в этой строке можно добавить параметр default_server, тогда этот виртуальный хост будет использоваться по умолчанию;
- server_name - доменные имена, на которые будет отзываться этот хост. При отправке запроса на сервер, браузер указывает, к какому домену он обращается. Nginx анализирует этот параметр и выбирает необходимый виртуальный хост. Чтобы обрабатывать все домены, используйте символ подчеркивания _;
- root - путь к файлам сайта, которые будут открываться при запросе к этому виртуальному хосту. У Nginx должен быть доступ на чтение ко всем папкам по этому пути;
- index - файлы, которые будут открываться, если адрес файла не указан в URL;
- location - это набор правил обработки путей в url. Каждый location может содержит путь URL а внутри него можно настроить открытие другого файла, аутентификацию, запрос к другому серверу и другие подобные вещи. Nginx анализирует все location в конфигурационном файле и выбирает самое подходящее. Из этого правила есть одно исключение. Если несколько location содержат регулярные выражения, то для обработки будет выбран первый подходящий.
2. Виртуальный хост по умолчанию
Теперь разберём создание виртуальных хостов nginx на примере. Давайте создадим виртуальный хост, который будет обрабатывать все необработанные запросы:
sudo vi /etc/nginx/sites-available/000-default.conf
server listen *:80 default_server;
server_name _;
root /usr/share/nginx/html;
index index.html index.htm;
location / <>
Все директивы, которые используются в блоке server, могут использоваться и в блоках location. Но нам не обязательно указывать root и index в каждом location. Если их опустить, то будут наследоваться те, которые были указаны в родительском блоке. Блоки server ведут себя аналогичным образом, поэтому, если мы не укажем другой путь к access.log, то будет использоваться путь, указанный в /etc/nginx/nginx.conf и так далее.
Теперь нам нужно активировать созданный виртуальный хост nginx. Для этого создайте символическую ссылку:
sudo ln -s /etc/nginx/sites-available/000-default.conf /etc/nginx/sites-enabled/000-default.conf
Затем убедитесь, что файлы из этого каталога подключены в основном конфигурационном файле:
sudo vi /etc/nginx/nginx.conf
Затем выполните эту команду, чтобы убедится, что вы не допустили ошибок:
Далее перечитайте конфигурацию nginx:
Теперь, если вы откроете IP-адрес сервера, то откроется созданный нами виртуальный хост.
2. Виртуальный хост с доменом
sudo vi /etc/nginx/sites-available/example.conf
Если вы работаете на локальной машине и доступа к DNS выбранного домена у вас нет, то надо добавить его IP в файл /etc/hosts:
sudo vi /etc/hosts
3. Отключение виртуального хоста
Благодаря структуре директорий, которую мы использовали, будет довольно просто отключить ненужный хост. Все наши виртуальные хосты Nginx находятся в папке /etc/nginx/sites-available, а в активной папке только ссылки на эти файлы. Поэтому для удаления достаточно удалить на него ссылку из папки /etc/nginx/sites-enabled/:
А затем, при необходимости, мы можем активировать его обратно, просто создав ссылку.
Выводы
В этой статье была рассмотрена настройка виртуальных хостов Nginx. Как видите, всё довольно просто и очень удобно, особенно, если вам нужно иметь несколько сайтов на одной машине. Конечно, у Nginx нет таких удобных утилит для активации сайтов, как в Apache, но работать вполне можно.
Нет похожих записей
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
Будем работать под учетной записью обычного пользователя с sudo правами. Так же вам понадобится установленный веб-сервер Nginx. При желании можно установить полностью LEMP (Linux, Nginx, MySQL и PHP). Чтобы установить Nginx достаточно выполнить следующую команду:
Шаг 1 - настройка новой корневой директории
По-умолчанию на вашем Nginx сервере активирован только один виртуальный хост. Он работает с документами по адресу: /usr/share/nginx/html . Мы изменим эту настройку, так как чаще всего приходится работать с каталогом /var/www . Nginx не использует эту директорию по-умолчанию, так как это противоречит политике Debian по использованию пакетов в каталоге /var/www .
Но так как мы простые пользователи, и с вопросами хранения пакетов редко сталкиваемся, проигнорируем эту политику и установим этот каталог в качестве корневого. Точнее говоря, каждый каталог внутри корневой директории должен соответствовать отдельному сайту. А все файлы сайта разместим в директории /var/www/site_name/html . Сначала создадим все необходимые подкаталоги. Для этого выполним следующую команду:
Флаг -р указывает оболочке, чтобы она создавала новые каталоги если их не существует в указанном пути. Теперь передадим права на этот каталог обычному пользователю. Воспользуемся переменной окружения $USER , чтобы не вводить имя своего аккаунта. После этих действий мы сможем создавать в каталоге /var/www/ файлы, а посетители сайта - нет.
Права на корневой каталог должны быть настроены корректно если вы не исправляли значение umask , но на всякий случай поправим:
Мы полностью подготовили структуру для нашего сервера, можем двигаться дальше.
Шаг 2 - Создаём шаблон страницы для каждого сайта
Давайте создадим страницу, которая будет отображаться по-умолчанию при создании нового сайта. Создайте файл index.html в каталоге первого домена:
Внутри сделаем минимальное наполнение, чтобы понимать на каком сайте мы находимся. Вот примерное содержание:
Сохраните и закройте файл. Так как второй файл будет с похожим содержанием, просто скопируем его:
Внесём в него небольшие изменения:
Сохраните и закройте этот файл. Теперь мы будем видеть правильно ли настроены наши сайты.
Шаг 3 - создание файлов виртуальных хостов для каждого домена
Теперь у нас есть содержимое для каждого сайта, настало время создать виртуальный хосты (точнее в Nginx они называются server block, но мы будет пользоваться термином виртуальный хост). По-умолчанию, Nginx использует один виртуальный хост под названием default. Используем его в качестве шаблона для нашей конфигурации. Сначала проработаем настройку для первого домена, которую потом просто скопируем и внесем минимальные изменения для второго домена.
Создание первого файла виртуального хоста
Как я уже сказал, скопируем файл настройки default:
Откроем этот файл с правами администратора:
Если опустить комментарии, то файл должен выглядеть следующим образом:
Для начала разберемся с директивой listen . Только одному блоку server мы можем установить значение default_server . Блок с таким значением будет обслуживать запросы, если не было найдено подходящего блока (блок - это всё что находится в server). Мы отключим эту директиву в виртуальном хосте default , чтобы использовать default_server на одном из наших доменов. Я оставлю эту функцию активированной для первого домена, но при желании вы можете её перенести на второй.
Следующее что мы сделаем - настроим корневой каталог при помощи директивы root . Она должна указывать на каталог, где лежат все документы вашего сайта:
Заметка: каждая инструкция Nginx должна заканчиваться символом “;”.
Далее настроим server_name , эта директива должна соответствовать первому доменному имени. Добавим также псевдоним:
Окончательная настройка должна выглядеть следующим образом:
На этом базовая настройка окончена. Сохраните и закройте файл.
Создание второго виртуального хоста
Для этого просто скопируем файл настроек для первого сайта:
Откройте этот файл с правами администратора
В этом файле также начнем с директивы listen . Если опцию default_server вы оставили в первом файле, то здесь её следует удалить. Также необходимо убрать опцию ipv6only=on, так как её указывают только для одной комбинации адрес/порт:
Установите корневой каталог для второго сайта:
Теперь укажем server_name для второго домена:
Окончательная настройка должна выглядеть следующим образом:
Сохраните и закройте файл.
Шаг 4 - активация виртуальных хостов и перезапуск Nginx
Мы настроили наши виртуальные хосты, теперь настало время активировать их. Для этого надо создать символические ссылки на эти файлы и положить их в каталог sites-enabled , которые Nginx считывает при запуске. Создать ссылки можно следующей командой:
Теперь Nginx обработает эти файлы. Но виртуальный хост default , также активирован, поэтому мы получим конфликт параметра default_server . Отключить эту настройку можно просто удалив ссылку на файл. Сам файл останется в каталоге sites-available , так что при необходимости мы всегда сможем вернуть его на место.
Осталось ещё одна настройка, которую требуется выполнить в конфигурационном файле Nginx. Откройте его:
Надо снять комментарий с одной из строк:
Поэтому лучше увеличить это значение до 64. Теперь можно перезапустить веб сервер, чтобы изменения вступили в силу:
Ваш сервер теперь должен обрабатывать запросы к обоим доменам.
Шаг 5 - Настройка локального файла hosts (дополнительно)
Если вы использовали свои доменные имена, то необходимо настроить ваш локальный сервер, чтобы тот распознавал их и вы смогли бы проверить свои виртуальные хосты (будем прописывать свои доменные имена в локальный файл hosts). Конечно, интернет пользователи не смогут таким образом просматривать ваш сайт, но для проверки хостов этого будет достаточно. Таким образом мы перехватываем запрос, который должен быть отправлен DNS серверу. По идее мы указываем по какому ip адресу наш компьютер должен перейти при обращении к определенному доменному имени.
Обратите внимание, что эти изменения следует производить только на локальной машине, а не на VPS сервере. Вам понадобятся root права, также необходимо иметь право изменять системные файлы.
Если вы используете Mac или Linux систему, то исправления можно внести следующим образом:
Если же вы пользуетесь Windows, то инструкции по этой ОС вы найдете на официальном сайте производителя (или в google). Вам необходимо знать открытый IP адрес вашего сервера и доменные имена, которые вы хотите привязать к нему. Допустим мой адрес 111.111.111.111 , тогда мне надо добавить следующие строки в файл hosts :
Таким образом мы перехватим все запросы к этим доменным именам и перенаправим их на наш сервер. Сохраните и закройте файл когда закончите.
Шаг 6 - Проверка
На данном этапе вы должны получить полностью рабочую настройку. Осталось только её проверить. Для этого перейдем в браузере по адресу: http://example.com < :target="_blank" >. Если оба сайта отображаются корректно, то вас можно поздравить с полной настройкой сервера Nginx. На этом этапе, если вы вносили изменения в файл hosts , то их следует удалить т.к. проверка прошла успешно и они уже не нужны. Чтобы открыть доступ к сайтам для интернет пользователей, придется приобрести доменные имена.
Заключение
Вы научились полностью настраивать виртуальные хосты для каждого сайта на вашем сервере. По сути, не существует каких либо ограничений на количество сайтов на одной машине, кроме ресурсов самой системы.
Представьте ситуацию: вы создали веб-приложение и теперь ищете подходящий веб-сервер для его размещения. Ваше приложение может состоять из нескольких статических файлов – HTML, CSS и JavaScript, бэкэнда API-сервиса или даже нескольких веб-сервисов. Использование NGINX может быть тем, что вы ищете, и для этого есть несколько причин.
Существует два способа установки NGINX – либо использовать установку из пакетов, либо компилировать из исходников.
Первый способ быстрее и проще, но компиляция из исходников дает возможность подключать сторонние библиотеки и модули, что делает NGINX еще более мощным инструментом. Такой способ позволит настроить все “под себя” и для нужд приложения.
Чтобы установить веб-сервер из пакета в ОС Debian, нужно всего лишь:
По завершении процесса установки вы можете проверить, что все в порядке, выполнив приведенную ниже команду, которая выведет на экран установленную версию NGINX.
Ваш веб-сервер будет установлен в директорию /etc/nginx/. Если перейти в эту директорию, можно увидеть несколько файлов и папок. Наиболее важные из них – это файл nginx.conf и папка sites-available.
Основной файл настроек NGINX – это файл nginx.conf, который по умолчанию выглядит так:
Различные параметры этого файла могут быть изменены при необходимости, но NGINX настолько прост, что все будет работать с настройками по умолчанию. Рассмотрим некоторые важные параметры конфигурационного файла:
Ваш установленный сервер может поддерживать больше одного сайта, а файлы, которые описывают сайты вашего сервера, находятся в каталоге /etc/nginx /sites-available.
Это дает вам возможность быстро помещать сайты в онлайн и отправлять их в автономный режим без фактического удаления каких-либо файлов. Когда вы будете готовы перевести сайт в онлайн – делайте символическую ссылку на sites-enabled и перезапускайте процесс.
В директории sites-available находится конфигурационный файл для виртуальных хостов. Этот файл позволяет настроить веб-сервер на мультисайтовость, чтобы каждый сайт имел свой отдельный конфиг. Сайты в этом каталоге не активны и будут включены только в том случае, если мы создадим символическую ссылку на папку sites-enabled.
Теперь создайте новый файл для своего веб-приложения или отредактируйте дефолтный. Типичный конфиг выглядит так:
Блок server описывает специфику работы виртуального сервера, который будет обрабатывать запросы пользователей. У вас может быть несколько таких блоков, и веб-сервер сам будет выбирать между ними на основании директив listen и server_name.
Внутри блока сервера мы определяем несколько контекстов location, которые используются для определения того, как обрабатывать клиентские запросы. Всякий раз, когда приходит запрос, сервер будет пытаться сопоставить свой URI с одним из этих определений location и обрабатывать его соответствующим образом.
Существует много важных директив, которые могут быть использованы, среди них:
- try_files: указывает на статический файл, находящийся в root-директории.
- proxy_pass: запрос будет отправлен на указанный прокси-сервер.
- rewrite: переписывает входящий URI основываясь на регулярном выражении, чтобы другой блок обработал его.
Блок upstream определяет пул серверов, на который будут отправляться запросы. После того, как мы создадим блок upstream и определим сервер внутри него, мы можем ссылаться на него по имени внутри наших блоков location. Кроме того, в upstream контексте может быть назначено множество серверов, поэтому NGINX будет выполнять некоторую балансировку нагрузки при проксировании запросов.
После того, как все настройки завершены и сайт перемещен в нужную директорию, мы можем запускать наш веб-сервер следующей командой:
После какого-либо изменения в файле конфигурации, мы должны заставить процесс NGINX перечитать конфиг (без перезагрузки) такой командой:
И наконец, мы можем проверить состояние процесса командой:
Школа хостинга Редактор: Дмитрий Сокол 724 30 мин Аудио
- обратного прокси-сервера;
- почтового прокси-сервера; прокси-сервера общего назначения.
Часто Nginx используют в связке с веб-сервером Apache в качестве frontend web-сервера, отвечающий за контент, который видит пользователь в браузере. Два веб-сервера распределяют между собой нагрузку, что ускоряет работу сайта.
Nginx создавался для решения проблемы C10k – обработки сервером одновременно 10 тыс. соединений. Все эти запросы Nginx выполняет в рамках одного потока, не тратя ресурсы и время на создание отдельных потоков.
Установка Nginx
Веб-сервер Nginx – программный продукт с открытым исходным кодом. Чтобы установить Nginx, воспользуйтесь предподготовленными пакетами вашего дистрибутива. Например, для Ubuntu 20.04 это две команды:
$ sudo apt update
$ sudo apt install nginx
Настройка параметров работы веб-сервера Nginx выполняется путем редактирования конфигурационных файлов в каталоге /etc/nginx. Например, базовая настройка веб-сервера:
- параметр listen определяет сетевой порт, на котором будет отвечать веб-сервер;
- server_name – имя сервера;
- ssl_certificate – указывает местоположения публичного сертификата сервера;
- ssl_certificate_key – секретный ключ, с доступом на чтение только для главного процесса Nginx;
- ssl_protocols и ssl_ciphers задают значение номера версии протоколов и шифры, которые будут использоваться при установке соединения и передаче данных.
Для упрощения процедуры настройки SSL-соединения, можно воспользоваться генератором конфигурации, разработанного компанией Mozilla (проект на GitHub).
Mozilla SSL Configuration Generator
После редактирования конфигурационного файла веб-сервера следует применить настройки.
Обычно для этого нужно перезагрузить веб-сервер, но Nginx позволяет применить настройки без своей перезагрузки, причем изменения вступают в силу прозрачно для соединений, которые были установлены ранее.
веб-сервер Nginx поручает главному процессу проверить правильность настроек.
В случае успешного выполнения проверок главный процесс применяет конфигурацию и запускает новые рабочие процессы, сообщая старым процессам о необходимости завершения. Если что-то пойдет неверно, то веб-сервер просто откатится на предыдущую конфигурацию.
Вместе с управлением поведением веб-сервера Nginx вы можете управлять непосредственно работой его службы, например, остановка службы выполняется командой:
Запустить снова процесс работы nginx:
Узнать состояние, в котором находится процесс nginx:
Как вы можете увидеть на скриншоте, Nginx работает, и его работу обеспечивают два процесса:
- master – главный процесс (он всегда один);
- worker – рабочий процесс (их может быть несколько).
Главный процесс отвечает за загрузку конфигурации и управляет рабочими процессами, которые выполняют обработку запросов от пользователей.
Количество рабочих процессов должно соответствовать количеству процессорных ядер в системе (настраивается директивой worker_processes в файле конфигурации nginx.conf).
По умолчанию конфигурационный файл nginx настроен таким образом, что веб-сервер отвечает на любой запрос на свой IP-адрес по 80 порту.
Nginx в разных системах
Nginx – это кроссплатформенное решение, но если для Linux-дистрибутивов и FreeBSD все в порядке, то на платформе Windows этот веб-сервер желательно использовать в тестовом режиме, т.к. он не оптимизирован на производительность и масштабирование.
На платформе Windows логичнее использовать другой веб-сервер, например, IIS. Однако, если все-таки в Windows появится необходимость получить работающий Nginx, то всегда есть альтернативное решение – это использование систем виртуализации.
Nginx – небольшой веб-сервер, он идеально подходит для работы в контейнере. Например, если у вас установлен Docker, то поднять контейнер с Nginx можно из официального образа:
$ docker run --name mynginx1 -p 80:80 -d nginx
- mynginx1 – имя создаваемого контейнера на базе образа nginx, находящегося на Docker Hub;
- параметр -p – указывает соответствие портов контейнера и узла, на котором он запущен.
Такой вариант позволяет быстро получить работоспособную систему.
Виртуальные серверы
Nginx может быть разделен на несколько виртуальных машин при едином централизованном управлении веб-сервером. Это удобно для поддержки и администрирования множества сайтов на одном хосте.
В файле конфигурации nginx.conf, в отдельной секции server <>, для каждого виртуального сервера должно быть указано его уникальное доменное имя или IP-адрес, или уникальный для данного физического сервера порт.
Например, для сайта с адресом site.local сначала создайте на сервере отдельный каталог для хранения файлов виртуального сервера:
$ sudo mkdir /var/www/site.local
$ sudo mkdir /var/www/site.local/html
Затем измените владельца каталога на текущего пользователя, чтобы он мог работать с файловой системой виртуального сервера Nginx:
$ sudo chown -R $USER:$USER /var/www/site.local/html
Дайте непривилегированному пользователю права на доступ к каталогу и файлам виртуального сервера:
Как используется и работает nginx
Как проверить, установлен ли NGINX
Пишете в консоль SSH следующую команду, она покажет версию NGINX
Если видите что-то навроде
nginx version: nginx/1.10.3
Значит, всё в порядке, установлен NGINX версии 1.10.3 . Если нет, установим его.
Как установить NGINX
Если вы сидите не под root , предваряйте команды apt-get префиксом sudo , например sudo apt-get install nginx
- Обновляем порты (не обязательно)
- Установка NGINX
- Проверим, установлен ли NGINX
Команда должна показать версию сервера, что-то подобное:
nginx version: nginx/1.10.3
Где расположен nginx
Во FreeBSD NGINX располагается в /usr/local/etc/nginx .
В Ubuntu, Debian NGINX располагается тут: /etc/nginx . В ней располагается конфигурационный файл nginx.conf — основной конфигурационный файл nginx.
Чтобы добраться до него, выполняем команду в консоли
По умолчанию, файлы конфигураций конкретных сайтов располагаются в /etc/nginx/sites-enabled/
или в /etc/nginx/vhosts/
Как правильно составить правила nginx.conf
Идём изучать мануалы на официальный сайт.
Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде
А вот вариант для PHP-FPM:
NGINX WordPress Multisite
Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:
Как заблокировать по IP в NGINX
Блокировать можно с помощью директив allow и deny.
Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.
Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:
Приведу пример конфигурации, как можно закрыть доступ к панели администратора WordPress по IP:
Ещё один неплохой вариант. Правда, по умолчанию определяются только статичные IP. А чтобы разрешить подсеть, придётся использовать дополнительный модуль GEO:
Как в NGINX указать размер и время
- Байты указываются без суффикса. Пример:
- Килобайты указываются с суффиксом k или K . Пример:
- Мегабайты указываются с суффиксом m или M . Пример:
- Гигабайты указываются с суффиксом g или G . Пример:
Время задаётся в следующих суффиксах:
- ms — миллисекунды
- s — секунды
- m — минуты
- h — часы
- d — дни
- w — недели
- M — месяцы, 30 дней
- Y — годы, 365 дней
В одном значении можно комбинировать различные единицы, указывая их в порядке от более к менее значащим, и по желанию отделяя их пробелами. Например, 1h 30m задаёт то же время, что и 90m или 5400s . Значение без суффикса задаёт секунды.
Рекомендуется всегда указывать суффикс
Некоторые интервалы времени можно задать лишь с точностью до секунд.
Настройка отладки в NGINX
Вместо статичной строки можно выводить данные различных переменных, что очень удобно для правильной настройки сервера и поиска узких мест.
Добавление модулей NGINX в Linux (Debian/CentOS/Ubuntu)
Все команды выполняются в консоли, используйте Putty или Far Manager с NetBox/WinSCP. Установка будет происходить под Debian
В результате увидите что-то навроде
Установим дополнительные пакеты.
Если выходит ошибка aptitude: команда не найдена , нужно предварительно установить aptitude:
—add-module=
Эта проблема решается установкой libpcre++-dev :
Эта проблема решается так:
В результате должны увидеть модуль на месте
Основные ошибки nginx и их устранение
502 Bad Gateway
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:
Тут мы выставили ожидание таймаута в 800 секунд.
Upstream timed out (110: Connection timed out) while reading response header from upstream
Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута
800 секунд на ожидание ответа от бекенда.
Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php
413 Request Entity Too Large
Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку
и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до 100Mb
Также, можно отключить проверку размера тела ответа полностью значением ноль:
Следует помнить, зачем ввели это ограничение: если любой пользователь может загружать файлы на неподготовленный сайт, можно сравнительно легко провести DDOS-атаку на него, перегружая входной поток большими файлами.
После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx
304 Not Modified не устанавливается
Если возникает проблема с правильным отображением ответного заголовка сервера 304 Not Modified , то проблема, скорее всего, в пунктах:
Client intended to send too large body
Решается с помощью увеличения параметра client_max_body_size
Как перезагрузить nginx
Для перезагрузки NGINX используйте restart или reload .
Команда в консоли:
Эти команды остановят и перезапустят сервер NGINX.
Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:
Проверить правильность конфигурации можно командой
В чём разница между reload и restart
Как происходит перезагрузка в NGINX:
- Команда посылается серверу
- Сервер анализирует конфигурационный файл
- Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
- Если конфигурация содержит ошибки, то при использовании
- restart процесс перезагрузки сервера прерывается, сервер не запускается
- reload сервер откатывается назад к старой конфигурации, работа продолжается
Короче говоря, restart обрывает работу резко, reload делает это плавно.
Restart рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.Ещё лучше, если вы будете предварительно проверять правильность конфигурации командой nginx -t , например:
Как вместо 404 ошибки делать 301 редирект на главную
Как в NGINX сделать редирект на мобильную версию сайта
Данный код вставляется на уровне server в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).
Как в NGINX включить поддержку WebP
Теперь, в секции server можно использовать:
Полезные материалы и ссылки
Настройка NGINX под WP Super Cache
Конвертер правил .htaccess (Apache) в NGINX
Весьма полезный сервис, который поможет cконвертировать правила из .htaccess в NGINX . Результат, возможно, придётся донастроить вручную, но, в целом, он весьма удобен в применении.
Вот как описывают сервис сами авторы:Сервис предназначен для перевода конфигурационного файла Apache .htaccess в инструкции конфигурационного файла nginx.
В первую очередь, сервис задумывался как переводчик инструкций mod_rewrite с htaccess на nginx. Однако, он позволяет переводить другие инструкции, которые можно и резонно перевести из Apache в nginx.
Инструкции, не относящиеся к настройке сервера (например, php_value), игнорируются.
Переводчик не проверяет правильность входящего конфига, в том числе регулярные выражения и логические ошибки.
Результат перевода следует обязательно проверить вручную, а затем разместить в секции server <> конфигурационного файла nginx.
Замечания и предложения по улучшению ждем, как обычно, на [email protected] ;)
Читайте также: