Nginx Server Block (Virtual Host) Kanggo Nampung Luwih Saka Siji Situs

Blok server Nginx iku sawijining prinsip virtual host sing ngidini sampeyan nerbitake luwih saka siji domain utawa situs web kanthi konfigurasi sing kapisah ing siji instalasi Nginx. Contone, sampeyan bisa nemtokake direktori root, log file, sertifikat SSL, lan setelan PHP sing beda kanggo example.com, blog.example.com, lan situs-kedua.com ing VPS sing padha. Ringkesan solusi iki yaiku nggawe direktori kapisah kanggo saben situs, ngarahake catatan DNS domain menyang alamat IP server, nulis blok server sing kapisah ing /etc/nginx/sites-available, nyambungake menyang direktori sites-enabled, nguji konfigurasi, lan mbukak maneh layanan Nginx.

Ing pandhuan iki, kita bakal ngatasi proses nampung luwih saka siji situs nggunakake blok server Nginx ing cara sing cocog kanggo lingkungan produksi. Tujuane ora mung nggawe struktur sing bisa digunakake, nanging uga nggawe sistem sing bisa dikelola, aman, cepet, bisa dibackup, lan bisa diskalakan. Kita bakal nuduhake langkah-langkah praktis, utamane kanggo agensi, pangembang, pemilik e-commerce, bisnis sing ngelola merek luwih saka siji, lan administrator sistem sing nglakokake luwih saka siji proyek ing server tunggal. Yen sampeyan durung duwe server, sampeyan bisa mriksa kaca server VPS kanggo pilihan sumber daya lan Registrasi Domain kanggo manajemen domain.

Apa Kuwa Blok Server Nginx?

Blok server Nginx iku bagean konfigurasi sing diarani server block ing konfigurasi Nginx, sing nemtokake situs endi sing bakal dituju nalika ana permintaan HTTP utawa HTTPS. Iki mirip karo konsep VirtualHost ing Apache. Nalika pengunjung nulis domain ing browser, DNS ngowahi domain iki dadi alamat IP server. Sawise iku, Nginx mriksa header Host ing permintaan lan mbukak blok server sing cocog karo nilai server_name.

Kanthi cara iki, puluhan situs web sing beda bisa diterbitake ing alamat IP sing padha lan server fisik utawa virtual sing padha. Sampeyan bisa nemtokake direktori root, log akses, log kesalahan, aturan redirect, sertifikat SSL, kebijakan cache, lan aturan keamanan sing kapisah kanggo saben situs. Contone, sampeyan bisa nyimpen situs korporat ing /var/www/korporat/public, blog sampeyan ing /var/www/blog/public, lan lingkungan uji coba ing /var/www/staging/public.

Nginx bisa ngatur kanthi efisien ing struktur iki amarga arsitektur sing fokus ing acara, ngidini manajemen koneksi simultan sing dhuwur kanthi konsumsi sumber daya sing murah. Mula, iki asring dipilih ing lingkungan hosting bersama, VPS, server cloud, lan infrastruktur aplikasi kanthi lalu lintas tinggi. Kanggo nampung luwih saka siji situs kanthi sehat, kabeh rincian kudu direncanakake kanthi bener, saka ijin file nganti pengalihan DNS, instalasi SSL hingga pemisahan log.

Nalika Nginx Server Block Digunakake?

Blok server Nginx digunakake utamane nalika sampeyan butuh ngatur luwih saka siji entitas web ing server tunggal. Iki bisa dadi rong situs korporat cilik, utawa bisa uga puluhan proyek pelanggan, subdomain, utawa layanan mikro. Titik kritis ing kene yaiku saben proyek kudu dipisah sacara logis.

• Yen sampeyan pengin nerbitake luwih saka siji domain ing VPS sing padha.
• Yen sampeyan pengin ngarahake domain www lan domain tanpa www menyang alamat kanonik sing siji.
• Yen sampeyan pengin nyambungake subdomain menyang folder utawa aplikasi sing beda.
• Yen sampeyan pengin nemtokake sertifikat SSL lan kebijakan keamanan sing kapisah kanggo saben situs.
• Yen sampeyan pengin ngawasi proyek pelanggan nganggo file log sing kapisah.
• Yen sampeyan pengin mbukak aplikasi sing beda kaya Laravel, WordPress, HTML statis, lan Node.js ing server sing padha.

