Nginx nedir, ne işe yarar?

• Sunucu ve Altyapı
• Güncelleme: 04.10.2026
• Yaklaşık 8 dk okuma

Nginx'i tanıyın

1. 1

   Nginx'in dört rolü

   Aynı yazılım, yapılandırmasına göre farklı işler üstlenir. Çoğu kurulumda bu rollerin birkaçı bir arada kullanılır.

   • Web sunucusu: HTML, CSS, JavaScript, görsel gibi statik dosyaları doğrudan diskten okuyup ziyaretçiye gönderir.
   • Ters vekil (reverse proxy): İsteği kendisi yanıtlamak yerine arkadaki bir uygulamaya (arka uç sunucusu, backend) iletir ve yanıtı ziyaretçiye geri taşır. PHP, Node.js, Python ya da Java uygulamaları çoğunlukla bu şekilde yayınlanır. Ayrıntısı: ters vekil nedir.
   • Yük dengeleyici (load balancer): Aynı uygulamayı çalıştıran birden fazla sunucu varsa istekleri aralarında paylaştırır. Ayrıntısı: yük dengeleme.
   • Önbellek (cache): Arka uçtan gelen yanıtların bir kopyasını belirli süre saklar; aynı istek yeniden geldiğinde uygulamayı çalıştırmadan yanıt verir. Ayrıntısı: önbellek ve sıkıştırma.

   Bunlara ek olarak HTTPS bağlantısını Nginx'te karşılayıp arkadaki uygulamaya şifresiz iletmek (SSL sonlandırma, SSL termination) de yaygın bir kullanımdır.

   : Büyüt

2. 2

   Olay tabanlı mimari: az süreç, çok bağlantı

   Nginx çalışırken iki tür süreç görürsünüz. Ana süreç (master) yapılandırmayı okur, işçi süreçleri başlatır ve yeniden yüklemeyi yönetir. İşçi süreçler (worker) ziyaretçi bağlantılarını karşılar.

   Önemli olan şudur: her bağlantı için ayrı bir süreç ya da iş parçacığı açılmaz. Her işçi süreç, aynı anda çok sayıda bağlantıyı izler ve yalnızca o anda yapılacak işi olan (veri gelen ya da veri göndermeye hazır) bağlantıyla ilgilenir. Buna olay tabanlı (event-driven) çalışma denir. Bir ziyaretçinin yavaş bağlantısı, işçiyi onu beklerken boşta tutmaz; işçi o sırada diğer bağlantılara hizmet eder.

   İşçi süreç sayısı worker_processes yönergesiyle (directive) belirlenir; auto değeri sayıyı işlemci çekirdeği sayısına göre ayarlar. Bu mimari, özellikle çok sayıda eşzamanlı bağlantının açık kaldığı durumlarda bellek kullanımını öngörülebilir tutmayı amaçlar. Gerçek başarım ise sitenize, uygulamanıza ve yapılandırmaya bağlıdır; ölçmeden genelleme yapmak doğru olmaz.

   : Büyüt

3. 3

   Apache ile farkı

   Apache da köklü ve yaygın bir web sunucusudur. İkisi aynı işi yapar ama yapılandırma anlayışları farklıdır.

   • .htaccess yoktur. Apache, izin verildiğinde her klasördeki .htaccess dosyasını istek sırasında okur; dosyayı değiştirdiğinizde ayar hemen geçerli olur ve sunucuyu yeniden başlatmanız gerekmez. Nginx böyle bir dosyayı tanımaz; klasöre koyduğunuz .htaccess hiçbir şey yapmaz.
   • Yapılandırma merkezidir. Nginx'te tüm ayarlar sunucudaki yapılandırma dosyalarında durur ve bunları değiştirmek için genellikle yönetici yetkisi gerekir.
   • Değişiklik test ve yeniden yükleme ister. Dosyayı kaydetmek yetmez; önce sözdizimi denetlenir, sonra Nginx'e yapılandırmayı yeniden okuması söylenir.
   • PHP'yi kendisi çalıştırmaz. Apache, PHP'yi bir modül olarak kendi içinde çalıştırabilir. Nginx ise isteği ayrı çalışan PHP-FPM'e iletir. Ayrıntısı: Nginx ve PHP-FPM.

   Apache'nin de olay tabanlı çalışma kipi vardır ve PHP-FPM ile kullanılabilir; yani fark siyah beyaz değildir. Asıl ayrım, ayarların nerede durduğu ve kimin değiştirebildiğidir. Mevcut .htaccess kurallarını taşımak için Apache'den Nginx'e geçiş rehberine bakın.

   : Büyüt

