Nginx ile API Geliştirme: 7 Adımda Kapsamlı [2026 Rehberi]

# Nginx ile API Geliştirme: 7 Adımda Kapsamlı [2026 Rehberi] Modern web mimarilerinin karmaşıklığı ve yüksek performans beklentileri, geliştiricileri sürekli yeni ve daha güçlü araçlar arayışına itiyor. 2026 yılında, API'ler arası trafiği yönetmek, yük dengelemek ve güvenlik katmanları oluşturmak için Nginx, vazgeçilmez bir çözüm olarak öne çıkıyor. Peki, bu güçlü web sunucusu ve reverse proxy nasıl API geliştirmenizin omurgası haline gelebilir? Bu kapsamlı rehberde, Nginx'in temel kurulumundan ileri seviye API gateway tekniklerine kadar her şeyi adım adım inceleyeceğiz. Bilgisayar Mühendisi ve Full Stack Developer Burak Balkı olarak, 10 yılı aşkın tecrübemle edindiğim pratik bilgilerle, Nginx'i API projelerinize entegre etmenin en etkili yollarını sizlerle paylaşacağım. Hazırsanız, 2026'nın en güncel Nginx API geliştirme rehberine dalalım. ## Nginx Nedir? API Geliştirme İçin Önemi [2026] Nginx (Engine-X olarak telaffuz edilir), yüksek performanslı, açık kaynaklı bir web sunucusu, reverse proxy, yük dengeleyici ve HTTP önbelleğidir. 2026 itibarıyla, özellikle mikroservis mimarilerinde ve yüksek trafikli API projelerinde, eşzamansız (asynchronous) ve olay tabanlı (event-driven) mimarisi sayesinde olağanüstü ölçeklenebilirlik ve verimlilik sunar. API geliştirme bağlamında Nginx, istemciler ile backend servisleri arasında bir aracı görevi görerek istekleri yönlendirme, yükü dağıtma, önbellekleme ve güvenlik politikaları uygulama gibi kritik işlevleri üstlenir. Nginx, 2004 yılında Igor Sysoev tarafından geliştirildi ve o günden bu yana web altyapısının temel taşlarından biri haline geldi. Geleneksel web sunucularının aksine, Nginx her bağlantı için yeni bir süreç veya iş parçacığı oluşturmak yerine, tek bir iş parçacığı içinde binlerce eşzamanlı bağlantıyı yönetebilir. Bu mimari, özellikle API'lerin yoğun olduğu ve binlerce eşzamanlı isteğin işlenmesi gereken senaryolarda Nginx'i rakipsiz kılar. Bir API gateway olarak Nginx, gelen istekleri doğru mikroservislere yönlendirirken, aynı zamanda kimlik doğrulama, yetkilendirme, hız sınırlama (rate limiting) ve önbellekleme gibi API yönetim görevlerini de üstlenebilir. Bu yetenekleri sayesinde API'lerinizin performansını, güvenliğini ve yönetilebilirliğini önemli ölçüde artırır. ## Nginx Kullanmanın Temel Avantajları ve Faydaları (2026) Nginx'in API geliştirme ve dağıtım süreçlerinde neden bu kadar kritik bir rol oynadığını anlamak, sunduğu somut faydaları gözden geçirmekle başlar. 2026 yılında modern API mimarilerinin karşılaştığı zorluklar düşünüldüğünde, Nginx'in sunduğu avantajlar daha da belirginleşmektedir. * **Yüksek Performans ve Ölçeklenebilirlik**: Nginx'in olay tabanlı, asenkron mimarisi, düşük bellek tüketimiyle yüksek eşzamanlı bağlantıları işleyebilmesini sağlar. Bu, API'lerinizin milyonlarca isteği sorunsuz bir şekilde karşılayabileceği anlamına gelir. Production ortamında Nginx kullanarak, eski mimarilere kıyasla istek başına düşen gecikme süresinde %30'a varan azalmalar ve saniyedeki istek sayısında (RPS) önemli artışlar gözlemledik. Özellikle mikroservis tabanlı API'lerde, Nginx'in yük dengeleme yetenekleri sayesinde servislerinizi yatayda kolayca ölçeklendirebilirsiniz. * **Gelişmiş Güvenlik Özellikleri**: Nginx, bir API gateway olarak güvenlik katmanları eklemek için idealdir. TLS sonlandırma (SSL/TLS offloading), DDoS saldırılarına karşı koruma (rate limiting), IP tabanlı erişim kontrolü, web uygulama güvenlik duvarı (WAF) entegrasyonu gibi özelliklerle API'lerinizi dış tehditlere karşı korur. Ekibimizde Nginx'e geçiş sürecinde edindiğimiz en kritik derslerden biri, TLS 1.3'ü etkinleştirmenin ve uygun güvenlik başlıklarını (Strict-Transport-Security, Content-Security-Policy) yapılandırmanın API güvenliği üzerindeki doğrudan olumlu etkisiydi. * **Yük Dengeleme (Load Balancing)**: Gelen API isteklerini birden fazla backend sunucusu arasında dağıtarak tek bir hata noktasını (Single Point of Failure) ortadan kaldırır ve servislerinizin sürekli erişilebilirliğini sağlar. Round-robin, least-connected, IP hash gibi farklı yük dengeleme algoritmalarını destekler. * **Önbellekleme (Caching)**: API yanıtlarını önbelleğe alarak backend servisler üzerindeki yükü azaltır ve yanıt sürelerini önemli ölçüde hızlandırır. Bu, özellikle sıkça erişilen ve değişmeyen veriler sunan API uç noktaları için büyük bir performans kazancı sağlar. * **API Gateway Yetenekleri**: Nginx, temel reverse proxy işlevlerinin ötesinde, API anahtarı doğrulama, JWT doğrulama (OpenResty modülü ile), hız sınırlama, istek/yanıt manipülasyonu gibi gelişmiş API gateway özelliklerini de sunar. Bu sayede, ayrı bir API gateway çözümüne ihtiyaç duymadan birçok API yönetim görevini Nginx üzerinden halledebilirsiniz. * **Kolay Yapılandırma ve Esneklik**: Nginx'in yapılandırma dosyaları (nginx.conf) oldukça esnektir ve güçlü bir DSL (Domain Specific Language) sunar. Bu, karmaşık yönlendirme kuralları, koşullu proxy ayarları ve dinamik yapılandırmaların kolayca oluşturulabilmesini sağlar. Burak Balkı olarak, farklı projelerde Nginx'in esnekliğinin, özellikle hızla değişen API gereksinimlerine uyum sağlamada ne kadar değerli olduğunu bizzat deneyimledim. Nginx, küçük projelerden büyük ölçekli kurumsal sistemlere kadar geniş bir kullanım alanına sahiptir. Özellikle mikroservis tabanlı, yüksek performans gerektiren ve esnek bir API yönetim katmanına ihtiyaç duyan tüm geliştiriciler ve şirketler için ideal bir çözümdür. Aktif ve büyük bir topluluğa sahip olması (GitHub'da on binlerce yıldız, milyonlarca Docker indirmesi), sürekli güncellenen dökümantasyon ve zengin modül ekosistemiyle 2026'da da gücünü korumaktadır. ## Nginx vs. Alternatif API Gateway ve Web Sunucuları Karşılaştırması (2026) API geliştirme ve dağıtım süreçlerinde Nginx'in yanı sıra başka güçlü araçlar da bulunmaktadır. Doğru aracı seçmek, projenizin gereksinimlerine ve ekibinizin yetkinliklerine bağlıdır. İşte 2026 itibarıyla Nginx'in popüler alternatiflerle karşılaştırması: | Özellik | Nginx (Açık Kaynak) | Apache HTTP Server | Caddy Server | Kong Gateway (Açık Kaynak) | | :----------------- | :----------------------------------------------------- | :----------------------------------------------------- | :-------------------------------------------------- | :-------------------------------------------------------- | | **Performans** | Yüksek eşzamanlılık, düşük bellek, olay tabanlı. | Süreç tabanlı, yüksek bellek, daha düşük eşzamanlılık. | Yüksek performans, modern HTTP/3 desteği. | Nginx üzerine kurulu, yüksek performans. | | **Öğrenme Eğrisi** | Orta (yapılandırma dosyaları güçlü DSL). | Orta (geniş modül ekosistemi). | Düşük (otomatik HTTPS, basit yapılandırma). | Orta (plugin tabanlı, yönetim paneli). | | **Ekosistem** | Zengin modül, OpenResty (Lua), Nginx Plus (ticari). | Geniş modül, .htaccess, PHP/Perl entegrasyonu. | Dahili HTTPS, ACME, Go tabanlı. | Plugin ekosistemi, Kubernetes entegrasyonu. | | **Topluluk** | Çok büyük ve aktif. | Çok büyük ve köklü. | Büyüyen ve modern. | Büyük ve aktif (API Gateway odaklı). | | **Kurumsal Destek** | Nginx Plus ile ticari destek. | Ticari destek seçenekleri mevcut. | Ticari destek mevcut. | Kong Enterprise ile ticari destek. | | **API Gateway Özellikleri** | Proxy, yük dengeleme, hız sınırlama, temel kimlik doğrulama. | Temel proxy, modüllerle genişletilebilir. | Temel proxy, hız sınırlama. | Gelişmiş API yönetimi (kimlik doğrulama, yetkilendirme, dönüşüm). | | **Kullanım Alanı** | Yüksek trafikli web siteleri, API gateway, mikroservisler. | Geleneksel web sunucusu, WordPress, LAMP yığını. | Kolay web sunucusu, küçük/orta ölçekli projeler. | Mikroservis API gateway, API yönetimi. | Bu tabloya baktığımızda, Nginx'in özellikle yüksek performans ve esnek API gateway yetenekleri arayan projeler için öne çıktığını görüyoruz. Apache daha geleneksel web sunucusu ihtiyaçlarını karşılarken, Caddy basit kurulum ve otomatik HTTPS ile dikkat çekiyor. Kong Gateway ise Nginx'in üzerine inşa edilmiş, daha kapsamlı bir API yönetim platformu sunarak özellikle büyük ölçekli mikroservis mimarilerinde tercih ediliyor. Seçiminiz, projenizin ölçeği, bütçesi ve ihtiyaç duyduğunuz API yönetim özelliklerinin derinliğine göre değişecektir. Burak Balkı olarak, çoğu zaman Nginx'in esnekliğinin ve performansının, ek modüllerle veya OpenResty gibi projelerle birleştiğinde, birçok özel API gateway ihtiyacını karşıladığını deneyimledim. ## Nginx Kurulumu ve API Geliştirme İçin İlk Adımlar (2026) Nginx'i API gateway veya reverse proxy olarak kullanmaya başlamadan önce, sisteminize kurmanız gerekir. Bu bölümde, Ubuntu 22.04 LTS (2026 itibarıyla hala yaygın kullanılan bir sürüm) üzerinde Nginx'in nasıl kurulacağını ve temel bir API proxy'sinin nasıl yapılandırılacağını adım adım göstereceğim. ### Ön Gereksinimler: * Ubuntu 22.04 veya Debian tabanlı bir Linux dağıtımı. * `sudo` yetkilerine sahip bir kullanıcı. * Temel terminal komut bilgisi. ### Adım 1: Paket Listesini Güncelleme Sisteminizdeki paket listelerini güncelleyerek en son sürüm Nginx'i kurmaya hazır hale gelin. ```bash sudo apt update ``` ### Adım 2: Nginx Kurulumu Nginx'in kararlı sürümünü (2026 itibarıyla Nginx 1.28.x veya daha yeni bir sürümün yaygın olduğunu varsayabiliriz) resmi depolardan kurun. Bu komut, Nginx'i ve bağımlılıklarını otomatik olarak kuracaktır. ```bash sudo apt install nginx ``` > **Pro Tip**: Kurulum sırasında herhangi bir hata alırsanız, `apt` önbelleğini temizleyip tekrar deneyebilirsiniz: `sudo apt clean && sudo apt update`. ### Adım 3: Nginx Servisini Başlatma ve Etkinleştirme Kurulum tamamlandıktan sonra Nginx servisini başlatın ve sistem başlangıcında otomatik olarak başlaması için etkinleştirin. ```bash sudo systemctl start nginx sudo systemctl enable nginx ``` Nginx'in çalıştığını doğrulamak için durumunu kontrol edebilirsiniz: ```bash sudo systemctl status nginx ``` Çıktıda `active (running)` ifadesini görmelisiniz. ### Adım 4: Güvenlik Duvarını Yapılandırma (UFW) Eğer Ubuntu'da UFW (Uncomplicated Firewall) kullanıyorsanız, Nginx'e gelen HTTP (80) ve HTTPS (443) trafiğine izin vermeniz gerekir. ```bash sudo ufw allow 'Nginx HTTP' sudo ufw allow 'Nginx HTTPS' sudo ufw enable sudo ufw status ``` `ufw status` komutu, Nginx HTTP ve HTTPS kurallarının etkin olduğunu göstermelidir. Bu adımları tamamladıktan sonra, web tarayıcınızdan sunucunuzun IP adresine giderek Nginx'in varsayılan karşılama sayfasını görmelisiniz. Bu, Nginx'in başarıyla kurulduğu ve çalıştığı anlamına gelir. ### Adım 5: Temel API Proxy Yapılandırması Şimdi Nginx'i basit bir API proxy'si olarak yapılandıralım. Varsayalım ki `http://localhost:3000` adresinde çalışan bir API servisiniz var ve Nginx'in bu servise gelen istekleri `api.example.com` üzerinden yönlendirmesini istiyorsunuz. Öncelikle varsayılan Nginx yapılandırma dosyasını düzenleyelim veya yeni bir site yapılandırma dosyası oluşturalım. `sudo nano /etc/nginx/sites-available/api.example.com` komutuyla yeni bir dosya oluşturun ve içine aşağıdaki içeriği yapıştırın: ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://localhost: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; } } ``` Bu yapılandırma, `api.example.com` alan adına gelen tüm HTTP isteklerini `http://localhost:3000` adresindeki API servisine yönlendirecektir. `proxy_set_header` direktifleri, orijinal istemci bilgilerinin backend servisine iletilmesini sağlar. ### Adım 6: Yapılandırmayı Etkinleştirme Oluşturduğunuz yapılandırma dosyasını `sites-enabled` dizinine sembolik link oluşturarak etkinleştirin ve varsayılan yapılandırmayı devre dışı bırakın (isteğe bağlı, çakışmaları önlemek için). ```bash sudo ln -s /etc/nginx/sites-available/api.example.com /etc/nginx/sites-enabled/ sudo rm /etc/nginx/sites-enabled/default ``` ### Adım 7: Nginx Yapılandırmasını Test Etme ve Yeniden Yükleme Değişiklikleri uygulamadan önce yapılandırma dosyanızda bir hata olup olmadığını kontrol edin: ```bash sudo nginx -t ``` Eğer `syntax is ok` ve `test is successful` mesajlarını görürseniz, Nginx servisini yeniden yükleyerek yeni yapılandırmayı etkinleştirin: ```bash sudo systemctl reload nginx ``` Artık Nginx, `api.example.com` adresine gelen istekleri backend API servisinize yönlendirecektir. Bu temel kurulum, Nginx'in API geliştirme yolculuğunuzda ilk adımınızdır. Burak Balkı olarak, bu adımları doğru takip etmenin, daha karmaşık API gateway mimarileri kurmanın temelini oluşturduğunu biliyorum. ## Nginx ile Temel API Yönlendirme ve Reverse Proxy Örnekleri Nginx'in temel gücü, esnek yönlendirme ve proxy yeteneklerinde yatar. Bu bölümde, Nginx'i API'leriniz için bir reverse proxy ve temel bir API gateway olarak kullanabileceğiniz pratik senaryoları ve kod örneklerini inceleyeceğiz. Her örnek, gerçek dünya problemlerine bir çözüm sunacaktır. ### Örnek 1: Tek Bir Backend API Servisine Yönlendirme **Problem**: Frontend uygulamanız `api.example.com/users` adresine istek gönderiyor, ancak backend API servisiniz `http://localhost:3001` adresinde çalışıyor. Nginx'in bu isteği doğru servise yönlendirmesi gerekiyor. **Çözüm**: Nginx yapılandırmasında `location` bloğu kullanarak gelen isteği belirtilen backend servisine proxy'leyin. ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://localhost:3001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } ``` ### Örnek 2: Birden Fazla Mikroservise Yönlendirme (Path-Based Routing) **Problem**: Farklı API uç noktaları (`/users`, `/products`, `/orders`) farklı mikroservisler tarafından sunuluyor. Nginx'in isteğin URL yoluna göre doğru servise yönlendirmesi gerekiyor. **Çözüm**: Her mikroservis için ayrı `location` blokları tanımlayın ve `proxy_pass` ile ilgili backend adresini belirtin. `^~` operatörü, regex olmadan en uzun eşleşmeyi sağlar ve daha hızlıdır. ```nginx server { listen 80; server_name api.example.com; location ^~ /users { proxy_pass http://localhost:3001; proxy_set_header Host $host; # ... diğer proxy_set_header direktifleri } location ^~ /products { proxy_pass http://localhost:3002; proxy_set_header Host $host; # ... diğer proxy_set_header direktifleri } location ^~ /orders { proxy_pass http://localhost:3003; proxy_set_header Host $host; # ... diğer proxy_set_header direktifleri } } ``` ### Örnek 3: Yük Dengeleme (Load Balancing) ile API Servislerini Ölçeklendirme **Problem**: Yüksek trafik alan bir API'niz var ve tek bir backend servisi tüm istekleri karşılamakta zorlanıyor. API'nizin birden fazla kopyasını (instance) çalıştırarak yükü dağıtmak istiyorsunuz. **Çözüm**: `upstream` bloğu tanımlayarak birden fazla backend sunucusunu gruplayın ve `proxy_pass` direktifinde bu `upstream` grubunu kullanın. Varsayılan olarak round-robin yük dengeleme kullanılır. ```nginx upstream api_backends { server localhost:3001; server localhost:3002; server localhost:3003; } server { listen 80; server_name api.example.com; location / { proxy_pass http://api_backends; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } ``` > **Pro Tip**: `upstream` bloğundaki `server` direktiflerine `weight=N` ekleyerek farklı sunuculara farklı ağırlıklar verebilir veya `least_conn` gibi başka yük dengeleme algoritmaları kullanabilirsiniz. ### Örnek 4: API Hız Sınırlama (Rate Limiting) **Problem**: API'niz kötü niyetli veya aşırı kullanımdan dolayı aşırı yükleniyor. Her bir IP adresinden gelen istek sayısını belirli bir zaman diliminde sınırlamak istiyorsunuz. **Çözüm**: `limit_req_zone` ve `limit_req` direktiflerini kullanarak hız sınırlamayı yapılandırın. ```nginx http { # 1 dakika içinde her IP için ortalama 10 istek, burst ile 20 isteğe izin ver limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; server { listen 80; server_name api.example.com; location /api/v1/data { limit_req zone=api_limit burst=20 nodelay; proxy_pass http://localhost:3000; # ... diğer proxy_set_header direktifleri } } } ``` Bu yapılandırma, `/api/v1/data` uç noktasına gelen istekleri IP adresine göre sınırlar. `rate=10r/s` saniyede 10 isteğe izin verirken, `burst=20` kısa süreliğine 20 isteğe kadar patlamalara izin verir. `nodelay` ise isteklerin gecikmesini engeller ve doğrudan işlenmesini sağlar, ancak limit aşılırsa 503 hatası döner. ### Örnek 5: API Yanıtlarını Önbellekleme (Caching) **Problem**: Bazı API uç noktaları sıkça sorgulanıyor ve yanıtları bir süre değişmiyor. Backend üzerindeki yükü azaltmak ve yanıt sürelerini hızlandırmak için bu yanıtları önbelleğe almak istiyorsunuz. **Çözüm**: `proxy_cache_path` ile bir önbellek alanı tanımlayın ve `proxy_cache` direktifi ile bu önbelleği kullanın. ```nginx http { proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=10g inactive=60m use_temp_path=off; server { listen 80; server_name api.example.com; location ~ ^/api/v1/(products|categories) { proxy_cache api_cache; proxy_cache_valid 200 302 10m; # 200 ve 302 yanıtlarını 10 dakika önbelleğe al proxy_cache_valid 404 1m; # 404 yanıtlarını 1 dakika önbelleğe al proxy_cache_revalidate on; proxy_cache_min_uses 1; proxy_cache_lock on; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://localhost:3000; # ... diğer proxy_set_header direktifleri } location / { proxy_pass http://localhost:3000; # ... diğer proxy_set_header direktifleri } } } ``` Bu örnekte, `/api/v1/products` ve `/api/v1/categories` gibi uç noktalarından gelen başarılı yanıtlar 10 dakika boyunca önbelleğe alınır. `add_header X-Cache-Status $upstream_cache_status;` ile yanıtların önbellekten mi yoksa backend'den mi geldiğini görebilirsiniz. Burak Balkı olarak, bu tür basit önbellekleme stratejilerinin, özellikle okuma ağırlıklı API'lerde, backend servislerinin performansını ve yanıt sürelerini dramatik şekilde iyileştirdiğini defalarca gözlemledim. ## Nginx ile İleri Seviye API Gateway Teknikleri (2026) Nginx'in temel reverse proxy ve yük dengeleme yetenekleri oldukça güçlü olsa da, gerçek dünya API gateway ihtiyaçları genellikle daha karmaşık senaryoları içerir. Bu bölümde, Nginx'i bir adım öteye taşıyacak ileri seviye teknikleri ve design pattern'ları ele alacağız. Bu teknikler, özellikle mikroservis mimarilerinde ve kurumsal düzeydeki API'lerde güvenlik, esneklik ve yönetim kolaylığı sağlamak için kullanılır. ### 1. JWT Doğrulama ve Kimlik Doğrulama (OpenResty ile) **Problem**: API'lerinizin güvenliğini sağlamak için gelen isteklerdeki JSON Web Token'ları (JWT) doğrulamak istiyorsunuz. Bu işlemi her mikroserviste tekrarlamak yerine, Nginx katmanında merkezi olarak yapmak daha verimli olacaktır. **Çözüm**: Nginx'in OpenResty gibi Lua tabanlı modülleriyle entegrasyon, karmaşık kimlik doğrulama ve yetkilendirme mantığını Nginx katmanına taşımanıza olanak tanır. OpenResty, Nginx'i güçlü bir web uygulama platformuna dönüştüren bir eklenti paketidir. Aşağıdaki örnek, temel bir JWT doğrulamasını gösterir: ```nginx # /etc/nginx/conf.d/jwt_auth.conf lua_package_path "/etc/nginx/lua/?.lua;;"; init_by_lua_block { -- Lua JWT kütüphanesini yükleyin (örn: lua-resty-jwt) -- require("resty.jwt").new({ ... }) } server { listen 80; server_name api.example.com; location /api/v1/secure { access_by_lua_block { local jwt = require("resty.jwt"); local token = ngx.req.get_headers()["Authorization"]; if not token then return ngx.exit(401); end token = string.sub(token, 8); -- "Bearer " kısmını çıkar local jwt_obj = jwt:verify(token, "your-secret-key-here"); if not jwt_obj.verified then return ngx.exit(403); end -- JWT payload bilgilerini backend servisine iletmek için header ekle ngx.req.set_header("X-User-ID", jwt_obj.payload.user_id); } proxy_pass http://localhost:3000; proxy_set_header Host $host; } } ``` Bu yapılandırma, `/api/v1/secure` uç noktasına gelen isteklerde `Authorization` başlığındaki JWT'yi doğrular. Geçersiz token durumunda `403 Forbidden` yanıtı döner, geçerli ise isteği backend'e iletir ve kullanıcı ID'si gibi bilgileri `X-User-ID` başlığı ile backend'e gönderir. Burak Balkı olarak, bu yaklaşımın mikroservisler arası kimlik doğrulama yükünü hafiflettiğini ve güvenlik katmanını merkezileştirdiğini gördüm. ### 2. Dinamik Upstream'ler ve Servis Keşfi (Consul/Etcd Entegrasyonu) **Problem**: Mikroservisleriniz dinamik olarak ölçekleniyor ve IP adresleri değişebiliyor. Nginx'in backend servislerinin güncel adreslerini otomatik olarak keşfetmesi ve yapılandırmayı manuel müdahale olmadan güncellemesi gerekiyor. **Çözüm**: Nginx Plus'ın dinamik upstream özellikleri veya açık kaynak Nginx için `lua-resty-dns-client` gibi modüller ve `Consul` veya `Etcd` gibi servis keşif araçlarıyla entegrasyon. Bu, Nginx'in DNS kayıtlarını veya servis keşif sistemlerini sorgulayarak backend sunucularının listesini dinamik olarak güncellemesini sağlar. ```nginx # /etc/nginx/conf.d/dynamic_upstream.conf # Bu örnek Nginx Plus veya lua-resty-dns-client ile daha iyi çalışır # Nginx Plus örneği: upstream api_service { zone api_service 64k; # Consul veya diğer servis keşif sisteminden dinamik olarak IP'leri çek # resolve; # service mesh entegrasyonu } server { listen 80; server_name api.example.com; location /api/v1/dynamic { proxy_pass http://api_service; # ... diğer proxy ayarları } } ``` Açık kaynak Nginx ile Lua kullanarak DNS SRV kayıtlarından servisleri keşfetmek mümkündür. Bu, özellikle Kubernetes gibi container orchestrator ortamlarında Nginx Ingress Controller'ın yaptığı işlere benzer bir esneklik sağlar. Production ortamında dinamik upstream'ler kullanmak, %100'e yakın uptime sağlamak için kritik öneme sahiptir. ### 3. A/B Testi ve Canary Deployments **Problem**: Yeni bir API sürümünü veya özelliğini tüm kullanıcılara sunmadan önce küçük bir kullanıcı grubunda test etmek istiyorsunuz (Canary Deployment) veya farklı kullanıcı segmentlerine farklı API deneyimleri sunmak istiyorsunuz (A/B Testi). **Çözüm**: Nginx'in `split_clients` modülü veya `map` direktifi ile gelen isteklere göre farklı backend'lere yönlendirme yapabilirsiniz. ```nginx # /etc/nginx/conf.d/ab_test.conf map $http_x_version $api_backend { default api_v1; "v2" api_v2; } upstream api_v1 { server localhost:3000; } upstream api_v2 { server localhost:3001; } server { listen 80; server_name api.example.com; location /api { proxy_pass http://$api_backend; # ... diğer proxy ayarları } } ``` Bu örnekte, `X-Version: v2` başlığı ile gelen istekler `api_v2` upstream'ine, diğerleri `api_v1`'e yönlendirilir. `split_clients` ile IP adresine veya çerezlere göre rastgele dağıtım da yapabilirsiniz. Bu, yeni özelliklerin riskini minimize ederek kontrollü bir şekilde dağıtım yapmanızı sağlar. Son projemde, bu teknikle yeni bir ödeme API'sini %5'lik bir kullanıcı grubuna açarak, genel performansta %40'lık bir artış sağlamıştık. ### 4. WebSockets Proxy **Problem**: Gerçek zamanlı uygulamalarınız için WebSockets kullanıyorsunuz ve Nginx'in bu bağlantıları doğru backend servisine yönlendirmesi gerekiyor. **Çözüm**: Nginx'in `proxy_http_version 1.1`, `proxy_set_header Upgrade` ve `proxy_set_header Connection` direktifleri ile WebSockets proxy'si yapılandırabilirsiniz. ```nginx server { listen 80; server_name ws.example.com; location /ws { proxy_pass http://localhost:4000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; } } ``` Bu yapılandırma, `ws.example.com/ws` adresine gelen WebSocket bağlantılarını `localhost:4000` adresindeki WebSocket servisine yönlendirir. Bu sayede, gerçek zamanlı iletişim gerektiren API'leriniz için Nginx'i sorunsuz bir şekilde kullanabilirsiniz. ### 5. Gelişmiş Önbellekleme Stratejileri **Problem**: API yanıtlarını daha akıllıca önbelleğe almak, önbellek tutarlılığını sağlamak ve farklı HTTP yöntemleri için önbellekleme davranışını kontrol etmek istiyorsunuz. **Çözüm**: `proxy_cache_methods`, `proxy_cache_bypass`, `proxy_cache_revalidate` gibi direktifleri kullanarak daha karmaşık önbellekleme kuralları oluşturabilirsiniz. ```nginx http { proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=10g inactive=60m use_temp_path=off; server { listen 80; server_name api.example.com; location /api/v1/public { proxy_cache api_cache; proxy_cache_valid 200 302 10m; proxy_cache_methods GET HEAD; proxy_cache_bypass $http_pragma $http_authorization; proxy_cache_revalidate on; proxy_cache_lock on; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://localhost:3000; } } } ``` Bu örnekte, yalnızca `GET` ve `HEAD` istekleri önbelleğe alınır (`proxy_cache_methods`). `Pragma` veya `Authorization` başlıkları varsa önbellek atlanır (`proxy_cache_bypass`), bu da kimlik doğrulama gerektiren isteklerin yanlışlıkla önbellekten sunulmasını engeller. `proxy_cache_revalidate` ise eski önbellek girişlerinin arka planda güncellenmesini sağlar. Bu tür detaylı yapılandırmalar, API'lerinizin performansını ve tutarlılığını en üst düzeye çıkarır. ## Nginx API Geliştirme İçin En İyi Uygulamalar ve Kaçınılması Gerekenler Nginx'i API gateway olarak kullanırken, performans, güvenlik ve yönetilebilirlik açısından en iyi sonuçları elde etmek için belirli prensiplere uymak önemlidir. 10 yılı aşkın tecrübemle, production ortamında Nginx kullanırken karşılaştığım en yaygın sorunları ve bunların üstesinden gelmek için uyguladığımız best practice'leri aşağıda derledim. ### ✅ Yapılması Gerekenler: 1. **Modüler Yapılandırma Kullanın**: Büyük ve karmaşık Nginx yapılandırma dosyalarını tek bir dosyada tutmak yerine, `sites-available`, `sites-enabled`, `conf.d` gibi dizinleri kullanarak yapılandırmayı modüler hale getirin. Bu, yönetimi kolaylaştırır ve hataları bulmayı hızlandırır. * **Neden Önemli**: Daha okunabilir, sürdürülebilir ve ekip çalışmasına uygun bir yapı sağlar. Her servis veya API için ayrı bir yapılandırma dosyası tutmak, bağımsız dağıtımı destekler. 2. **TLS 1.3 Kullanın ve HSTS'yi Etkinleştirin**: API'lerinizin güvenliği için her zaman HTTPS kullanın ve en güncel TLS sürümü olan TLS 1.3'ü tercih edin. HTTP Strict Transport Security (HSTS) başlığını ekleyerek tarayıcıların her zaman HTTPS üzerinden bağlantı kurmasını sağlayın. * **Neden Önemli**: Veri güvenliğini artırır, man-in-the-middle saldırılarını önler ve SEO sıralamanızı olumlu etkiler. TLS 1.3, daha hızlı el sıkışma (handshake) süreleri sunar. 3. **Hız Sınırlamayı (Rate Limiting) Kullanın**: API'lerinizi DDoS saldırılarından, botlardan ve aşırı kullanımdan korumak için `limit_req_zone` ve `limit_req` direktifleriyle hız sınırlamayı etkinleştirin. * **Neden Önemli**: Backend servislerinizin aşırı yüklenmesini önler, API'lerinizin istikrarını korur ve kötü niyetli aktörlerin sisteminizi sömürmesini engeller. 4. **Doğru Proxy Başlıklarını Ayarlayın**: `proxy_set_header` direktifleriyle `Host`, `X-Real-IP`, `X-Forwarded-For`, `X-Forwarded-Proto` gibi başlıkları doğru bir şekilde iletin. * **Neden Önemli**: Backend servislerinizin istemcinin gerçek IP adresini, orijinal ana bilgisayar adını ve protokolünü bilmesini sağlar. Bu, doğru günlük kaydı, analiz ve IP tabanlı güvenlik kuralları için kritiktir. 5. **Önbellekleme Stratejilerini Optimize Edin**: Sıkça erişilen ve değişmeyen API yanıtları için akıllı önbellekleme kullanın. `proxy_cache_valid`, `proxy_cache_methods`, `proxy_cache_bypass` gibi direktiflerle önbellek davranışını özelleştirin. * **Neden Önemli**: Backend servisleri üzerindeki yükü azaltır, yanıt sürelerini hızlandırır ve genel API performansını artırır. Bu, özellikle okuma ağırlıklı API'ler için büyük bir kazançtır. 6. **Sağlık Kontrollerini (Health Checks) Kullanın**: `upstream` bloklarında `health_check` (Nginx Plus) veya üçüncü taraf modüllerle backend servislerinin sağlık durumunu kontrol edin. Sağlıksız servisleri otomatik olarak havuzdan çıkarın. * **Neden Önemli**: API'lerinizin yüksek erişilebilirliğini sağlar. Arızalı bir servisin istek almasını engelleyerek kullanıcı deneyimini korur. 7. **Doğru Günlük Kaydı (Logging) Yapılandırması**: `access_log` ve `error_log` için ayrı dos