Cara Menyimpan Banyak Website Dengan Nginx Server Block (Virtual Host) di Satu VPS

Blok pelayan (server block) Nginx ialah kaedah mengurus pelbagai domain atau laman web dalam satu pemasangan Nginx, setiap satunya dengan tetapan tersendiri. Contohnya, anda boleh host example.com, blog.example.com dan website-dua.com pada VPS yang sama dengan folder root, log, SSL serta konfigurasi PHP berasingan. Secara ringkas: buat folder untuk setiap laman, tetapkan DNS domain ke IP server, tulis fail server block di /etc/nginx/sites-available, sambungkan ke sites-enabled, uji konfigurasi dan reload servis Nginx.

Panduan ini membahas cara mengatur hosting multi-website menggunakan Nginx server block secara profesional—bukan sekadar “boleh jalan”, tapi juga mudah diurus, selamat, laju, boleh backup dan scalable. Kami akan kongsikan langkah-langkah praktikal untuk agensi, pembangun web, pemilik e-dagang, syarikat multi-brand dan sysadmin yang mengurus banyak projek dalam satu server. Jika anda belum ada server, boleh rujuk Pelayan VPS untuk pemilihan sumber dan Pendaftaran Domain untuk pengurusan domain.

Apa Itu Nginx Server Block?

Nginx server block merupakan bahagian konfigurasi server yang menentukan ke website mana permintaan HTTP atau HTTPS harus dihantar. Konsepnya mirip VirtualHost di Apache. Bila pelawat menaip domain di browser, DNS akan resolve ke IP server. Kemudian, Nginx membaca Host header dan memilih server block dengan server_name yang sepadan.

Dengan kaedah ini, anda boleh host puluhan laman web pada satu IP dan satu server fizikal atau VPS. Setiap website boleh ada root folder, log akses, log error, rules redirect, SSL, caching dan sekuriti tersendiri. Contohnya, website korporat di /var/www/korporat/public, blog di /var/www/blog/public, staging di /var/www/staging/public.

Nginx sangat efisien untuk model multi-site kerana architecture event-driven membolehkan sambungan serentak diurus dengan penggunaan resource yang rendah. Sebab itu ia pilihan utama untuk hosting shared, VPS, server cloud dan aplikasi bertrafik tinggi. Tetapi, untuk operasi yang lancar, pastikan semua aspek—izin fail, DNS, SSL, log, dan lain-lain—dirancang dengan teliti.

Bila Perlu Guna Nginx Server Block?

Nginx server block digunakan bila anda perlu host lebih dari satu website dalam satu server. Kadang-kadang dua website korporat, kadang-kadang banyak projek pelanggan, subdomain atau microservice. Yang penting, setiap projek dipisahkan secara logik.

• Jika anda mahu host pelbagai domain di VPS yang sama.
• Jika anda mahu redirect domain www dan non-www ke satu versi canonical.
• Jika subdomain perlu ke folder/aplikasi berbeza.
• Jika SSL dan sekuriti perlu unik bagi setiap website.
• Jika projek pelanggan perlu log berasingan.
• Jika anda mahu jalankan pelbagai aplikasi—Laravel, WordPress, HTML statik, Node.js—di satu server.

Contohnya, agensi digital boleh host 8 website korporat trafik rendah pada satu VPS RAM 4GB. Tapi, perlu kira trafik, penggunaan disk, proses PHP, beban database dan kekerapan backup untuk setiap site. Untuk projek bertrafik tinggi atau perlu isolation, gunakan VPS lebih kuat, server cloud atau hosting managed. Bandingkan pilihan di Penyimpanan Web dan Hosting Korporat.

Keperluan Sebelum Bermula

Panduan ini mengandaikan anda menggunakan server Linux Ubuntu/Debian. Arahan mungkin sedikit berbeza mengikut distro, tapi prinsipnya sama. Pastikan backup sebelum buat perubahan—konfigurasi Nginx yang salah boleh menyebabkan semua site tidak dapat diakses sementara.

Persediaan teknikal

• Akaun Linux dengan akses root/sudo.
• Nginx telah dipasang dan running.
• Sekurang-kurangnya satu domain telah di-point ke IP server.
• Port 80 dan 443 dibuka dalam firewall.
• Struktur folder yang teratur untuk fail website.
• SSL yang sah atau guna Let’s Encrypt percuma.
• Untuk aplikasi PHP, PHP-FPM mesti dipasang.

