Nginx Server Blokları ilə Eyni VPS-də Birdən Çox Saytın İdarə Edilməsi

Nginx server blokları, tək bir Nginx quraşdırmasında bir neçə domeni və ya vebsaytı ayrı-ayrı konfiqurasiyalarla idarə etməyə imkan verən virtual host prinsipi əsasında işləyir. Məsələn, eyni VPS üzərində example.com, blog.example.com və ikinci-sayt.com üçün fərqli kök qovluqları, log faylları, SSL sertifikatları və PHP parametrləri təyin edə bilərsiniz. Sadə dillə desək, həll yolu budur: hər sayt üçün ayrıca qovluq yaratmaq, domenin DNS qeydini serverin IP ünvanına yönləndirmək, /etc/nginx/sites-available qovluğunda fərdi bir server bloku yazmaq, onu sites-enabled qovluğuna simvolik linklə bağlamaq, konfiqurasiyanı yoxlamaq və Nginx xidmətini yenidən yükləmək.

Bu bələdçi Nginx server blokları ilə bir neçə saytı istehsal mühitinə uyğun şəkildə necə idarə etməyi addım-addım izah edir. Məqsəd yalnız işləyən bir sistem qurmaq deyil; həm də idarəolunan, təhlükəsiz, sürətli, ehtiyat nüsxələmə üçün əlverişli və miqyaslana bilən bir infrastruktur yaratmaqdır. Xüsusilə agentliklər, tərtibatçılar, e-ticarət sahibləri, çoxlu brendləri idarə edən müəssisələr və tək serverdə bir neçə layihə işlədən sistem administratorları üçün praktik tövsiyələr təqdim edəcəyik. Əgər hələ serveriniz yoxdursa, resurs seçimi üçün VPS server və domen idarəsi üçün Domain Təsdiqi səhifələrinə baxa bilərsiniz.

Nginx Server Blokları Nədir?

Nginx server blokları, Nginx konfiqurasiyasında server bloku kimi təyin olunan və gələn HTTP və ya HTTPS sorğusunun hansı sayta yönləndiriləcəyini müəyyən edən konfiqurasiya hissələridir. Apache-dəki VirtualHost anlayışına bənzəyir. İstifadəçi brauzerə domen yazdıqda, DNS həmin domeni serverin IP ünvanına həll edir. Sonra Nginx sorğuda gələn Host başlığına baxır və server_name dəyəri ilə uyğun gələn server blokunu işə salır.

Bu sayədə eyni IP ünvanı və fiziki və ya virtual server üzərində çoxsaylı fərqli vebsaytlar yayımlana bilər. Hər sayt üçün ayrıca root qovluğu, giriş (access) logları, səhv (error) logları, yönləndirmə qaydaları, SSL sertifikatı, cache siyasəti və təhlükəsizlik qaydaları təyin etmək mümkündür. Məsələn, korporativ saytınızı /var/www/korporativ/public qovluğunda, bloqunuzu /var/www/blog/public qovluğunda, test mühitinizi isə /var/www/staging/public qovluğunda saxlaya bilərsiniz.

Nginx bu quruluşda çox effektivdir, çünki hadisə əsaslı arxitekturası sayəsində yüksək sayda eyni vaxtda bağlantıları az resurs sərfiyyatı ilə idarə edə bilir. Buna görə paylaşılan hosting, VPS, bulud serverləri və yüksək trafikli tətbiq infrastrukturunda geniş istifadə olunur. Çoxsaylı saytların problemsiz işləməsi üçün fayl icazələrindən DNS yönləndirmələrinə, SSL quraşdırılmasından logların ayrılmasına qədər bütün detalları düzgün planlamaq lazımdır.

Nginx Server Blokları Nə Zaman İstifadə Olunur?

Nginx server blokları xüsusilə bir tək serverdə bir neçə vebsaytı idarə etmək lazım olduqda tətbiq edilir. Bu, bəzən iki kiçik korporativ sayt ola bilər, bəzən isə onlarca müştəri layihəsi, subdomen və ya mikroservis ola bilər. Əsas məsələ, hər layihənin məntiqi olaraq ayrılmasıdır.

