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

Р ръководство за начинаещи

Този урок дава първоначално въведение в nginx и описва някои от простите задачи, които могат да се извършват с него. Предполага се, че nginx вече е инсталиран на компютъра на четеца. Ако не, вижтеИнсталиране на nginx . Това ръководство описва как да стартирате и спрете nginx и да презаредите неговата конфигурация, обяснява как работи конфигурационният файл и описва как да настроите nginx да обслужва статично съдържание, как да настроите прокси сървър на nginx и как да свържете nginx към Приложение FastCGI.

Nginx има един основен и няколко работни процеса. Основната задача на основния процес е да чете и валидира конфигурацията и да управлява работни процеси. Работните процеси извършват действителната обработка на заявките. nginx използва базиран на събития модел и зависи от операционна системамеханизми за ефективно разпределение на заявките между работните процеси. Броят на работните процеси е посочен в конфигурационния файл и може да бъде фиксиран за дадена конфигурация или автоматично зададен равен на броя на наличните процесорни ядра (вижте раздел 3.3.работни_процеси).

Как работят nginx и неговите модули е определено в конфигурационния файл. По подразбиране конфигурационният файл е наименуван nginx.conf и се намират в каталога/usr/local/nginx/conf, /etc/nginx или /usr/local/etc/nginx

За да стартирате nginx, трябва да изпълните изпълнимия файл. След като nginx стартира, той може да се контролира чрез извикване на изпълнимия файл с параметъра-с . Използвайте следния синтаксис:

nginx -s сигнал

Къде е сигналът може да бъде едно от следните:

  • стоп - бързо прекратяване
  • - повторно отваряне на лог файлове

Например, за да спрете процесите на nginx, докато чакате работните процеси да завършат обслужването на текущи заявки, можете да изпълните следната команда:

nginx -s излезте

Командата трябва да се изпълнява под същия потребител, под който е стартиран nginx.

Промените, направени в конфигурационния файл, няма да бъдат приложени, докато командата за презареждане на конфигурацията не бъде изпратена ръчно до nginx или не бъде рестартиран. За да презаредите конфигурацията, изпълнете:

nginx -s презареждане

При получаване на сигнала основен процеспроверява синтаксиса на новия конфигурационен файл и се опитва да приложи съдържащата се в него конфигурация. Ако успее, главният процес стартира нови работни процеси и изпраща съобщения до старите работни процеси за прекратяване. В противен случай главният процес връща обратно промените и продължава да работи със старата конфигурация. Старите работни процеси, когато им бъде дадена команда за край, спират да приемат нови заявки и продължават да обслужват текущи заявки, докато всички такива заявки не бъдат обслужени. След това старите работни процеси се прекратяват.

Можете също да изпращате сигнали към процесите на nginx, като използвате Unix инструменти, като помощната програмаубивам . В този случай сигналът се изпраща директно към процеса с даден ID. Идентификаторът на основния процес на nginx се записва във файла по подразбиране nginx.pid в /usr/local/nginx/logs или /var/run . Например, ако идентификаторът на основния процес е 1628, за да изпратите сигнал QUIT, който ще прекрати елегантно nginx, трябва да изпълните:

kill -s ИЗХОД 1628

Помощната програма може да се използва за изброяване на всички работещи процеси на nginxпс , например, както следва:

ps-ax | grep nginx

Повече информация за изпращане на сигнали към процеси на nginx можете да намерите вуправление на nginx.

Структура на конфигурационния файл

nginx се състои от модули, които са конфигурирани чрез директиви, посочени в конфигурационния файл. Директивите се делят на прости и блокови. Простата директива се състои от име и параметри, разделени с интервали, и завършва с точка и запетая (; ). Блоковата директива има същата структура като простата директива, но вместо точка и запетая, името и параметрите са последвани от набор от допълнителни инструкции, поставени във фигурни скоби (( И ) ). Ако една блокова директива може да има други директиви във фигурни скоби, тогава тя се нарича контекст (примери:събития, http, сървър и местоположение).

Директивите, поставени в конфигурационния файл извън какъвто и да е контекст, се считат за намиращи се в контекстаосновен. събития и http директиви поставени в контекст main, сървърът е в http, а местоположението е в server.

Част от низ след символ# счита за коментар.

Сервиране на статично съдържание

Една от важните задачи на конфигурацията на nginx е обслужването на файлове като изображения или статични HTML страници. Нека разгледаме пример, в който, в зависимост от заявката, файловете ще бъдат разпределени от различни локални директории:/данни/www , който съдържа HTML файлове и/данни/изображения Съдържащи файлове с изображения. За да направите това, трябва да редактирате конфигурационния файл и да конфигурирате блокасървър вътре в http блок с два блока за местоположение.

Първо създайте директория/данни/www и поставете файла в него index.html с произволно текстово съдържание, както и създаване на каталог/данни/изображения и поставете няколко файла с изображения в него.

След това отворете конфигурационния файл. Конфигурационният файл по подразбиране вече включва някои примери за блоковесървър , предимно коментирани. За нашата текуща задача е по-добре да коментираме всички такива блокове и да добавим нов блоксървър:

