Nginx Sunucu Blokları (Virtual Hosts) İle Birden Fazla Site Barındırma

Nginx sunucu blokları, tek bir Nginx kurulumunda birden fazla alan adını veya web sitesini ayrı yapılandırmalarla yayınlamanızı sağlayan sanal host mantığıdır. Örneğin aynı VPS üzerinde example.com, blog.example.com ve ikinci-site.com için farklı kök dizinler, log dosyaları, SSL sertifikaları ve PHP ayarları tanımlayabilirsiniz. Kısaca çözüm; her site için ayrı dizin oluşturmak, alan adının DNS kayıtlarını sunucu IP adresine yönlendirmek, /etc/nginx/sites-available altında ayrı bir sunucu bloğu yazmak, bunu sites-enabled dizinine bağlamak, yapılandırmayı test etmek ve Nginx servisini yeniden yüklemektir.

Bu rehberde Nginx sunucu blokları ile birden fazla site barındırma sürecini üretim ortamına uygun şekilde ele alacağız. Amaç yalnızca çalışır bir yapı kurmak değil; yönetilebilir, güvenli, hızlı, yedeklenebilir ve ölçeklenebilir bir düzen oluşturmaktır. Özellikle ajanslar, geliştiriciler, e-ticaret sahipleri, çoklu marka yöneten işletmeler ve tek sunucuda birden fazla proje çalıştıran sistem yöneticileri için pratik adımlar paylaşacağız. Eğer henüz sunucunuz yoksa kaynak seçimi için VPS Sunucu ve alan adı yönetimi için Domain Tescil sayfalarını inceleyebilirsiniz.

Nginx Sunucu Blokları Nedir?

Nginx sunucu blokları, Nginx yapılandırması içinde server bloğu olarak tanımlanan ve gelen HTTP ya da HTTPS isteğinin hangi siteye yönlendirileceğini belirleyen yapılandırma parçalarıdır. Apache tarafındaki VirtualHost kavramına benzer. Bir ziyaretçi tarayıcıya bir alan adı yazdığında DNS bu alan adını sunucunun IP adresine çözer. Ardından Nginx, istekte gelen Host başlığına bakar ve server_name değeri eşleşen sunucu bloğunu çalıştırır.

Bu sayede aynı IP adresi ve aynı fiziksel ya da sanal sunucu üzerinde onlarca farklı web sitesi yayınlanabilir. Her site için ayrı root dizini, erişim logu, hata logu, yönlendirme kuralı, SSL sertifikası, cache politikası ve güvenlik kuralı belirlemek mümkündür. Örneğin kurumsal sitenizi /var/www/kurumsal/public içinde, blogunuzu /var/www/blog/public içinde, test ortamınızı ise /var/www/staging/public içinde tutabilirsiniz.

Nginx bu yapıda oldukça verimlidir çünkü olay odaklı mimarisi sayesinde yüksek eş zamanlı bağlantıları düşük kaynak tüketimiyle yönetebilir. Bu nedenle paylaşımlı hosting, VPS, bulut sunucu ve yüksek trafikli uygulama altyapılarında sık tercih edilir. Çoklu site barındırmanın sağlıklı çalışması için ise dosya izinlerinden DNS yönlendirmelerine, SSL kurulumundan log ayrımına kadar her detayın doğru planlanması gerekir.

Nginx Sunucu Blokları Ne Zaman Kullanılır?

Nginx sunucu blokları özellikle tek sunucuda birden fazla web varlığını yönetmeniz gerektiğinde kullanılır. Bu bazen iki küçük kurumsal site olabilir, bazen de onlarca müşteri projesi, alt alan adı veya mikro servis olabilir. Buradaki kritik nokta, her projenin birbirinden mantıksal olarak ayrılmasıdır.

• Birden fazla alan adını aynı VPS üzerinde yayınlamak istiyorsanız.
• www ve www olmayan alan adlarını tek bir kanonik adrese yönlendirmek istiyorsanız.
• Alt alan adlarını farklı klasörlere veya uygulamalara bağlamak istiyorsanız.
• Her site için ayrı SSL sertifikası ve güvenlik politikası tanımlamak istiyorsanız.
• Müşteri projelerini ayrı log dosyalarıyla takip etmek istiyorsanız.
• Laravel, WordPress, statik HTML ve Node.js gibi farklı uygulamaları aynı sunucuda çalıştırmak istiyorsanız.