• Bir neçə domeni eyni VPS üzərində yayımlamaq istəyirsinizsə.
• www və www olmayan domenləri bir kanonik ünvana yönləndirmək istəyirsinizsə.
• Alt domenləri fərqli qovluqlara və ya tətbiqlərə bağlamaq istəyirsinizsə.
• Hər sayt üçün ayrıca SSL sertifikatı və təhlükəsizlik siyasəti tətbiq etmək istəyirsinizsə.
• Müştəri layihələrini ayrıca log faylları ilə izləmək istəyirsinizsə.
• Laravel, WordPress, statik HTML və Node.js kimi fərqli tətbiqləri eyni serverdə işlətmək istəyirsinizsə.

Məsələn, bir rəqəmsal agentlik tək bir 4 GB RAM-lı VPS üzərində 8 ədəd aşağı trafikli korporativ saytı idarə edə bilər. Lakin hər sayt üçün trafik, disk istifadəsi, PHP prosesləri sayı, verilənlər bazası yüklənməsi və ehtiyat nüsxələmə tezliyi hesablanmalıdır. Əgər layihələr yüksək trafik alırsa və ya resursların izolyasiyası vacibdirsə, daha güclü VPS, bulud server və ya idarə olunan hosting həllərinə üstünlük verilməlidir. Bu məqamda Veb Hostinq və Korporativ Hosting variantları müqayisə oluna bilər.

Başlamazdan Əvvəl Tələblər

Bu bələdçidə Ubuntu və ya Debian əsaslı Linux serveri nəzərdə tutacağıq. Əmrlər paylama fərqlərinə görə bir az dəyişə bilər, amma əsas məntiq eynidir. İstehsal mühitində dəyişiklik etməzdən əvvəl mütləq ehtiyat nüsxə alın. Yanlış Nginx konfiqurasiyası bütün saytların müvəqqəti əlçatmaz olmasına səbəb ola bilər.

Texniki hazırlıqlar

• Root və ya sudo hüququ olan Linux istifadəçi hesabı.
• Quraşdırılmış və işləyən Nginx xidməti.
• Server IP ünvanına yönləndirilmiş ən azı bir domen.
• 80 və 443 portlarının firewall-da açıq olması.
• Sayt faylları üçün nizamlı qovluq strukturu.
• SSL üçün etibarlı sertifikat və ya pulsuz Let’s Encrypt istifadəsi.
• PHP əsaslı tətbiqlər üçün PHP-FPM quraşdırılması.

DNS tərəfində A qeydi əsas domeni IPv4 ünvanına, AAAA qeydi varsa IPv6 ünvanına yönləndirir. www kimi alt domenlər üçün CNAME və ya A qeydi istifadə edilə bilər. DNS yayılması adətən bir neçə dəqiqədən 24 saata qədər davam edir. Yeni quruluş zamanı əvvəlcə DNS qeydlərini hazırlamaq, daha sonra Nginx server bloklarının konfiqurasiyasına başlamaq prosesi sürətləndirir.

Tövsiyə Edilən Qovluq Strukturu

Çoxsaylı sayt idarəsi zamanı ən çox edilən səhvlərdən biri bütün faylları qarışıq şəkildə tək qovluqda saxlamaqdır. Bu yanaşma qısa müddətdə rahat görünə bilər, amma baxım, ehtiyat nüsxələmə və səhv tapma proseslərində ciddi vaxt itkisinə səbəb olur. Daha yaxşı üsul, hər domen üçün ayrıca üst qovluq yaratmaq və onun içində public, logs, backups kimi alt qovluqlar təşkil etməkdir.

Məsələn, belə bir struktur planlaşdırıla bilər: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public və /var/www/site2.com/logs. Nginx root dəyəri birbaşa public qovluğuna göstəriş verməlidir. Bu yolla tətbiq faylları, .env kimi həssas sənədlər və ehtiyat nüsxələr vebdən birbaşa əlçatan olmur.

Sadə statik test səhifəsi üçün hər sayt qovluğuna index.html faylı əlavə edə bilərsiniz. İçində sayt adını yazaraq hansı server blokunun işə düşdüyünü tez yoxlaya bilərsiniz. İstehsal mühitində bu qovluqların sahibi adətən www-data istifadəçisi və ya deployment əməliyyatlarını edən xüsusi istifadəçi olur. Fayl icazələrində qovluqlar üçün 755, fayllar üçün 644 standart olaraq yetərlidir. WordPress kimi yazma tələb edən tətbiqlərdə uploads qovluğu kimi yerlərə ayrıca yanaşılmalıdır.