http(

сървър (

По принцип конфигурационният файл може да съдържа няколко блокасървър , отличен според портовете, на които теслушане и по име на сървър . Като се определи коесървър ще обработи заявката, nginx сравнява URI, посочен в заглавката на заявката, с параметрите на директивитеместоположение , определени вътре в блокасървър.

Добавете блок за местоположение към сървърния блок следната форма:

местоположение / (

Корен /данни/www;

Този блок за местоположение дефинира „/ ” като префикс, който се сравнява с URI от заявката. За съвпадащи заявки, чрез добавяне на URI към пътя, посочен в директиватакорен , тоест в този случай към/данни/www , пътя до искания файл в локалния файлова система. Ако има съвпадение с множество блоковеместоположение , nginx избира блока с най-дълъг префикс. В блокаместоположение по-горе е най-краткият префикс, дължина едно, и следователно този блок ще се използва само ако няма съвпадение с някой от другите блоковеместоположение.

местоположение /изображения/ (

Корен/данни;

Той ще съответства на заявки, започващи с/изображения/ (местоположение / също подходящ за тях, но посоченият там префикс е по-кратък).

Окончателна блокова конфигурациясървър трябва да изглежда така:

сървър (

Местоположение / (

Корен /данни/www;

Местоположение /изображения/ (

Корен/данни;

Това е работеща сървърна конфигурация, която слуша на стандартния порт 80 и е достъпна на локален компютърпо адреса http://localhost/ . В отговор на заявки, чиито URI започват с/изображения/ , сървърът ще изпрати файлове от директорията/данни/изображения . Например за заявкаhttp://localhost/images/example.pngnginx ще изпрати файл в отговор/data/images/example.png . Ако този файл не съществува, nginx ще изпрати отговор, показващ грешка 404. Заявки, чиито URI не започват с/изображения/ , ще бъде картографиран към директория/данни/www . Например в резултат на запитванеhttp://localhost/some/example.htmlв отговор ще бъде изпратен файл/data/www/some/example.html .

За кандидатстване нова конфигурация, стартирайте nginx, ако вече не работи, или изпратете сигналпрезаредете към основния процес на nginx, като изпълните:

nginx -s презареждане

В случай, че нещо не работи според очакванията, можете да опитате да разберете причината, като използвате файловете access.log и error.log от директорията /usr/local/nginx/logs или /var/log/nginx.

Настройка на прост прокси сървър

Едно от често срещаните приложения на nginx е използването му като прокси сървър, тоест сървър, който приема заявки, препраща ги към прокси сървъри, получава отговори от тях и ги изпраща на клиента.

Ще настроим основен прокси сървър, който ще обслужва заявки за изображения от локалната директория и ще препраща всички други заявки към прокси сървъра. В този пример и двата сървъра ще работят под едно и също копие на nginx.

Първо създайте сървъра нагоре по веригата, като добавите друг блоксървър към конфигурационния файл на nginx със следното съдържание:

сървър (

Слушай 8080;

Корен /данни/up1;

Местоположение / (

Това ще бъде прост сървър, слушащ на порт 8080 (преди товаслушам не е посочен, защото е използван стандартен порт 80) и показва всички заявки за директория/данни/up1 на локалната файлова система. Създайте тази директория и поставете файла в нея index.html . Имайте предвид, че директиватакорен поставени в контекстсървър . Такава директивакорен ще се използва, когато директиватаместоположение Избраното за изпълнение на заявката не съдържа собствена директивакорен.

След това използвайте конфигурацията на сървъра от предишния раздел и я променете, за да стане конфигурация на прокси сървър. До първия блокместоположение добавете директива proxy_pass , указвайки протокола, името и порта на прокси сървъра като параметър (в нашия случай това http://localhost:8080 ):

сървър (

Местоположение / (

Proxy_pass http://localhost:8080;

Местоположение /изображения/ (

Корен/данни;

Ще сменим втория блокместоположение , който е на този моментпоказва заявки с префикс/изображения/ на файлове от директория/данни/изображения така че да е подходящ за заявки за изображения с типични файлови разширения. Променен блокместоположение както следва:

Корен /данни/изображения;

Аргументът е регулярен израз, който съответства на всички URI, завършващи на.gif , .jpg или .png . Регулярният израз трябва да бъде предшестван от знак~ . Съответните заявки ще бъдат картографирани към директорията/данни/изображения.

Когато nginx избере блокместоположение , който ще обслужва заявката, тогава първо проверява директивитеместоположение , дефиниране на представки, запомнянеместоположение с най-дългия съответстващ префикс и след това проверява за регулярни изрази. Ако има съвпадение на регулярен израз, nginx избира подходящияместоположение , в противен случай, предварително запомненотоместоположение.

Получената конфигурация на прокси сървъра изглежда така:

сървър (

Местоположение / (

Proxy_pass http://localhost:8080/;

Местоположение ~ \.(gif|jpg|png)$ (

Корен /данни/изображения;

Този сървър ще филтрира заявки, завършващи с.gif , .jpg или .png и ги покажете в директорията/данни/изображения (чрез добавяне на URI към параметъра на директиватакорен ) и пренасочва всички други заявки към сървъра нагоре по веригата, конфигуриран по-горе.

За да приложите новата конфигурация, изпратете сигналпрезаредете nginx, както е описано в предишните раздели.

Има много други директиви за допълнително конфигуриране на прокси връзката.

Конфигуриране на FastCGI прокси

nginx може да се използва за препращане на заявки към FastCGI сървъри. Те могат да изпълняват приложения, създадени с помощта на различни рамки и езици за програмиране, като PHP.

Основната конфигурация на nginx за работа с прокси сървър FastCGI включва използването на директивата fastcgi_pass вместо директива proxy_pass и fastcgi_param директиви за конфигуриране на параметрите, предавани на FastCGI сървъра. Представете си, че FastCGI сървърът е достъпен налокален хост: 9000 . Въз основа на конфигурацията на прокси сървъра от предишния раздел, заменете директивата proxy_pass към директивата fastcgi_pass и променете настройката налокален хост:9000. В PHP, параметърът SCRIPT_FILENAME се използва за определяне на името на скрипта и в параметъра QUERY_STRING параметрите на заявката се предават. Ще получите следната конфигурация:

сървър (

Местоположение / (

fastcgi_pass localhost:9000;

Fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Fastcgi_param QUERY_STRING $query_string;

Местоположение ~ \.(gif|jpg|png)$ (

Корен /данни/изображения;

Това ще настрои сървър, който ще пренасочва всички заявки, с изключение на заявките за статични изображения, към прокси сървър, работещ налокален хост: 9000 , използвайки протокола FastCGI.

Един от най-популярните уеб сървъри

Nginx е много популярен сред потребителите на уеб и прокси сървъри поради своята производителност. Сървърът има много предимства, но настройването му ще бъде трудно за начинаещ. Искаме да ви помогнем да разберете конфигурационните файлове, синтаксиса и настройката на основните параметри на Nginx.

Йерархия на директорията

Всички конфигурационни файлове на сървъра се намират в директорията /etc/nginx. Освен това в директорията се намират още няколко папки, както и модулни конфигурационни файлове.

cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params активирани сайтове/

Ако сте използвали Apache, трябва да сте запознати с директориите за активирани и достъпни сайтове. Те определят конфигурацията на сайтовете. Генерираните файлове се съхраняват в последната директория. Папката с активирани сайтове е необходима за съхраняване на конфигурации само за активирани страници. За да ги свържете, имате нужда от символна връзка между папките. Конфигурациите могат да се съхраняват и в директорията conf.d. В същото време, по време на стартиране на Nginx, всеки файл с разширение .conf ще бъде прочетен в нов. Когато пишете конфигурационни файлове, въведете код без грешки и следвайте синтаксиса. Всички останали файлове се намират в /etc/nginx. Конфигураторът съдържа информация за конкретни процеси, както и допълнителни компоненти.

Основният конфигурационен файл за Nginx е nginx.conf.

Той чете всички конфигурационни файлове, обединявайки ги в един, поискан при стартиране на сървъра. Отворете файла с:

sudo nano /etc/nginx/nginx.conf

На екрана ще се появят следните редове:

потребителски www-данни;
работни_процеси 4;
pid /var/run/nginx.pid;
събития (
worker_connections 768;
# мулти_приемане на;
}
http(
. . .

Първият е Главна информацияотносно Nginx. Фразата user www-data указва потребителя, който управлява сървъра. Директивата pid показва къде се намират PID процесите, предназначени за вътрешна употреба. Редът worker_processes показва колко процеса Nginx може да изпълнява едновременно. Освен това тук могат да бъдат зададени регистрационни файлове (например регистърът на грешките се определя от директивата error_log). По-долу е разделът за събития. Необходим е за обработка на сървърни връзки. След него е блокът http.

Структура на конфигурационния файл на Nginx

Разбирането на структурата на файловото форматиране ще ви помогне да разберете по-добре конфигурацията на уеб сървъра. Разделя се на изграждащи блокове. Подробностите за конфигурацията на http блока са наслоени от частни блокове. Те наследяват свойства от родителя, т.е. тази, в която се намират. Този блок съхранява повечето от сървърните конфигурации. Те са разделени на сървърни блокове, в рамките на които са разположени локации.

Когато конфигурирате Nginx сървъра, имайте предвид, че колкото по-нисък е конфигурационният блок, толкова по-малко елементи ще наследяват свойства и обратно. Файлът съдържа голям брой опции, които променят работата на сървъра. Можете например да зададете компресията на файловете, изпратени до клиента. За да направите това, въведете параметрите:

gzip включен;
gzip_disable "msie6";

Имайте предвид, че един и същ параметър може да има различни стойности в различни блокове. Първо го задайте в горната част, след това заменете параметъра на желаното ниво. Ако последно действиене се изпълни, програмата ще зададе стойностите автоматично.

Последните редове на файла nginx.conf са:

включват /etc/nginx/conf.d/*.conf;
включват /etc/nginx/sites-enabled/*;

Те показват, че местоположението и сървърните блокове се съхраняват извън този файл. Те определят настройките за url адреси и конкретни файлове. Такава структура е необходима за поддържане на модулна конфигурационна структура. Вътре в него ще можете да създавате нови директории, файлове за различни сайтове. Освен това можете да групирате подобни файлове. След като обмислите, можете да затворите файла nginx.conf.

Виртуални блокове

Те са аналогични на виртуалните хостове в Apache. Блоковете на раздела на сървъра включват характеристиките на отделните сайтове, които се намират на сървъра. В папката sites-available ще намерите сървърния блокиращ файл, който е по подразбиране. Вътре в него можете да намерите необходимите данни, които може да са необходими при поддръжка на сайтове.

cd сайтове - налични
sudo nano по подразбиране
сървър (
корен /usr/share/nginx/www;
индекс индекс.html индекс.htm;
server_namelocalhost;
местоположение / (
try_files $uri $uri/ /index.html;
}
местоположение /doc/ (
псевдоним /usr/share/doc/;
включен автоиндекс;
позволи 127.0.0.1;
отричам всички;
}
}

В горния пример коментарите бяха умишлено премахнати. Това беше направено за по-лесно възприемане. Вътре в сървърните блокове има настройки, затворени във фигурни скоби:

Този блок се поставя с помощта на директивата за включване в края на http, посочен във файла nginx.conf. Основната директива определя директорията, където ще бъде разположено съдържанието на сайта. В него програмата ще търси файловете, които потребителят ще поиска. Пътят по подразбиране е /usr/share/nginx/www. Nginx разделя редовете или директивите една от друга с точка и запетая. Ако препинателният знак не е поставен, няколко реда се четат като един. За да напишете правилата, които ще се използват като индекс, използвайте директивата за индекс. Сървърът ще ги провери в реда, в който са изброени. Ако нито една от наличните страници не е била поискана от потребителя, ще бъде върнат index.html. Ако не е там, тогава сървърът ще търси index.htm.

правило за име на сървър

Той включва списък с имена на домейни, които сървърният блок ще трябва да обработи. Можете да въведете произволен брой от тях, разделени с интервали. Ако поставите * в края или началото на домейна, можете да посочите име с маска. Звездицата съответства на част от името. Ако пишете *.com.ua, тогава всички адреси на посочените домейн зона. Ако адресът отговаря на описанието на няколко директиви, тогава той ще отговаря на тази, която отговаря напълно. Ако няма съвпадения, отговорът ще бъде на най-дългото име, което има маска. В противен случай ще се извърши съвпадение на регулярен израз. Имената на сървъри, които използват регулярни изрази, започват с тилда (~).

Блокове за местоположение

Следващ по ред ще имаме блок за местоположение. Необходимо е да се определи как се обработват определени заявки. Ако ресурсите не съвпадат с други блокове за местоположение, тогава директивите в скоби ще се прилагат за тях. Тези блокове могат да включват път като /doc/. За установяване на пълно съответствие между uri и местоположение се използва знакът =. Използвайки тилдата, можете да сравнявате регулярни изрази. Можете също да зададете чувствителност към малки и главни букви, като поставите ~. Ако добавите звездичка, случаят няма да играе никаква роля.

Имайте предвид: когато заявката отговаря напълно на блока за местоположение, тя ще бъде използвана и търсенето ще спре. Когато съвпадението е непълно, URI ще бъде съпоставен с параметрите на директивите за местоположение. Използва се блок с комбинация ^~, съответстващ на URI за избор на блок. Ако тази опция не е активирана, сървърът избира най-доброто съвпадение и също търси с помощта на регулярни изрази. Това е необходимо, за да изберете един от подходящите шаблони. Ако се намери подходящ израз, той ще бъде използван. В противен случай ще бъде приложено предишното съвпадение на URI. Имайте предвид обаче, че Nginx предпочита пълни съвпадения. Ако ги няма, ще започне търсенето на регулярни изрази и след това по URI. Паритетът на търсенето се определя от комбинация от знаци ^~.

правило try_files

Това е много полезен инструмент, който може да проверява за съществуването на файлове в даден ред. Той прилага първите съвпадащи критерии за обработка на заявката. Можете да използвате разширени опции, за да посочите как сървърът ще обслужва заявки. В конфигуратора има този ред по подразбиране:

try_files $uri $uri/ /index.html;

какво има предвид тя Ако пристигне заявка, която се обслужва от блок за местоположение, сървърът първо ще се опита да третира uri като файл. Това се предоставя от променливата $uri. Когато няма съвпадение за него, uri ще се третира като директория. Можете да проверите за съществуването му, като добавите наклонена черта в края: $uri/. Има ситуации, когато нито файлът, нито директорията няма да бъдат намерени. В този случай ще се зареди файлът по подразбиране - index.html. Правилото try_files използва последния параметър като резервен. Защото даден файлтрябва да е в системата. Ако обаче изобщо не бъде намерено съвпадение, Nginx ще върне страница за грешка. За да го зададете, напишете = и кода на грешката:

Допълнителни опции

Ако приложите правилото за псевдоним, можете да обслужвате страниците на блока за местоположение извън основната директория, например. Когато са необходими файлове от doc, те ще бъдат поискани от /usr/share/doc/. Освен това правилото за автоматично индексиране задейства списък със сървърни директории за указаната директива за местоположение. Ако напишете редовете за отказ и разрешение, можете да промените достъпа до директории.

Като заключение си струва да се каже, че Nginx е много мощен. мулти инструмент. Но за да разберете добре принципа на неговата работа, ще отнеме време и усилия. Ако разбирате как работят конфигурациите, ще можете да се насладите напълно на всички функции на програмата.

|

Nginx е безплатен уеб сървър с отворен код, който се използва за обслужване на уебсайтове и приложения с всякаква сложност. Nginx е известен със своето ниско въздействие върху паметта, висока мащабируемост и модулна, управлявана от събития архитектура, която може да осигури надеждна и предвидима производителност. Nginx работи не само като уеб сървър, но и като балансиращо натоварване, HTTP кеширащ сървър и обратен прокси.

Разбира се, в началото може да е трудно да запомните всички команди и препоръки за управление на Nginx сървъра. Това ръководство е предназначено за тези, които работят с Nginx. Той обхваща някои основни команди за управление на услугата, както и съвети за диагностициране и разрешаване на някои често срещани проблеми.

Всеки раздел може да се използва самостоятелно, така че можете да пропускате раздели, които не ви трябват. Всички условни стойности в командите са маркирани в червено; вместо тези стойности можете да замените вашите собствени данни.

Забележка: Това предполага, че използвате версията на Nginx, инсталирана от хранилището по подразбиране на подобна на Debian дистрибуция. Някои от командите и директивите, описани в това ръководство, не са налични в други дистрибуции или версии на Nginx, инсталирани от други източници.

Инсталиране на Nginx

Актуализирайте индекса на пакета и след това инсталирайте Nginx:

sudo apt-get актуализация
sudo apt-get инсталирайте nginx

Проверка на състоянието на Nginx

За да проверите състоянието на уеб сървъра на текущата машина, въведете:

sudo systemctl status nginx

Автоматично зареждане на Nginx

По подразбиране услугата Nginx стартира автоматично. Ако искате да промените това поведение, въведете:

sudo systemctl деактивира nginx

За да добавите Nginx към стартиране отново, въведете:

sudo systemctl активира nginx

Управление на услугата Nginx

За да спрете Nginx сървъра, въведете следната команда:

sudo systemctl стоп nginx

За да стартирате Nginx сървъра, въведете:

sudo systemctl стартира nginx

За да спрете услугата и да я стартирате отново, въведете:

sudo systemctl рестартирайте nginx

Ако сте променили конфигурацията, можете да презаредите Nginx в текущата сесия. Въведете следната команда:

sudo systemctl презареди nginx

Създаване на основна директория за статично съдържание

Когато създават сайтове на Nginx, разработчиците често използват виртуални хостове(или сървърни блокове) са хостове, които обслужват отделни сайтове или домейни. За да направите това, трябва да създадете корен на документа, директория Най-високо ниво, което Nginx проверява при обслужване на съдържание.

Командите в блока по-долу ще създадат нова основна директория, ще прехвърлят разрешения към нея на потребителя на sudo и ще променят разрешенията на всяка поддиректория в поддиректория под /var/www/.


sudo chown -R $USER:$USER /var/www/example.com/html
намери /var/www -type d -exec chmod 775 () \;

В този случай основната директория предлага глобални разрешения за четене и изпълнение. За да изберете други разрешения, заменете 775 и посочете необходимите разрешения.

Не забравяйте, че правата за достъп трябва да се променят според ситуацията.

Създаване на основна директория за динамични файлове

Ако вашият сайт използва динамични модули като PHP-FPM, може да се наложи да прехвърлите разрешения за някои файлове към групата www-data. Ако групата се нуждае от достъп за запис в директорията, дайте на групата собственост върху директорията.

Командите по-долу създават нов корен на документа, дават го на групата www-data и променят разрешенията за всяка поддиректория под /var/www.

sudo mkdir -p /var/www/example.com/html
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www -type d -exec chmod 775 () \;

Активиране и деактивиране на конфигурационни файлове

За да активирате виртуалния хост, трябва да създадете символна връзка от директорията sites-available към директорията sites-enabled, която Nginx чете при стартиране.

За да направите това, въведете командата:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

След това трябва да рестартирате Nginx, за да се актуализират настройките.

Отстраняване на проблеми с хеш таблица

Nginx използва хеш таблици за бърза обработка на статични данни (имена на сървъри, MIME типове). Ако сте добавили множество имена на сървъри, шансовете са посоченият хеш размер на името на сървъра да не е достатъчен и ще видите грешката server_names_hash_bucket_size, когато правите промени. Това може да бъде коригирано чрез редактиране на една стойност във файла /etc/nginx/nginx.conf.

Отворете този файл:

sudo nano /etc/nginx/nginx.conf

Намерете директивата server_names_hash_bucket_size във файла. Премахнете символа #, за да разкоментирате реда и да увеличите стойността на директивата:

http(
. . .
сървър_имена_хеш_бакет_размер 64;
. . .
}

Това ще увеличи размера на хеш-таблиците с имена на сървъри на Nginx и ще позволи на услугата да обработи всички имена на сървъри, които сте добавили. Запазете и затворете файла, след което рестартирайте Nginx, за да актуализирате настройките.

Тестване на конфигурацията

Всеки път, когато правите промени в конфигурационните файлове на Nginx, не забравяйте да изпълните следната команда, за да проверите за синтактични грешки:

Ако има грешки в конфигурацията, изходът на командата ще покаже точно къде са открити. Ако няма синтактични грешки в конфигурационните файлове, ще видите нещо подобно:

nginx: синтаксисът на конфигурационния файл /etc/nginx/nginx.conf е ок
nginx: тестът на конфигурационния файл /etc/nginx/nginx.conf е успешен

Ако няма грешки, можете да презаредите услугата:

sudo systemctl рестартирайте nginx

Важни файлове и директории на Nginx

Съдържание

Директорията /var/www/html съхранява цялото съдържание на сайта (това е основната директория на сайта). можете да промените стандартни настройки Nginx и посочете други директории във var/www.

Конфигурация на сървъра

  • /etc/nginx/: конфигурационна директория на Nginx (всички конфигурационни файлове на уеб сървъра се съхраняват тук).
  • /etc/nginx/nginx.conf: Основният конфигурационен файл на уеб сървъра, където се намират всички глобални настройки.
  • /etc/nginx/sites-available/default: виртуален хост Nginx по подразбиране. Други виртуални хостове също трябва да се съхраняват в директорията за достъпни сайтове (но те няма да работят без символна връзка в активирани сайтове).
  • /etc/nginx/sites-enabled/: Това е мястото, където се съхраняват файловете за активирани виртуални хостове. При стартиране или рестартиране, Nginx чете конфигурационните файлове и връзките в тази директория, за да изгради пълната конфигурация.

трупи

  • /var/log/nginx/access.log: Това е регистрационният файл, който регистрира всички Nginx заявки (освен ако конфигурацията на уеб сървъра не казва друго).
  • /var/log/nginx/error.log: Това е регистърът на грешките.

За достъп до системните регистрационни файлове на процеса Nginx изпълнете тази команда:

sudo journalctl -u nginx

Заключение

Това ръководство съдържа списък общи процедуриподдържа nginx сървъри. За да научите повече за работата с Nginx, вижте следните уроци.

Тагове:

Уеб сървърът Nginx е един от най-популярните уеб сървъри с много висока производителност и бързо обработване на статични заявки от потребители. При правилна настройкаможете да постигнете много висока производителност от този уеб сървър. Nginx обработва статични файлове много бързо html странициили други видове ресурси.

В една от предишните статии вече разгледахме конфигурацията на основните му параметри, в същата статия искам да се спра повече на производителността и подготовката на уеб сървъра за използване в бойни условия. Що се отнася до дистрибуцията на Linux, днес ще разгледаме CentOS, тази система често се използва на сървъри и може да има някои трудности при настройването на Nginx. След това ще разгледаме настройката на Nginx CentOS, нека поговорим за това как да активираме пълна поддръжка за http2, google pagespeed и да настроим основния конфигурационен файл.

Официално CentOS хранилищаима Nginx и най-вероятно вече е инсталиран на вашата система. Но ние искаме сайтът да работи с помощта на протокола http2, който ви позволява да прехвърляте всички данни в една връзка, а това увеличава производителността. За да работите над http2 трябва да конфигурирате SSL сертификат, но това вече е разгледано в статията Получаване на Lets Encrypt Nginx сертификат. Но това не е всичко. Повечето браузъри сега използват протокола ALPN за превключване от обикновен SSL към HTTP2.0 и той се поддържа от OpenSSL 1.02. Докато хранилищата имат само OpenSSL 1.01. Следователно трябва да инсталираме версия на Nginx, изградена с OpenSSL 1.02. Счупеното репо може да се използва за това:

sudo yum -y инсталирайте yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo

Ако използвате хранилището на EPEL, тогава трябва да посочите, че не е необходимо да вземате Nginx от него:

sudo yum-config-manager --save --setopt=epel.exclude=nginx*;

Сега, за да инсталирате правилната версия на Nginx, просто въведете:

sudo yum инсталирайте nginx

Повечето последна версия Nginx 1.13.2, с пълна поддръжка на ALPN. Нека да преминем към настройката.

2. Настройка на Nginx

Първата стъпка е да разгледате структурата на конфигурационния файл. На пръв поглед всичко тук може да изглежда много объркващо, но там всичко е съвсем логично:

глобални опции
събития()
http(
сървър (
местоположение ()
}
сървър()
}

Първо има глобални опции, които задават основните параметри на програмата, например от кой потребител ще се стартира и броя на процесите. Следва раздел. събития, който описва как Nginx ще реагира на входящи връзки, последван от раздел http, който обединява всички настройки относно работата на http протокола. Съдържа раздел сървър, всеки такъв раздел отговаря за отделен домейн, сървърният раздел съдържа секции местоположение, всеки от които отговаря за конкретен URL адрес на заявка, имайте предвид, че не е файл на сървъра, както в Apache, а URL адресът на заявката.

Ще направим основните глобални настройки във файла /etc/nginx/nginx.conf. След това помислете какво точно ще променим и какви стойности е желателно да зададете. Нека започнем с глобалните опции:

  • потребител- потребителят, под чието име ще се стартира сървъра, трябва да е собственик на директорията с файловете на сайта и от негово име да се стартира php-fpm;
  • работни_процеси- броят на Nginx процесите, които ще бъдат стартирани, трябва да бъде зададен точно толкова, колкото ядра имате, например аз имам 4;
  • worker_cpu_affinity- този параметър ви позволява да присвоите всеки процес на отделно процесорно ядро, задайте стойността на auto, така че програмата сама да избере какво и към какво да прикачи;
  • worker_rlimit_nofile - максимална сумафайлове, които програмата може да отвори, имате нужда от поне два файла на връзка и всеки процес ще има броя връзки, които сте посочили, така че формулата е: работни_процеси* работни_връзки* 2, параметър работни_връзкище анализираме малко по-ниско;
  • pcre_jit- активирайте тази опция, за да ускорите обработката на регулярни изрази с помощта на JIT компилация;

В раздела за събития трябва да конфигурирате два параметъра:

  • работни_връзки- броят на връзките за един процес трябва да е достатъчен за обработка на входящите връзки. Първо трябва да знаем колко от тези входящи връзки има, за това разглеждаме статистиката на адреса ip_server/nginx_status. Как да активирате, вижте по-долу. В реда Активни връзки виждаме броя на активните връзки към сървъра, трябва също да вземете предвид, че връзките с php-fpm също се броят. След това обърнете внимание на приетите и обработени полета, първото показва обработените връзки, второто - броя на приетите. От стойностите трябва да са еднакви. Ако се различават, значи няма достатъчно връзки. Вижте примери, първата снимка е проблема, втората е реда. За моята конфигурация цифрата от 200 връзки може да е оптимална (800 общо, като се вземат предвид 4 процеса):

  • мулти_приемане- позволява на програмата да приеме няколко връзки едновременно, също така ускорява работата, с голям брой връзки;
  • accept_mutex- задайте стойността на този параметър на изключено, така че всички процеси незабавно да получават известие за нови връзки;

Също така се препоръчва използването на директивата use epoll в раздела за събития, тъй като това е най-ефективният метод за обработка на входящи връзки за Linux, но този метод се използва по подразбиране, така че не виждам причина да го добавяте ръчно. Обмислете още няколко параметъра от раздела http:

  • изпрати файл- използвайте метода за изпращане на данни sendfile. Най-ефективният метод за Linux.
  • tcp_nodelay, tcp_nopush- изпраща заглавки и тяло на заявка в един пакет, работи малко по-бързо;
  • keepalive_timeout- изчакване за поддържане на връзка с клиента, ако нямате много бавни скриптове, тогава ще са достатъчни 10 секунди, задайте стойността толкова дълго, колкото е необходимо, за да може потребителят да се свърже със сървъра;
  • reset_timeout_connection- прекъснете връзките след изчакване.
  • отворен_файл_кеш- кеш информация за отворени файлове. Например open_file_cache max=200000 inactive=120s; max - максималният брой файлове в кеша, време за кеширане.
  • отворен_файл_кеш_валиден- когато трябва да проверите уместността на файловете. Например: open_file_cache_valid 120s;
  • open_file_cache_min_uses- кеширане само на файлове, които са били отворени определения брой пъти;
  • отворен_файл_кеш_грешки- запомняне на грешки при отваряне на файлове.
  • if_modified_since- задава как ще се обработват заглавките if-modified-since. С тази заглавка браузърът може да получи отговор 304, ако страницата не се е променила от последния път, когато е била прегледана. Има опции - не изпращай - изключено, изпращане при точно съвпадение на часа - точно, изпращане при точно съвпадение на часа или повече - преди;

Ето как ще изглежда настройката на nginx conf:

потребител nginx;
работни_процеси 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit включен;
error_log /var/log/nginx/error.log предупреждение;
load_module "modules/ngx_pagespeed.so";
събития (
мулти_приемане на;
accept_mutex изключен;
worker_connections 1024;
}
http(
изпращане на файл;
tcp_nopush включен;
tcp_nodelay включен;
open_file_cache max=200000 неактивен=20s;
open_file_cache_valid 120s;
open_file_cache_errors на;
reset_timeout_connection включено;
client_body_timeout 10;
keepalive_timeout 65;
включват /etc/nginx/sites-enabled.*.conf
}

3. Настройка на http2

Няма да описвам подробно конфигурацията на сървърния раздел, защото вече го направих в статията за инсталиране на Nginx в Ubuntu и няма какво да добавя тук, конфигурирането на SSL е доста обширна тема и също ще бъде обсъдена в отделна статия. Но за да настроите http2, трябва вече да имате SSL. След това просто настройте директивата за слушане в секцията на вашия сървър:

слушане 194.67.215.125:443 default_server;

слушане 194.67.215.125:443 http2 default_server;

като този по прост начинвъзможно е да активирате http2, ако правилната версия на Nginx е била инсталирана преди това.

4. Настройка на PageSpeed

Google Pagespeed е модул на Nginx, който извършва различни оптимизации, за да накара страниците да се зареждат по-бързо, уеб сървърът да работи по-ефективно и потребителите да се чувстват комфортно. Това включва кеширане, оптимизация html код, оптимизация на изображения, комбиниране на javascript и css код и много други. Всичко това се прави на ниво Nginx, така че е по-ефективно, отколкото ако го направите в php. Но има един недостатък, модулът премахва заглавка Последномодифициран.

Факт е, че PageSpeed ​​​​задава много дълъг кеширащ ред за всички файлове и добавя неговия хеш към името на файла. Това прави зареждането на ресурса много по-бързо, тъй като браузърът ще изисква само файлове с новия хеш, а LastModified се премахва, така че потребителите да могат да видят промените, ако някой файл е променен. Сега нека да разгледаме как да инсталирате модула. Ще трябва да го изградим от източника.

Първо инсталирайте инструментите за изграждане, това е много важно, ако не го инсталирате, тогава ще получите грешка и няма да знаете какво да правите:

yum инсталирайте wget gcc cmake разархивирайте gcc-c++ pcre-devel zlib-devel

Изтеглете и извлечете изходните кодове на Nginx за вашата версия, например 1.13.3:

wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz

Настройването на nginx сървъра не включва повторно изграждане и подмяна на програмата от хранилището, ние просто използваме тези източници за изграждане на модула. Изтеглете и извлечете източниците на PageSpeed:

wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# разархивирайте v1.12.34.2-stable.zip

Изтеглете и разархивирайте библиотеката за оптимизация на PageSpeed ​​в папката източник на модула:

cd ngx_pagespeed-1.12.34.2-стабилен/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz

Изтеглете и извлечете източниците на OpenSSL 1.02:

wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz

Сега трябва да изградим модула. Първо, нека да разгледаме опциите, с които е изграден текущият Nginx:

И сега отиваме в папката с Nginx, заместваме всички получени опции, опцията --add-dynamic-module за PageSpeed, OpenSSL и се опитваме да изградим:

cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx .conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx .pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache /nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path= /var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_module_with-http_module --with-http_sub_module --wit h-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with-ld-opt= --with -openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable $(PS_NGX_EXTRA_FLAGS)
#правя

Ако всичко е направено правилно, тогава на изхода ще получите модула ngx_pagespeed.so в папката obj, трябва да го копирате в папката /etc/nginx/modules:

cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so

Създайте папка за кеша:

mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache

Сега добавете този ред, за да активирате модула в /etc/nginx/nginx.conf:

load_module "modules/ngx_pagespeed.so";

Ще работим под сметкаредовен потребител с sudo права. Ще ви трябва и инсталиран уеб сървър Nginx. Ако желаете, можете да инсталирате пълния LEMP (Linux, Nginx, MySQL и PHP). За да инсталирате Nginx, просто изпълнете следната команда:

sudo apt-get актуализация sudo apt-get инсталирайте nginx

Преди да продължите да четете статията, горещо ви препоръчваме да изпълните горните условия. Например ще настроим два домейна на нашия сървър. Имената им са example.com, test.com. Ако не разполагате с две безплатни имена, просто измислете две и по-късно ще ви покажем как да персонализирате вашето локален сървърза проверка на тяхната функционалност.

Стъпка 1 - Създаване на нова основна директория

По подразбиране само един виртуален хост е активиран на вашия Nginx сървър. Работи с документи на: /usr/share/nginx/html. Ще променим тази настройка, защото е най-вероятно да работим с директорията /var/www. Nginx не използва тази директория по подразбиране, тъй като е против политиката на Debian да използва пакети в директорията /var/www.

Но тъй като ние сме обикновени потребители и рядко срещаме проблеми със съхранението на пакети, ще пренебрегнем тази политика и ще зададем тази директория като основна. По-конкретно, всяка директория в основната директория трябва да съответства на отделен сайт. И ние ще поставим всички файлове на сайта в директорията /var/www/site_name/html. Първо, нека създадем всички необходими поддиректории. За да направите това, изпълнете следната команда:

sudo mkdir -p /var/www/example.com/html sudo mkdir -p /var/www/test.com/html

Флагът -p казва на обвивката да създаде нови директории, ако те не съществуват в посочения път. Сега ще прехвърлим правата върху тази директория обикновен потребител. Нека използваме променливата на средата $USER, за да избегнем въвеждането на името на нашия акаунт. След тези стъпки ние ще можем да създаваме файлове в директорията /var/www/, но посетителите на сайта не.

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 в директорията на първия домейн:

Nano /var/www/example.com/html/index.html

Вътре ще направим минималното съдържание, за да разберем на кой сайт се намираме. Ето примерно съдържание:

Добре дошли в Example.com!

Това е виртуалният хост example.com!



Запазете и затворете файла. Тъй като вторият файл ще има подобно съдържание, просто го копирайте:

cp /var/www/example.com/html/index.html /var/www/test.com/html/

Нека направим няколко промени в него:

Nano /var/www/test.com/html/index.html Добре дошли в Test.com!

Това е виртуалният хост test.com!



Запазете и затворете този файл. Сега ще видим дали нашите сайтове са конфигурирани правилно.

Стъпка 3 - Създайте виртуални хост файлове за всеки домейн

Сега имаме съдържание за всеки сайт, време е да създадем виртуални хостове(по-точно в Nginx те се наричат ​​сървърни блокове, но ние ще използваме термина виртуален хост). По подразбиране Nginx използва един виртуален хост, извикан по подразбиране. Нека го използваме като шаблон за нашата конфигурация. Първо ще изработим настройката за първия домейн, който след това просто ще копираме и ще направим минимални промени във втория домейн.

Създаване на първия виртуален хост файл

Както казах, копирайте конфигурационния файл по подразбиране:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

Нека отворим този файл с администраторски права:

Sudo nano /etc/nginx/sites-available/example.com

Ако пропуснете коментарите, файлът трябва да изглежда така:

Сървър (слушайте 80 default_server; слушайте [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; индекс index.html index.htm; сървър_име localhost; местоположение / ( try_files $uri $uri/ =404 ;))

Да започнем с директивата за слушане. Само един сървърен блок може да бъде зададен на default_server. Блок с тази стойност ще обслужва заявки, ако не е намерен съответстващ блок (блокът е всичко в сървъра). Ще деактивираме тази директива във виртуалния хост по подразбиране, за да използваме default_server на един от нашите домейни. Ще оставя тази функция активирана за първия домейн, но можете да я преместите във втория, ако желаете.

Следващото нещо, което ще направим, е да настроим основната директория с директивата root. Той трябва да сочи към директорията, където се намират всички документи на вашия сайт:

Корен /var/www/example.com/html;

Бележката: всяка инструкция на Nginx трябва да завършва със знак „;“.

Име на сървър example.com www.example.com;

Сървър (слушайте 80 default_server; слушайте [::]:80 default_server ipv6only=on; корен /var/www/example.com/html; индекс index.html index.htm; име на сървър example.com www.example.com; местоположение / (try_files $uri $uri/ =404; ))

По този основна настройказавършен. Запазете и затворете файла.

Създайте втори виртуален хост

За да направите това, просто копирайте файла с настройки за първия сайт:

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

Отворете този файл с администраторски права

sudo nano /etc/nginx/sites-available/test.com

В този файл също ще започнем с директивата за слушане. Ако сте оставили опцията default_server в първия файл, тя трябва да бъде изтрита тук. Също така е необходимо да премахнете опцията ipv6only=on, тъй като е посочена само за една комбинация адрес/порт:

Слушайте 80; слушам[::]:80;

Задайте основната директория за втория сайт:

Корен /var/www/test.com/html;

Сега нека посочим server_name за втория домейн:

Име на сървър test.com www.test.com;

Крайната настройка трябва да изглежда така:

Сървър ( слушайте 80; слушайте [::]:80; корен /var/www/test.com/html; индекс index.html index.htm; име на сървър test.com www.test.com; местоположение / ( try_files $uri $ uri/ =404; ) )

Запазете и затворете файла.

Стъпка 4 - Активиране на виртуални хостове и рестартиране на Nginx

Настроихме нашите виртуални хостове, сега е време да ги активирате. За да направите това, трябва да създадете символни връзки към тези файлове и да ги поставите в директорията с активирани сайтове, която 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/

Сега Nginx ще обработи тези файлове. Но виртуалният хост по подразбиране също е активиран, така че получаваме конфликт на параметър default_server. Можете да деактивирате тази настройка просто като премахнете връзката към файла. Самият файл ще остане в директорията sites-available, така че винаги да можем да го върнем при необходимост.

sudo rm /etc/nginx/sites-enabled/default

Има още една настройка, която трябва да се направи в конфигурационния файл на Nginx. Отвори го:

sudo nano /etc/nginx/nginx.conf

Трябва да премахнете коментара от един от редовете:

Server_names_hash_bucket_size: 64

Тази директива се използва, когато са дадени голям брой имена на сървъри или са дадени необичайно дълги имена. Например, ако стойността по подразбиране е 32 и името на сървъра е зададено на "too.long.server.name.example.org", тогава nginx ще откаже да стартира и ще даде съобщение за грешка:

Не може да се изгради server_names_hash, трябва да увеличите server_names_hash_bucket_size: 32

Затова е по-добре да увеличите тази стойност до 64. Сега можете да рестартирате уеб сървъра, за да влязат в сила промените:

Рестартирайте услугата Sudo nginx

Вашият сървър вече трябва да обработва заявки и за двата домейна.

Стъпка 5 — Настройване на файл с локални хостове (по избор)

Ако сте използвали свои собствени имена на домейни, тогава трябва да конфигурирате локалния си сървър, така че да ги разпознава и да можете да проверявате вашите виртуални хостове (ние ще регистрираме нашите имена на домейни в локалния хост файл). Разбира се, интернет потребителите няма да могат да видят вашия сайт по този начин, но ще бъде достатъчно да проверят хостовете. По този начин прихващаме заявката, която трябва да бъде изпратена DNS сървър. На теория ние посочваме към кой IP адрес трябва да отиде нашият компютър, когато осъществява достъп до конкретно име на домейн.

Моля, обърнете внимание, че тези промени трябва да се правят само на локалната машина, а не на VPS сървъра. Ще имаш нужда root права, вие също трябва да имате право да променяте системните файлове.

Ако използвате Mac или Linux система, корекциите могат да бъдат направени, както следва:

sudo nano /etc/hosts

Ако използвате Windows, можете да намерите инструкции за тази операционна система на официалния уебсайт на производителя (или в Google). Трябва да знаете публичния IP адрес на вашия сървър и имената на домейни, които искате да свържете с него. Да приемем, че адресът ми е 111.111.111.111, тогава трябва да добавя следните редове към файла hosts:

127.0.0.1 localhost 127.0.0.1 работен плот за гости 111.111.111.111 example.com 111.111.111.111 test.com

По този начин ще прихванем всички заявки към тях имена на домейнии ги пренасочваме към нашия сървър. Запазете и затворете файла, когато сте готови.

Стъпка 6 - Проверка

На този етаптрябва да получите напълно работеща настройка. Остава само да го проверите. За да направите това, отидете на адреса на браузъра: http://example.com ( :target="_blank") . Ако и двата сайта се показват правилно, можете да бъдете поздравени пълно персонализиране nginx сървър. На този етап, ако сте направили промени във файла hosts, те трябва да бъдат изтрити. Проверката беше успешна и те вече не са необходими. За да отворите достъп до сайтове за интернет потребители, ще трябва да закупите имена на домейни.

Заключение

Научихте как да конфигурирате напълно виртуални хостове за всеки сайт на вашия сървър. Всъщност няма ограничения за броя сайтове на една машина, с изключение на ресурсите на самата система.



Зареждане...
Връх