Contone, iku bisa teknis kanggo sawijining agensi digital kanggo nerbitake 8 situs korporat kanthi lalu lintas rendah ing siji VPS kanthi RAM 4 GB. Nanging, sampeyan kudu ngitung lalu lintas, panggunaan disk, jumlah proses PHP, beban database, lan frekuensi backup kanggo saben situs. Yen proyek-proyek kasebut nampa lalu lintas sing dhuwur utawa isolasi sumber daya kritis, luwih becik milih VPS sing luwih kuat, server cloud, utawa solusi hosting sing dikelola. Ing titik iki, pilihan Web Hosting lan Hosting Korporat bisa dibandhingake.

Kaperluan Sadurunge Miwiti

Ing pandhuan iki, kita bakal nganggep server Linux adhedhasar Ubuntu utawa Debian. Perintah bisa beda-beda sithik gumantung saka distribusi; nanging logika tetep padha. Sadurunge nindakake operasi ing lingkungan produksi, mesthine kudu nggawe cadangan. Konfigurasi Nginx sing salah bisa nyebabake kabeh situs ora bisa diakses kanggo sementara.

Persiapan Teknikal Sing Diperlukan

• Akun pangguna Linux kanthi hak akses root utawa sudo.
• Layanan Nginx sing wis diinstal lan aktif.
• Minimal siji domain sing wis diarahkan menyang alamat IP server.
• Port 80 lan 443 kudu mbukak ing firewall.
• Struktur direktori sing teratur kanggo file situs.
• Sertifikat sing valid kanggo SSL utawa nggunakake Let’s Encrypt sing gratis.
• Instalasi PHP-FPM kanggo aplikasi berbasis PHP.

Ing sisih DNS, catatan A ngarahake domain utama menyang alamat IPv4, lan catatan AAAA yen ana ngarahake menyang alamat IPv6. Catatan CNAME utawa A bisa digunakake kanggo subdomain kaya www. Penyebaran DNS biasane rampung ing sawetara menit nganti 24 jam. Nalika nggawe instalasi anyar, luwih becik nyiapake catatan DNS dhisik, banjur nerusake menyang konfigurasi blok server Nginx.

Struktur Direktori Sing Disaranake

Salah sawijining kesalahan paling umum ing nampung luwih saka siji situs yaiku nyimpen kabeh file ing siji direktori sing campur. Pendekatan iki bisa katon gampang ing jangka pendek, nanging bakal nyebabake masalah wektu ing proses perawatan, backup, lan debugging. Metode sing luwih apik yaiku nggunakake direktori utama kapisah kanggo saben domain, lan ngatur subdirektori kaya public, logs, backups ing jerone.

Struktur conto bisa direncanakake kaya ing ngisor iki: /var/www/situs1.com/public, /var/www/situs1.com/logs, /var/www/situs2.com/public lan /var/www/situs2.com/logs. Nilai root Nginx kudu langsung nuduhake direktori public. Kanthi cara iki, file aplikasi, file sensitif kaya .env, lan cadangan ora bisa diakses langsung saka web.

Sampeyan bisa nambahake file index.html sing prasaja ing saben folder situs kanggo tes statis. Kanthi nulis jeneng situs ing konten, sampeyan bisa cepet verifikasi blok server sing aktif. Ing lingkungan produksi, kepemilikan folder iki biasane diatur dening pangguna www-data utawa pangguna khusus sing nindakake deployment. Kanggo ijin file, 755 kanggo folder lan 644 kanggo file cukup kanggo akeh skenario statis. Ing aplikasi kaya WordPress sing butuh nulis, area kaya direktori uploads kudu dinilai kanthi terpisah.

Langkah demi Langkah Nggawe Blok Server Nginx

Langkah-langkah ing ngisor iki dijlentrehake kanthi conto domain situs1.com. Sampeyan bisa mbaleni metode sing padha kanggo situs kaping loro, katelu, utawa luwih. Titik kritis yaiku nggunakake server_name, root, lan file log sing unik kanggo saben situs.

1. Gawe Folder Situs

Langkah pertama yaiku nggawe direktori kanggo file web. Conto: sudo mkdir -p /var/www/situs1.com/public. Sawise iku, sampeyan bisa nggawe file /var/www/situs1.com/public/index.html kanggo tes, lan nulis teks sing bisa dibedakake kaya "Iki kaca tes situs1.com".

