Apache mı Nginx mi? Web Sunucusu Karşılaştırması

Bir web projesini yayına almadan önce verdiğiniz en temel altyapı kararlarından biri hangi web sunucusunu kullanacağınızdır. Bu alanda iki isim öne çıkar: uzun yıllardır standart kabul edilen Apache HTTP Server ve son on yılda özellikle yüksek trafikli sitelerde tercih edilen Nginx. İkisi de olgun, güvenilir ve ücretsizdir; ancak temeldeki tasarım felsefeleri birbirinden oldukça farklıdır ve bu fark, sunucunuzun eş zamanlı binlerce isteği nasıl karşılayacağını doğrudan etkiler.

Bu yazıda iki sunucunun mimari yaklaşımını, statik ve dinamik içerikteki davranışını, yapılandırma modellerini, bellek kullanımını ve ters proxy yeteneklerini karşılaştıracağız. Sonunda "hangisi daha iyi?" sorusuna tek bir cevap vermek yerine, hangi senaryoda hangisinin daha mantıklı olduğunu ve ikisini birlikte nasıl kullanabileceğinizi somut örneklerle göreceksiniz.

Temel Mimari Farkı: Süreç/Thread vs Olay Tabanlı#

İki sunucu arasındaki en belirleyici fark, eş zamanlı bağlantıları işleme biçimlerinde yatar.

Apache klasik olarak her bağlantı için ayrı bir işlem (process) veya iş parçacığı (thread) ayırma modeliyle çalışır. Bu davranış, kullanılan MPM (Multi-Processing Module) ile belirlenir:

• prefork: Her istek ayrı bir işlemde çalışır, thread paylaşımı yoktur. Thread güvenli olmayan modüllerle (klasik mod_php ve bazı eski uzantılar gibi) sorunsuz çalışır ama her işlem ayrı bellek tükettiği için pahalıdır.
• worker: İşlem başına birden fazla thread kullanır; aynı bağlantı sayısını daha az işlemle karşıladığı için prefork'a göre daha az bellek harcar.
• event: worker ile aynı thread yapısını kullanır, ancak keep-alive nedeniyle boşta bekleyen bağlantıları ayrı bir dinleyici thread'ine devrederek worker thread'lerini meşgul etmez. Böylece çok sayıda açık ama atıl bağlantı, Nginx'in yaptığına yaklaşan bir verimlilikle yönetilir. Apache 2.4'ten beri varsayılan MPM'dir.

Bu modelin sorunu şudur: 10.000 eş zamanlı bağlantı, kabaca 10.000 thread veya işlem anlamına gelebilir. Her thread'in kendi bellek yükü olduğu için, bağlantı sayısı arttıkça bellek tüketimi hızla yükselir. Buna literatürde C10k problemi denir.

Nginx bu problemi çözmek için işi baştan farklı kurgular: olay tabanlı (event-driven), asenkron bir mimari kullanır. Genellikle worker_processes auto; ayarıyla çekirdek başına bir worker process başlatır ve her worker, binlerce bağlantıyı tek bir olay döngüsü içinde bloklamadan yönetir. Bir bağlantı ağdan veri beklerken worker boşta oturmaz; o an hazır olan başka bağlantılarla ilgilenir, veri geldiğinde geri döner. Böylece Nginx, on binlerce açık bağlantıyı bağlantı başına yeni bir thread açmadan, sabit ve düşük bir bellek bütçesiyle taşıyabilir.

Kısacası: Apache "her isteğe bir çalışan" mantığıyla, Nginx ise "az sayıda çalışan, çok sayıda iş" mantığıyla ölçeklenir.

Statik ve Dinamik İçerik Performansı#

Performansı iki ayrı senaryoda değerlendirmek gerekir.

Statik dosyalar#

Resim, CSS, JavaScript, PDF gibi statik dosyaları sunmakta Nginx belirgin biçimde daha hızlı çalışır ve daha az kaynak tüketir. Olay tabanlı yapısı ve dosyayı kullanıcı alanına kopyalamadan doğrudan çekirdek üzerinden gönderme (sendfile) yeteneği sayesinde yüksek eş zamanlılıkta bile stabil kalır. Ayrıca proxy_cache ile arka uçtan gelen yanıtları önbelleğe alabildiği için, aynı içeriği tekrar tekrar üreten uygulamaların yükünü ciddi biçimde hafifletir. Yoğun görsel içeren bir kurumsal site ya da bir CDN'in arkasındaki köken (origin) sunucusu için Nginx tipik olarak daha isabetli bir seçimdir.