Addım-addım Nginx Server Bloku Yaratmaq

Aşağıdakı addımlar nümunə olaraq site1.com domeni əsasında izah olunub. Eyni metodu ikinci, üçüncü və daha çox sayt üçün də tətbiq etmək olar. Əsas məqam hər sayt üçün unikal server_name, root və log fayllarından istifadə etməkdir.

1. Sayt qovluğunu yaradın

İlk addım veb fayllarının yerləşəcəyi qovluğu yaratmaqdır. Məsələn: sudo mkdir -p /var/www/site1.com/public. Daha sonra test üçün /var/www/site1.com/public/index.html faylı yaradıb içərisinə “Bu site1.com test səhifəsidir” kimi tanınan mətn yaza bilərsiniz.

Fayl sahibliyini düzgün qurmaq üçün sudo chown -R www-data:www-data /var/www/site1.com əmri istifadə oluna bilər. Əgər deployment əməliyyatlarını fərqli istifadəçi ilə aparırsınızsa, qrup icazələrini ona görə tənzimləyin. İstehsal mühitində hamıya yazma icazəsi verən 777-dən qaçın; bu icazələr hücum edənlərin qovluqlardan sui-istifadə etməsinə şərait yarada bilər.

2. Server bloku faylını yaradın

Nginx-də geniş istifadə olunan praktika aktiv olmayan konfiqurasiyaları /etc/nginx/sites-available qovluğunda saxlamaq və aktiv ediləcək faylları /etc/nginx/sites-enabled qovluğuna simvolik linklə bağlamaqdır. Nümunə fayl: /etc/nginx/sites-available/site1.com.

Sadə HTTP server bloku belə yazılır:
server {
listen 80;
server_name site1.com www.site1.com;
root /var/www/site1.com/public;
index index.html index.htm;
access_log /var/log/nginx/site1.com.access.log;
error_log /var/log/nginx/site1.com.error.log;
location / {
try_files $uri $uri/ =404;
}
}

Bu konfiqurasiyada listen 80 HTTP trafiki dinləyir, server_name hansı domenlərin bu bloka aid olduğunu göstərir, root veb fayllarının yerini bildirir, index əsas faylı müəyyənləşdirir. try_files istənilən fayl və ya qovluq tapılmazsa 404 səhvini qaytarır. Statik saytlar üçün bu quruluş kifayətdir.

3. Saytı aktivləşdirin

Konfiqurasiyanı aktiv etmək üçün simvolik link yaradılır: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Bu üsul faylları kopyalamaqdan daha sağlamdır, çünki bütün dəyişikliklər əsas konfiqurasiya faylında edilir və link avtomatik yenilənir.

Əgər standart Nginx səhifəsinin saytınızın qarşısına çıxmasını istəmirsinizsə, default konfiqurasiyanı deaktiv edə bilərsiniz. Bunun üçün /etc/nginx/sites-enabled/default linkini silmək kifayətdir. Amma bunu etməzdən əvvəl öz server blokunuzun düzgün işlədiyinə əmin olun.

4. Konfiqurasiyanı yoxlayın və Nginx-i yenidən yükləyin

Hər dəyişiklikdən sonra sudo nginx -t əmrini işlədərək sintaksis yoxlaması aparılmalıdır. Əgər yoxlama uğurludursa, sudo systemctl reload nginx ilə xidmət kəsilmədən yenidən yüklənir. reload komandası restart-dan daha yumşaqdır, çünki mövcud bağlantıları daha yaxşı idarə edir.

Əgər yoxlama zamanı səhv çıxarsa, mesaj adətən fayl və sətir nömrəsini göstərir. Ən çox rast gəlinən problemlər nöqtəli vergülün olmaması, səhv süslü mötərizə, yanlış qovluq yolu və server_name dəyərlərinin üst-üstə düşməsidir. Səhv aradan qaldırılmadan Nginx yenidən yüklənməməlidir.

