Настройка виртуальных хостов Nginx
В одной из прошлых статей мы говорили о том, как выполняется установка и первоначальная настройка веб-сервера 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. Синтаксис виртуального хоста
Каждый виртуальный хост представляет из себя такой блок кода:
Кроме того, здесь могут использоваться и другие инструкции, но эти основные и обязательные.
- 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, могут использоваться и в блоках 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. Виртуальный хост с доменом
Аналогичным образом можно создать виртуальный хост для домена. Например example.ru:
sudo vi /etc/nginx/sites-available/example.conf
Если вы работаете на локальной машине и доступа к DNS выбранного домена у вас нет, то надо добавить его IP в файл /etc/hosts:
sudo vi /etc/hosts
Повторите процедуру активации домена, и затем в браузере при запросе к домену example.ru откроется стартовая страница Nginx. Если по каким-либо причинам виртуальный хост Nginx не работает, вы можете посмотреть полный скомпилированный файл nginx.conf:
Также можно проверить, есть ли в нём конфигурация нужного хоста, например, ищем упоминания example.ru:
nginx -T | grep example.ru
3. Отключение виртуального хоста
Благодаря структуре директорий, которую мы использовали, будет довольно просто отключить ненужный хост. Все наши виртуальные хосты Nginx находятся в папке /etc/nginx/sites-available, а в активной папке только ссылки на эти файлы. Поэтому для удаления достаточно удалить на него ссылку из папки /etc/nginx/sites-enabled/:
А затем, при необходимости, мы можем активировать его обратно, просто создав ссылку.
Выводы
В этой статье была рассмотрена настройка виртуальных хостов Nginx. Как видите, всё довольно просто и очень удобно, особенно, если вам нужно иметь несколько сайтов на одной машине. Конечно, у Nginx нет таких удобных утилит для активации сайтов, как в Apache, но работать вполне можно.
Настройка виртуальных хостов Nginx в Ubuntu
Виртуальные хосты в Nginx также называются блоками server. Эти блоки используются для обслуживания нескольких индивидуальных доменов на одном сервере.
Данное руководство покажет, как настроить виртуальные хосты Nginx на сервере Ubuntu 16.04.
Требования
- Не-root пользователь с доступом sudo (о настройке такого пользователя – в этой статье).
- Предварительно установленный веб-сервер Nginx. Инструкции по установке Nginx можно найти здесь. Чтобы установить более надёжную платформу для веб-сервера, читайте руководство «Установка стека LEMP в Ubuntu 16.04».
Кроме того, для выполнения предложенных в руководстве примеров нужно иметь два доменных имени; в руководстве используются условные домены example.com и test.com. Не забудьте заменить их своими доменными именами.
Если у вас нет доменных имён, которые можно использовать для тестирования настроек, укажите фиктивные домены. В руководстве есть специальный раздел, объясняющий, как протестировать сайты при помощи локальной машины.
1: Каталоги Document Root
По умолчанию в Ubuntu 16.04 включен один стандартный виртуальный хост Nginx, который обслуживает документы из каталога /var/www/html.
Для обслуживания нескольких сайтов нужно создать дополнительные каталоги. Каталог /var/www/html будет использоваться в качестве каталога по умолчанию, который будет обслуживаться, если запрос клиента не соответствует ни одному из других сайтов.
Создайте структуру каталогов в /var/www для каждого отдельного сайта. Весть текущий контент нужно поместить в каталог html. Используйте следующую команду; флаг –p создаст все необходимые родительские каталоги.
sudo mkdir -p /var/www/example.com/html
sudo mkdir -p /var/www/test.com/html
Создав все необходимые каталоги, передайте права на них текущему пользователю с доступом к sudo.
Примечание: В зависимости от требований сервера вам может потребоваться повторно настроить права доступа или права собственности на папки, чтобы разрешить доступ к пользователю www-data. В этом, как правило, часто нуждаются динамические сайты. Конечно, привилегии доступа полностью зависят от конфигурации сервера.
Используйте переменную окружения $USER, чтобы задать текущего пользователя. Это позволит создавать файлы в этих каталогах.
sudo chown -R $USER:$USER /var/www/example.com/html
sudo chown -R $USER:$USER /var/www/test.com/html
Теперь права на эти каталоги установлены верно, если ранее значение umask не было изменено. Это можно проверить при помощи команды:
sudo chmod -R 755 /var/www
2: Создание страниц для сайтов
Создав необходимую структуру каталогов, можно переходить к созданию стандартных страниц сайтов, чтобы иметь возможность просмотреть добавленный контент.
Создайте страницу index.html для первого сайта.
В этот файл вставьте следующий код; эта простая базовая страница сообщит, какой из двух сайтов открыт.
Сохраните и закройте файл.
Файл для второго сайта будет почти таким же, потому можно просто скопировать только что созданный файл, а затем отредактировать его.
cp /var/www/example.com/html/index.html /var/www/test.com/html/
Откройте этот файл в текстовом редакторе:
Откорректируйте данные, указав информацию о втором сайте:
Сохраните и закройте файл.
Теперь стандартные страницы сайтов готовы.
3: Создание виртуальных хостов
Итак, теперь файловая структура и страницы, обслуживающие контент, готовы к работе. Приступайте к созданию блоков server для Nginx.
По умолчанию Nginx содержит один блок server по имени default, который можно использовать в качестве шаблона.
Блок server для первого сайта
Итак, скопируйте стандартный файл, чтобы создать первый блок server.
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com
Откройте новый файл в текстовом редакторе:
sudo nano /etc/nginx/sites-available/example.com
Не учитывая закомментированных строк, этот файл выглядит так:
server <
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / <
try_files $uri $uri/ =404;
>
>
Сначала нужно разобраться с директивами listen. Спецификация default_server может быть действительна только для одного виртуального хоста. Она указывает, какой из виртуальных хостов должен обслуживать запрос, если запрашиваемый server_name не совпадает ни с одним из существующих виртуальных хостов.
Добавьте опцию default_server в директиву listen одного из своих сайтов. Также можно оставить эту опцию в файле стандартного виртуального хоста, который будет обслуживать каталог /var/www/html, если запрашиваемый хост не может быть найден.
В данном руководстве стандартный виртуальный хост будет обслуживать несовпадающие запросы, потому директиву default_server нужно удалить из него и добавить в файл другого хоста.
Примечание: Чтобы убедиться, что опция default_server включена только в одном файле виртуального хоста, введите:
grep -R default_server /etc/nginx/sites-enabled/
Если такие записи в раскомментированном виде находятся в нескольких файлах (указывается в последнем столбце), веб-сервер пожалуется на ошибку.
Далее нужно указать каталог document root, отредактировав директиву root.
server <
listen 80;
listen [::]:80;
root /var/www/example.com/html;
>
Затем нужно отредактировать server_name, указав доменное имя (в данном случае – домен первого сайта). Также можно добавить несколько алиасов (например, www.example.com). В результате получится:
server <
listen 80;
listen [::]:80;
root /var/www/example.com/html;
index index.html index.htm index.nginx-debian.html;
server_name example.com www.example.com;
location / <
try_files $uri $uri/ =404;
>
>
Базовая настройка виртуального хоста завершена.
Блок server для второго сайта
Итак, базовый код блока server готов. Файл блока server можно использовать в качестве шаблона для блока второго сайта. Скопируйте этот файл:
sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com
Откройте новый файл с привилегиями root:
sudo nano /etc/nginx/sites-available/test.com
Обратите внимание на директиву listen. Если опция default_server была включена в предыдущий файл, удалите её из этого файла. Также нужно откорректировать значение директивы root (укажите document root второго сайта) и server_name (укажите доменное имя и все алиасы).
В результате файл будет выглядеть так:
server <
listen 80;
listen [::]:80;
root /var/www/test.com/html;
index index.html index.htm index.nginx-debian.html;
server_name test.com www.test.com;
location / <
try_files $uri $uri/ =404;
>
>
Сохраните и закройте файл.
4: Включение виртуальных хостов
Теперь виртуальные хосты готовы, но их нужно активировать.
Для этого нужно создать символьные ссылки из этих файлов в каталог sites-enabled, который читается веб-сервером Nginx во время запуска.
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/
Теперь эти файлы в каталоге sites-enabled. На данный момент у вас есть три виртуальных блока, которые смогут отвечать на запросы согласно директивам listen и server_name.
- example.com: файл для сайта example.com и его алиасов.
- test.com: файл для сайта test.com и его алиасов.
- default: стандартный файл, который будет отвечать на запросы, не соответствующие ни первому, ни второму сайту.
Чтобы избежать потенциальных проблем с памятью, которые могут возникнуть из-за дополнительных имён сервера, отредактируйте файл /etc/nginx/nginx.conf:
sudo nano /etc/nginx/nginx.conf
Найдите директиву server_names_hash_bucket_size и раскомментируйте её:
http <
. . .
server_names_hash_bucket_size 64;
. . .
>
Сохраните и закройте файл.
Проверьте синтаксис на наличие ошибок:
Если ошибок нет, перезапустите Nginx, чтобы обновить настройки:
sudo systemctl restart nginx
Теперь Nginx обслуживает два домена.
5: Настройка локальных хостов (опционально)
Если вместо настоящих доменных имён вы использовали фиктивные имена, вы можете испытать новые виртуальные хосты, не подключаясь при этом к доменному имени. Для этого нужно настроить на компьютере локальные хосты.
Это не позволит другим посетителям просматривать сайт, но даст вам возможность проверить работу и настройки каждого сайта. Этот метод работает путем перехвата запросов, которые, как правило, поступают в DNS для разрешения доменных имен. Вместо этого можно указать IP-адреса, которые будут использоваться локальным компьютером, при поступлении запросов к доменным именам.
Примечание: прежде чем приступить к выполнению данного раздела, убедитесь, что вы находитесь на компьютере, а не на сервере. Для выполнения данного раздела нужно иметь root-права и состоять в административной группе, чтобы иметь возможность редактировать системные файлы.
В системах Mac или Linux войдите как root-пользователь (su) и откройте файл hosts:
sudo nano /etc/hosts
При использовании Windows обратитесь к сайту Microsoft.
На данном этапе понадобится внешний IP-адрес и домены, которые нужно направить на сервер. Допустим, внешний IP-адрес сервера 111.111.111.111; в таком случае строки будут выглядеть так:
127.0.0.1 localhost
. . .
111.111.111.111 example.com www.example.com
111.111.111.111 test.com www.test.com
Это будет перехватывать запросы к example.com и test.com и передавать их на сервер.
Сохраните и закройте файл.
6: Тестирование
Теперь нужно протестировать работу виртуальных хостов. Для этого посетите домены в браузере:
На экране появится сообщение:
Success! The example.com server block is working!
Посетите второй домен:
На экране должно появиться сообщение:
Success! The test.com server block is working!
Если веб-сервер ответил на запросы, значит, всё работает должным образом.
Если файл hosts на локальном компьютере был отредактирован, на этом этапе нужно удалить добавленные в него строки.
Количество виртуальных хостов, которое можно разместить на одном сервере, ограничивается только ресурсами самого сервера. Чтобы виртуальный хост, просто повторите весь вышеописанный процесс.
Name already in use
blog / notes / admin / virtual_server_in_nginx.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Создание виртуального сервера в nginx
Эта заметка является далеко не исчерпывающей по своему содержанию, более того, некоторые моменты сознательно опущены для простоты понимания. Заметка появилась всего-лишь по просьбе коллеги написать краткую простую инструкцию о том, как добавить виртуальный сервер в nginx для разных доменных имен.
Более полная информация, как обычно, содержится в разделе «Веб-сервер» руководства администратора nginx.
Примечание. В заметке речь идет от веб-сервере nginx, установленном на ОС CentOS 6.5
Виртуальный сервер в nginx описывается в файле конфигурации, размещение которого зависит от операционной системы. По умолчанию файл конфигурации называется nginx.conf и может лежать в одном из каталогов:
В данном случае это каталог /etc/nginx .
Файл конфигурации состоит из директив, которые могут быть как простыми — в виде одной строки, так и блочными — выделяемыми фигурными скобками <> , и содержащими в себе простые.
Каждая простая директива должна оканчиваться точкой с запятой ; (частая ошибка — не указывается точка с запятой после редактирования файла конфигурации, что приводит к ошибке запуска веб-сервера).
Блоковая директива, содержащая в себе другие директивы, также называется контекстом. Так весь файл конфигурации — это основной контекст (main context). Так же контекстом являются другие блоковые директивы: events , http , server , location . При этом директивы events и http размещаются в основном контексте, директива server — в контексте http , и директива location — в контексте server .
Сервер в конфигурационном файле nginx описывается директивой server , которая располагается в контексте http :
В файле конфигурации, созданном по умолчанию, некоторые настройки внутри контекста http вынесены в отдельные файлы также с расширением .conf , и размещенные в подкаталоге conf.d . Подключаются эти файлы директивой include :
Этим обстоятельством можно воспользоваться для того, чтобы не править лишний раз основной файл конфигурации, а прописать настройки нового виртуального сервера в отдельном файле. Если этот файл будет размещен в подкаталоге conf.d и иметь расширение .conf , то он автоматически будет подключатся вместе со всеми остальными ему подобными файлами.
Можно создать дополнительный файл конфигурации в другом месте и подключать его отдельной директивой include . Тогда, в случае необходимости, его легко будет отключить просто закомментировав строку подключения (для комментариев в настойках nginx используется символ # ).
Еще одним преимуществом отдельного файла для описания виртуального сервера будет являться «чистота» файла. То есть отсутствие лишних директив и акцентирование только на описании непосредственно сервера.
Так как директива include уже размещена в контексте http , то в подключаемом файле конфигурации можно начать сразу с блочной директивы server :
Описание виртуального сервера в файле конфигурации может иметь много особенностей, зависящих от контента, используемого на веб-вервере, размещения этого контента, от технологических моментов работы веб-приложения (например, используемый язык программирования на стороне сервера). Здесь рассматриваются самые общие вопросы конфигурации. За более подробной информацией можно обратиться к документации по директиве server .
При описании нового виртуального сервера следует исходить из того, что в конфигурации nginx уже прописан сервер по умолчанию примерно следующим образом (закомментированные директивы опущены):
- server_name — имя сервера (возможно так же указание нескольких серверов через пробел);
- listen — прослушиваемый порт (может также указываться, как ip-адрес:порт).
Можно сказать, что эта связка — server_name и listen — является ключевой при определении конфигурации сервера. Другими словами, если на прослушиваемый порт listen поступает http-запрос, в котором заголовок host имеет одно из значений равное server_name , то применяется именно эта конфигурация.
При описании дополнительных виртуальных серверов можно и опустить директиву listen . Тогда прослушиваться будет порт по умолчанию. В свою очередь, порт по умолчанию — это может быть порт, указанный в какой-нибудь конфигурации с параметром default_server , как, например:
Если же параметр default_server ни где не указан, то портом по умолчанию считается порт, указанный в конфигурации для первого сервера. Дополнительно можно акцентировать, что параметр default_server относится только к прослушиваемому порту, но не к имени сервера. Так как при установке nginx создается файл конфигурации по умолчанию, в котором уже прописан сервер для порта 80 , то можно считать его портом по умолчанию.
Таким образом, если порт для дополнительного сервера не меняется, то можно начать конфигурацию с директивы server_name .
root определяет корневой каталог файловой системы сервера для заданного виртуального сервера. Надо помнить, что выход за корневой каталог не возможен. То есть, например, указание ../1.gif не вернет ожидаемого файла, если этот относительный путь указан относительно корневого каталога.
Директива location — блочная, задает конфигурацию сервера в зависимости от запрошенного URI, проверяя его на соответствие заданному в директиве выражению. Это выражение может определяться либо в виде префиксной подстроки, либо в виде регулярного выражения, либо может указываться полное соответствие при помощи модификатора = . Внутри директивы server может быть более одной директивы location .
При поиске соответствия URI сначала проверяются директивы location , значение которых задано в виде префикса. Конфигурация location с самой длинной совпавшей строкой запоминается. После этого идет сравнение со значениям в виде регулярного выражения в порядке, указанном в конфигурационном файле. При первом же совпадении URI с регулярным выражением поиск останавливается и конфигурация location с этим значением применяется. Если же ни одно из регулярных выражений не совпало, то применяется конфигурация location , запомненного при сравнении по префиксу. Если существует значение директивы location с использованием модификатора = , то при при первом же полном соответствии запрошенного URI этому значению поиск останавливается.
Самое простое значение директивы location — это / , что означает конфигурацию для всех URI, указанных для server_name .
Чуть подробнее директива location рассматривается далее.
Если сайт имеет статический контент и нет необходимости размещать какие-либо ресурсы за пределами root , то директива location может либо не понадобиться вовсе, если указать root в контексте server , либо location может иметь самую простую реализацию:
Здесь директива index определяет файлы, которые могут быть использованы как индексные файлы, размещенные по запрашиваемому пути.
Для большей демонстрации работы location , можно рассмотреть следующий случай. Пусть имеется статический сайт example.com с одним и тем же контентом, но на разных языках — русском и английском. Для каждого языка создан свой отдельный домен: ru.example.com — для русскоязычной версии и en.example.com — для англоязычной. Для каждого из вариантов сайта создан свой каталог, соответственно:
Файл конфигурации для каждого сервера будет предельно прост:
Это нормально, что страницы с текстом на разных языках будут размещаться в своих каталогах. Но ведь стили, скрипты, медиа и другие ресурсы вероятно должны быть общими, если контент одинаковый. Нет смысла дублировать ресурсы в каждом из каталогов, разумнее будет поместить их в общий. Однако, как было сказано выше, выход запроса за root не возможен. Здесь и пригодиться директива location , которая переопределит root , когда на сервер поступает запрос ресурса.
Пусть для рассматриваемого сайта стили запрашиваются по пути /css , скрипты — /js , медиа — /images . При этом физически на сервере созданы одноименные каталоги по пути /usr/share/nginx/html/example . Тогда для каждого из серверов необходимо прописать соответствующие location :
Чтобы не повторять в настройках каждого сервера одно и тоже, можно повторяемые директивы вынести в отдельный файл и подключать его в нужном месте. Например, создать файл example_common.conf с содержимым:
а затем подключать его:
Здесь можно обратить внимание на то, что пути /css , /js , /images чисто условны. То есть, размещать в этих каталогах можно все, что угодно и это будет выведено в соответствующем запросе. Но есть способ привязать каталоги к конкретному типу ресурсов. Для этого используются регулярные выражения при указании пути в location . Например, указание пути:
приведет к поиску всех ресурсов *.css в каталоге /usr/share/nginx/html/example/css . А если стиль расположен в подкаталоге: ru.example.com/slider/slider.css , то и размещаться он должен соответственно по пути
Подобные настройки для скриптов и изображений могут выглядеть следующим образом:
Здесь приведены простые примеры для того, чтобы представить, как работает директива location . Более подробнее можно почитать в документации по location .
В статических сайтах основная задача веб-сервера — отдать запрашиваемый в URL ресурс, который является статическим файлов на сервере. В динамических сайтах некоторые запрашиваемые ресурсы подразумевают исполняемый файл, написанный, например, на каком-либо из интерпретируемых или компилируемых языков программирования. Этот файл должен быть исполнен, а затем сервер возвращает результат выполнения. Сам сервер nginx не исполняет скрипты, этим занимаются соответствующие процессы (интерпретаторы, виртуальные машины и т.д.), работающие параллельно. Задача веб-сервера — перенаправить запрашиваемый ресурс на исполнение процессу. Далее рассматривается самый простой пример с PHP.
Как правило, для работы с nginx используется php-fpm , который является реализацией FastCGI для PHP. Взаимодействие nginx и php-fpm может осуществляться как по TCP/IP протоколу, так и через сокет (Unix Socket). Конкретно, как будет работать php-fmp указывается в его файле конфигурации, и соответствующим образом должно быть настроено в nginx .
Пусть в конфигурации php-fpm адресом для FastCGI-запросов является 127.0.0.1:9000 (обычно, значение по умолчанию при установке php-fpm ). Чтобы перенаправить на выполнение запрашиваемый ресурс, являющийся PHP-скриптом, в nginx используется все та же директива location с самым простым набором директив:
- fastcgi_pass — адрес по которому FastCGI-приложение ожидает запрос исполняемого ресурса;
- fastcgi_param — устанавливает значение параметра, передаваемого FastCGI. В данном случае устанавливается параметр SCRIPT_FILENAME значением $document_root$fastcgi_script_name , где в свою очередь:
- $document_root — переменная, содержащая root текущего запроса;
- $fastcgi_script_name — имя запрашиваемого ресурса. Если в запросе имя не указано (запрос заканчивается на / ), то будет подставлено значение, определенное директивой index . Так как index может определять не только исполняемый ресурс, но и статические страницы — *.html, *htm, то для FastCGI можно прописать «свой» индекс в директиве fastcgi_index .
Здесь же include подключает файл fastcgi_params (обычно расположенный рядом с nginx.conf ), в котором необходимые параметры FastCGI определяются соответствующими значениями сервера nginx . Этими параметрами, например, могут быть параметры запроса ( $query_string ), метод запроса ( $request_method ) и многие другие.
В случае, когда php-fpm настроен на работу через сокет, директива fastcgi_pass будет выглядеть следующим образом:
How to Set Up Nginx Virtual Hosts on Ubuntu 20.04
Nginx is designed to handle multiple domains on a single server and IP address. Virtual hosts provide this feature. In this tutorial, we will set up Nginx virtual hosts.
In the Serverspace you can create a server with already installed app «Nginx».
Nginx configuration files
First, you need to install the Nginx package.
apt install nginx
All configuration files for Nginx virtual hosts are stored in the /etc/nginx/sites-available/ folder. The best way is to create a separate file for each web site on the server. Let’s create the first configuration for domain-name.com.
Now insert this configuration there.
server <
listen 80; # Specify the listening port
listen [::]:80; # The same thing for IPv6
root /var/www/domain-name.com/html; # The path to the website files
index index.html index.htm; # Files to display if only the domain name is specified in the address
server_name domain-name.com; # Domain name of this site
location / <
try_files $uri $uri/ =404;
>
>Save and close this file.
Create a folder for the website and place its files there.mkdir -p /var/www/domain-name.com/html
And set permissions for the folder.
chmod -R 755 /var/www
Enabling the Nginx virtual host
You need to create a symbolic link to the configuration in the sites-enabled directory to enable the virtual host.
ln -s /etc/nginx/sites-available/domain-name.com /etc/nginx/sites-enabled/
Now check the configuration for errors.
And restart the service.
systemctl restart nginx
Now you have a working virtual host for a single domain. You can access it by domain name if the DNS server is configured correctly. Any number of domains can be added to the server in this way.
Disabling Nginx virtual hosts
To disable a virtual host, remove the symbolic link from the sites-enabled folder. To disable returning a standard web page when accessing the server’s IP address, you can simply delete the link to the default configuration.
Restart the service after that.
systemctl restart nginx
This way you can disable any configuration you need. And enable it by adding a symbolic link again, as we did earlier.
Cloud Servers from €4 / mo Intel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channel Try