Örneğin bir dijital ajansın tek bir 4 GB RAM VPS üzerinde 8 adet düşük trafikli kurumsal siteyi yayınlaması teknik olarak mümkündür. Ancak her site için trafik, disk kullanımı, PHP işlem sayısı, veritabanı yükü ve yedekleme sıklığı hesaplanmalıdır. Eğer projeler yoğun trafik alıyorsa veya kaynak izolasyonu kritikse daha güçlü VPS, bulut sunucu ya da yönetilebilir hosting çözümleri tercih edilmelidir. Bu noktada Web Hosting ve Kurumsal Hosting seçenekleri karşılaştırılabilir.

Başlamadan Önce Gereksinimler

Bu rehberde Ubuntu veya Debian tabanlı bir Linux sunucu varsayacağız. Komutlar dağıtıma göre küçük farklılıklar gösterebilir; ancak mantık aynıdır. Üretim ortamında işlem yapmadan önce mutlaka yedek alın. Yanlış bir Nginx yapılandırması tüm sitelerin geçici olarak erişilemez olmasına neden olabilir.

Gerekli teknik hazırlıklar

• Root veya sudo yetkisine sahip Linux kullanıcı hesabı.
• Kurulu ve çalışan Nginx servisi.
• Sunucu IP adresine yönlendirilmiş en az bir alan adı.
• 80 ve 443 portlarının güvenlik duvarında açık olması.
• Site dosyaları için düzenli bir dizin yapısı.
• SSL için geçerli bir sertifika veya ücretsiz Let’s Encrypt kullanımı.
• PHP tabanlı uygulamalar için PHP-FPM kurulumu.

DNS tarafında A kaydı ana alan adını IPv4 adresine, AAAA kaydı varsa IPv6 adresine yönlendirir. www gibi alt alan adları için CNAME veya A kaydı kullanılabilir. DNS yayılımı genellikle birkaç dakika ile 24 saat arasında tamamlanır. Yeni kurulum yaparken önce DNS kayıtlarını hazırlamak, ardından Nginx sunucu blokları yapılandırmasına geçmek süreci hızlandırır.

Önerilen Dizin Yapısı

Çoklu site barındırmada en sık yapılan hatalardan biri tüm dosyaları karışık şekilde tek bir dizinde tutmaktır. Bu yaklaşım kısa vadede kolay görünse de bakım, yedekleme ve hata ayıklama süreçlerinde ciddi zaman kaybettirir. Daha iyi bir yöntem, her alan adı için ayrı bir üst dizin ve bunun içinde public, logs, backups gibi alt dizinler kullanmaktır.

Örnek bir yapı şu şekilde planlanabilir: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public ve /var/www/site2.com/logs. Nginx root değeri doğrudan public dizinine işaret etmelidir. Böylece uygulama dosyaları, .env benzeri hassas dosyalar ve yedekler web üzerinden doğrudan erişilebilir olmaz.

Örnek statik test sayfası için her site klasörüne basit bir index.html dosyası koyabilirsiniz. İçeriğinde site adını yazarak hangi sunucu bloğunun çalıştığını hızlıca doğrularsınız. Üretim ortamlarında bu klasörlerin sahipliği genellikle www-data kullanıcısı veya deployment yapan özel kullanıcı ile düzenlenir. Dosya izinlerinde klasörler için 755, dosyalar için 644 çoğu statik senaryoda yeterlidir. WordPress gibi yazma gerektiren uygulamalarda uploads dizini gibi alanlar ayrıca değerlendirilmelidir.

Adım Adım Nginx Sunucu Bloğu Oluşturma

Aşağıdaki adımlar örnek olarak site1.com alan adı üzerinden anlatılmıştır. Aynı yöntemi ikinci, üçüncü veya daha fazla site için tekrarlayabilirsiniz. Kritik nokta her site için benzersiz server_name, root ve log dosyası kullanmaktır.

1. Site klasörünü oluşturun

İlk adım web dosyalarının duracağı dizini oluşturmaktır. Örnek: sudo mkdir -p /var/www/site1.com/public. Ardından test için /var/www/site1.com/public/index.html dosyası oluşturup içine Bu site1.com test sayfasıdır gibi ayırt edilebilir bir metin yazabilirsiniz.

