Mimari fark: süreç tabanlı ve olay tabanlı yaklaşım
Web sunucularının temel farkı, eş zamanlı bağlantıları nasıl karşıladıklarında yatar. Apache, MPM (Multi-Processing Module) adı verilen modüllerle çalışır. Eski prefork modelinde her bağlantı ayrı bir süreç tarafından karşılanır; bu model basit ve uyumludur ama çok sayıda eş zamanlı bağlantıda belleği hızla tüketir. Daha yeni event modeli iş parçacıklarıyla çalışır ve bekleyen bağlantıları daha verimli yönetir.
Nginx baştan itibaren olay tabanlı tasarlanmıştır. Az sayıda işçi süreci, binlerce bağlantıyı bloklamadan aynı anda yönetir. Bu yüzden özellikle statik dosya sunumunda ve ters vekil (reverse proxy) rolünde düşük bellekle yüksek eş zamanlılık sağlar. LiteSpeed de olay tabanlı bir mimari kullanır ve buna Apache yapılandırmasıyla uyumluluğu ekler.
Pratikte bu farklar küçük bir sitede hissedilmeyebilir. Fark, eş zamanlı ziyaretçi sayısı arttığında, yavaş bağlantılı istemciler çoğaldığında ya da sunucu belleği kısıtlı olduğunda ortaya çıkar.
.htaccess: en çok gözden kaçan fark
Apache, her dizinde bulunabilen .htaccess dosyalarını okur ve bu dosyalardaki yönlendirme, erişim ve önbellek kurallarını uygular. Paylaşımlı hostingte bu özellik çok değerlidir: site sahibi sunucu yapılandırmasına erişmeden kendi kurallarını yazabilir. WordPress gibi pek çok uygulama da kalıcı bağlantı yapısı için .htaccess'e dayanır.
Nginx ise .htaccess dosyalarını hiç okumaz. Tüm kurallar sunucu yapılandırmasındaki server bloklarına yazılır. Bu daha hızlıdır, çünkü her istekte dizinlerde dosya aranmaz; ama Apache'den geçerken mevcut kuralların elle Nginx söz dizimine çevrilmesi gerekir. Çevrilmeyen bir yönlendirme kuralı, sitenin bir bölümünün 404 hatası vermesine ya da daha kötüsü korunması gereken bir klasörün erişime açılmasına yol açabilir.
LiteSpeed'in ticari sürümü Apache yapılandırmasını ve .htaccess dosyalarını büyük ölçüde okuyabilir; bu yüzden Apache'den geçişte genellikle kural çevirisi gerekmez. Açık kaynak OpenLiteSpeed'in .htaccess desteği daha sınırlıdır; hangi yönergeleri desteklediğini ve değişikliklerin ne zaman devreye girdiğini kurmadan önce belgelerinden kontrol edin.
PHP nasıl çalıştırılıyor?
Web sunucusu seçimi, PHP'nin çalıştırılma biçimini de belirler ve performans farkının önemli bir kısmı aslında buradan gelir.
| Web sunucusu | Yaygın PHP modeli | Not |
|---|---|---|
| Apache | PHP-FPM (event MPM ile) veya eski mod_php (prefork ile) | Modern kurulumlarda PHP-FPM tercih edilir. |
| Nginx | PHP-FPM | Nginx PHP'yi kendisi çalıştırmaz, isteği FPM'e iletir. |
| LiteSpeed | LSAPI | LiteSpeed'in kendi PHP arabirimi. |
PHP-FPM ile çalışırken en kritik ayar, havuzdaki en fazla süreç sayısıdır. Bu sayı sunucunun belleğine göre belirlenmezse yoğun anlarda bellek tükenir ve sistem takasa düşer. Bu değerin nasıl hesaplanacağını sunucu kaynak izleme rehberinde anlattık. Ayrıca her site için ayrı bir FPM havuzu ve ayrı bir sistem kullanıcısı tanımlamak, bir sitedeki güvenlik açığının diğer sitelere yayılmasını zorlaştırır.
Önbellek ve performans özellikleri
Üç sunucu da statik dosyaları verimli sunar; fark, dinamik sayfaların önbelleğe alınmasında belirginleşir.
- Nginx: FastCGI önbelleği ile PHP'nin ürettiği sayfaları diskte saklayıp sonraki isteklere doğrudan sunabilir. Oturum açmış kullanıcılar ve sepet gibi kişisel sayfalar için önbelleği atlama kurallarını dikkatle yazmanız gerekir.
- LiteSpeed: sunucu düzeyinde yerleşik bir önbellek motoru vardır ve yaygın içerik yönetim sistemleri için hazır eklentilerle birlikte çalışır. Bu, kurulumu kolaylaştıran önemli bir avantajdır.
- Apache: önbellek modülleri bulunur, ama dinamik sayfa önbelleği genellikle uygulama katmanında ya da önüne konan bir ters vekilde yapılır.
HTTP/2 her üç sunucuda yaygın olarak desteklenir. HTTP/3 desteği ise sunucudan sunucuya ve sürümden sürüme farklılık gösterir; bu özellik sizin için önemliyse kullandığınız sürümün belgelerini kontrol edin.
Karma kurulum: Nginx önde, Apache arkada
Pek çok panel ve sağlayıcı, iki dünyanın avantajını birleştirmek için Nginx'i Apache'nin önüne ters vekil olarak koyar. Bu yapıda Nginx statik dosyaları doğrudan sunar ve bağlantı yönetimini üstlenir; dinamik istekleri ise .htaccess desteği olan Apache'ye iletir. Böylece mevcut uygulamalar değişmeden çalışır, statik dosya sunumu hızlanır.
Bu yapının bir bedeli vardır: iki yazılımı yapılandırmak ve sorun anında hangi katmanın hata verdiğini ayırt etmek gerekir. Ayrıca arkadaki Apache, ziyaretçinin gerçek IP adresini görebilmek için Nginx'in gönderdiği başlıkları okuyacak şekilde ayarlanmalıdır; aksi halde loglarda ve güvenlik araçlarında tüm istekler yerel adresten geliyormuş gibi görünür.
Hangi senaryoda hangisi?
| Senaryo | Mantıklı seçim |
|---|---|
| Paylaşımlı hosting, kullanıcılar .htaccess kullanıyor | Apache veya LiteSpeed |
| Tek uygulama, yapılandırmayı siz yönetiyorsunuz | Nginx ve PHP-FPM |
| Apache uyumluluğu ve yerleşik önbellek isteniyor, lisans bütçesi var | LiteSpeed |
| Mevcut Apache kurulumu var, statik yük ağır | Önde Nginx, arkada Apache |
| Birden çok uygulamayı tek IP'de yayınlamak | Ters vekil olarak Nginx |
Kullandığınız panel de seçimi daraltır: her panel her web sunucusunu aynı ölçüde desteklemez. Panel tarafındaki farkları cPanel, Plesk ve DirectAdmin karşılaştırması rehberinde bulabilirsiniz.
Örnek geçiş: Apache'den Nginx'e
Bir WordPress sitesini Apache'den Nginx'e taşıdığınızı düşünelim. Apache'de kalıcı bağlantılar .htaccess dosyasındaki yeniden yazma kurallarıyla çalışır: istenen dosya ya da klasör yoksa istek index.php dosyasına yönlendirilir. Nginx'te aynı davranış, sitenin location / bloğundaki try_files $uri $uri/ /index.php?$args; satırıyla sağlanır. Bu tek satır temel işi görür, ama geçişte şunları da gözden geçirmeniz gerekir:
- Eklentilerin .htaccess dosyasına eklediği güvenlik ve önbellek kurallarını listeleyin; her birinin Nginx karşılığını yazın ya da gereksizse çıkarın.
- Yükleme klasöründe PHP çalıştırmayı engelleyen kural varsa Nginx'te ayrı bir location bloğuyla yeniden tanımlayın.
- Eski adreslerden yenilerine yapılan 301 yönlendirmelerini taşıyın ve en önemli adresleri tek tek test edin.
- Gizli dosyalara (örneğin .git veya .env) erişimi engelleyen kuralı eklemeyi unutmayın; Apache'de varsayılan olarak korunan bazı dosyalar Nginx'te ayrıca korunmalıdır.
Geçişi önce bir test alan adında yapın, erişim ve hata loglarını birkaç gün izleyin, ardından canlı alan adını çevirin. DNS geçişini kesintisiz yapmak için TTL ayarlarını domain ve DNS yönetimi sayfasındaki önerilere göre önceden düşürün.
Hız sınırlama ve kötü niyetli trafik
Web sunucusu, uygulamaya ulaşmadan önce kötü niyetli trafiği süzmek için iyi bir yerdir. Nginx'te istek sayısını IP başına sınırlayan yerleşik bir modül bulunur; giriş sayfası ve arama gibi pahalı adreslere bu sınırı uygulamak, kaba kuvvet denemelerinin ve agresif botların sunucuyu yormasını engeller. Apache'de benzer iş için ek modüller kullanılır, LiteSpeed ise bağlantı ve istek sınırlarını kendi yönetim arayüzünden sunar. Sınırları çok sıkı tutmayın: aynı ofisten ya da mobil operatör üzerinden aynı IP'yi paylaşan gerçek kullanıcılar da etkilenebilir. Sunucu düzeyindeki güvenlik duvarı ve kaba kuvvet korumasıyla birlikte düşünmek için VPS güvenlik ayarları rehberine bakabilirsiniz.
Değişiklik yaparken güvenli çalışma alışkanlıkları
- Her değişiklikten sonra yapılandırmayı test edin: Nginx için nginx -t, Apache için Debian/Ubuntu'da apache2ctl configtest, RHEL tabanlı sistemlerde apachectl configtest.
- Test başarılıysa servisi yeniden başlatmak yerine yeniden yükleyin (systemctl reload nginx gibi). Yeniden yükleme açık bağlantıları koparmaz.
- Yapılandırma dosyalarını bir sürüm kontrol sisteminde ya da en azından tarihli kopyalarla saklayın.
- Sunucu sürümünü yanıt başlıklarında göstermeyin; bu bilgi saldırganların işini kolaylaştırır.
Web sunucusunu kurduktan sonraki adım HTTPS'tir; sertifika kurulumu ve otomatik yenileme için Let's Encrypt SSL kurulumu rehberine geçin. Yapılandırma hatalarınızı ve log çıktılarınızı Linux Sunucular bölümünde paylaşabilirsiniz. Konunun özeti için hosting paneli ve web sunucusu sayfasına dönebilirsiniz.
Forumdaki ilgili bölümler
- Linux SunucularWeb sunucusu yapılandırması ve hata ayıklama.
- Sunucu/Hosting Bilgi AlışverişiWeb sunucusu tercihleri ve performans deneyimleri.
- PHPPHP-FPM ve PHP yapılandırma soruları.
Sık sorulan sorular
Nginx Apache'den her zaman daha hızlı mıdır?
Hayır. Nginx yüksek eş zamanlılıkta ve statik dosya sunumunda genellikle daha az bellek kullanır, ancak dinamik sayfalarda hız büyük ölçüde PHP, veritabanı ve önbellek ayarlarına bağlıdır. Küçük sitelerde fark çoğu zaman hissedilmez.
Nginx'te .htaccess dosyası çalışır mı?
Hayır, Nginx .htaccess dosyalarını okumaz. Kuralların sunucu yapılandırmasına Nginx söz dizimiyle yazılması gerekir.
LiteSpeed ile OpenLiteSpeed arasındaki fark nedir?
LiteSpeed Enterprise ticari lisanslı sürümdür ve Apache yapılandırmasıyla geniş uyumluluk sunar. OpenLiteSpeed açık kaynaklı ve ücretsizdir ancak .htaccess desteği ve bazı özellikleri daha sınırlıdır. Ayrıntılar için resmi belgeleri inceleyin.
Web sunucusunu değiştirince SEO etkilenir mi?
Doğru yapılırsa hayır. Ancak yönlendirme kuralları eksik çevrilirse sayfalar 404 verebilir veya yönlendirmeler bozulabilir. Geçişten sonra önemli adresleri ve yönlendirmeleri tek tek test edin.