İkinci və Üçüncü Saytı Əlavə Etmək

Bir neçə saytın idarəsinin üstünlüyü ondan ibarətdir ki, ilkin düzgün qurulandan sonra proses təkrar istifadəyə uyğundur. site2.com üçün /var/www/site2.com/public qovluğunu yaradıb, /etc/nginx/sites-available/site2.com faylını yazır, root və log parametrlərini dəyişdirib, simvolik link yaradıb və Nginx testini keçirirsiniz.

İkinci sayt üçün sadə konfiqurasiya belədir:
server {
listen 80;
server_name site2.com www.site2.com;
root /var/www/site2.com/public;
index index.html;
access_log /var/log/nginx/site2.com.access.log;
error_log /var/log/nginx/site2.com.error.log;
location / {
try_files $uri $uri/ =404;
}
}

Hər sayt üçün ayrı log fayllarının olması real həyatda çox dəyərlidir. Məsələn, bir saytda 404 səhvləri çoxalırsa, digər saytda problem olmaya bilər. Ayrı log strukturu sayəsində səhv mənbəyini saniyələr içində tapmaq mümkündür. Eyni zamanda trafik analizi, bot hücumları, qırıq linklər və performans problemləri sayt səviyyəsində izlənə bilər.

SSL və HTTPS Konfiqurasiyası

2026-cı ilin SEO standartlarına görə HTTPS yalnız təhlükəsizlik üçün deyil, həm də istifadəçi etimadı və texniki keyfiyyət göstəricisi kimi qəbul edilir. Brauzerlər HTTP saytları qeyri-təhlükəsiz kimi işarələyir; ödəniş, üzvlük, forma və idarəetmə panelləri olan layihələrdə SSL mütləqdir. Çoxsaylı sayt idarə edərkən hər domen üçün düzgün sertifikat təyin olunmalıdır. Hostragons üzərindən SSL ehtiyaclarınız üçün SSL sertifikatları səhifəsini nəzərdən keçirə bilərsiniz.

Let’s Encrypt istifadə edirsinizsə, Certbot vasitəsilə hər domen üçün sertifikat almaq mümkündür. Məsələn, certbot --nginx -d site1.com -d www.site1.com əmri Nginx konfiqurasiyasını müəyyən edir və HTTPS bloku avtomatik əlavə edə bilər. Lakin avtomatik düzəlişdən sonra faylı yoxlamaq yaxşı vərdişdir. Yanlış yönləndirmə və ya təkrarlanan server blokları problemləri yarana bilər.

HTTPS quruluşunda adətən 80 portundakı trafik daimi olaraq 443 portuna yönləndirilir. 301 yönləndirmə SEO baxımından qalıcı seçim siqnalı verir. www istifadə edib-etməmək qərarını verin və bütün variasiyaları tək kanonik ünvana yönləndirin. Məsələn, https://www.site1.com yerinə https://site1.com istifadə edəcəksinizsə, həm HTTP, həm də HTTPS www trafikini www olmayan ünvana yönləndirin. Bu, təkrarlanan məzmun riskini azaldır.

PHP və WordPress Saytları Üçün Nginx Server Blokları

Statik HTML saytlarında konfiqurasiya sadədir; amma WordPress, Laravel və ya xüsusi PHP tətbiqlərində PHP-FPM ilə inteqrasiya tələb olunur. Bu halda index.php faylı əlavə olunur və PHP sorğuları müvafiq soketə yönləndirilir. Məsələn, Ubuntu-da PHP 8.3 üçün soket yolu /run/php/php8.3-fpm.sock ola bilər. Versiya serverə görə dəyişir.