Dosya sahipliğini doğru ayarlamak için sudo chown -R www-data:www-data /var/www/site1.com komutu kullanılabilir. Eğer deployment işlemlerini farklı bir kullanıcıyla yapıyorsanız grup izinlerini buna göre düzenleyin. Üretim ortamında herkesin yazma iznine sahip olduğu 777 izinlerinden kaçının. Bu izinler saldırganların yükleme dizinlerini kötüye kullanmasına neden olabilir.

2. Sunucu bloğu dosyasını oluşturun

Nginx’te yaygın pratik, aktif olmayan yapılandırmaları /etc/nginx/sites-available altında tutmak ve aktif edilecekleri /etc/nginx/sites-enabled içine sembolik bağlantı ile bağlamaktır. Örnek dosya: /etc/nginx/sites-available/site1.com.

Basit bir HTTP sunucu bloğu şu mantıkla 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 yapılandırmada listen 80 HTTP trafiğini dinler, server_name hangi alan adlarının bu bloğa ait olduğunu belirtir, root web dosyalarının bulunduğu dizini gösterir, index varsayılan dosyayı tanımlar. try_files ise istenen dosyayı veya klasörü bulamazsa 404 döndürür. Statik siteler için bu yapı oldukça yeterlidir.

3. Siteyi etkinleştirin

Yapılandırmayı aktif etmek için sembolik bağlantı oluşturulur: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Bu yöntem dosyaları kopyalamaktan daha sağlıklıdır çünkü tek bir ana yapılandırma dosyası üzerinde çalışırsınız. Değişiklik yaptığınızda bağlantılı dosya da güncel kalır.

Eğer varsayılan Nginx sayfasının sitenizin önüne geçmesini istemiyorsanız default yapılandırmasını pasifleştirebilirsiniz. Bunun için /etc/nginx/sites-enabled/default bağlantısı kaldırılabilir. Ancak bunu yapmadan önce kendi sunucu bloğunuzun doğru çalıştığından emin olun.

4. Yapılandırmayı test edin ve Nginx’i yeniden yükleyin

Her değişiklikten sonra sudo nginx -t komutu ile sözdizimi testi yapılmalıdır. Test başarılıysa sudo systemctl reload nginx komutu ile servis kesintisiz biçimde yeniden yüklenir. reload komutu genellikle restart komutuna göre daha güvenlidir çünkü çalışan bağlantıları daha yumuşak yönetir.

Eğer test başarısız olursa hata mesajı çoğunlukla dosya adını ve satır numarasını gösterir. Eksik noktalı virgül, yanlış süslü parantez, hatalı dizin yolu veya çakışan server_name değerleri en yaygın sorunlardır. Hata giderilmeden Nginx yeniden yüklenmemelidir.

İkinci ve Üçüncü Siteyi Eklemek

Birden fazla site barındırmanın güzelliği, ilk doğru kurulumdan sonra sürecin tekrarlanabilir hale gelmesidir. site2.com için /var/www/site2.com/public dizinini oluşturur, /etc/nginx/sites-available/site2.com dosyasını yazar, root ve log değerlerini site2.com olacak şekilde değiştirir, sembolik bağlantı oluşturur ve Nginx testini çalıştırırsınız.

İkinci site için basit yapı şu mantıkla ayrılır: 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; } }

Her site için ayrı log kullanmak gerçek hayatta çok değerlidir. Örneğin bir sitede 404 hataları artarken diğer sitede sorun olmayabilir. Ayrı log yapısı sayesinde hata kaynağını saniyeler içinde bulabilirsiniz. Aynı şekilde trafik analizi, bot saldırıları, kırık bağlantılar ve performans problemleri site bazında izlenebilir.

SSL ve HTTPS Yapılandırması

2026 SEO standartlarında HTTPS artık yalnızca güvenlik özelliği değil, kullanıcı güveni ve teknik kalite göstergesidir. Tarayıcılar HTTP siteleri güvensiz olarak işaretler; ödeme, üyelik, form veya yönetim paneli içeren projelerde SSL zorunludur. Çoklu site barındırırken her alan adı için doğru sertifika tanımlanmalıdır. Hostragons üzerinden SSL ihtiyaçlarınız için SSL Sertifikaları sayfasına göz atabilirsiniz.

Let’s Encrypt kullanıyorsanız Certbot ile her alan adı için sertifika alınabilir. Örnek süreçte certbot --nginx -d site1.com -d www.site1.com komutu Nginx yapılandırmasını algılar ve HTTPS bloğunu otomatik ekleyebilir. Ancak otomatik düzenleme sonrası dosyayı kontrol etmek iyi bir alışkanlıktır. Yanlış yönlendirme veya tekrar eden server bloğu sorunları oluşabilir.