4. 4

   İkisi birlikte: Nginx önde, Apache arkada

   Nginx ile Apache arasında seçim yapmak zorunda değilsiniz. Yaygın bir düzen şöyledir: ziyaretçiyi Nginx karşılar, statik dosyaları kendisi verir, HTTPS bağlantısını yönetir; geri kalan istekleri ters vekil olarak arkadaki Apache'ye iletir. Apache ise uygulamayı ve .htaccess kurallarını çalıştırmayı sürdürür.

   Bu düzenin yararı, .htaccess kullanan mevcut uygulamayı değiştirmeden öne bir katman eklemektir. Bedeli ise yönetilecek iki yazılım olmasıdır: iki yapılandırma, iki günlük (log) ve Apache'nin ziyaretçinin gerçek IP adresini görebilmesi için ek ayar. Bu düzenin kurulumu ters vekil kurulumu rehberinde anlatılır.

   : Büyüt

5. 5

   Yapılandırma yapısı: http, server, location

   Nginx yapılandırması iç içe bloklardan oluşur. Her satır bir yönergedir ve noktalı virgülle biter; bloklar süslü ayraçla açılıp kapanır.

   • http bloğu: Web trafiğiyle ilgili genel ayarlar. Tüm siteler için geçerlidir.
   • server bloğu: Tek bir siteyi (alan adını) tanımlar; Apache'deki sanal sunucunun karşılığıdır. Hangi bağlantı noktasını dinleyeceği (listen) ve hangi alan adlarına yanıt vereceği (server_name) burada yazılır.
   • location bloğu: Sitenin belirli bir adres kalıbına (ör. /, /img/, .php ile biten adresler) nasıl davranılacağını belirler.

   İçteki blok, dıştakinin ayarlarını devralır ve gerekirse kendi değeriyle değiştirir. En sade hâliyle tam bir yapılandırma dosyası şöyle görünür:

   Nginx

   # Ana bağlam: sürecin geneli
   worker_processes auto;
   
   events {
       worker_connections 1024;
   }
   
   http {
       # Tüm siteler için ortak ayarlar
       include mime.types;
       default_type application/octet-stream;
   
       server {
           # Tek bir site
           listen 80;
           server_name ornek.com;
           root /var/www/ornek.com/public;
   
           location / {
               # Belirli bir adres kalıbı için kurallar
               try_files $uri $uri/ =404;
           }
       }
   }

   Uygulamada her site ayrı bir dosyada tutulur ve ana dosya bunları include ile içeri alır. Ana dosya çoğunlukla /etc/nginx/nginx.conf yolundadır; site dosyalarının konumu dağıtıma göre değişir (/etc/nginx/conf.d/ yaygındır; /etc/nginx/sites-available/ ve sites-enabled/ Debian ve Ubuntu düzenidir).

   Aşağıdaki örnek, statik bir siteyi yayınlayan küçük bir server bloğudur. Klasör yolu örnektir; kendi sunucunuzdaki yolu yazın.

   Nginx

   server {
       listen 80;
       listen [::]:80;
       server_name ornek.com www.ornek.com;
   
       # Sitenin dosyalarının bulunduğu klasör ve varsayılan belge
       root /var/www/ornek.com/public;
       index index.html;
   
       # Önce dosyayı, sonra klasörü ara; yoksa 404 döndür
       location / {
           try_files $uri $uri/ =404;
       }
   
       # Statik dosyalar tarayıcıda 30 gün saklanabilir
       location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$ {
           expires 30d;
       }
   
       # Nokta ile başlayan gizli dosyalar (.git, .env, .htaccess) sunulmaz;
       # sertifika doğrulamasında kullanılan /.well-known/ hariç
       location ~ /\.(?!well-known) {
           deny all;
       }
   }

   try_files, istenen adresi önce dosya, sonra klasör olarak arar; bulamazsa 404 döndürür. Bu örnek yalnızca HTTP (80) dinler; HTTPS için HTTPS ve SSL sertifikası rehberine geçin.

   : Büyüt