Kanggo nyetel kepemilikan file kanthi bener, perintah sudo chown -R www-data:www-data /var/www/situs1.com bisa digunakake. Yen sampeyan nindakake proses deployment kanthi pangguna sing beda, atur ijin grup miturut. Ing lingkungan produksi, aja nganti nggunakake ijin 777 sing menehi akses tulis kanggo kabeh. Ijin kasebut bisa nyebabake penyalahgunaan direktori unggahan dening penyerang.

2. Gawe File Blok Server

Praktik umum ing Nginx yaiku nyimpen konfigurasi sing ora aktif ing /etc/nginx/sites-available lan nyambungake menyang /etc/nginx/sites-enabled nganggo tautan simbolis. Conto file: /etc/nginx/sites-available/situs1.com.

Blok server HTTP sederhana bisa ditulis kanthi logika iki: server { listen 80; server_name situs1.com www.situs1.com; root /var/www/situs1.com/public; index index.html index.htm; access_log /var/log/nginx/situs1.com.access.log; error_log /var/log/nginx/situs1.com.error.log; location / { try_files $uri $uri/ =404; } }

Ing konfigurasi iki, listen 80 ngrungokake lalu lintas HTTP, server_name nemtokake domain endi sing kalebu ing blok iki, root nuduhake direktori sing ngemot file web, lan index nemtokake file default. try_files bali 404 yen ora bisa nemokake file utawa folder sing dijaluk. Struktur iki cukup kanggo situs statis.

3. Aktifake Situs

Kanggo ngaktifake konfigurasi, tautan simbolis digawe: sudo ln -s /etc/nginx/sites-available/situs1.com /etc/nginx/sites-enabled/situs1.com. Cara iki luwih sehat tinimbang nyalin file, amarga sampeyan mung kerja ing siji file konfigurasi utama. Yen sampeyan nggawe owah-owahan, file sing disambung uga tetep anyar.

Yen sampeyan ora pengin kaca default Nginx muncul ing ngarepe situs sampeyan, sampeyan bisa mateni konfigurasi default. Kanggo iki, tautan /etc/nginx/sites-enabled/default bisa dicopot. Nanging, priksa manawa blok server sampeyan wis mlaku kanthi bener sadurunge nindakake iki.

4. Uji Konfigurasi lan Muat Ulang Nginx

Setiap owah-owahan kudu dites sintaksis kanthi perintah sudo nginx -t. Yen tes sukses, layanan bisa dimuat ulang tanpa gangguan nganggo perintah sudo systemctl reload nginx. Perintah reload biasane luwih aman tinimbang restart amarga ngatur koneksi sing aktif luwih alus.

Yen tes gagal, pesen kesalahan asring nuduhake jeneng file lan nomer baris. Titik koma sing ilang, kurung kurawal sing salah, jalur direktori sing salah, utawa nilai server_name sing bentrok minangka masalah sing paling umum. Nginx ora kudu dimuat ulang nganti kesalahan diperbaiki.

Nambahake Situs Kapindho lan Katelu

Kecantikan nampung luwih saka siji situs yaiku proses kasebut bisa diulang sawise instalasi sing bener. Sampeyan nggawe direktori /var/www/situs2.com/public, nulis file /etc/nginx/sites-available/situs2.com, ngowahi nilai root lan log dadi situs2.com, nggawe tautan simbolis, lan nindakake tes Nginx.

Struktur sederhana kanggo situs kapindho bisa ditulis kaya iki: server { listen 80; server_name situs2.com www.situs2.com; root /var/www/situs2.com/public; index index.html; access_log /var/log/nginx/situs2.com.access.log; error_log /var/log/nginx/situs2.com.error.log; location / { try_files $uri $uri/ =404; } }

Nggawe log sing kapisah kanggo saben situs iku penting ing urip nyata. Contone, nalika kesalahan 404 saya akeh ing siji situs, bisa uga ora ana masalah ing situs liyane. Struktur log sing kapisah ngidini sampeyan nemokake sumber kesalahan ing detik. Cara sing padha, analisis lalu lintas, serangan bot, tautan sing rusak, lan masalah kinerja bisa dipantau saben situs.

Konfigurasi SSL lan HTTPS

Ing standar SEO 2026, HTTPS saiki ora mung minangka fitur keamanan, nanging uga minangka indikator kepercayaan pengguna lan kualitas teknis. Browser nandhani situs HTTP minangka ora aman; SSL dibutuhake ing proyek sing ngemot pembayaran, pendaftaran, formulir, utawa panel manajemen. Nalika nampung luwih saka siji situs, sertifikat sing bener kudu ditetepake kanggo saben domain. Sampeyan bisa mriksa kaca sertifikat SSL kanggo kabutuhan SSL sampeyan liwat Hostragons.