Dinamik içerik (PHP, Python vb.)#

Dinamik içerikte tablo biraz değişir. Apache, mod_php gibi modüllerle PHP'yi kendi süreci içinde çalıştırabilir; bu, kurulumu basitleştirir. Nginx ise PHP'yi kendisi çalıştırmaz — isteği PHP-FPM (FastCGI Process Manager) gibi ayrı bir işlemci havuzuna iletir:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

İlginç olan şu: modern kurulumlarda Apache de artık genellikle mod_php yerine php-fpm ile çalıştırılır. Bu durumda PHP'nin gerçek işleme performansı iki sunucuda da benzerdir, çünkü asıl işi yapan PHP-FPM'dir. Fark, isteğin PHP-FPM'e kadar taşınmasında ortaya çıkar ve burada yine Nginx'in hafif yapısı yüksek trafikte avantaj sağlar.

WordPress gibi PHP tabanlı bir site kuruyorsanız her iki sunucu da sorunsuz çalışır; performans farkı ziyaretçi trafiği yükseldikçe hissedilir hale gelir. Hazır bir WordPress altyapısı arıyorsanız WordPress hosting paketleri bu yapılandırmayı sizin için hazır sunar.

.htaccess vs Merkezi Yapılandırma#

Yapılandırma yaklaşımı, iki sunucu arasındaki en pratik günlük farklardan biridir.

Apache, dizin bazlı .htaccess dosyalarını destekler. Bu dosyalar sayesinde, ana sunucu yapılandırmasına dokunmadan ve sunucuyu yeniden başlatmadan bir dizinin davranışını değiştirebilirsiniz — yönlendirme kuralları, erişim kısıtlamaları, önbellek başlıkları gibi. Paylaşımlı hosting ortamlarında bu esneklik çok değerlidir; her müşteri kendi dizinini yönetebilir.

Tipik bir .htaccess yönlendirme örneği:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Bunun bedeli performanstır: Apache, her istekte istenen dizin ve üst dizinlerdeki .htaccess dosyalarını okumak zorundadır. Yüksek trafikte bu, ölçülebilir bir yük getirir.

Nginx .htaccess desteklemez. Tüm yönlendirme ve kurallar merkezi yapılandırma dosyalarında (nginx.conf ve sites-available altındaki server blokları) tanımlanır ve nginx -s reload ile yüklenir. Aynı yönlendirmenin Nginx karşılığı:

server {
    listen 80;
    server_name ornek.com;
    return 301 https://$host$request_uri;
}

Bu merkezi model daha hızlıdır çünkü kurallar başlangıçta bir kez belleğe alınır; her istekte diskten dosya okunmaz. Dezavantajı, her değişikliğin sunucu yapılandırmasına erişim gerektirmesidir — bu yüzden çok kiracılı paylaşımlı ortamlarda Nginx'i esnek biçimde kullanmak daha zordur. Nginx yapılandırmasına yeni başlıyorsanız Nginx kurulumu rehberimiz temel bir server bloğunu adım adım kurmayı gösterir.

Ters Proxy ve Yük Dengeleme#

Nginx'in en güçlü olduğu alanlardan biri ters proxy (reverse proxy) ve yük dengeleme (load balancing) yetenekleridir. Bir Nginx örneği, gelen istekleri arka plandaki birden fazla uygulama sunucusuna dağıtabilir:

upstream uygulama_havuzu {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000;
}