Pada DNS, rekod A domain utama ke IPv4, AAAA ke IPv6 jika ada. Untuk subdomain seperti www, gunakan rekod CNAME atau A. Propagasi DNS biasanya 5 minit hingga 24 jam. Rancang dahulu rekod DNS sebelum setup Nginx untuk proses yang lancar.

Struktur Folder Yang Disarankan

Kesilapan biasa: semua fail website dicampur dalam satu folder. Ini menyusahkan maintenance, backup dan troubleshooting. Kaedah lebih baik—setiap domain ada folder utama sendiri, dengan subfolder public, logs, backups dan sebagainya.

Contoh: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public, /var/www/site2.com/logs. root Nginx hendaklah menunjuk ke public folder. Fail aplikasi, .env, backup tidak boleh diakses terus dari web.

Untuk test, letakkan index.html ringkas dalam setiap public folder. Tulis nama site di dalamnya untuk mudah kenal pasti blok server yang mana sedang berjalan. Dalam production, biasanya folder dimiliki oleh user www-data atau user deployment khusus. Permission 755 untuk folder dan 644 untuk fail sudah cukup untuk scenario statik. Untuk aplikasi seperti WordPress, folder upload perlu permission tulis khas.

Langkah Demi Langkah Setup Nginx Server Block

Langkah berikut menggunakan site1.com sebagai contoh. Ulang cara yang sama untuk site kedua, ketiga dan seterusnya. Penting: setiap site mesti ada server_name, root dan log tersendiri.

1. Buat folder laman web

Mula-mula, buat folder untuk fail web. Contoh: sudo mkdir -p /var/www/site1.com/public. Untuk test, buat /var/www/site1.com/public/index.html dengan kandungan “Ini laman ujian site1.com” atau yang mudah dikenali.

Set permission dengan sudo chown -R www-data:www-data /var/www/site1.com. Jika deployment guna user lain, adjust group permissions. Elakkan permission 777—ia boleh dimanipulasi oleh hacker pada folder upload.

2. Buat fail server block

Praktis terbaik: simpan konfigurasi yang tidak aktif dalam /etc/nginx/sites-available, dan sambungkan yang aktif ke /etc/nginx/sites-enabled dengan symbolic link. Contoh fail: /etc/nginx/sites-available/site1.com.

Contoh konfigurasi HTTP:

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;
    }
}

listen 80 untuk trafik HTTP, server_name domain, root lokasi fail web, index fail utama. try_files memastikan hanya fail/dir yang wujud boleh diakses. Untuk site statik, ini sudah memadai.

3. Aktifkan laman

Untuk aktifkan konfigurasi: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Symbolic link lebih baik dari copy kerana mudah urus perubahan.

Jika mahu elak homepage Nginx default override site anda, buang link default dari sites-enabled. Pastikan server block anda sudah berfungsi sebelum disable default.

4. Uji dan reload Nginx

Setiap kali ubah konfigurasi, uji syntax dengan sudo nginx -t. Jika lulus, reload Nginx tanpa ganggu sambungan aktif: sudo systemctl reload nginx. Reload lebih selamat dari restart kerana ia tidak memutuskan sambungan aktif.

Jika test gagal, error akan tunjuk nama fail dan baris. Masalah biasa: kurang titik koma, bracket salah, path fail salah, server_name bertindih. Jangan reload Nginx jika error belum diperbetulkan.

Tambah Website Kedua dan Ketiga

Kelebihan multi-site, selepas setup pertama betul, anda cuma ulang proses untuk site lain. Contoh: buat /var/www/site2.com/public, tulis /etc/nginx/sites-available/site2.com dengan root dan log yang sesuai, buat symbolic link dan uji Nginx.

Contoh server block untuk site kedua:

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;
    }
}

Log berasingan sangat bernilai—contohnya, jika satu site banyak error 404, tapi yang lain tiada masalah. Dengan log berasingan, troubleshooting jadi pantas. Trafik, serangan bot, link rosak dan masalah prestasi boleh dipantau setiap site.

Konfigurasi SSL dan HTTPS

Standard SEO 2026: HTTPS bukan sekadar sekuriti, tapi signal kepercayaan dan kualiti teknikal. Browser akan tanda HTTP sebagai “Tidak Selamat”, dan SSL wajib untuk laman payment, login, borang atau admin panel. Setiap domain mesti ada SSL sendiri. Untuk keperluan SSL, rujuk Sijil SSL.

