Nginx (“engine x” diye okunur), HTTP ve HTTPS isteklerini karşılayan açık kaynaklı bir web sunucusu yazılımıdır. Ancak onu yalnızca sitenin önünde duran bir servis olarak görmek eksik olur. Nginx; statik dosyaları sunabilir, SSL bağlantılarını yönetebilir, uygulamanın önünde reverse proxy olarak çalışabilir, önbellek kullanabilir ve trafiği birden fazla uygulama sunucusuna dağıtabilir.
Ben Nginx’i çoğu projede trafiğin giriş kapısı olarak konumlandırıyorum. Kişisel projelerimde, Veridyen üzerinde hazırladığımız servislerde ve mikroservis düzenlerinde Nginx’i tercih etmemin sebebi de bu. Tek noktadan TLS, yönlendirme ve uygulama servislerini yönetebilmek işimi kolaylaştırıyor. Ziyaretçi tarayıcıdan istek gönderir; Nginx bu isteğin doğrudan bir dosyayla mı karşılanacağına, yoksa arkadaki uygulamaya mı gideceğine karar verir. Böylece Laravel, Node.js veya Python uygulamanız her HTTP bağlantısının ayrıntısıyla uğraşmak zorunda kalmaz.
Nginx nasıl çalışır?
Nginx’in öne çıkan tarafı olay güdümlü ve eş zamansız çalışma modelidir. Klasik yaklaşımda her bağlantı için ayrı bir işlem veya iş parçacığı açmak, bağlantı sayısı arttıkça kaynak tüketimini büyütebilir. Nginx ise bağlantıları olaylar üzerinden takip eder. Bir bağlantı ağdan veri beklerken işlemciyi boş yere meşgul etmek yerine, hazır olan başka bir istekle ilgilenebilir.
Bu yaklaşımın amacı “her koşulda en hızlı yazılım” olmak değildir. Asıl hedef, çok sayıda eşzamanlı bağlantıyı düzenli ve düşük ek yükle yönetmektir. Özellikle görseller, CSS, JavaScript, fontlar ve indirme dosyaları gibi statik içerikler için bunun karşılığı nettir. Dosya diskte hazırsa, isteğin PHP’ye veya uygulama katmanına uğramadan doğrudan ziyaretçiye gönderilmesi mümkündür.
Nginx yapılandırmasında bir ana süreç ve istekleri işleyen worker süreçleri bulunur. Ana süreç yapılandırmayı ve worker’ları yönetir; asıl trafik yükünü worker’lar taşır. Bu yapı, yapılandırma değişikliklerini kontrollü biçimde yeniden yüklemeye de izin verir. Yine de her değişikliğin önce test edilmesi gerekir; küçük bir yönlendirme hatası bile tüm siteyi etkileyebilir.
Performans sadece Nginx demek değildir
Nginx, performans konuşulurken sık anılır; fakat tek başına performans çözümü değildir. Yavaş bir veritabanı sorgusu, büyük boyutlu görseller, gereksiz WordPress eklentileri, hatalı önbellek ayarı veya yetersiz sunucu kaynağı varsa Nginx bunları sihirli biçimde düzeltmez. Bir projede darboğazın nerede olduğunu ölçmeden “web sunucusunu değiştirelim” demek çoğu zaman erken verilmiş bir karardır.
Yine de Nginx’in üstlendiği işler önemlidir. Sıkıştırma, cache kontrol başlıkları, statik dosyaların verimli sunulması ve SSL sonlandırma gibi işleri uygulamanın önünde yapabilir. Böylece PHP veya uygulama sunucusu, yalnızca dinamik olan isteklere zaman ayırır. Doğru ayarlandığında gereksiz uygulama yükü azalır ve ziyaretçinin gördüğü yanıt süresi iyileşir.
PHP projelerinde önemli bir ayrım var: Nginx, PHP kodunu doğrudan çalıştırmaz. İsteği çoğunlukla PHP-FPM’e FastCGI üzerinden iletir; PHP-FPM kodu çalıştırır ve yanıtı geri verir. Nginx web trafiğini yönetir, PHP-FPM ise PHP süreçlerini. Sorun ararken bu iki katmanı birbirine karıştırmamak gerekir.
Reverse proxy ne işe yarar?
Reverse proxy, ziyaretçi ile arka plandaki uygulama arasına yerleştirilen aracı katmandır. Ziyaretçi siteadi.com adresine gider; uygulamanın hangi portta, hangi sunucuda veya kaç kopya halinde çalıştığını bilmez. Nginx isteği alır, gerekli kuralları uygular ve uygun arka uç servise aktarır.
Örneğin Laravel uygulamanız aynı sunucuda bir portta, Node.js ile çalışan API’niz başka bir portta durabilir. Nginx, alan adı ve URL yoluna göre bu servisleri tek bir HTTPS adresi altında dış dünyaya açabilir. Sertifika yönetimini, HTTP’den HTTPS’e yönlendirmeyi ve güvenlikle ilgili başlıkları merkezi bir yerde tutmak da daha kolay hale gelir.
Bu yapı uygulamayı büyütürken daha da değerli olur. Aynı uygulamanın birden fazla örneği çalışıyorsa Nginx, istekleri tanımladığınız kurala göre bunlar arasında dağıtabilir. Buna load balancing denir. Fakat yük dağıtımı eklemek, uygulamanın kendiliğinden ölçeklenebilir olduğu anlamına gelmez. Oturum yönetimi, dosya depolama, kuyruklar ve veritabanı bağlantıları da çoklu sunucu düzenine uygun olmalıdır.
Nginx ile istek hızı sınırlama, dosya yükleme boyutu sınırı koyma ve belirli URL’lere erişimi kısıtlama gibi temel önlemler de uygulanabilir. Bunlar güvenliğe katkı sağlar; ancak güncel olmayan yazılımı, zayıf parolayı veya uygulama içindeki bir açığı telafi etmez. Proxy katmanını güvenlik duvarı yerine koymak doğru değildir.
Nginx vs Apache
Apache ve Nginx karşılaştırmasında genellikle kazanan ilan edilmeye çalışılır. Bence doğru soru “hangisi daha hızlı?” değil, “bu projenin ihtiyacı ne?” olmalı. Apache olgun, geniş bir modül ekosistemine sahip ve özellikle .htaccess kullanan projelerde pratik bir seçenektir. Paylaşımlı hosting alışkanlıklarının önemli bir kısmı da bu dosyaya dayanır.
Nginx .htaccess dosyalarını istek anında okumaz. Yönlendirme, erişim ve önbellek kurallarını merkezi yapılandırma dosyalarında tutarsınız. Bu yaklaşım daha öngörülebilir bir yapı sağlar; fakat değişiklik için sunucu yapılandırmasına erişim ve ardından kontrollü yeniden yükleme gerekir. Kendi sunucunuzu yönetmiyorsanız bu ayrım kararınızı doğrudan etkileyebilir.
Statik içerik, yoğun bağlantı ve reverse proxy katmanında Nginx güçlü bir tercihtir. Apache ise mevcut .htaccess kuralları, özel modüller veya alışılmış yönetim biçimi nedeniyle daha uygun olabilir. PHP tarafında iki yazılım da PHP-FPM ile çalışabilir. Eski bir Apache uygulamasını arka uçta bırakıp Nginx’i ön tarafa koymak, statik dosya ve proxy işlerini Nginx’e vermek de mümkündür.
Nginx ne zaman tercih edilmeli?
Kendi Linux sunucunuzu yönetiyorsanız ve uygulamanız için tek bir giriş noktası kurmak istiyorsanız Nginx mantıklı bir başlangıçtır. Laravel, Node.js, Django veya birden fazla servisin aynı sunucuda çalıştığı projelerde reverse proxy rolü özellikle işe yarar. Sadece statik bir site yayınlıyorsanız da sade bir Nginx yapılandırması yeterli olabilir.
Ama küçük bir web sitesinde yalnızca “Nginx daha hızlı” diye mevcut ve sorunsuz Apache kurulumunu değiştirmek için acele etmeyin. Önce ölçün: Yanıt süresi nerede uzuyor, CPU ve RAM kullanımı nasıl, PHP-FPM kuyruk oluşturuyor mu, veritabanı sorguları ne kadar sürüyor? Sağlıklı karar, web sunucusunun adından değil bu verilerden çıkar.
Özetle Nginx, modern web uygulamalarında yalnızca bir web sunucusu değil; performans, TLS, proxy ve trafik yönetimi için güçlü bir ön katmandır. Doğru yerde konumlandırıldığında uygulamanın işini kolaylaştırır. Yanlış yapılandırıldığında ise en iyi yazılım bile sorun çıkarır; bu yüzden sade başlayıp ihtiyaç oldukça büyütmek en güvenli yoldur.