Yen sampeyan nggunakake Let’s Encrypt, sampeyan bisa entuk sertifikat kanggo saben domain kanthi Certbot. Proses contone: certbot --nginx -d situs1.com -d www.situs1.com bakal ngenali konfigurasi Nginx lan bisa nambah blok HTTPS kanthi otomatis. Nanging, apik kanggo mriksa file sawise pangaturan otomatis. Bisa ana masalah pengalihan sing salah utawa blok server sing duplikat.

Ing konfigurasi HTTPS, lalu lintas ing port 80 biasane dialihkan kanthi permanen menyang port 443. Pengalihan 301 menehi sinyal pilihan permanen ing SEO. Putusake apa sampeyan bakal nggunakake www utawa ora, lan ngumpulake kabeh variasi menyang alamat kanonik sing siji. Contone, yen sampeyan bakal nggunakake https://site1.com tinimbang https://www.site1.com, arahake lalu lintas www HTTP lan HTTPS menyang alamat tanpa www. Iki ngurangi risiko konten duplikat.

Blok Server Nginx kanggo Situs PHP lan WordPress

Ing situs HTML statis, konfigurasi iku prasaja; nanging ing WordPress, Laravel, utawa aplikasi PHP khusus, integrasi karo PHP-FPM dibutuhake. Ing kasus iki, file index.php kudu ditetepake lan permintaan PHP kudu dialihkan menyang soket sing relevan. Contone, ing Ubuntu, jalur soket kanggo PHP 8.3 bisa dadi /run/php/php8.3-fpm.sock. Versi bisa beda-beda miturut server.

Logika conto berbasis PHP: 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; } }

Struktur try_files $uri $uri/ /index.php?$args penting kanggo operasi permalink WordPress. Kajaba iku, akses menyang xmlrpc.php, pembatasan tarif kanggo wp-login.php, lan pencegahan eksekusi PHP ing direktori uploads kudu dipikirake minangka langkah keamanan. Yen sampeyan nampung akeh situs WordPress ing VPS sing padha, gunakake database sing kapisah, pangguna kapisah, lan kebijakan pembaruan sing teratur kanggo saben situs. Kanggo sing golek alternatif hosting WordPress, Hosting WordPress bisa dadi pilihan sing luwih dikelola.

Perbandingan Blok Server Nginx lan Apache VirtualHost

Nginx lan Apache nggayuh tujuan sing padha kanthi arsitektur sing beda. Keduanya bisa nampung luwih saka siji situs ing server sing padha. Pilihan kasebut gumantung marang kabutuhan aplikasi, kebiasaan manajemen, lan ekspektasi kinerja.

Yen aplikasi sampeyan akeh gumantung marang aturan .htaccess, Apache bisa luwih gampang. Nanging kanggo lalu lintas dhuwur, proxy terbalik, cache, lan aliran distribusi modern, Nginx dadi pilihan sing kuat ing akeh proyek. Ing sawetara infrastruktur, Nginx bisa digunakake minangka proxy terbalik, dene Apache minangka server aplikasi backend.

Praktik Terbaik kanggo Keamanan

Nampung luwih saka siji situs ing server sing padha menehi keuntungan biaya; nanging uga nambah tanggung jawab keamanan. Prinsip isolasi lan hak akses minimal kudu diterapkan supaya kerentanan ing siji situs ora mengaruhi situs liyane.

• Gawe database lan pangguna database sing kapisah kanggo saben situs.
• Batasi root web directory mung kanggo folder public.
• Jaga file backup, .env, .git, file config, lan SQL supaya ora diakses web.
• Rutin nganyari sertifikat SSL lan mewajibkan pengalihan HTTPS.
• Gunakake firewall kaya UFW ing server; mbukak mung port sing perlu.
• Rutin ngaplikasikake pembaruan Nginx lan sistem operasi.
• Jaga file access_log lan error_log sing kapisah kanggo saben situs.
• Tambahake pembatasan IP utawa otentikasi tambahan ing panel manajemen.
• Ngindhari ijin sing luas kaya 777 ing file.

Uga migunani kanggo nambahake header keamanan dasar. Header kaya X-Frame-Options, X-Content-Type-Options, Referrer-Policy, lan Content-Security-Policy bisa dipertimbangkan ing proyek sing cocog. Nanging, utamane Content-Security-Policy bisa nyegah file skrip lan gaya yen diterapkan kanthi salah; mula, kudu diuji ing lingkungan tes dhisik. Kanggo informasi luwih lanjut babagan keamanan, sampeyan bisa nyambungake menyang artikel Keamanan Situs Web.

