Як хостынгавать некалькі сайтаў на адным серверы з Nginx: лепшыя практыкі для віртуальных хостаў

Nginx серверныя блокі (віртуальныя хосты) — гэта гнуткая сістэма, якая дазваляе размяшчаць некалькі даменаў ці вэб-сайтаў на адной інсталяцыі Nginx з рознымі настройкамі. Напрыклад, на адным VPS можна запусціць example.com, blog.example.com і drugasite.by, задаўшы для кожнага асобную root-дырэкторыю, журналы, SSL-сертыфікаты і PHP налады. Каротка: для кожнага сайта ствараецца асобная дырэкторыя, дамен накіроўваецца на IP сервера праз DNS, у /etc/nginx/sites-available пішацца асобны серверны блок, які падключаецца ў sites-enabled, канфігурацыя тэстуецца і пасля Nginx перазагружаецца.

У гэтым гайдзе разглядаем працэс мульці-сайтавага хостынгу з Nginx у прамысловай (production) рэальнасці. Мэта — не проста працуючая схема, а кіраваная, бяспечная, хуткая, рэзервуемая і маштабуемая структура. Асабліва падыходзіць для агенцтваў, распрацоўшчыкаў, уладальнікаў інтэрнэт-крам, кампаній з некалькімі брэндамі, а таксама для сістэмных адміністратароў, што запускаюць некалькі праектаў на адным серверы. Калі ў вас яшчэ няма сервера, глядзіце VPS сервер для выбару рэсурсаў і Рэгістрацыя дамена для кіравання даменамі.

Што такое Nginx серверныя блокі?

Серверны блок у Nginx — гэта частка канфігурацыі (server block), якая вызначае, да якога сайта накіроўваць HTTP ці HTTPS-запыт. Гэта аналог Apache VirtualHost. Калі карыстальнік уводзіць дамен у браўзеры, DNS перакладае яго ў IP сервера, а Nginx выбірае server_name, які адпавядае загалоўку Host, і загружае адпаведны блок.

Гэта дазваляе размяшчаць дзясяткі сайтаў на адным IP і фізічна або віртуальна серверы. Для кожнага можна задаць асобны root, журналы доступу і памылак, правілы перанакіравання, SSL, cache і security палітыку. Напрыклад, карпаратыўны сайт — /var/www/kompania/public, блог — /var/www/blog/public, тэставы сайт — /var/www/testing/public.

Nginx выдатна спраўляецца з такой архітэктурай: падзеяўная мадэль забяспечвае высокую канкурэнтнасць пры мінімальных рэсурсах. Таму яго выбіраюць для VPS, cloud-сервераў, shared hosting і нагружаных праектаў. Для надзейнай працы мульці-сайтавы хостынг патрабуе дакладна прадуманых дазволаў, DNS, SSL, асобных журналяў і іншых дэталяў.

Калі выкарыстоўваць серверныя блокі Nginx?

Ідэальны выпадк — калі трэба размясціць некалькі вэб-актываў на адным серверы: два карпаратыўныя сайты, дзясяткі кліенцкіх праектаў, субдамены або мікрасервісы. Галоўнае — логічна ізаляваць кожны праект.

• Калі хочаце размяшчаць некалькі даменаў на адным VPS.
• Калі трэба накіраваць www і без www дамены на адзін кананічны адрас.
• Калі субдамены павінны ісці ў розныя дырэкторыі ці праграмы.
• Калі кожны сайт мае асобны SSL і політыку бяспекі.
• Калі кліенцкія праекты трэба адсочваць па асобных журналах.
• Калі WordPress, Laravel, статычны HTML або Node.js працуюць разам на серверы.

Напрыклад, у агенцтва на VPS з 4 GB RAM можна размясціць да 8 невялікіх карпаратыўных сайтаў. Але для кожнага трэба ўлічваць трафік, дыскавыя рэсурсы, PHP-працэсы, нагрузку на базу і частату бэкапаў. Для высокага трафіку ці ізаляцыі — выбірайце больш магутныя VPS, cloud або managed hosting. Параўнайце Вэб-хостынг і Карпаратыўны Хостынг для выбару.

Патрабаванні перад пачаткам

Гайд разлічаны на Ubuntu або Debian Linux сервер. Каманды могуць крыху адрознівацца, але прынцыпы аднолькавыя. Перад зменамі абавязкова зрабіце рэзервовую копію. Няправільная настройка Nginx можа часова заблакаваць усе сайты.

Тэхнічная падрыхтоўка