Jika anda gunakan Let’s Encrypt, Certbot boleh generate SSL untuk setiap domain: certbot --nginx -d site1.com -d www.site1.com akan auto tambah HTTPS block. Selepas auto-edit, semak fail server block untuk pastikan tiada duplicate atau redirect yang salah.

Biasanya, trafik di port 80 akan redirect ke port 443 secara kekal (301). Pilih versi canonical—www atau non-www—dan pastikan semua trafik ke satu versi sahaja. Contoh: jika mahu https://site1.com sebagai canonical, redirect semua www ke non-www. Ini elak isu duplicate content.

Nginx Server Block untuk PHP dan WordPress

Untuk website statik, konfigurasi mudah. Tapi untuk WordPress, Laravel atau aplikasi PHP custom, perlu integrasi PHP-FPM. Fail index.php mesti ditetapkan dan request PHP dihantar ke socket PHP yang betul. Contoh, untuk PHP 8.3 di Ubuntu: /run/php/php8.3-fpm.sock (versi bergantung pada server).

server {
    listen 80;
    server_name wordpress-site.com www.wordpress-site.com;
    root /var/www/wordpress-site.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;
    }
}

Untuk WordPress, try_files $uri $uri/ /index.php?$args penting untuk permalink. Tambah juga sekuriti—block xmlrpc.php, limit wp-login.php, disable PHP di uploads folder. Untuk multi-site WordPress di satu VPS, buat database dan user berasingan, dan pastikan update secara berkala. Untuk hosting WordPress lebih mudah, lihat Hosting WordPress.

Perbandingan Nginx Server Block vs Apache VirtualHost

Nginx dan Apache boleh host banyak website di satu server, tapi architecture berbeza. Pilihan bergantung pada aplikasi, tabiat admin dan prestasi yang dikehendaki.

Jika aplikasi banyak guna .htaccess, Apache lebih mudah. Untuk trafik tinggi, reverse proxy, caching dan deployment moden, Nginx sangat digalakkan. Kadang-kadang, Nginx sebagai reverse proxy, Apache sebagai backend server, pun boleh digunakan.

Amalan Terbaik Untuk Sekuriti

Hosting multi-site jimat kos, tapi tingkat risiko sekuriti. Pastikan isolation dan minimum privilege untuk elak satu site rosak menjejaskan yang lain.

• Setiap site guna database serta user yang berasingan.
• Root web hanya untuk folder public.
• Backup, .env, .git, config, fail SQL tidak boleh diakses web.
• SSL mesti sentiasa diperbaharui; redirect ke HTTPS wajib.
• Gunakan firewall (UFW atau lain); buka port yang perlu sahaja.
• Kemas kini Nginx dan OS secara berkala.
• Log akses dan error berasingan untuk setiap site.
• Admin panel mesti ada sekatan IP atau auth tambahan.
• Elakkan permission 777.

Tambah header sekuriti seperti X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy. Content-Security-Policy mesti diuji di staging dahulu—salah konfigurasi boleh block script atau style. Untuk artikel sekuriti, lihat Keselamatan Laman Web.

Tip Prestasi & SEO

Nginx server block bukan hanya untuk hosting, tapi juga beri impak pada prestasi dan SEO. Redirect chain yang salah, canonical yang tidak tepat, kurang gzip/brotli, log besar, cache yang tidak optima boleh menjejaskan kelajuan site. Google kini menilai pengalaman pengguna—site yang laju, selamat, stabil akan lebih baik.

Pilih satu versi canonical untuk setiap domain. Redirect HTTP ke HTTPS, www ke non-www (atau sebaliknya) dengan 301, jangan buat redirect berlapis-lapis. Contoh: dari http://site.com terus ke https://site.com—bukan http://site.com ke http://www.site.com ke https://www.site.com ke https://site.com.

Untuk fail statik, tetapkan cache-control header. Gambar, CSS, JS boleh disimpan di browser untuk tempoh tertentu. Untuk fail kerap berubah, guna versioning atau query string. gzip compress HTML, CSS, JS, JSON untuk jimat bandwidth. Untuk trafik tinggi, pertimbangkan microcache, FastCGI cache atau CDN. Untuk CDN dan global access, rujuk Apa itu CDN.

Pengurusan Log dan Pemantauan

Log sangat penting untuk troubleshooting multi-site. Log berasingan tunjuk error untuk setiap website. access_log rekod request pelawat, error_log rekod masalah—config, permission, file not found, upstream error. Error 502 Bad Gateway selalunya berkaitan PHP-FPM atau backend; 403 Forbidden biasanya masalah permission atau tiada index file; 404 Not Found mungkin root path tidak betul atau rule rewrite.