Perhatian Kanggo Kinerja lan SEO

Blok server Nginx ora mung mengaruhi penerbitan, nanging uga kualitas kinerja lan SEO. Rantai pengalihan sing salah, pilihan kanonik sing salah, gzip utawa brotli kompresi sing ilang, file log sing gedhe, lan pengaturan cache sing kurang bisa nyuda kecepatan situs. Sinyal pengalaman kaca Google fokus ing pengguna; situs sing responsif, aman, lan stabil cenderung duwe kinerja sing luwih apik.

Kaping pisanan, tetapkan siji versi kanonik kanggo saben domain. Arahake saka HTTP menyang HTTPS, saka www menyang non-www, utawa sebaliknya, ing siji langkah. Rantai iki ora kudu kaya ngene: http://site.com menyang http://www.site.com, banjur https://www.site.com, banjur https://site.com. Nanging, luwih becik kanggo langsung menyang target nganggo siji 301.

Header cache-control bisa digunakake kanggo file statis. Gambar, CSS, lan file JS bisa disimpen ing browser kanggo wektu tartamtu. Nanging, kanggo file sing asring diganti, strategi versi utawa query string kudu digunakake. Kompresi gzip ngurangi bandwidth kanggo file berbasis teks kaya HTML, CSS, JS, lan JSON. Kanggo situs sing nampa lalu lintas dhuwur, nggunakake microcache Nginx, FastCGI cache, utawa CDN bisa dipertimbangkan. Sampeyan bisa nyambungake kanggo kebutuhan akses global lan CDN menyang konten kaya Apa iku CDN.

Manajemen Log lan Pemantauan

Manajemen log minangka kunci kanggo ngrampungake masalah nalika nampung luwih saka siji situs. File log sing kapisah nuduhake kanthi cetha kesalahan sing kedadeyan ing situs endi. access_log nyathet permintaan pengunjung, dene error_log nyathet konfigurasi, ijin, file ora ketemu, lan kesalahan upstream. Kesalahan 502 Bad Gateway biasane ana hubungane karo sambungan PHP-FPM utawa layanan backend. Kesalahan 403 Forbidden bisa dadi masalah ijin utawa file index. Kesalahan 404 Not Found nuduhake masalah jalur file, penulisan ulang, utawa kesalahan root sawise DNS.

Kanggo nyegah file log saka ngembang tanpa wates, konfigurasi logrotate kudu dipriksa. Kanggo proyek cilik, rotasi saben dina utawa saben minggu bisa cukup. Ing situs kanthi lalu lintas tinggi, manajemen log pusat, pemantauan metrik, lan sistem peringatan kudu digunakake. Disk sing kebak bisa nyebabake Nginx ora bisa nulis log, database mandheg, lan situs ora bisa diakses. Mula, nemtokake ambang batas kanggo panggunaan disk minangka langkah praktis.

Kesalahan Umum lan Solusi Cepat

Ana sawetara kesalahan sing bisa muncul nalika nggunakake blok server Nginx sing bisa ditemoni ing hampir saben proyek. Ngerti iki bisa banget nyepetake wektu instalasi.

• Domain mbukak situs sing salah: Priksa konflik server_name lan blok server default.
• Kesalahan 403 Forbidden: Priksa direktori root, ijin file, lan keberadaan file index.
• Kesalahan 404 Not Found: Priksa jalur root lan aturan try_files.
• Kesalahan 502 Bad Gateway: Priksa manawa layanan PHP-FPM aktif lan jalur soket bener.
• Sertifikat SSL katon salah situs: Priksa server_name ing port 443 lan file sertifikat.
• Terjadi loop pengalihan: Sederhanakan aturan pengalihan HTTP-HTTPS lan www.
• Nginx ora bisa di-reload: Betulkan kesalahan sintaksis miturut nomer baris ing output sudo nginx -t.

Administrator sing wis pengalaman duwe dhaptar kontrol sing prasaja: Apa DNS bener, apa konfigurasi Nginx aktif, apa folder root ana, apa ijin bener, apa layanan wis lulus tes, apa log ngomong? Maju kanthi urutan iki bakal ngidini sampeyan ngasilake solusi cepet tanpa panik.