PHP əsaslı nümunə konfiqurasiya:
server {
listen 80;
server_name wordpress-sayt.com www.wordpress-sayt.com;
root /var/www/wordpress-sayt.com/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 üçün kalıcı bağlantıların işləməsi məqsədilə try_files $uri $uri/ /index.php?$args strukturu vacibdir. Bundan əlavə, xmlrpc.php girişinə nəzarət, wp-login.php üçün limit qoyma, uploads qovluğunda PHP işlətmənin məhdudlaşdırılması kimi təhlükəsizlik tədbirləri də düşünülməlidir. Eyni VPS-də bir neçə WordPress saytı idarə edirsinizsə, hər sayt üçün ayrı verilənlər bazası, ayrıca istifadəçi və müntəzəm yeniləmə siyasəti tətbiq edin. Daha rahat idarə olunan WordPress hosting axtaranlar üçün WordPress hostinq yaxşı bir alternativdir.

Nginx Server Blokları və Apache VirtualHost Müqayisəsi

Nginx və Apache eyni məqsədə fərqli arxitekturalarla çatır. Hər ikisi bir serverdə bir neçə sayt yayımlaya bilir. Seçim tətbiq ehtiyaclarına, idarəetmə vərdişlərinə və performans gözləntilərinə bağlıdır.

Əgər tətbiqiniz .htaccess qaydalarına çox bağlıdırsa, Apache daha asan görünə bilər. Lakin yüksək trafik, reverse proxy, cache və müasir paylama axınları üçün Nginx bir çox layihədə daha güclü seçimdir. Bəzi infrastrukturlarda Nginx reverse proxy, Apache isə backend server kimi birlikdə istifadə edilə bilər.

Təhlükəsizlik Üçün Ən Yaxşı Təcrübələr

Eyni serverdə bir neçə saytın yerləşdirilməsi maliyyə baxımından sərfəli olsa da, təhlükəsizlik məsuliyyətini artırır. Bir saytdakı zəifliyin digər saytları təsir etməməsi üçün izolyasiya və minimum hüquq prinsipi tətbiq olunmalıdır.

• Hər sayt üçün ayrı verilənlər bazası və ayrıca istifadəçi yaradın.
• Veb kök qovluğunu yalnız public qovluğu ilə məhdudlaşdırın.
• Ehtiyat nüsxə, .env, .git, config və SQL fayllarını vebdən əlçatan olmayan yerdə saxlayın.
• SSL sertifikatlarını müntəzəm yeniləyin və HTTPS yönləndirməsini məcbur edin.
• Serverdə UFW və ya oxşar firewall istifadə edin; yalnız lazım olan portları açın.
• Nginx və əməliyyat sistemi yeniləmələrini daima tətbiq edin.
• Hər sayt üçün ayrıca access_log və error_log saxlayın.
• Admin panellərə IP məhdudiyyəti və əlavə identifikasiya tətbiq edin.
• Fayl icazələrində 777 kimi geniş hüquqlardan çəkinin.

Əlavə olaraq, əsas təhlükəsizlik başlıqları əlavə etmək faydalıdır. X-Frame-Options, X-Content-Type-Options, Referrer-Policy və Content-Security-Policy kimi başlıqlar uyğun layihələrdə tətbiq edilə bilər. Lakin Content-Security-Policy səhv tətbiq olunarsa, skript və stil fayllarını bloklaya bilər; buna görə əvvəlcə test mühitində yoxlanmalıdır. Təhlükəsizlik mövzularında daha çox məlumat üçün veb saytı təhlükəsizliyi məqalələrinə baxa bilərsiniz.

Performans və SEO Üçün Nəzərə Alınmalı Məqamlar

Nginx server blokları yalnız saytları yayımlamaqla kifayətlənmir, həm də performans və SEO keyfiyyətinə təsir edir. Yanlış yönləndirmə zəncirləri, səhv kanonik seçimləri, gzip və brotli sıxılmasının olmaması, böyük log faylları və zəif cache parametrləri saytın sürətini aşağı sala bilər. Google-un səhifə təcrübəsi siqnalları istifadəçi yönümlüdür; sürətli cavab verən, təhlükəsiz və stabil saytlar daha yaxşı nəticə göstərir.

Əvvəlcə hər domen üçün tək kanonik versiyanı seçin. HTTP-dən HTTPS-ə, www-dən www olmayan versiyaya və ya əksinə bir addımla yönləndirmə edin. Məsələn, http://site.com əvvəl http://www.site.com, sonra https://www.site.com, sonra https://site.com kimi zəncir yaratmayın. Bir 301 yönləndirmə ilə birbaşa hədəfə getmək daha düzgündür.

Statik fayllar üçün cache-control başlıqları tətbiq oluna bilər. Şəkillər, CSS və JS faylları müəyyən müddət brauzerdə saxlanıla bilər. Lakin tez-tez dəyişən fayllarda fayl adı versiyalaşdırma və ya query string strategiyası istifadə edilməlidir. gzip sıxılması HTML, CSS, JS və JSON kimi mətn əsaslı fayllarda bant genişliyini azaldır. Yüksək trafik alan saytlarda Nginx microcache, FastCGI cache və ya CDN istifadəsi nəzərdən keçirilə bilər. CDN və qlobal çatdırılma ehtiyacları üçün CDN Nədir məqaləsinə baxmaq faydalıdır.

Log İdarəetməsi və Monitorinq

Çoxsaylı saytların idarəsində logların düzgün idarə olunması problemin həllində əsas açardır. Ayrı log faylları hansı saytda hansı səhvin baş verdiyini dəqiq müəyyən edir. access_log ziyarətçi sorğularını, error_log isə konfiqurasiya, icazə, fayl tapılmama və upstream xətalarını yazır. 502 Bad Gateway xətası adətən PHP-FPM və ya backend xidmət bağlantıları ilə bağlıdır. 403 Forbidden icazə və ya index faylı problemi ola bilər. 404 Not Found isə yanlış root yolu, rewrite və ya DNS-dən sonra yaranan uyğunsuzluq göstəricisidir.

Log fayllarının limitsiz böyüməsinin qarşısını almaq üçün logrotate konfiqurasiyasına diqqət yetirilməlidir. Kiçik layihələrdə gündəlik və ya həftəlik dövr kifayət edir. Yüksək trafik saytlarında mərkəzləşdirilmiş log toplama, metrik izləmə və xəbərdarlıq sistemləri istifadə olunmalıdır. Disk dolması Nginx-in log yazmamasına, verilənlər bazasının dayanmasına və saytların əlçatmaz olmasına səbəb ola bilər. Buna görə disk istifadəsi üçün limitlər müəyyənləşdirmək praktik tədbirdir.

Tez-tez Görülən Səhvlər və Həlləri

Nginx server blokları ilə işləyərkən bəzi səhvlər demək olar ki, bütün layihələrdə rast gəlinir. Bunları bilmək quraşdırma vaxtını ciddi şəkildə azaldır.

• Düzgün domen açılmır: server_name üst-üstə düşmələrini və default server blokunu yoxlayın.
• 403 Forbidden xətası: root qovluğunu, fayl icazələrini və index faylının mövcudluğunu nəzərdən keçirin.
• 404 Not Found xətası: root yolu və try_files qaydasını təftiş edin.
• 502 Bad Gateway xətası: PHP-FPM xidmətinin işlədiyini və soket yolunun düzgün olduğunu yoxlayın.
• SSL sertifikatı səhv sayta aid görünür: 443 portundakı server_name və sertifikat fayllarını təkrar gözdən keçirin.
• Yönləndirmə döngüsü yaranır: HTTP-HTTPS və www yönləndirmə qaydalarını sadələşdirin.
• Nginx reload olmur: sudo nginx -t əmrinin nəticəsində göstərilən sətir nömrəsinə görə sintaksis səhvini düzəldin.

Təcrübəli administratorların istifadə etdiyi sadə yoxlama siyahısı var: DNS düzgün qurulubmu, Nginx konfiqurasiyası aktivdirmi, root qovluq mövcuddurmu, icazələr düzgündürmü, xidmət testi keçibmi, loglar nə deyir? Bu ardıcıllıq panikaya qapılmadan tez həll tapmağa kömək edir.

İstehsal Mühiti Üçün Praktik Yoxlama Siyahısı

Canlıya çıxmazdan əvvəl aşağıdakı yoxlama siyahısı ilə hər saytı təsdiqləyin. Xüsusilə müştəri layihələrində təhvil vaxtı bu maddələri sənədləşdirmək peşəkar standartdır.

• Domenin A və ya AAAA qeydi düzgün IP-yə yönəldilir.
• www və www olmayan versiyalardan biri kanonik olaraq seçilib.
• HTTP trafiki 301 ilə HTTPS-ə yönəldilir.
• SSL sertifikatı etibarlıdır və avtomatik yenilənmə aktivdir.
• Hər sayt üçün ayrı root və log faylları təyin olunub.
• Nginx konfiqurasiyası sudo nginx -t ilə yoxlanılıb.
• Ehtiyat nüsxə planı müəyyən edilib və bərpa testləri aparılıb.
• Fayl icazələri minimum hüquq prinsipinə uyğundur.
• Firewall-da yalnız zəruri portlar açıqdır.
• Xəta logları canlıya çıxandan sonra ən azı 15 dəqiqə izlənilib.

Bu siyahı kiçik görünsə də, real layihələrdə fasilə riskini xeyli azaldır. Xüsusilə SSL yenilənməsi, DNS yoxlanması və log izləmə addımları görünməyən səhvləri vaxtında ortaya çıxarır.

Nəticə

Nginx server blokları tək bir serverdə bir neçə saytı nizamlı, təhlükəsiz və yüksək performansla idarə etməyin əsas yollarından biridir. Düzgün qovluq strukturu, ayrı konfiqurasiya faylları, aydın yönləndirmə qaydaları, HTTPS istifadəsi, logların ayrılması və müntəzəm testlərlə çoxsaylı sayt idarəsi çox effektiv olur. Kiçik portfel saytlarından tutmuş bir neçə müştəri layihəsinə qədər eyni prinsiplər tətbiq edilə bilər.

Yeni layihə yayımlayacaqsınızsa, əvvəl domen, server resursları və SSL ehtiyaclarınızı dəqiqləşdirin; sonra yuxarıdakı yoxlama siyahısı ilə Nginx konfiqurasiyanızı addım-addım qurun. Daha idarəolunan infrastruktur axtarırsınızsa, Hostragons-un Hosting paketləri, VPS server və SSL sertifikatları həllərinə baxaraq layihəniz üçün uyğun başlanğıc nöqtəsi seçə bilərsiniz.

Tez-tez Verilən Suallar

Nginx server blokları ilə neçə sayt idarə etmək olar?

Texniki baxımdan Nginx ilə eyni serverdə çoxsaylı sayt idarə etmək mümkündür; limitlər CPU, RAM, disk, trafik, verilənlər bazası yüklənməsi və PHP-FPM tutumuna bağlıdır. Aşağı trafikli statik saytlar üçün onlarca sayt ola bilər, yüksək trafikli WordPress və ya e-ticarət layihələrində isə daha az sayt idarə etmək məsləhətdir.

Hər sayt üçün ayrı SSL sertifikatı tələb olunur?

Bəli, hər domen və ya subdomen HTTPS üzərindən yayımlanacaqsa, sertifikat onun əhatə dairəsində olmalıdır. Fərdi sertifikatlar istifadə edilə biləcəyi kimi SAN və ya wildcard sertifikatlar da seçilə bilər. Əsas məsələ Nginx-in 443 server blokunda düzgün sertifikat fayllarının doğru domenə bağlanmasıdır.

Nginx server bloku ilə subdomen yayımlamaq mümkündürmü?

Bəli. blog.site.com və ya panel.site.com kimi alt domenlər üçün ayrıca server_name təyin edib fərqli root qovluğuna və ya fərqli backend tətbiqinə yönləndirmək olar. DNS tərəfində həmin subdomen üçün A və ya CNAME qeydi yaradılmalıdır.

sites-available və sites-enabled arasında fərq nədir?

sites-available istifadə edilə bilən konfiqurasiya fayllarının saxlandığı yerdir; sites-enabled isə aktiv konfiqurasiyaları ehtiva edir. Adətən sites-enabled içində sites-available faylına simvolik link yaradılır. Bu üsul saytları aktivləşdirmək və deaktiv etmək prosesini daha nizami edir.

Yanlış sayt açılırsa səbəb nə ola bilər?

Ən çox rast gəlinən səbəblər DNS-nin yanlış IP-yə yönləndirilməsi, server_name dəyərinin səhv olması, default Nginx blokunun sorğunu tutması və ya 443 portunda yanlış SSL blokunun işləməsidir. Əvvəlcə DNS qeydlərini, sonra nginx -t komandasının nəticəsini, aktiv sites-enabled linklərini və müvafiq access_log faylını yoxlayın.