Elak log membesar tanpa kawalan dengan logrotate. Untuk projek kecil, rotate harian atau mingguan cukup. Untuk trafik tinggi, guna central log collecting, monitoring dan alert system. Jika disk penuh, Nginx tidak boleh tulis log, database boleh stop, site jadi tidak boleh akses. Tetapkan threshold untuk disk usage supaya masalah dapat dikesan awal.

Masalah Lazim & Solusi Cepat

Beberapa error sering berlaku bila setup Nginx server block. Dengan tahu punca, anda boleh troubleshoot dengan cepat.

• Domain buka site yang salah: semak server_name bertindih dan default block.
• 403 Forbidden: semak root folder, permission, dan kewujudan index file.
• 404 Not Found: periksa root path dan try_files rule.
• 502 Bad Gateway: pastikan PHP-FPM running dan socket path betul.
• SSL salah: periksa server_name dan fail SSL di port 443.
• Redirect loop: simplify rule untuk HTTP-HTTPS dan www.
• Nginx tidak reload: perbaiki syntax error mengikut output nginx -t.

Checklist pantas yang biasa digunakan admin: DNS betul? Nginx aktif? Root folder wujud? Permission ok? Test nginx -t lepas ubah? Log tunjuk apa? Ikut urutan ini untuk troubleshooting tanpa panik.

Checklist Praktikal Untuk Production

Sebelum go live, gunakan checklist ini untuk setiap website. Untuk projek pelanggan, dokumentasikan item ini untuk standard kerja profesional.

• Domain A/AAAA record menunjuk ke IP yang betul.
• Satu versi canonical dipilih (www atau non-www).
• HTTP redirect ke HTTPS dengan 301.
• SSL sah dan auto-renew aktif.
• Root dan log fail unik untuk setiap site.
• Konfigurasi Nginx lulus nginx -t.
• Backup plan disiapkan dan restore test dibuat.
• Permission fail minimum privilege.
• Firewall hanya buka port penting.
• Error log dipantau sekurang-kurangnya 15 minit selepas live.

Checklist ini mungkin ringkas, tapi sangat mengurangkan risiko outage. SSL renewal, DNS dan log monitoring boleh cegah masalah yang tidak nampak dengan cepat.

Kesimpulan

Nginx server block ialah asas hosting multi-site yang teratur, selamat dan berprestasi. Dengan struktur folder yang betul, konfigurasi per-site, redirect jelas, penggunaan HTTPS, log berasingan dan proses test yang konsisten, pengurusan banyak website jadi mudah dan scalable. Prinsip sama boleh digunakan untuk portfolio kecil atau projek pelanggan besar.

Sebelum publish projek baru, pastikan domain, sumber server dan keperluan SSL jelas, kemudian setup Nginx step-by-step dengan checklist di atas. Jika perlukan platform lebih mudah diurus, tinjau Pakej Hosting, Pelayan VPS dan Sijil SSL dari Hostragons untuk pilihan permulaan yang sesuai.

Soalan Lazim

Berapa banyak website boleh host dengan Nginx server block?

Dari segi teknikal, hampir tiada had—bergantung pada CPU, RAM, disk, trafik, database dan kapasiti PHP-FPM. Untuk website statik trafik rendah, boleh host puluhan. Untuk WordPress atau e-dagang bertrafik tinggi, limitkan bilangan untuk prestasi optimum.

Perlu SSL berasingan untuk setiap website?

Ya, jika setiap domain atau subdomain mahu guna HTTPS, mesti ada SSL tersendiri. Boleh guna single, SAN atau wildcard certificate. Pastikan fail SSL di server block port 443 sesuai dengan domain yang betul.

Bolehkah publish subdomain dengan Nginx server block?

Boleh. Untuk blog.site.com atau panel.site.com, tetapkan server_name berasingan dan root folder atau backend yang berbeza. Pada DNS, buat rekod A atau CNAME untuk subdomain.

Apa beza sites-available dan sites-enabled?

sites-available ialah tempat simpan konfigurasi yang boleh digunakan; sites-enabled ialah konfigurasi aktif. Biasanya, symbolic link dari sites-enabled ke sites-available dibuat. Ini memudahkan urus enable/disable site.

Kenapa domain buka website yang salah?

Sebab utama: DNS ke IP salah, server_name salah, default block Nginx intercept request, atau SSL block port 443 tidak betul. Semak DNS, output nginx -t, symbolic link sites-enabled dan log akses untuk troubleshoot.