HTTPS yapılandırmasında genellikle 80 portundaki trafik 443 portuna kalıcı olarak yönlendirilir. 301 yönlendirme SEO açısından kalıcı tercih sinyali verir. www kullanıp kullanmayacağınıza karar verin ve tüm varyasyonları tek kanonik adrese toplayın. Örneğin https://www.site1.com yerine https://site1.com kullanacaksanız hem HTTP hem HTTPS www trafiğini www olmayan adrese yönlendirin. Bu, kopya içerik riskini azaltır.

PHP ve WordPress Siteleri İçin Nginx Sunucu Blokları

Statik HTML sitelerinde yapılandırma basittir; ancak WordPress, Laravel veya özel PHP uygulamalarında PHP-FPM ile entegrasyon gerekir. Bu durumda index.php dosyası tanımlanır ve PHP istekleri ilgili sokete yönlendirilir. Örneğin Ubuntu’da PHP 8.3 için soket yolu /run/php/php8.3-fpm.sock olabilir. Sürüm sunucuya göre değişir.

PHP tabanlı örnek mantık: 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; } }

WordPress için kalıcı bağlantıların çalışması adına try_files $uri $uri/ /index.php?$args yapısı önemlidir. Ayrıca xmlrpc.php erişimi, wp-login.php oran sınırlaması, uploads dizininde PHP çalıştırmanın engellenmesi gibi güvenlik önlemleri düşünülmelidir. Çok sayıda WordPress sitesini aynı VPS üzerinde barındırıyorsanız her site için ayrı veritabanı, ayrı kullanıcı ve düzenli güncelleme politikası kullanın. WordPress hosting alternatifi arayanlar için WordPress Hosting daha yönetilebilir bir seçenek olabilir.

Nginx Sunucu Blokları ile Apache VirtualHost Karşılaştırması

Nginx ve Apache aynı hedefe farklı mimarilerle ulaşır. İkisi de tek sunucuda birden fazla site barındırabilir. Seçim, uygulama ihtiyaçlarına, yönetim alışkanlıklarına ve performans beklentilerine bağlıdır.

Eğer uygulamanız .htaccess kurallarına yoğun biçimde bağlıysa Apache daha kolay gelebilir. Ancak yüksek trafik, ters proxy, cache ve modern dağıtım akışları için Nginx çoğu projede güçlü bir tercihtir. Bazı altyapılarda Nginx reverse proxy, Apache ise arka uç uygulama sunucusu olarak birlikte de kullanılabilir.

Güvenlik İçin En İyi Uygulamalar

Birden fazla siteyi aynı sunucuda barındırmak maliyet açısından avantaj sağlar; fakat güvenlik sorumluluğunu artırır. Bir sitedeki zafiyetin diğerlerini etkilememesi için izolasyon ve minimum yetki prensibi uygulanmalıdır.

• Her site için ayrı veritabanı ve ayrı veritabanı kullanıcısı oluşturun.
• Web kök dizinini yalnızca public klasörüyle sınırlandırın.
• Yedek, .env, .git, config ve SQL dosyalarını web erişimi dışında tutun.
• SSL sertifikalarını düzenli yenileyin ve HTTPS yönlendirmesini zorunlu kılın.
• Sunucuda UFW veya benzeri güvenlik duvarı kullanın; yalnızca gerekli portları açın.
• Nginx ve işletim sistemi güncellemelerini düzenli uygulayın.
• Her site için ayrı access_log ve error_log tutun.
• Yönetim panellerine IP kısıtı veya ek kimlik doğrulama ekleyin.
• Dosya izinlerinde 777 gibi geniş izinlerden kaçının.

Ayrıca temel güvenlik başlıkları eklemek faydalıdır. X-Frame-Options, X-Content-Type-Options, Referrer-Policy ve Content-Security-Policy gibi başlıklar uygun projelerde değerlendirilebilir. Ancak özellikle Content-Security-Policy yanlış uygulanırsa script ve stil dosyalarını engelleyebilir; bu nedenle önce test ortamında denenmelidir. Güvenlik hakkında daha fazla içerik için Web Sitesi Güvenliği yazılarına bağlantı verilebilir.

