İletişim

Nginx Nedir?

Kısa tanım

Nginx (“engine-x” diye okunur), Igor Sysoev'in geliştirdiği açık kaynaklı bir web sunucusudur; aynı zamanda reverse proxy, yük dengeleyici, içerik önbelleği ve TCP/UDP proxy olarak çalışır. Olay güdümlü mimarisi sayesinde az bellekle çok sayıda eş zamanlı bağlantıyı yönetebilir; bu yüzden statik dosya sunmak, HTTPS bağlantısını sonlandırmak ve uygulama sunucularının önünde durmak için yaygın olarak kullanılır.

Diğer adları: NGINX, engine-x, nginx web sunucusu

Bir Nginx sunucu bloğunun 443 portunda TLS ile dinleyip uygulamaya vekil yönlendirme yaptığı ve statik dosyaları doğrudan sunduğu yapılandırma şeması

Tek yazılım, birkaç farklı rol

Nginx'i yalnızca “web sunucusu” olarak düşünmek onu eksik tarif eder. Resmî tanımında HTTP sunucusu, reverse proxy, içerik önbelleği, yük dengeleyici, TCP/UDP proxy ve e-posta proxy'si birlikte sayılır. Pratikte bir sunucuda genellikle şu işlerden birkaçını aynı anda üstlenir:

  • Statik dosya sunmak: CSS, JavaScript, görseller ve önceden üretilmiş HTML diskten doğrudan gönderilir.
  • TLS sonlandırmak: HTTPS bağlantısı Nginx'te açılır; arkadaki uygulama düz HTTP ile yerel ağda konuşur. Sertifika yönetimi tek bir yerde toplanır.
  • Uygulama sunucusunun önünde durmak: Node.js, PHP-FPM, Python veya Go uygulamasına gelen istekleri iletir, yanıtları istemciye geri taşır.
  • Trafiği dağıtmak: upstream bloğunda tanımlanan birden fazla sunucu arasında istekleri paylaştırarak basit bir yük dengeleyici işlevi görür.

Master ve worker süreçleri

Nginx çalıştığında bir master süreç ve birkaç worker süreç başlar. Master, konfigürasyonu okur ve worker'ları yönetir; istekleri asıl işleyen worker'lardır. Her worker, her bağlantı için ayrı bir thread açmak yerine olay döngüsüyle binlerce bağlantıyı aynı anda izler. Yavaş bir mobil istemcinin yanıtı yavaşça indirmesi bu yüzden bir thread'i kilitlemez.

Aynı yapı kesintisiz yeniden yüklemeyi de mümkün kılar: nginx -s reload komutuyla master yeni konfigürasyonun söz dizimini kontrol eder, yeni worker'ları başlatır; eski worker'lar ellerindeki istekleri bitirip kapanır. Konfigürasyon hatalıysa eski ayarlar çalışmaya devam eder.

Küçük bir server bloğu

Konfigürasyon iç içe bağlamlardan oluşur: http içinde her site için bir server, onun içinde URL yollarına göre location blokları. Aşağıdaki örnek HTTP isteklerini HTTPS'e yönlendirir, /static/ altındaki dosyaları diskten sunar ve geri kalan her şeyi 3000 portundaki uygulamaya iletir:

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

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    location /static/ {
        root /var/www/example;
        expires 30d;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

root ile tanımlanan yolda URL'nin tamamı eklenir: /static/app.css isteği /var/www/example/static/app.css dosyasına karşılık gelir. Nginx bir isteği eşleştirirken önce önek (prefix) location'ları içinden en uzun eşleşeni not eder, ardından düzenli ifade (regex) bloklarını sırayla dener.

Konfigürasyonda sık yapılan hatalar

  • Host başlığını iletmemek: proxy_set_header Host yazılmazsa Nginx varsayılan olarak $proxy_host, yani proxy_pass'teki adresi gönderir. Uygulama kendini 127.0.0.1:3000 sanır; mutlak URL'ler, canonical etiketleri ve yönlendirmeler yanlış alan adıyla üretilebilir.
  • Gerçek istemci IP'sini kaybetmek: X-Forwarded-For gönderilmezse uygulama loglarında herkes 127.0.0.1 görünür; hız sınırlama da tek bir “kullanıcıya” uygulanır.
  • Zaman aşımlarını görmezden gelmek: Uygulama yanıt vermezse veya çökerse istemci 502 Bad Gateway ya da 504 alır. Bu hatalar Nginx'in değil, arkasındaki sürecin sorununa işaret eder.
  • Test etmeden yeniden yüklemek: nginx -t konfigürasyonu uygulamadan doğrular; dağıtım betiklerinde reload'dan önce çalıştırmak alışkanlık olmalıdır.

Ne zaman Nginx, ne zaman başka bir şey?

Kendi yönettiğiniz bir VPS üzerinde birden fazla uygulama, sertifika ve statik dosya varsa Nginx olgun ve iyi belgelenmiş bir tercihtir. Apache, dizin bazlı .htaccess dosyaları gerektiren eski PHP uygulamalarında hâlâ pratiktir; Caddy ise sertifikaları kendiliğinden alıp yenilemesiyle daha az ayar ister. Uygulamanızı yönetilen bir platformda veya CDN'in arkasında çalıştırıyorsanız bu katman zaten sağlayıcı tarafından işletiliyor olabilir; ayrıca bir Nginx eklemek yalnızca gerçek bir ihtiyaç varsa anlamlıdır.

İlgili terimler

← Sözlüğe dön