• Linux-карыстальнік з root або sudo правамі.
• Усталяваны і працуючы Nginx.
• Як мінімум адзін дамен, які паказвае на IP сервера.
• Адкрыты порты 80 і 443 у firewall.
• Структураваная дырэкторыя для сайтаў.
• Актуальны SSL-сертыфікат або Let’s Encrypt.
• PHP-FPM для PHP-сайтаў.

DNS: A-запіс — дамен → IPv4, AAAA — → IPv6. Для www і іншых субдаменаў — CNAME або A. Распаўсюджанне DNS — ад некалькіх хвілін да 24 гадзін. Лепш спачатку наладзіць DNS, пасля — Nginx блокі.

Рэкамендаванае структура дырэкторыяў

Памылка — усе файлы ў адной папцы. Гэта лёгка спачатку, але цяжка для абслугоўвання, бэкапаў і адладкі. Лепш — асобная root-папка для кожнага дамена, з public, logs, backups як падпапкі.

Напрыклад: /var/www/site1.by/public, /var/www/site1.by/logs, /var/www/site2.by/public, /var/www/site2.by/logs. root у Nginx — public. Так .env, бэкапы і канфігурацыі не трапляюць у вэб-доступ.

Для тэсту — index.html з назвай сайта ў public кожнага сайта. Так можна хутка праверыць, які блок працуе. У prod-умовах уладальнік — www-data або deployment-карыстальнік. Права доступу 755 для папак, 644 для файлаў — дастаткова. Для WordPress uploads — настройвайце асобна.

Пакрокавая настройка сервернага блока Nginx

Прыклад — для site1.by. Можна паўтараць для кожнага новага сайта. Галоўнае — асобныя server_name, root, журналы.

1. Стварыце папку сайта

sudo mkdir -p /var/www/site1.by/public — root для сайта. У public/index.html напішыце “Гэта тэст сайта site1.by” для праверкі.

sudo chown -R www-data:www-data /var/www/site1.by — уладальнік. Калі deployment іншым карыстальнікам — наладзьце group. Не давайце 777! Гэта рызыка для бяспекі (хакеры могуць загружаць шкодныя файлы).

2. Стварыце файл сервернага блока

Актыўныя і неактыўныя канфігурацыі трымаюць у /etc/nginx/sites-available, актыўныя — у /etc/nginx/sites-enabled праз symbolic link. Файл: /etc/nginx/sites-available/site1.by

Базавы server block:

server {
    listen 80;
    server_name site1.by www.site1.by;
    root /var/www/site1.by/public;
    index index.html index.htm;
    access_log /var/log/nginx/site1.by.access.log;
    error_log /var/log/nginx/site1.by.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

listen 80 — HTTP; server_name — дамены; root — папка; index — базавы файл; try_files — калі няма файла/папкі, вяртае 404. Для статычных сайтаў — гэтага дастаткова.

3. Актывуйце сайт

sudo ln -s /etc/nginx/sites-available/site1.by /etc/nginx/sites-enabled/site1.by — symbolic link. Гэта лепш, чым копія, бо ўсе змены ў файле адразу актуальныя для актыўнай канфігурацыі.

Калі не хочаце, каб стандартная старонка Nginx перашкаджала — выдаліце /etc/nginx/sites-enabled/default. Перад гэтым упэўніцеся, што ваш блок працуе.

4. Праверце канфігурацыю і перазагрузіце Nginx

sudo nginx -t — тэст сінтаксісу. Калі ўсё добра — sudo systemctl reload nginx. reload лепш, бо не перарывае злучэнні, як restart.

Калі test nginx -t падае, звычайна паказвае файл і радок. Папулярныя памылкі — адсутнасць ;, няправільныя {}, памылковыя шляхі, дубляваны server_name. Не перазагружайце, пакуль не выправіце!

Даданне другога і трэцяга сайта

Прыгажосць мульці-сайтавай схемы — працэс паўтаральны. Для site2.by — ствараеце /var/www/site2.by/public, канфігурацыю /etc/nginx/sites-available/site2.by, мяняеце root і журналы, робіце symbolic link і тэст.

Базавы block для другога сайта:

server {
    listen 80;
    server_name site2.by www.site2.by;
    root /var/www/site2.by/public;
    index index.html;
    access_log /var/log/nginx/site2.by.access.log;
    error_log /var/log/nginx/site2.by.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Асобныя журналы — вялікая каштоўнасць. Калі ў site1.by шмат 404, а ў site2.by усё добра — можна хутка знайсці прычыну. Таксама для аналізу трафіку, атак ботаў, паламаных спасылак, праблем з прадукцыйнасцю.

SSL і HTTPS настройка

На 2026 год HTTPS — стандарт і крытэр даверу карыстальнікаў, плюс SEO. Браўзеры пазначаюць HTTP як “небяспечны”; для аплаты, рэгістрацыі, формаў, адміністрацыйных панэляў SSL — абавязкова. Для кожнага дамена — асобны сертыфікат. Для патрэб SSL глядзіце Сертыфікаты SSL.

Для Let’s Encrypt — certbot --nginx -d site1.by -d www.site1.by. Certbot сам дадае HTTPS блок, але лепш праверыць ручна — могуць быць памылкі ў перанакіраваннях або дубляванні блокаў.

Звычайна HTTP (port 80) накіроўваецца на HTTPS (port 443) з пастаянным 301 redirect — гэта важна для SEO. Вызначце, ці патрэбны www, і ўсе варыянты накіруйце на адзін кананічны дамен. Напрыклад, калі выбіраеце https://site1.by, перанакіроўвайце www.site1.by на site1.by. Гэта зніжае рызыку дублявання кантэнту.

Nginx серверныя блокі для PHP і WordPress

Для статычнага HTML — простая канфігурацыя. Для WordPress, Laravel або PHP — патрэбны PHP-FPM. index.php задаецца як entry-point, PHP-запыты ідуць у сокет. На Ubuntu PHP 8.3 — /run/php/php8.3-fpm.sock (шлях залежыць ад версіі).

Прыклад блока для PHP:

server {
    listen 80;
    server_name wordpress-site.by www.wordpress-site.by;
    root /var/www/wordpress-site.by/public;
    index index.php index.html;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Для WordPress try_files $uri $uri/ /index.php?$args — каб працавалі пермалінкі. Дадатковая бяспека: абмежаваць доступ да xmlrpc.php, wp-login.php (rate limit), забараніць запуск PHP у uploads. Для кожнага сайта — асобная база, карыстальнік, рэгулярныя абнаўленні. Калі хочаце больш просты менеджмент — глядзіце хостынг WordPress.

Nginx server blocks vs Apache VirtualHost

Nginx і Apache даюць мульці-сайтавы хостынг, але з рознай архітэктурай. Выбар залежыць ад патрэбаў, звычак і чакання прадукцыйнасці.

Калі ваш праект моцна залежыць ад .htaccess — Apache лягчэй. Але для высокага трафіку, проксі, кэша і сучасных workflow — Nginx пераважней. Магчымы і гібрид: Nginx як proxy, Apache — backend.

Лепшыя практыкі бяспекі

Мульці-сайтавы хостынг зніжае кошты, але павялічвае адказнасць за бяспеку. Для ізаляцыі і мінімізацыі рызыкі — прытрымлівайцеся прынцыпа мінімальных правоў.

• Для кожнага сайта — асобная база і карыстальнік.
• Web root абмяжуйце public-папкай.
• Рэзервовыя, .env, .git, config і SQL-файлы не павінны быць даступныя праз вэб.
• SSL рэгулярна абнаўляйце, HTTPS — абавязкова.
• Firewall (UFW) — толькі неабходныя порты.
• Наладжвайце абнаўленні Nginx і OS.
• Асобныя журналы для кожнага сайта.
• Адміністрацыйныя панэлі — IP-абмежаванне або дадатковая аўтэнтыфікацыя.
• Не давайце 777 — гэта рызыка!

Дадайце загалоўкі бяспекі: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy. Але Content-Security-Policy можа заблакаваць style/script — спачатку тэстуйце на staging. Для больш інфармацыі — Бяспека сайта.

Парады для прадукцыйнасці і SEO

Nginx server blocks важны не толькі для размяшчэння, але і для прадукцыйнасці і SEO. Няправільныя цепачкі перанакіравання, некарэктны canonical, адсутнасць gzip/brotli, вялікія журналы і дрэнны кэш — усё гэта ўплывае на хуткасць сайта. Google ацэньвае user experience: хуткасць, бяспека, стабільнасць.

Для кожнага дамена — выберыце кананічную версію. HTTP → HTTPS, www → без www (ці наадварот) — адна перанакіраванне, не шматступенчатая цепачка. Правільна: http://site.by → https://site.by (адразу).

Для статычных файлаў — cache-control. Картынкі, CSS, JS могуць быць закэшаваны на пэўны час. Для часта абнаўляемых — версія файла або query string. gzip — для HTML, CSS, JS, JSON — зніжае трафік. Для вялікіх сайтаў — microcache, FastCGI cache, CDN (Што такое CDN).

Кіраванне журналамі і маніторынг

Журналы — ключ да хуткага рашэння праблем. Асобныя журналы паказваюць, дзе і калі памылка. access_log — запыты; error_log — канфігурацыя, дазволы, адсутнасць файлаў, upstream-памылкі. 502 Bad Gateway — праблемы PHP-FPM або backend, 403 Forbidden — дазволы або адсутнасць index, 404 — шлях, rewrite або root.

Каб журналы не раслі бясконца — настройвайце logrotate. Для малых праектаў — штодзённа ці штотыдзень, для вялікіх — цэнтральны збор, метрыкі, алерты. Калі дыск поўны — Nginx не можа запісваць журналы, база можа спыніцца, сайты — недаступныя. Вызначайце threshold для выкарыстання дыска.

Папулярныя памылкі і хуткія рашэнні

Пры працы з Nginx server blocks часта сустракаюцца наступныя памылкі:

• Дамен адкрываецца не той сайт: праверце server_name і default block.
• 403 Forbidden: праверце root, дазволы і наяўнасць index.
• 404 Not Found: праверце root і try_files.
• 502 Bad Gateway: PHP-FPM працуе? Правільны сокет?
• SSL паказвае не той сайт: праверце server_name і сертыфікат у 443 block.
• Redirect loop: спрасціце правілы перанакіравання HTTP/HTTPS і www.
• Nginx не перазагружаецца: sudo nginx -t — выправіце сінтаксіс па радку.

Прафесіяналы ідуць па checklist: DNS → канфігурацыя Nginx → root-класер → дазволы → тэст → журналы. Спакойна, па парадку — і праблема вырашаецца.

Практичны checklist перад запуском

Перад запуском кожнага сайта праверце:

• Дамен A/AAAA паказвае на правільны IP.
• www і без www — выбраны кананічны.
• HTTP — 301 на HTTPS.
• SSL-сертыфікат актуальны, аўтаматычнае абнаўленне.
• Асобны root і журналы для кожнага сайта.
• Nginx канфігурацыя праверана sudo nginx -t.
• План бэкапа і тэст на аднаўленне.
• Дазволы адпавядаюць прынцыпу мінімальных правоў.
• Firewall — толькі неабходныя порты.
• Памылкі ў журналах маніторынгуецца 15 хвілін пасля запуску.

Гэты checklist дазваляе зменшыць рызыку для кліенцкіх праектаў. Асабліва SSL, DNS і журналы — часта ловяць невідочныя памылкі.

Вынік

Nginx server blocks — аснова для мульці-сайтавага хостынгу: акуратная структура, асобныя канфігурацыі, выразныя перанакіраванні, HTTPS, журналы і рэгулярныя тэсты — робяць кіраванне простым і надзейным. Выкарыстоўвайце гэтыя прынцыпы — ад маленькага партфоліа да вялікіх агенцкіх праектаў.

Пры запуску новага сайта — вызначыце дамен, серверныя рэсурсы і SSL; настройвайце Nginx па checklist. Для прастоты кіравання — разглядайце Пакеты хостынгу, VPS сервер, Сертыфікаты SSL ад Hostragons.

Частыя пытанні

Колькі сайтаў можна размясціць на Nginx server blocks?

Тэхнічна — вельмі шмат, але абмежаванне — CPU, RAM, дыск, трафік, нагрузка базы, PHP-FPM. Для статычных малатрафікавых — дзясяткі; для WordPress, e-commerce — лепш менш, але якасна.

Ці патрэбен асобны SSL для кожнага сайта?

Так, калі кожны дамен або субдамен павінен быць па HTTPS — сертыфікат павінен уключаць гэты дамен. Можна выкарыстоўваць SAN або wildcard, але галоўнае — правільна падключыць сертыфікат у 443 блок для кожнага дамена.

Ці можна размяшчаць субдамены праз Nginx server blocks?

Так. blog.site.by, panel.site.by — асобны server_name, розная root або backend. У DNS стварайце A або CNAME для субдамена.

Якая розніца паміж sites-available і sites-enabled?

sites-available — усе канфігурацыі; sites-enabled — актыўныя (праз symbolic link). Гэта дазваляе лёгка актываваць/дэактываваць сайты.

Чаму адкрываецца няправільны сайт?

Частыя прычыны: няправільны DNS, server_name, default block, памылковы SSL block на 443. Праверце DNS, nginx -t, links у sites-enabled і журнал доступу.