Performans ve SEO İçin Dikkat Edilecekler

Nginx sunucu blokları yalnızca yayınlama değil, performans ve SEO kalitesini de etkiler. Yanlış yönlendirme zincirleri, hatalı canonical tercihleri, eksik gzip veya brotli sıkıştırması, büyük log dosyaları ve yetersiz cache ayarları sitenin hızını düşürebilir. Google’ın sayfa deneyimi sinyalleri kullanıcı odaklıdır; hızlı yanıt veren, güvenli ve istikrarlı siteler daha iyi performans gösterme eğilimindedir.

Öncelikle her alan adı için tek bir kanonik sürüm belirleyin. HTTP’den HTTPS’ye, www’den www olmayana veya tam tersine tek adımda yönlendirme yapın. Zincir şu şekilde olmamalıdır: http://site.com önce http://www.site.com, sonra https://www.site.com, sonra https://site.com. Bunun yerine tek 301 ile hedefe gitmek daha doğrudur.

Statik dosyalar için cache-control başlıkları kullanılabilir. Görseller, CSS ve JS dosyaları belirli süre tarayıcıda saklanabilir. Ancak sık değişen dosyalarda dosya adı versiyonlama veya query string stratejisi kullanılmalıdır. gzip sıkıştırması HTML, CSS, JS ve JSON gibi metin tabanlı dosyalarda bant genişliğini azaltır. Büyük trafik alan sitelerde Nginx microcache, FastCGI cache veya CDN kullanımı değerlendirilebilir. CDN ve global erişim ihtiyaçları için CDN Nedir gibi bir içeriğe bağlantı verilebilir.

Log Yönetimi ve İzleme

Çoklu site barındırmada log yönetimi sorun çözmenin anahtarıdır. Ayrı log dosyaları, hangi sitede hangi hatanın yaşandığını net şekilde gösterir. access_log ziyaretçi isteklerini, error_log ise yapılandırma, izin, dosya bulunamama ve upstream hatalarını kaydeder. 502 Bad Gateway hatası genellikle PHP-FPM veya arka uç servis bağlantısıyla ilgilidir. 403 Forbidden izin veya index dosyası sorunu olabilir. 404 Not Found ise dosya yolu, rewrite veya DNS sonrası yanlış root problemine işaret edebilir.

Log dosyalarının sınırsız büyümesini engellemek için logrotate yapılandırması kontrol edilmelidir. Küçük projelerde günlük veya haftalık rotasyon yeterli olabilir. Trafiği yüksek sitelerde merkezi log toplama, metrik izleme ve uyarı sistemleri kullanılmalıdır. Disk dolması Nginx’in log yazamamasına, veritabanının durmasına ve sitelerin erişilemez olmasına neden olabilir. Bu nedenle disk kullanımı için eşik değerler belirlemek pratik bir önlemdir.

Yaygın Hatalar ve Hızlı Çözümler

Nginx sunucu blokları ile çalışırken bazı hatalar neredeyse her projede karşınıza çıkabilir. Bunları bilmek kurulum süresini ciddi biçimde kısaltır.

• Alan adı yanlış siteyi açıyor: server_name çakışmalarını ve default server bloğunu kontrol edin.
• 403 Forbidden hatası: root dizini, dosya izinleri ve index dosyasının varlığını kontrol edin.
• 404 Not Found hatası: root yolu ve try_files kuralını inceleyin.
• 502 Bad Gateway hatası: PHP-FPM servisinin çalıştığını ve soket yolunun doğru olduğunu doğrulayın.
• SSL sertifikası yanlış siteye ait görünüyor: 443 portundaki server_name ve sertifika dosyalarını kontrol edin.
• Yönlendirme döngüsü oluşuyor: HTTP-HTTPS ve www yönlendirme kurallarını sadeleştirin.
• Nginx reload olmuyor: sudo nginx -t çıktısındaki satır numarasına göre sözdizimi hatasını düzeltin.

Deneyimli yöneticilerin uyguladığı basit bir kontrol listesi vardır: DNS doğru mu, Nginx yapılandırması aktif mi, root klasörü var mı, izinler doğru mu, servis testten geçti mi, log ne söylüyor? Bu sırayla ilerlemek panik yapmadan hızlı çözüm üretmenizi sağlar.

Üretim Ortamı İçin Pratik Kontrol Listesi