Dhaptar Kontrol Praktis Kanggo Lingkungan Produksi

Sadurunge go-live, verifikasi saben situs nganggo dhaptar kontrol ing ngisor iki. Utamane ing proyek pelanggan, nyathet item-item iki sadurunge pangiriman nggawe standar kerja profesional.

• Domain A utawa AAAA ngarahake alamat IP sing bener.
• Salah siji versi www utawa non-www wis dipilih minangka kanonik.
• Lalu lintas HTTP diarahkan menyang HTTPS nganggo 301.
• Sertifikat SSL valid lan pembaruan otomatis aktif.
• Root lan file log sing kapisah wis ditemtokake kanggo saben situs.
• Konfigurasi Nginx wis diverifikasi nganggo sudo nginx -t.
• Rencana backup wis ditemtokake lan uji coba pemulihan wis ditindakake.
• Ijin file cocog karo prinsip hak akses minimal.
• Ing firewall, mung port sing perlu sing mbukak.
• Log kesalahan dipantau setidaknya 15 menit sawise go-live.

Dhaptar iki bisa katon cilik, nanging ing proyek nyata bisa nyuda risiko gangguan kanthi signifikan. Utamane, langkah-langkah pembaruan SSL, pemeriksaan DNS, lan pemantauan log bisa cepet ngenali kesalahan sing ora katon.

Kesimpulan

Blok server Nginx iku salah siji cara dhasar kanggo nampung luwih saka siji situs kanthi teratur, aman, lan kinerja sing apik ing siji server. Struktur direktori sing bener, file konfigurasi sing kapisah, aturan pengalihan sing jelas, nggunakake HTTPS, pemisahan log, lan proses tes sing rutin nggawe manajemen situs luwih efisien. Prinsip sing padha bisa diterapake saka situs portofolio cilik nganti proyek pelanggan sing akeh.

Yen sampeyan arep nerbitake proyek anyar, dhisik netepake domain, sumber server, lan kabutuhan SSL; banjur ngatur konfigurasi Nginx langkah demi langkah nggunakake dhaptar kontrol ing ndhuwur. Yen sampeyan nggoleki infrastruktur sing luwih dikelola, sampeyan bisa mriksa Paket Hosting, server VPS, lan sertifikat SSL saka Hostragons kanggo milih titik awal sing cocog kanggo proyek sampeyan.

Pertanyaan Sing Sering Ditakoni

Pira situs sing bisa ditampung nganggo blok server Nginx?

Secara teknis, sampeyan bisa nampung akeh situs ing server sing padha nggunakake Nginx; watesan biasane gumantung marang CPU, RAM, disk, lalu lintas, beban database, lan kapasitas PHP-FPM. Ing situs statis kanthi lalu lintas rendah, sampeyan bisa nampung puluhan situs, nanging kanggo proyek WordPress utawa e-commerce sing sibuk, luwih apik kanggo nampung situs sing luwih sithik.

Apa saben situs butuh sertifikat SSL kapisah?

Ya, saben domain utawa subdomain sing diterbitake liwat HTTPS kudu kalebu ing lingkup sertifikat. Sertifikat tunggal bisa digunakake, utawa sertifikat SAN utawa wildcard bisa dipilih. Sing penting, file sertifikat sing bener kudu dipasangake karo domain sing tepat ing blok server Nginx 443.

Bisakah subdomain diterbitake nganggo blok server Nginx?

Ya. Sampeyan bisa nemtokake server_name kapisah kanggo subdomain kaya blog.site.com utawa panel.site.com lan ngarahake menyang direktori root sing beda utawa aplikasi backend sing beda. Sampeyan kudu nggawe catatan A utawa CNAME kanggo subdomain kasebut ing sisi DNS.

Apa bedane sites-available lan sites-enabled?

sites-available yaiku panggonan kanggo nyimpen file konfigurasi sing bisa digunakake; sites-enabled ngemot konfigurasi sing aktif. Biasane, tautan simbolis digawe ing sites-enabled kanggo file ing sites-available. Cara iki nggawe ngaktifake lan mateni situs luwih teratur.

Yen situs salah mbukak, saka endi masalah kasebut asal?

Sebagian besar sebab umum yaiku DNS ngarahake menyang IP sing salah, nilai server_name sing salah, blok server default Nginx sing nyekel permintaan, utawa blok SSL sing salah ing port 443. Priksa dhisik catatan DNS, banjur output nginx -t, tautan sites-enabled sing aktif, lan file access_log sing relevan.