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

Р посібник для початківців

У цьому посібнику дається початкове введення в nginx і описуються деякі прості завдання, які можна вирішити з його допомогою. Передбачається, що nginx вже встановлено на читачовому комп'ютері. Якщо ні, див.Установка nginx . У цьому посібнику описано, як запустити і зупинити nginx і перезавантажити його конфігурацію, пояснюється, як влаштований конфігураційний файл, і описується, як налаштувати nginx для роздачі статичного вмісту, як налаштувати проксі-сервер на nginx, і як зв'язати nginx з FastCGI.

Nginx має один головний і кілька робочих процесів. Основне завдання головного процесу - читання та перевірка конфігурації та управління робочими процесами. Робочі процеси виконують фактичну обробку запитів. nginx використовує модель, засновану на подіях, і залежить від операційної системимеханізми ефективного розподілу запитів між робочими процесами. Кількість робочих процесів задається в конфігураційному файлі і може бути фіксованим для даної конфігурації або автоматично встановлюватись рівним кількості доступних процесорних ядер (див. worker_processes).

Як працюють nginx та її модулі, визначається конфігураційному файлі. За замовчуванням конфігураційний файл називається nginx.conf і розташований у каталозі/usr/local/nginx/conf , /etc/nginx або /usr/local/etc/nginx

Щоб запустити nginx, потрібно виконати файл, що виконується. Коли nginx запущено, ним можна керувати, викликаючи виконуваний файл з параметром-s . Використовуйте наступний синтаксис:

nginx -s сигнал

Де сигнал може бути одним з наступних:

  • stop - швидке завершення
  • - перевідкриття лог-файлів

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

nginx -s quit

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

Зміни, зроблені в конфігураційному файлі, не будуть застосовані, поки команда перезавантажити конфігурацію не буде вручну відправлено nginx'у або він не буде перезапущено. Для перезавантаження конфігурації виконайте:

nginx -s reload

Отримавши сигнал, головний процесперевіряє правильність синтаксису нового конфігураційного файлу та намагається застосувати конфігурацію, що міститься в ньому. Якщо це вдається, головний процес запускає нові робочі процеси і надсилає повідомлення старим робочим процесам із вимогою завершитися. Інакше головний процес відкочує зміни і продовжує працювати зі старою конфігурацією. Старі робочі процеси, отримавши команду завершитися, припиняють приймати нові запити і продовжують обслуговувати поточні запити до тих пір, поки такі запити не будуть обслужені. Після цього старі робочі процеси завершуються.

Посилати сигнали процесам nginx можна також засобами Unix, такими як утиліта kill . У цьому випадку сигнал відправляється безпосередньо з цим ID. ID головного процесу nginx записується за замовчуванням у файл nginx.pid у каталозі /usr/local/nginx/logs або /var/run . Наприклад, якщо ID головного процесу дорівнює 1628, для відправки сигналу QUIT, який призведе до плавного завершення nginx, потрібно виконати:

kill-s QUIT 1628

Для перегляду списку всіх запущених процесів nginx може бути використана утиліта ps , наприклад, так:

ps-ax | grep nginx

Додаткову інформацію про надсилання сигналів процесам nginx можна знайти вУправління nginx.

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

nginx складається з модулів, які налаштовуються директивами, зазначеними у конфігураційному файлі. Директиви поділяються на прості та блокові. Проста директива складається з імені та параметрів, розділених пробілами, і закінчується крапкою з комою (; ). Блокова директива влаштована так само, як і проста директива, але замість крапки з комою після імені та параметрів слід набір додаткових інструкцій, поміщених усередині фігурних дужок ((і) ). Якщо у блокової директиви всередині фігурних дужок можна задавати інші директиви, вона називається контекстом (приклади: events , http , server та location ).

Директиви, розміщені в конфігураційному файлі поза будь-яким контекстом, вважаються такими, що знаходяться в контексті main. Директиви events та http розташовуються в контексті main, server - в http, а location - в server.

Частина рядка після символу# вважається коментарем.

Роздача статичного вмісту

Одна з важливих задач конфігурації nginx - роздача файлів, таких як зображення чи статичні сторінки HTML. Розглянемо приклад, у якому залежно від запиту файли будуть лунати з різних локальних каталогів:/data/www , який містить HTML-файли, та/data/images , що містить файли із зображеннями. Для цього потрібно відредагувати конфігураційний файл та настроїти блок server всередині блоку http з двома блоками location.

По-перше, створіть каталог/data/www і покладіть у нього файл index.html з будь-яким текстовим змістом, а також створіть каталог/data/images і покладіть кілька файлів із зображеннями.