Canlıya almadan önce aşağıdaki kontrol listesiyle her siteyi doğrulayın. Özellikle müşteri projelerinde teslim öncesi bu maddeleri belgelemek profesyonel bir çalışma standardı oluşturur.

• Alan adı A veya AAAA kaydı doğru IP adresine yönleniyor.
• www ve www olmayan sürümlerden biri kanonik olarak seçildi.
• HTTP trafiği HTTPS’ye 301 ile yönleniyor.
• SSL sertifikası geçerli ve otomatik yenileme aktif.
• Her site için ayrı root ve log dosyası tanımlandı.
• Nginx yapılandırması sudo nginx -t ile doğrulandı.
• Yedekleme planı belirlendi ve geri yükleme testi yapıldı.
• Dosya izinleri minimum yetki prensibine uygun.
• Güvenlik duvarında yalnızca gerekli portlar açık.
• Hata logları canlıya alma sonrası en az 15 dakika izlendi.

Bu liste küçük görünse de gerçek projelerde kesinti riskini büyük ölçüde azaltır. Özellikle SSL yenileme, DNS kontrolü ve log izleme adımları çoğu görünmez hatayı erkenden yakalar.

Sonuç

Nginx sunucu blokları, tek bir sunucu üzerinde birden fazla siteyi düzenli, güvenli ve performanslı biçimde barındırmanın temel yöntemlerinden biridir. Doğru dizin yapısı, ayrı yapılandırma dosyaları, net yönlendirme kuralları, HTTPS kullanımı, log ayrımı ve düzenli test süreciyle çoklu site yönetimi oldukça verimli hale gelir. Küçük bir portföy sitesinden çoklu müşteri projelerine kadar aynı prensipler uygulanabilir.

Eğer yeni bir proje yayınlayacaksanız önce alan adı, sunucu kaynağı ve SSL ihtiyaçlarınızı netleştirin; ardından yukarıdaki kontrol listesiyle Nginx yapılandırmanızı adım adım kurun. Daha yönetilebilir bir altyapı arıyorsanız Hostragons’un Hosting Paketleri, VPS Sunucu ve SSL Sertifikaları çözümlerini inceleyerek projenize uygun başlangıç noktasını seçebilirsiniz.

Sıkça Sorulan Sorular

Nginx sunucu blokları ile kaç site barındırılabilir?

Teknik olarak Nginx ile aynı sunucuda çok sayıda site barındırabilirsiniz; sınır genellikle CPU, RAM, disk, trafik, veritabanı yükü ve PHP-FPM kapasitesine bağlıdır. Düşük trafikli statik sitelerde onlarca site mümkün olabilirken, yoğun WordPress veya e-ticaret projelerinde daha az site barındırmak daha sağlıklıdır.

Her site için ayrı SSL sertifikası gerekir mi?

Evet, her alan adı veya alt alan adı HTTPS üzerinden yayınlanacaksa sertifika kapsamına dahil edilmelidir. Tek tek sertifikalar kullanılabileceği gibi SAN veya wildcard sertifikalar da tercih edilebilir. Önemli olan Nginx 443 sunucu bloğunda doğru sertifika dosyalarının doğru alan adına bağlanmasıdır.

Nginx sunucu bloğu ile subdomain yayınlanabilir mi?

Evet. blog.site.com veya panel.site.com gibi alt alan adları için ayrı server_name tanımlayabilir ve farklı root dizinine ya da farklı arka uç uygulamasına yönlendirebilirsiniz. DNS tarafında ilgili subdomain için A veya CNAME kaydı oluşturmanız gerekir.

site-available ve sites-enabled farkı nedir?

sites-available kullanılabilir yapılandırma dosyalarının tutulduğu yerdir; sites-enabled ise aktif yapılandırmaları içerir. Genellikle sites-enabled içinde, sites-available dosyasına sembolik bağlantı oluşturulur. Bu yöntem siteleri etkinleştirmeyi ve devre dışı bırakmayı daha düzenli hale getirir.

Yanlış site açılıyorsa sorun nereden kaynaklanır?

En yaygın nedenler DNS’in yanlış IP’ye yönlenmesi, server_name değerinin hatalı olması, default Nginx bloğunun isteği yakalaması veya 443 tarafında yanlış SSL bloğunun çalışmasıdır. Önce DNS kayıtlarını, ardından nginx -t çıktısını, aktif sites-enabled bağlantılarını ve ilgili access_log dosyasını kontrol edin.