6. 6

   Temel komutlar: test edin, sonra yeniden yükleyin

   Yapılandırmada her değişiklikten sonra iki adım vardır: önce denetim, sonra yeniden yükleme.

   Bash

   # 1. Yapılandırmayı denetle (sözdizimi hatası varsa dosya ve satırı gösterir)
   sudo nginx -t
   
   # 2. Kesintisiz yeniden yükle (ikisinden biri yeterlidir)
   sudo systemctl reload nginx
   sudo nginx -s reload
   
   # Yardımcı komutlar
   nginx -v                     # kurulu sürümü gösterir
   sudo nginx -T                # geçerli yapılandırmanın tamamını ekrana döker
   sudo systemctl status nginx  # servis çalışıyor mu?

   nginx -t hata bulursa dosya adını ve satır numarasını söyler; hata düzelmeden yeniden yükleme yapmayın. Yeniden yükleme (reload) siteyi kesintiye uğratmaz: ana süreç yeni yapılandırmayla yeni işçi süreçler başlatır, eski işçiler ellerindeki istekleri bitirip kapanır. Yeniden başlatma (restart) ise bağlantıları keser; olağan ayar değişikliklerinde gerekmez.

Ne zaman hangisi?

"Hangisi daha iyi?" sorusunun tek bir yanıtı yoktur. Seçimi hız iddiaları değil, aşağıdaki gibi somut ölçütler belirlemelidir.

Kararsız kaldığınızda sorulacak soru şudur: mevcut düzende çözülmeyen somut bir sorun var mı? Çalışan bir siteyi yalnızca "daha hızlı olur" beklentisiyle taşımak, kazançtan çok risk getirebilir. Değişiklikten önce ve sonra kendi sitenizde ölçüm yapın.

Sık yapılan hatalar

• .htaccess'in çalışmasını beklemek: Nginx'e geçildiğinde yönlendirme, erişim kısıtı ve "temiz adres" kuralları sunucu yapılandırmasına taşınmazsa sessizce devre dışı kalır. Korumalı klasörler açığa çıkabilir; geçişten sonra bunları tek tek sınayın.
• Test etmeden yeniden yüklemek: Önce nginx -t. Hatalı yapılandırmayla yapılan yeniden başlatma siteyi kapatabilir.
• Noktalı virgülü ya da ayracı unutmak: En sık görülen sözdizimi hatalarıdır; test komutu satırı gösterir.
• Dosyayı kaydedip değişikliği beklemek: Yeniden yükleme yapılmadıkça Nginx eski yapılandırmayla çalışmayı sürdürür.
• Canlı dosyayı yedeksiz düzenlemek: Değişiklikten önce dosyanın kopyasını alın; sorun çıkarsa geri dönmek bir dakikanızı alır.

Yol haritası: sıradaki rehberler

Bu kategorideki rehberleri ihtiyacınıza göre şu sırayla okuyabilirsiniz:

• Kavramlar: vekil sunucu (proxy) nedir, ters vekil nedir, yük dengeleme nedir, CDN nedir.
• Kurulum ve ayar: Nginx ile ters vekil kurulumu, HTTPS ve SSL sertifikası, Nginx ve PHP-FPM.
• Başarım: önbellek ve sıkıştırma.
• Güvenlik: Nginx güvenlik ayarları; ek olarak güvenlik başlıkları ve HTTPS.
• Sorun giderme: 502, 504 ve diğer Nginx hataları.
• Geçiş: Apache ve .htaccess'ten Nginx'e geçiş.

Sık sorulan sorular

İlgili rehberler

• Reverse proxy (ters vekil) nedir?Ters vekilin görevleri, tipik mimariler, gerçek ziyaretçi IP'si ve başlıklar, CDN ile ilişkisi ve kısa Nginx örneği.
• Nginx ve PHP-FPM: PHP siteleri Nginx ile nasıl çalışır?fastcgi_pass, SCRIPT_FILENAME, try_files, havuz (pool) kavramı, soket izinleri ve 502 hatası.
• Apache ve .htaccess'ten Nginx'e geçiş.htaccess kurallarını Nginx yapılandırmasına taşımak için yan yana örnekler, karşılık tablosu ve test listesi.
• Nginx'te HTTPS: SSL sertifikası kurulumuNginx'te sertifika alma, HTTPS'e yönlendirme, HSTS, SSL sonlandırma ve otomatik yenileme adımları.