Далі відкрийте конфігураційний файл. Конфігураційний файл за замовчуванням вже включає кілька прикладів блоку server , здебільшого закоментованих. Для нашого поточного завдання краще закоментувати всі такі блоки та додати новий блок server:

http (

Server (

У випадку конфігураційний файл може містити кілька блоків server , що розрізняються по портах, на яких вонислухають , і на ім'я сервера . Визначивши який server буде обробляти запит, nginx порівнює URI, вказаний у заголовку запиту, з параметрами директив location , визначених усередині блоку server.

У блок server додайте блок location наступного виду:

location / (

Root /data/www;

Цей блок location ставить “ / ” як префікс, який порівнюється з URI із запиту. Для відповідних запитів додаванням URI до шляху, вказаного у директиві root , тобто, в даному випадку, до/data/www , виходить шлях до запитуваного файлу в локальній файловій системі. Якщо є збіг з кількома блоками location , nginx вибирає блок із найдовшим префіксом. У блоці location вище вказано найкоротший префікс, довжини один, і тому цей блок буде використаний, тільки якщо не буде збігу з жодним з інших блоків location.

location /images/ (

Root/data;

Він даватиме збіг із запитами, що починаються з/images/ (location / їм теж підходить, але зазначений там префікс коротше).

Підсумкова конфігурація блоку server має виглядати так:

server (

Location / (

Root /data/www;

Location /images/ (

Root/data;

Це вже працююча конфігурація сервера, що слухає стандартний порт 80 і доступний на локальному комп'ютеріза адресою http://localhost/ . У відповідь на запити, URI яких починаються з/images/ , сервер відправлятиме файли з каталогу/data/images . Наприклад, на запитhttp://localhost/images/example.pngnginx відправить у відповідь файл/data/images/example.png . Якщо ж цей файл не існує, nginx відправить відповідь, що вказує на помилку 404. Запити, URI яких не починаються/images/ , будуть відображені на каталог/data/www . Наприклад, у результаті запитуhttp://localhost/some/example.htmlу відповідь буде надіслано файл/data/www/some/example.html .

Щоб застосувати нову конфігурацію, запустіть nginx, якщо він ще не запущений, або надішліть сигнал reload головному процесу nginx, виконавши:

nginx -s reload

Якщо щось працює не як очікувалося, можна спробувати з'ясувати причину за допомогою файлів access.log та error.log з каталогу /usr/local/nginx/logs або /var/log/nginx.

Налаштування простого проксі-сервера

Одним з частих застосувань nginx є використання його як проксі-сервер, тобто сервер, який приймає запити, перенаправляє їх на проксовані сервери, отримує відповіді від них і відправляє їх клієнту.

Ми налаштуємо базовий проксі-сервер, який обслуговуватиме запити зображень з локального каталогу і надсилатиме всі інші запити на сервер, що проксується. У цьому прикладі обидва сервери працюватимуть в рамках одного екземпляра nginx.

По-перше, створіть сервер, що проксується, додавши ще один блок server конфігураційний файл nginx з таким вмістом:

server (

Listen 8080;

Root /data/up1;

Location / (

Це буде простий сервер, що слухає порт 8080 (раніше директива listen не вказувалося, тому що використовувався стандартний порт 80) і відображає всі запити на каталог/data/up1 у локальній файловій системі. Створіть цей каталог і покладіть файл index.html . Зверніть увагу, що директива root поміщена в контекст server . Така директива root буде використано, коли директива location , вибрана для виконання запиту, не містить власної директиви root.

Далі, використовуйте конфігурацію сервера з попереднього розділу та видозмініть її, перетворивши на конфігурацію проксі-сервера. У перший блок location додайте директиву proxy_pass , вказавши протокол, ім'я та порт сервера, що проксується, як параметр (у нашому випадку це http://localhost:8080 ):

server (

Location / (

Proxy_pass http://localhost:8080;

Location /images/ (

Root/data;

Ми змінимо другий блок location , який на даний моментвідображає запити з префіксом/images/ на файли з каталогу/data/images так, щоб він підходив для запитів зображень із типовими розширеннями файлів. Змінений блок location виглядає наступним чином:

Root /data/images;

Параметром є регулярне вираження, що дає збіг з усіма URI, що закінчуються на.gif , .jpg або .png . Регулярному виразу має передувати символ~ . Відповідні запити будуть відображені на каталог/data/images .

Коли nginx вибирає блок location , який обслуговуватиме запит, то спочатку він перевіряє директиви location , що задають префікси, запам'ятовуючи location з найдовший підходящим префіксом, а потім перевіряє регулярні висловлювання. Якщо є збіг з регулярним виразом, nginx вибирає відповідний location , інакше береться запам'ятований раніше location.

Підсумкова конфігурація проксі-сервера виглядає так:

server (

Location / (

Proxy_pass http://localhost:8080/;

Location ~ \.(gif|jpg|png)$ (

Root /data/images;

Цей сервер фільтруватиме запити, що закінчуються на.gif , .jpg або .png , та відображати їх на каталог/data/images (додаванням URI до параметра директиви root ) і перенаправляти всі інші запити на сервер, що проксується, налаштований вище.

Щоб застосувати нову конфігурацію, надішліть сигнал reload nginx'у, як описувалося у попередніх розділах.

Існує безліч інших директив для подальшого налаштування проксі-з'єднання.

Налаштування проксіювання FastCGI

nginx можна використовувати для перенаправлення запитів на сервери FastCGI. Вони можуть виконувати програми, створені з використанням різноманітних фреймворків і мов програмування, наприклад, PHP.

Базова конфігурація nginx для роботи з проксованим FastCGI-сервером включає використання директиви fastcgi_pass замість директиви proxy_pass і директив fastcgi_param для налаштування параметрів, які передаються FastCGI-серверу. Уявіть, що сервер FastCGI доступний за адресою localhost:9000 . Взявши за основу конфігурацію проксі-сервера з попереднього розділу, замініть директиву proxy_pass на директиву fastcgi_pass та змініть параметр на localhost:9000. У PHP параметр SCRIPT_FILENAME використовується для визначення імені скрипта, а в параметрі QUERY_STRING передаються параметри запиту. Вийде наступна конфігурація:

server (

Location / (

Fastcgi_pass localhost:9000;

Fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Fastcgi_param QUERY_STRING $query_string;

Location ~ \.(gif|jpg|png)$ (

Root /data/images;

Таким чином буде налаштований сервер, який перенаправлятиме всі запити, крім запитів статичних зображень, на сервер, що працює за адресою localhost: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 sites-enabled/

Якщо ви користувалися Apache, то повинні бути знайомі з каталогами sites-enabled та sites-available. Вони визначають конфігурацію сайтів. Створені файли зберігаються в останньому каталозі. Папка sites-enabled потрібна для збереження конфігурацій лише активованих сторінок. Щоб зв'язати їх, потрібне символічне посилання між папками. Конфігурації також можна зберігати в каталозі conf.d. При цьому, під час запуску Nginx, кожен файл з розширенням.conf читатиметься по новій. При написанні конфігураційних файлів набирайте код без помилок і дотримуйтесь синтаксису. Всі інші файли знаходяться в /etc/nginx. Конфігуратор містить відомості про конкретні процеси, а також додаткові компоненти.

Головний конфігураційний файл Nginx – це nginx.conf.

Він зчитує всі конфігураційні файли, об'єднуючи в один, запитуваний під час запуску сервера. Відкрийте файл за допомогою:

sudo nano /etc/nginx/nginx.conf

На екрані з'являться такі рядки:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events (
worker_connections 768;
# multi_accept on;
}
http (
. . .

Перша – це загальні відомостіпро Nginx. Фраза user www-data вказує користувача, який запускає сервер. Директива pid показує, де розташовуються процеси PID, призначені для внутрішнього використання. Рядок worker_processes показує скільки процесів може одночасно запускати Nginx. З іншого боку, тут можна вказати логи (наприклад, лог помилок визначається з допомогою директиви error_log). Нижче розташовується розділ events. Він необхідний обробки з'єднань сервера. Після нього розміщується блок http.

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

Розуміння структури форматування файлу допоможе вам краще з'ясувати конфігурацію веб-сервера. Вона поділяється на структурні блоки. Деталі конфігурації блоку http розділені на рівні у вигляді закритих блоків. Вони успадковують якості з батьківського, тобто. того, у якому розташовуються. Цей блок зберігає більшість конфігурацій сервера. Вони поділяються на блоки сервера, всередині яких розташовані місцезнаходження.

Коли ви налаштовуєте сервер Nginx, пам'ятайте, що чим нижче розміщується блок конфігурації, тим менше елементів будуть успадковувати властивості і навпаки. У файлі є велика кількість опцій, що змінюють роботу сервера. Ви можете встановити стиснення файлів, що відправляються клієнту, наприклад. Для цього напишіть параметри:

gzip on;
gzip_disable "msie6";

Майте на увазі, що той самий параметр може приймати різні значення в різних блоках. Спочатку задайте його вгорі, потім перевизначте параметр на потрібному рівні. Якщо остання діяне виконати, програма встановить значення в автоматичному режимі.

Останніми рядками файлу nginx.conf є:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Вони свідчать про те, що блоки location і server зберігаються поза цим файлом. Вони визначають налаштування url-адрес та конкретних файлів. Така структура необхідна підтримки модульної структури конфігурацій. Усередині неї вдасться створювати нові директорії, файли для різних сайтів. Крім того, схожі файли ви зможете згрупувати. Після розгляду ви можете закрити файл nginx.conf.

Віртуальні блоки

Вони є аналогами віртуальних хостів в Apache. Блоки розділу server включають характеристики окремих сайтів, які розташовуються на сервері. У папці sites-available ви знайдете файл блоку server, який застосовується за замовчуванням. Усередині нього можна знайти поза необхідні дані, які можуть знадобитися при обслуговуванні сайтів.

cd sites-available
sudo nano default
server (
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / (
try_files $uri $uri//index.html;
}
location /doc/ (
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}

У наведеному вище прикладі було навмисно прибрано коментування. Це було зроблено для зручності сприйняття. Всередині блоки server розташовуються налаштування, укладені у фігурні дужки:

Цей блок розміщується за допомогою директиви include наприкінці http, прописаному у файлі nginx.conf. За допомогою директиви root визначається каталог, де буде розміщуватися контент сайту. У ньому програма і шукатиме файли, які користувач запитуватиме. Шлях такий за промовчанням: /usr/share/nginx/www. Nginx відокремлює рядки або директиви одна від одної за допомогою крапки з комою. Якщо розділовий пункт не проставити, кілька рядків прочитаються як одна. Щоб прописати правила, які будуть використовуватися як індекс, скористайтесь директивою index. Сервер перевірить їх у порядку перерахування. Якщо жодна з наявних сторінок не була запитана користувачем, повернеться index.html. Якщо його не буде, сервер шукатиме index.htm.

Правило server_name

Вона включає список доменних імен, які повинен буде обробити блок server. Їх можна прописати будь-яку кількість, розділяючи пробілами. Якщо поставити * в кінці або на початку домену, вдасться задати ім'я з маскою. Зірочка відповідає частині імені. Якщо прописати *.com.ua, то сюди відноситимуться всі адреси вказаної доменної зони. Якщо адреса підходить під опис кількох директив, він відповість тій, якій підходить повністю. За відсутності збігів відповідь буде найдовше ім'я, що має маска. Інакше буде виконано відповідність регулярним виразам. Імена сервера, які використовують регулярні вирази, починаються з тильди (~).

Location-блоки

Наступний на черзі у нас буде блок location. Він необхідний визначення способу обробки певних запитів. Якщо ресурси не відповідають іншим блокам location, то до них будуть застосовуватися директиви, зазначені в дужках. Ці блоки можуть містити шлях на кшталт /doc/. Для встановлення повної відповідності між uri та location, застосовується знак =. Застосовуючи тильду, вдасться задати відповідність регулярним виразам. Ви також можете встановити чутливість до регістру, поставивши ~. Якщо додати зірочку, регістр не відіграватиме жодної ролі.

Майте на увазі: коли запит повністю відповідатиме блоку location, він буде використаний, а пошук зупиниться. Коли неповний збіг, URI буде порівнюватися з параметрами директив location. Використовується блок із поєднанням ^~, що збігається з URI для вибору блоку. Якщо цю опцію не використовувати, сервер вибирає оптимальний збіг, а також здійснить пошук з використанням регулярних виразів. Це необхідно для вибору одного з відповідних шаблонів. Якщо відповідний вираз буде знайдено, його буде використано. Інакше застосовується попередній збіг з URI. Однак майте на увазі, що Nginx більше любить повні відповідності. Якщо їх немає, почнеться пошук регулярних виразів, а потім URI. Паритетність пошуку визначається комбінацією символів ^~.

Правило try_files

Це дуже корисний інструмент, здатний перевіряти наявність файлів у порядку. Він застосовує перший відповідний критеріїв обробки запиту. Ви можете використовувати додаткові параметри, щоб встановити, яким чином сервер обслуговує запити. У конфігураторі є такий рядок за замовчуванням:

try_files $uri $uri//index.html;

Що вона означає? Якщо надходить запит, який обслуговується блоком location, сервер спочатку спробує обробити uri як файл. Це забезпечує змінна $uri. Коли відповідності їй не буде, uri буде оброблено як каталог. Можна перевірити його існування, задавши слєш в кінці $uri/. Бувають ситуації, коли файл, каталог не буде знайдено. У такому разі завантажиться файл за замовчуванням – index.html. Правило try_files застосовує останній параметр як запасний варіант. Саме тому даний файлмає бути у системі. Однак якщо збігів взагалі не знайдено, Nginx поверне сторінку помилки. Щоб її задати, пропишіть = та код помилки:

Додаткові опції

Якщо застосувати правило alias, вдасться обслужити сторінки блоку location поза каталогом root, наприклад. Коли потрібні файли з doc, їх буде запрошено з /usr/share/doc/. Крім того, правило autoindеx on запускає лістинг директорій сервера для зазначеної директиви location. Якщо прописати рядки deny та allow, вдасться змінити доступ до каталогів.

Як висновок варто сказати, що Nginx - це дуже потужний багатофункціональний інструмент. Але щоб розібратися добре з принципом його роботи, знадобиться час та зусилля. Якщо зрозуміти роботу конфігурацій, ви зможете повною мірою насолоджуватися всіма можливостями програми.

|

Nginx – це вільний та відкритий веб-сервер, який використовується для обслуговування сайтів та програм будь-якої складності. Nginx відомий своїм низьким впливом на пам'ять, високою масштабованістю та модульною, керованою подіями архітектурою, яка може забезпечити надійну та передбачувану продуктивність. Nginx працює не тільки як веб-сервер, але і як балансувальник навантаження, кешуючий HTTP-сервер та зворотний проксі-сервер.

Звичайно, спочатку може бути складно запам'ятати всі команди та рекомендації щодо управління сервером Nginx. Цей посібник призначений для тих, хто працює з Nginx. Воно охоплює деякі основні команди управління сервісами, а також поради щодо діагностики та вирішення деяких поширених проблем.

Кожен розділ може використовуватись незалежно від інших, тому ви можете пропустити розділи, які вам не потрібні. Усі умовні значення у командах виділено червоним; замість цих значень ви можете підставити дані.

Примітка: Передбачається, що ви працюєте з версією Nginx, встановленою з репозиторію за замовчуванням у Debian-подібному дистрибутиві. Деякі з команд і директив, описаних у цьому посібнику, відсутні в інших дистрибутивах або версіях Nginx, встановлених з інших джерел.

Установка Nginx

Оновіть індекс пакетів та встановіть Nginx:

sudo apt-get update
sudo apt-get install nginx

Перевірка стану Nginx

Щоб перевірити стан веб-сервера на поточній машині, введіть:

sudo systemctl status nginx

Автозавантаження Nginx

За замовчуванням Nginx запускається автоматично. Якщо ви бажаєте змінити цю поведінку, введіть:

sudo systemctl disable nginx

Щоб знову додати Nginx до автозавантаження, введіть:

sudo systemctl enable nginx

Управління сервісом Nginx

Щоб зупинити сервер Nginx, введіть наступне:

sudo systemctl stop nginx

Щоб запустити сервер Nginx, введіть:

sudo systemctl start nginx

Щоб зупинити сервіс та запустити його знову, введіть:

sudo systemctl restart nginx

Якщо ви змінили конфігурацію, ви можете перезавантажити Nginx у поточній сесії. Введіть наступну команду:

sudo systemctl reload nginx

Створення кореневого каталогу для статичного контенту

При створенні сайтів на Nginx розробники часто використовують віртуальні хости(або блоки server) – це хости, які обслуговують окремі сайти чи домени. Для цього необхідно створити document root, каталог верхнього рівня, який Nginx перевіряє під час обслуговування контенту.

Команди в наведеному нижче блоці створять новий кореневий каталог, передадуть права на нього користувачеві sudo і змінять права доступу до кожного підкаталогу в /var/www/.


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

У цьому випадку кореневий каталог пропонує глобальні права на читання та виконання. Щоб вибрати інші права доступу, замініть 775 та вкажіть потрібні права.

Пам'ятайте, що права доступу повинні змінюватися відповідно до ситуації.

Створення кореневого каталогу для динамічних файлів

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

Запропоновані нижче команди створюють новий document root, передають його групі 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 (
. . .
server_names_hash_bucket_size 64;
. . .
}

Це збільшить розмір хеш-таблиць імен серверів Nginx та дозволить сервісу обробляти всі імена серверів, які ви додали. Збережіть і закрийте файл, а потім перезапустіть Nginx, щоб оновити налаштування.

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

Щоразу, коли ви вносите зміни до конфігураційних файлів Nginx, обов'язково виконайте наступну команду, щоб перевірити наявність синтаксичних помилок:

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

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Якщо помилок немає, ви можете перезавантажити сервіс:

sudo systemctl restart nginx

Важливі файли та каталоги Nginx

Контент

Каталог /var/www/html зберігає весь контент сайту (це кореневий каталог сайту). Ви можете змінити стандартні налаштування Nginx та вказати інші каталоги в var/www.

Конфігурація сервера

  • /etc/nginx/: конфігураційний каталог Nginx (тут зберігаються всі конфігураційні файли веб-сервера).
  • /etc/nginx/nginx.conf: головний файл конфігурації веб-сервера, в якому знаходяться всі глобальні параметри.
  • /etc/nginx/sites-available/default: віртуальний хост Nginx за промовчанням. Інші віртуальні хости також повинні зберігатися в каталозі sites-available (але вони не будуть працювати без симлінку в sites-enabled).
  • /etc/nginx/sites-enabled/: тут зберігаються файли включених віртуальних хостів. Під час запуску або перезавантаження Nginx читає конфігураційні файли та посилання в цьому каталозі, щоб зібрати повну конфігурацію.

Логи

  • /var/log/nginx/access.log: це лог, який реєструє всі запити Nginx (якщо конфігурації веб-сервера не сказано іншого).
  • /var/log/nginx/error.log: це лог помилок.

Щоб отримати доступ до логів systemd процесу Nginx, запустіть цю команду:

sudo journalctl -u nginx

Висновок

Цей мануал перерахував загальні процедуриз підтримки сервера Nginx. Щоб дізнатися більше про роботу з Nginx, перегляньте наступні посібники.

Tags:

Веб-сервер Nginx - це один із найпопулярніших веб-серверів з дуже високою продуктивністю та швидкою обробкою статичних запитів від користувачів. При правильному налаштуванніВи можете досягти дуже високої продуктивності від цього веб-сервера. Nginx дуже швидко справляється зі статичними файлами, будь то html сторінкичи інші види ресурсів.

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

В офіційних репозиторіях CentOSє Nginx і він, швидше за все, вже встановлено у вашій системі. Але ми хочемо, щоб сайт працював за протоколом http2, який дозволяє передавати всі дані одним підключенням, а це збільшує продуктивність. Для роботи по http2 вам знадобиться налаштувати SSL сертифікат, але про це вже написано у статті отримання сертифіката Lets Encrypt Nginx. Але це ще не все. для перемикання зі звичайного SSL на HTTP2.0 у більшості браузерів зараз використовується протокол ALPN, а він підтримується, починаючи з OpenSSL 1.02. У той час як у репозиторіях є тільки OpenSSL 1.01. Тому потрібно встановити версію Nginx, зібрану з OpenSSL 1.02. Для цього можна використовувати Broken Repo:

sudo yum -y install 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 install nginx

Буде встановлена ​​сама остання версія Nginx 1.13.2 з повною підтримкою ALPN. Далі перейдемо до настроювання.

2. Налаштування Nginx

Насамперед слід розглянути структуру конфігураційного файла. На перший погляд, тут все може здатися дуже заплутаним, але все досить логічно:

глобальні опції
events ()
http(
server (
location()
}
server ()
}

Спочатку йдуть глобальні опції, які визначають основні параметри програми, наприклад, від якого користувача вона буде запущена і кількість процесів. Далі є секція events, в якій описано як Nginx буде реагувати на вхідні підключення, потім йде секція http, яка об'єднує всі налаштування щодо роботи протоколу http. У ній знаходиться секція server, кожна така секція відповідає за окремий домен, у секції server розміщуються секції location, кожна з яких відповідає за певний URL запиту, зверніть увагу, що не файл на сервері, як і в Apache, а саме URL запиту.

Основні глобальні налаштування ми робитимемо у файлі /etc/nginx/nginx.conf. Далі розглянемо що саме змінюватимемо і які значення бажано встановити. Почнемо з глобальних опцій:

  • user- користувач, від імені якого буде запущено сервер, повинен бути власником каталогу з файлами сайту, і від імені його потрібно запускати php-fpm;
  • worker_processes- кількість процесів Nginx, які будуть запущені, потрібно встановити рівно стільки, скільки у вас є ядер, наприклад, у мене – 4;
  • worker_cpu_affinity- цей параметр дозволяє закріпити кожен процес за окремим ядром процесора, встановіть значення auto, щоб програма сама вибрала що і до чого кріпити;
  • worker_rlimit_nofile - максимальна кількістьфайлів, які може відкрити програма, на кожне з'єднання потрібно як мінімум два файли і кожен процес матиме вказану кількість з'єднань, тому формула така: worker_processes * worker_connections* 2, параметр worker_connectionsрозберемо трохи нижче;
  • pcre_jit- увімкніть цей параметр для прискорення обробки регулярних виразів за допомогою JIT компіляції;

У секції events варто налаштувати два параметри:

  • worker_connections- кількість з'єднань для одного процесу повинна бути достатньою для обробки вхідних з'єднань. Спочатку нам потрібно знати, скільки цих вхідних з'єднань є, для цього дивимося статистику за адресою ip_сервера/nginx_status. Як увімкнути розглянемо нижче. У рядку Active Connections бачимо кількість активних з'єднань із сервером, також потрібно враховувати, що з'єднання з php-fpm теж вважаються. Далі зверніть увагу на поля accepted і handled, перше відображає оброблені підключення, друге - кількість прийнятих. Зі значення повинні бути однаковими. Якщо відрізняються, значить з'єднань не вистачає. Дивіться приклади, перший знімок проблема, другий – порядок. Для моєї конфігурації оптимальною може бути цифра 200 з'єднань (всього 800, враховуючи 4 процеси):

  • multi_accept- дозволяє програмі приймати кілька з'єднань одночасно, також прискорює роботу при великій кількості з'єднань;
  • accept_mutex- встановіть значення цього параметра off, щоб відразу всі процеси отримували повідомлення про нові з'єднання;

Також у секції events рекомендується використовувати директиву use epoll, оскільки цей найефективніший метод обробки вхідних з'єднань для Linux, але цей метод застосовується за умовчанням, тому не бачу сенсу додавати його вручну. Розглянемо ще кілька параметрів із секції http:

  • sendfile- Використовувати метод відправлення даних sendfile. Найефективніший метод для Linux.
  • tcp_nodelay, tcp_nopush- відправляє заголовки та тіло запиту одним пакетом, працює трохи швидше;
  • keepalive_timeout- тайму підтримки з'єднання з клієнтом, якщо у вас немає дуже повільних скриптів, то буде достатньо буде 10 секунд, встановлюємо значення скільки потрібно, щоб користувач міг бути підключений до сервера;
  • reset_timedout_connection- Розривати з'єднання після таймууту.
  • open_file_cache- кешувати інформацію про відкритих файлах. Наприклад, open_file_cache max=200000 inactive=120s; max – максимальна кількість файлів у кеші, час кешування.
  • open_file_cache_valid- коли необхідно перевірити актуальність файлів. Наприклад: open_file_cache_valid 120s;
  • open_file_cache_min_uses- кешувати лише файли, які були відкриті вказану кількість разів;
  • open_file_cache_errors- Запам'ятовувати помилки відкриття файлів.
  • if_modified_since- встановлює як оброблятимуться заголовки if-modified-since. За допомогою цього заголовка браузер може отримати відповідь 304, якщо сторінка не змінилася з моменту останнього перегляду. Можливі варіанти – не відправляти – off, відправляти при точному збігу часу – exact, відправляти якщо час збігається точно або більше – before;

Ось якось так виглядатиме налаштування nginx conf:

User nginx;
worker_processes 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit on;
error_log /var/log/nginx/error.log warn;
load_module "modules/ngx_pagespeed.so";
events (
multi_accept on;
accept_mutex off;
worker_connections 1024;
}
http (
sendfile on;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;
reset_timedout_connection on;
client_body_timeout 10;
keepalive_timeout 65;
include /etc/nginx/sites-enabled.*.conf
}

3. Налаштування http2

Я не буду докладно описувати налаштування секції server, тому що робив це вже в статті установка Nginx в Ubuntu і тут мені нічого додати, налаштування SSL це досить велика тема і теж буде розглянута в окремій статті. Але, щоб налаштувати http2 вам потрібно мати вже SSL. Далі, просто підправте директиву listen у вашій секції server:

listen 194.67.215.125:443 default_server;

listen 194.67.215.125:443 http2 default_server;

Ось таким простим способом можна включити http2, якщо перед цим була встановлена ​​правильна версія Nginx.

4. Налаштування PageSpeed

Google Pagespeed - це модуль Nginx, який виконує різні оптимізації для того, щоб сторінки вантажилися швидше, веб-сервер працював ефективніше, а користувачі не відчували дискомфорту. Сюди входить кешування, оптимізація html коду, оптимізація картинок, об'єднання javascript та css коду та багато іншого. Все це виконується на рівні Nginx, тому ефективніше, ніж якби це робили в php. Але тут є один недолік, модуль видаляє заголовок Last Modified.

Справа в тому, що PageSpeed ​​встановлює дуже довгий рядок кешування для всіх файлів, а в ім'я файлу додає його хеш. Так швидкість завантаження ресурсів виходить набагато вище, оскільки браузер буде запитувати файли тільки з новим хешем, а LastModified видаляється, щоб користувачі змогли побачити зміни у випадку, якщо який-небудь файл буде змінено. А тепер розглянемо, як встановити модуль. Нам доведеться зібрати його із вихідних кодів.

Спочатку встановіть інструменти для складання, дуже важливо, якщо не встановіть, потім отримайте помилку і не знатимете що робити:

yum install wget gcc cmake unzip 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
# unzip v1.12.34.2-stable.zip

Завантажте та розпакуйте бібліотеку оптимізації PageSpeed ​​у папку з вихідними джерелами модуля:

cd ngx_pagespeed-1.12.34.2-stable/
# 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_modus --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)
# make

Якщо все було зроблено правильно, на виході ви отримаєте модуль 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 update sudo apt-get install 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

Прапор -р вказує оболонці, щоб вона створювала нові каталоги, якщо їх не існує у вказаному шляху. Тепер передамо права на цей каталог звичайному користувачеві. Скористайтеся змінною оточення $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 вони називаються server block, але ми будемо користуватися терміном віртуальний хост). За замовчуванням Nginx використовує один віртуальний хост під назвою default. Використовуємо його як шаблон для нашої конфігурації. Спочатку пропрацюємо налаштування для першого домену, яке потім просто скопіюємо та внесемо мінімальні зміни для другого домену.

Створення першого файлу віртуального хоста

Як я вже сказав, скопіюємо файл налаштування default:

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 ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / ( try_files $uri $uri/ =404 ; ) )

Для початку розберемося з директивою listen. Тільки одному блоку server ми можемо встановити значення default_server. Блок з таким значенням обслуговуватиме запити, якщо не було знайдено відповідного блоку (блок - це все, що знаходиться в server). Ми відключимо цю директиву у віртуальному хості default, щоб використовувати default_server на одному з наших доменів. Я залишу цю функцію активованою для першого домену, але за бажання ви можете її перенести на другий.

Наступне що ми зробимо - налаштуємо кореневий каталог за допомогою директиви root. Вона повинна вказувати на каталог, де лежать усі документи вашого сайту:

Root /var/www/example.com/html;

Нотатка: кожна інструкція Nginx має закінчуватися символом “;”.

Server_name example.com www.example.com;

Server ( listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/example.com/html; index index.html index.htm; server_name example.com www.example.com; location / ( 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

У цьому файлі також почнемо з директиви listen. Якщо опцію default_server ви залишили у першому файлі, то її слід видалити. Також необхідно прибрати опцію ipv6only=on, тому що її вказують лише для однієї комбінації адрес/порт:

Listen 80; listen [::]:80;

Встановіть кореневий каталог для другого сайту:

Root /var/www/test.com/html;

Тепер вкажемо server_name для другого домену:

Server_name test.com www.test.com;

Остаточне настроювання має виглядати так:

Server ( listen 80; listen [::]:80; root /var/www/test.com/html; index index.html index.htm; server_name test.com www.test.com; location / ( try_files $uri $ uri/ =404; ) )

Збережіть та закрийте файл.

Крок 4 - активація віртуальних хостів та перезапуск Nginx

Ми налаштували наші віртуальні хости, тепер настав час активувати їх. Для цього треба створити символічні посилання на ці файли і покласти їх у каталог 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/

Тепер Nginx обробить ці файли. Але віртуальний хост default також активований, тому ми отримаємо конфлікт параметра 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 service nginx restart

Ваш сервер тепер має обробляти запити до обох доменів.

Крок 5 - Налаштування локального файлу hosts (додатково)

Якщо ви використовували свої доменні імена, то необхідно налаштувати ваш локальний сервер, щоб той розпізнавав їх і ви змогли б перевірити свої віртуальні хости (прописуватимемо свої доменні імена в локальний файл hosts). Звичайно, користувачі не зможуть таким чином переглядати ваш сайт, але для перевірки хостів цього буде достатньо. Таким чином ми перехоплюємо запит, який має бути надісланий 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 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.com

Таким чином, ми перехопимо всі запити до цих доменних імента перенаправимо їх на наш сервер. Збережіть та закрийте файл, коли закінчите.

Крок 6 - Перевірка

На даному етапі ви повинні отримати повністю робоче настроювання. Залишилося лише її перевірити. Для цього перейдемо в браузері за адресою: http://example.com(: target="_blank"). Якщо обидва сайти відображаються коректно, вас можна привітати з повним налаштуваннямсервера Nginx. У цьому етапі, якщо ви вносили зміни у файл hosts , їх слід видалити т.к. перевірка пройшла успішно, і вони вже не потрібні. Щоб відкрити доступ до сайтів для інтернет користувачів, доведеться придбати доменні імена.

Висновок

Ви навчилися повністю настроювати віртуальні хости для кожного сайту на вашому сервері. По суті, немає жодних обмежень на кількість сайтів на одній машині, крім ресурсів самої системи.



Завантаження...
Top