server {
    listen 80;
    server_name api.ornek.com;

    location / {
        proxy_pass http://uygulama_havuzu;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Bu yapı, Node.js, Python (Gunicorn/Uvicorn) veya benzeri uygulama sunucularının önünde durup trafiği dağıtmak, SSL sonlandırmak ve statik dosyaları doğrudan sunmak için idealdir.

Apache da mod_proxy ve mod_proxy_balancer ile ters proxy ve yük dengeleme yapabilir; işlev olarak eksik değildir. Ancak yüksek eş zamanlılık altında, olay tabanlı mimarisi nedeniyle Nginx bu rolde genellikle daha az kaynakla daha kararlı çalışır. Bu nedenle mikroservis ve API mimarilerinde önyüz (edge) katmanı olarak çoğunlukla Nginx tercih edilir. Trafiği birden fazla sunucuya dağıtacak bir mimari planlıyorsanız VDS sunucular esnek kaynak ölçekleme için uygun bir başlangıçtır.

Bellek Kullanımı ve Ölçeklenebilirlik#

Bellek davranışı, iki mimarinin doğal bir sonucudur.

• Apache (prefork/worker): Bellek kullanımı eş zamanlı bağlantı sayısıyla neredeyse doğru orantılı artar. Her işlem/thread, yüklü modüllerle birlikte belli bir RAM tüketir. Çok sayıda modül yüklüyse (özellikle mod_php ile) bu yük daha da büyür.
• Nginx: Bellek kullanımı bağlantı sayısından büyük ölçüde bağımsızdır ve nispeten sabit kalır. On binlerce açık bağlantı, birkaç worker process içinde düşük bir RAM bütçesiyle yönetilebilir.

Pratikte bu, sınırlı belleğe sahip bir sunucuda (örneğin 1 GB RAM'li bir VPS) trafik yükselince Apache'nin daha erken zorlanabileceği, Nginx'in ise daha uzun süre stabil kalabileceği anlamına gelir. Düşük kaynaklı bir sunucuda çok sayıda ziyaretçiyi karşılamak istiyorsanız Nginx genellikle daha güvenli bir zemin sunar. Kaynak ölçeklenebilirliği önceliğinizse sanal sunucu çözümleri ihtiyacınıza göre yükseltilebilir yapıdadır.

Hangi Senaryoda Hangisi?#

Karar vermek için projenizin ihtiyaçlarına bakın. Aşağıdaki tablo tipik durumlara hızlı bir rehber sunar:

Kısaca: paylaşımlı ortamlar ve .htaccess esnekliği gerektiren projeler için Apache; yüksek eş zamanlılık, statik içerik ve ters proxy gerektiren projeler için Nginx öne çıkar. Ancak bu bir "ya o ya bu" seçimi olmak zorunda değildir.

İkisini Birlikte Kullanmak: Nginx Önde Reverse Proxy#

En yaygın ve güçlü senaryolardan biri, iki sunucuyu birlikte kullanmaktır. Bu yapıda Nginx önyüzde durur, statik dosyaları doğrudan sunar ve dinamik istekleri arka plandaki Apache'ye iletir:

server {
    listen 80;
    server_name ornek.com;

    # Statik dosyaları Nginx doğrudan sunsun
    location ~* \.(jpg|jpeg|png|css|js|ico|svg|woff2)$ {
        root /var/www/ornek.com;
        expires 30d;
    }

    # Dinamik istekleri arka plandaki Apache'ye ilet
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Bu kurulumda Apache'yi 8080 gibi dahili bir porttan dinlemeye ayarlarsınız. Böylece:

• Nginx'in hızlı statik sunumundan ve düşük bellek kullanımından faydalanırsınız.
• Apache'nin .htaccess ve modül ekosisteminden (mevcut uygulama gerektiriyorsa) vazgeçmezsiniz.
• SSL sonlandırmayı tek noktada (Nginx) yönetirsiniz.

Bu kurulumda dikkat edilecek klasik bir ayrıntı vardır: Apache artık istekleri doğrudan ziyaretçiden değil, 127.0.0.1 üzerinden Nginx'ten alır. Önlem almazsanız erişim loglarında ve uygulama tarafında her ziyaretçi 127.0.0.1 olarak görünür. Bunu çözmek için Nginx X-Forwarded-For / X-Forwarded-Proto başlıklarını iletir (yukarıdaki proxy_set_header satırları), Apache tarafında ise mod_remoteip bu başlıktaki gerçek IP'yi geri yazar. HTTPS bilgisinin ($scheme) iletilmesi de önemlidir; aksi halde arkadaki uygulama isteği HTTP sanıp hatalı yönlendirmeler üretebilir.

Bu hibrit yaklaşım, özellikle WordPress ve benzeri mevcut PHP uygulamalarını yeniden yapılandırmadan performans kazanmak istediğinizde çok işe yarar. SSL sertifikasını Nginx katmanında sonlandırmak için SSL çözümlerimiz ile başlangıç yapabilirsiniz.

Sıkça Sorulan Sorular#

Nginx her zaman Apache'den daha mı hızlıdır?#

Hayır, "her zaman" demek yanlış olur. Nginx özellikle statik içerikte ve yüksek eş zamanlılıkta daha az kaynakla daha hızlı yanıt verir. Ancak PHP-FPM ile çalışan tipik bir dinamik uygulamada iki sunucunun işleme hızı birbirine yakındır; fark asıl olarak yüksek trafik ve bellek verimliliğinde ortaya çıkar.

Apache'yi tamamen bırakmalı mıyım?#

Gerekmez. Apache hâlâ olgun, güvenilir ve .htaccess gibi benzersiz esnekliklere sahip bir sunucudur. Paylaşımlı hosting, mevcut Apache modüllerine bağımlı uygulamalar veya kullanıcı bazlı dizin yapılandırması gereken projelerde Apache mantıklı bir seçim olmayı sürdürür.

Nginx neden .htaccess desteklemiyor?#

Bu bilinçli bir tasarım tercihidir. .htaccess her istekte diskten dosya okumayı gerektirir ve performansı düşürür. Nginx bunun yerine tüm kuralları başlangıçta bir kez belleğe alarak hız kazanır; bu yüzden yapılandırma değişiklikleri merkezi dosyalarda yapılır ve nginx -s reload ile yüklenir.

PHP çalıştırmak için hangisi daha iyi?#

Modern kurulumlarda ikisi de PHP'yi PHP-FPM üzerinden çalıştırdığı için PHP işleme performansı benzerdir. Apache klasik mod_php ile hızlı bir kuruluma izin verse de bu yöntem günümüzde event MPM ile uyumsuz olduğu ve web sunucusu ile PHP'yi aynı işlemde birbirine bağladığı için giderek daha az önerilir; onun yerine Apache tarafında da mod_proxy_fcgi üzerinden PHP-FPM'e bağlanmak yaygınlaşmıştır. Nginx ise doğası gereği yüksek trafikte daha hafif kalır. WordPress gibi projelerde her iki sunucu da sorunsuz çalışır.

Nginx ve Apache'yi aynı sunucuda birlikte kullanabilir miyim?#

Evet, bu çok yaygın bir kurulumdur. Nginx önyüzde ters proxy olarak durur, statik dosyaları sunar ve dinamik istekleri dahili bir porttan (örneğin 8080) dinleyen Apache'ye iletir. Böylece Nginx'in hızından ve Apache'nin esnekliğinden aynı anda faydalanırsınız.

Küçük bir VPS için hangisini seçmeliyim?#

Sınırlı RAM'e sahip bir sunucuda Nginx genellikle daha güvenlidir, çünkü bellek kullanımı bağlantı sayısı arttıkça neredeyse sabit kalır. Trafik yükseldiğinde Apache prefork modeli daha erken zorlanabilir. Yine de uygulamanız Apache'ye özgü özelliklere bağlıysa, hibrit kurulumla ikisini birlikte kullanabilirsiniz.

Sonuç olarak Apache ve Nginx, aynı işi farklı felsefelerle yapan iki güçlü araçtır; doğru seçim projenizin trafik profiline, kaynaklarına ve mevcut uygulamalarınıza bağlıdır. İster tek bir sunucu kurun ister Nginx'i Apache'nin önüne koyarak hibrit bir mimari tercih edin, sağlam bir altyapı üzerinde çalışmak fark yaratır. Bu tür yapılandırmaları özgürce deneyebileceğiniz, kaynaklarını ihtiyacınıza göre ölçekleyebileceğiniz bir zemin arıyorsanız sunucu çözümlerimize göz atabilir, temel Linux komutlarını tazelemek için Linux temel komutlar rehberimize bakabilirsiniz.