Web uygulamalarınızın performansı ve güvenliği, sunucu yapılandırmanızla doğrudan ilişkilidir. Özellikle yüksek trafikli sitelerde, Nginx gibi güçlü bir web sunucusunun doğru yapılandırılması hayati önem taşır. Peki, Nginx gelen bir isteği hangi location bloğuna yönlendireceğine nasıl karar verir? Bu karmaşık seçim algoritmasını anlamak, sitenizin hızını artırmak, güvenlik açıklarını kapatmak ve bakım süreçlerini kolaylaştırmak için kritik bir adımdır. Bu makale, Nginx’in konum bloğu seçim mekanizmalarını derinlemesine inceleyerek, bu süreçteki gizem perdesini aralayacak ve size pratik uygulamalarla yol gösterecek.
Nginx Nedir ve Konum Blokları Neden Bu Kadar Önemli? (Giriş ve Temel Kavramlar)
Nginx (Engine-X olarak okunur), açık kaynaklı, yüksek performanslı bir HTTP ve ters proxy sunucusu, posta proxy sunucusu ve genel bir TCP/UDP proxy sunucusudur. Yüksek eşzamanlı bağlantıları işleme yeteneği ve düşük bellek tüketimi sayesinde, modern web altyapılarının vazgeçilmez bir parçası haline gelmiştir. Facebook, Netflix ve WordPress gibi devasa platformlar bile altyapılarında Nginx’i kullanmaktadır. Geleneksel sunucuların aksine, Nginx olay tabanlı (event-driven) ve asenkron bir mimariye sahiptir. Bu mimari, aynı anda binlerce isteği verimli bir şekilde yönetmesini sağlar, bu da onu özellikle yüksek trafikli web siteleri ve uygulamalar için ideal kılar.
Peki, Nginx’in bu kadar etkili olmasını sağlayan temel bileşenlerden biri nedir? Cevap: konum blokları (location blocks). Nginx yapılandırma dosyasındaki bu bloklar, gelen URL isteklerinin belirli bir yol veya kalıpla eşleştiğinde nasıl işleneceğini tanımlar. Örneğin, bir web sitesi düşünün; statik dosyalar (CSS, JavaScript, resimler) belirli bir klasörden sunulurken, dinamik içerik (PHP, Python, Node.js uygulamaları) başka bir sunucuya veya uygulama yorumlayıcısına yönlendirilebilir. Nginx, bu farklı istekleri doğru yere yönlendirmek için location bloklarını kullanır. Her bir location bloğu, belirli bir URL yoluna veya düzenli ifadeye (regex) göre kurallar belirler. Bu kurallar, isteğin hangi kök dizinden servis edileceğini, hangi proxy sunucusuna iletileceğini, hangi önbellekleme politikalarının uygulanacağını veya hangi HTTP başlıklarının ekleneceğini içerebilir.
Konum bloklarının önemi sadece yönlendirme ile sınırlı değildir. Aynı zamanda güvenlik, performans ve ölçeklenebilirlik açısından da kritik rol oynarlar. Yanlış yapılandırılmış bir location bloğu, uygulamanızın hassas dosyalarını açığa çıkarabilir veya performans düşüşlerine neden olabilir. Öte yandan, iyi optimize edilmiş bir location bloğu, statik içeriği hızla sunarak sunucu yükünü azaltır, dinamik içeriği doğru uygulama sunucularına yönlendirir ve hatta kötü niyetli istekleri engelleyebilir. Bu nedenle, Nginx’in bir isteği birden fazla location bloğu arasından nasıl seçtiğini anlamak, her Nginx yöneticisi için temel bir yetkinliktir. Bu algoritmalar, karmaşık web uygulamalarının sorunsuz çalışmasını sağlayan görünmez bir orkestrasyon görevi görür. Önümüzdeki bölümlerde, bu algoritmaların derinliklerine inecek ve gerçek dünya senaryolarıyla nasıl çalıştıklarını detaylı bir şekilde inceleyeceğiz.
Konum Bloğu Eşleştirme Algoritmaları Nasıl Çalışır? (Temel Seçim Mantığı)
Nginx, gelen bir HTTP isteğini işlerken, URL yolunu (URI) yapılandırma dosyasındaki server bloğu içinde tanımlanmış location bloklarıyla eşleştirmeye çalışır. Bu eşleştirme süreci belirli bir sıra ve öncelik hiyerarşisine göre gerçekleşir. Bu hiyerarşiyi anlamak, beklendiği gibi çalışan ve performanslı bir Nginx yapılandırması oluşturmanın anahtarıdır. Nginx, eşleşme için dört ana türde konum bloğu tanımlayıcısı kullanır: tam eşleşme (=), prefix eşleşme (^~ veya modifiyesiz), düzenli ifade eşleşmeleri (~ ve ~*). Bu türler, belirli bir sıraya göre değerlendirilir ve ilk eşleşen bloğun bulunması durumunda işlem durdurulabilir veya devam edebilir.
Nginx’in eşleştirme algoritması temel olarak şu adımları izler:
- Tam Eşleşme (
=): Nginx öncelikle URL’yi tam olarak eşleşen birlocationbloğu arar. Eğer tam bir eşleşme bulunursa, bu blok hemen seçilir ve başka hiçbir arama yapılmaz. Bu, en yüksek önceliğe sahip eşleşme türüdür ve genellikle kök dizin (/) veya belirli, sabit URL’ler için kullanılır. - Prefix Eşleşmeleri (
^~ve Modifiyesiz): Eğer tam eşleşme bulunamazsa, Nginx prefix (ön ek) eşleşmelerini değerlendirir.^~(Prefix Eşleşme, Düzenli İfade Aramasını Durdur): Bu modifiyeli prefix eşleşmesi, eğer bir eşleşme bulunursa, Nginx’in düzenli ifade (regex) tabanlılocationbloklarını aramayı durdurmasını sağlar. Bu, genellikle statik dosyaların sunulduğu veya belirli bir yolun regex kontrolünden muaf tutulması gereken durumlarda kullanılır. Eğer bir^~bloğu eşleşirse, bu blok seçilir ve düzenli ifade araması atlanır.- Modifiyesiz Prefix Eşleşmesi: Eğer
^~ile bir eşleşme bulunamazsa veya^~bloğu yoksa, Nginx modifiyesiz prefix eşleşmelerini değerlendirir. Bu tür eşleşmeler, URL’nin başlangıcının belirtilen yol ile eşleşip eşleşmediğine bakar. Nginx, en uzun eşleşen prefix bloğunu seçer. Ancak bu eşleşme, geçici bir eşleşmedir ve düzenli ifade eşleşmelerinin potansiyel olarak daha yüksek önceliğe sahip olabileceği göz önünde bulundurularak, arama düzenli ifade bloklarıyla devam eder.
- Düzenli İfade Eşleşmeleri (
~ve~*): Prefix eşleşmelerinden sonra (^~ile durdurulmadığı sürece), Nginx düzenli ifade eşleşmelerini değerlendirir.~(Büyük/Küçük Harf Duyarlı Regex): Bu modifikatör, URL’nin belirtilen düzenli ifadeyle büyük/küçük harf duyarlı bir şekilde eşleşip eşleşmediğini kontrol eder.~*(Büyük/Küçük Harf Duyarsız Regex): Bu modifikatör, büyük/küçük harf duyarsız bir düzenli ifade eşleşmesi yapar.
Nginx, yapılandırma dosyasında ilk tanımlanan düzenli ifade eşleşmesini seçer. Yani, birden fazla regex bloğu eşleşiyorsa, dosyada yukarıda olan kazanır.
- Son Çare Prefix Eşleşmesi: Eğer yukarıdaki hiçbir eşleşme bulunamazsa, Nginx daha önce geçici olarak seçilen en uzun modifiyesiz prefix eşleşmesini kullanır. Bu, genellikle kök dizin (
/) için tanımlanan varsayılan birlocationbloğu olur.
Bu sıralama, Nginx’in esnekliğini ve gücünü ortaya koyar. Doğru eşleşme türünü doğru yerde kullanmak, hem performansı optimize eder hem de beklenmedik yönlendirmelerin önüne geçer. Örneğin, statik dosyalar için ^~ kullanmak, Nginx’in gereksiz yere düzenli ifade aramaları yapmasını engelleyerek CPU döngülerinden tasarruf etmesini sağlar. Dinamik veya karmaşık URL yapıları için ise düzenli ifadeler vazgeçilmezdir. Şimdi, bu eşleşme türlerini daha yakından inceleyelim ve pratik örneklerle nasıl uygulandıklarını görelim.
= (Tam Eşleşme) ile Hızlı Yönlendirmeler Nasıl Yapılır?
Nginx’teki = modifikatörü, konum bloğu seçiminde en yüksek önceliğe sahiptir ve tam eşleşme için kullanılır. Bir isteğin URI’si, = ile tanımlanmış bir location bloğundaki yol ile tam olarak eşleşirse, Nginx hemen bu bloğu seçer ve başka hiçbir location bloğunu kontrol etmez. Bu durum, özellikle belirli bir URL’nin kesin ve hızlı bir şekilde işlenmesi gerektiğinde son derece faydalıdır. Örneğin, bir sitenin kök dizinine (/) yapılan istekler veya belirli bir dosya (/favicon.ico, /robots.txt) için özel kurallar tanımlamak istediğinizde bu modifikatör idealdir.
Tam eşleşmenin en büyük avantajı performanstır. Nginx, = ile eşleştiğinde algoritmayı durdurduğu için, gereksiz hesaplamalar ve diğer location bloklarının değerlendirilmesi atlanır. Bu da özellikle yüksek trafikli ortamlarda sunucu kaynaklarından tasarruf edilmesini sağlar ve yanıt sürelerini kısaltır. Genellikle, web sitelerinin ana sayfa istekleri veya sıkça istenen küçük statik dosyalar için bu modifikatör kullanılır.
İşte bir örnek:
server {
listen 80;
server_name example.com;
# Kök dizin için tam eşleşme
location = / {
root /var/www/html/public;
index index.html index.htm;
try_files $uri $uri/ =404;
}
# Favicon için tam eşleşme
location = /favicon.ico {
root /var/www/html/static;
expires 30d; # Favicon'u 30 gün önbellekle
log_not_found off; # Loglara bulunamadı hatası yazma
access_log off; # Erişim logu yazma
}
# Robots.txt için tam eşleşme
location = /robots.txt {
root /var/www/html/static;
expires 7d;
log_not_found off;
access_log off;
}
# Diğer tüm istekler için varsayılan prefix eşleşmesi
location / {
root /var/www/html/public;
try_files $uri $uri/ /index.php?$query_string; # PHP uygulaması için
}
}
Yukarıdaki örnekte:
location = /bloğu, tam olarakhttp://example.com/adresine yapılan istekleri yakalar. Bu, web sitenizin ana sayfasının hızlı bir şekilde sunulmasını sağlar.location = /favicon.icovelocation = /robots.txtblokları, sırasıyla/favicon.icove/robots.txtURL’lerine yapılan istekleri hedefler. Bu dosyalar genellikle küçüktür ve sıkça istenir, bu nedenle tam eşleşme ile hızlı bir şekilde sunulmaları performansı artırır. Ayrıca,expiresyönergesi ile tarayıcı önbelleklemesi etkinleştirilir,log_not_found offveaccess_log offile gereksiz günlük kaydı engellenir.
Bu yaklaşım, özellikle statik dosyaların yoğun olduğu veya belirli URL’lerin özel işlem gerektirdiği senaryolarda performansı maksimize etmek için harikadır. Tam eşleşme, diğer daha karmaşık eşleşme türlerine geçmeden önce Nginx’in iş yükünü önemli ölçüde azaltır. Bu sayede sunucunuz daha verimli çalışır ve kullanıcılarınız daha hızlı yanıt süreleri deneyimler.
Uzman İpucu: Nginx’in işlem gücünden tasarruf etmek için, ana sayfa (/) ve sıkça istenen küçük, statik dosyalar (/favicon.ico, /robots.txt) için mutlaka = tam eşleşmesini kullanın. Bu, Nginx’in diğer eşleşmeleri aramayı durdurmasını sağlayarak performansı gözle görülür şekilde artırır.
^~ (Prefix Eşleşme) ile Regex Karmaşasından Nasıl Kaçılır?
^~ modifikatörü, Nginx’in konum bloğu seçim algoritmalarında özel bir yere sahiptir. Bu modifikatör, “eğer bu prefix (ön ek) eşleşirse, düzenli ifade (regex) tabanlı location bloklarını aramayı durdur” anlamına gelir. Başka bir deyişle, ^~ ile tanımlanmış bir blok, URL’nin başlangıcıyla eşleştiğinde, Nginx’in daha sonraki düzenli ifade eşleşmelerini (~ ve ~*) tamamen atlamasını sağlar. Bu, özellikle belirli bir URL yolunun altındaki tüm isteklerin, düzenli ifadelerin karmaşıklığına veya potansiyel performans maliyetine maruz kalmadan belirli bir şekilde işlenmesini istediğiniz durumlarda son derece faydalıdır.
Bu modifikatörün en yaygın kullanım alanı, statik dosyaların (resimler, CSS, JavaScript dosyaları, fontlar vb.) sunulmasıdır. Genellikle bu tür dosyalar belirli bir dizin altında bulunur (örneğin, /static/ veya /assets/). Bu dosyalar için düzenli ifade eşleşmelerine ihtiyaç duyulmaz ve hatta bunları regex kontrolünden muaf tutmak, performansı artırabilir. Çünkü düzenli ifade eşleşmeleri, prefix eşleşmelerine göre daha fazla CPU kaynağı tüketir.
İşte bir örnek:
server {
listen 80;
server_name example.com;
# Statik dosyalar için ^~ prefix eşleşmesi
location ^~ /static/ {
root /var/www/html; # /var/www/html/static/ yoluna eşleşir
expires 30d;
add_header Cache-Control "public, no-transform";
access_log off;
log_not_found off;
}
location ^~ /assets/ {
root /var/www/html; # /var/www/html/assets/ yoluna eşleşir
expires 30d;
add_header Cache-Control "public, no-transform";
access_log off;
log_not_found off;
}
# PHP dosyalarını işleyen regex bloğu
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
}
# Diğer tüm istekler için varsayılan blok
location / {
root /var/www/html/public;
index index.html index.htm index.php;
try_files $uri $uri/ /index.php?$query_string;
}
}
Bu örnekte:
location ^~ /static/bloğu,/static/ile başlayan tüm URL’leri eşleştirir (örneğin,/static/css/style.css,/static/images/logo.png). Nginx bu bloğu eşleştirdiğinde, daha sonra tanımlanmış olanlocation ~ \.php$gibi düzenli ifade bloklarını tamamen atlar. Bu, statik dosyaların hızlı ve verimli bir şekilde sunulmasını sağlar, gereksiz regex kontrollerini önler.- Benzer şekilde,
location ^~ /assets/bloğu da aynı mantıkla çalışır. - Eğer bir istek
/static/veya/assets/ile başlamıyorsa, Nginx diğer prefix eşleşmelerine ve ardından düzenli ifade eşleşmelerine bakar. Örneğin,/index.phpisteğilocation ~ \.php$bloğu tarafından yakalanacaktır.
^~ kullanmak, Nginx’in çalışma prensibini optimize etmenize olanak tanır. Statik içeriği dinamik içerikten ayırarak, her ikisi için de en uygun işleme yolunu belirlersiniz. Bu, sadece performansı artırmakla kalmaz, aynı zamanda yapılandırmanızın daha okunabilir ve yönetilebilir olmasına da yardımcı olur. Unutmayın, bu modifikatör, Nginx’in eşleşme algoritmasının akışını değiştiren güçlü bir araçtır ve doğru kullanıldığında önemli faydalar sağlar.
Düzenli İfadeler (~ ve ~*) ile Dinamik Yönlendirmeler Nasıl Oluşturulur? (Gelişmiş Eşleştirme)
Nginx’in konum blokları arasında en esnek ve güçlü eşleştirme yöntemlerinden biri düzenli ifadelerdir (regular expressions). ~ ve ~* modifikatörleri ile kullanılan düzenli ifadeler, URL yollarındaki karmaşık desenleri eşleştirmek, dinamik içerikleri yönlendirmek, URL’leri yeniden yazmak (rewrite) ve özel işleme kuralları uygulamak için vazgeçilmezdir. Ancak, bu güç beraberinde dikkatli bir kullanım gerektirir, zira yanlış veya verimsiz yazılmış düzenli ifadeler performans düşüşlerine neden olabilir.
~ (Büyük/Küçük Harf Duyarlı Düzenli İfade Eşleşmesi):
Bu modifikatör, URL’yi belirtilen düzenli ifadeyle büyük/küçük harf duyarlı bir şekilde eşleştirir. Örneğin, /image.jpg ile /Image.jpg farklı kabul edilir. Genellikle dosya uzantıları gibi belirli kalıpları eşleştirmek için kullanılır. Nginx, yapılandırma dosyasında ilk tanımlanan ve eşleşen ~ bloğunu seçer. Bu, düzenli ifade blokları arasında bir öncelik sırası olduğu anlamına gelir; dosyadaki konumları önemlidir.
~* (Büyük/Küçük Harf Duyarsız Düzenli İfade Eşleşmesi):
~* modifikatörü, ~ ile aynı işlevi görür ancak eşleştirme sırasında büyük/küçük harf farkını göz ardı eder. Bu, özellikle işletim sistemine veya uygulamanın URL yapısına bağlı olarak harf duyarlılığı farklılık gösterebilen durumlarda veya kullanıcıların URL’leri farklı şekillerde yazabileceği senaryolarda kullanışlıdır. Örneğin, /image.jpg ve /Image.JPG ikisi de aynı ~* bloğu tarafından yakalanabilir. Tıpkı ~ gibi, ilk tanımlanan eşleşen ~* bloğu seçilir.
Düzenli İfade Bloklarının Değerlendirilme Sırası:
Nginx, bir URL isteğini işlerken, tam eşleşmeler (=) ve ^~ prefix eşleşmelerinden sonra düzenli ifade bloklarına bakar. Birden fazla düzenli ifade bloğu eşleşiyorsa, Nginx yapılandırma dosyasında ilk tanımlanan (yani, yukarıdan aşağıya doğru ilk karşılaşılan) bloğu seçer. Bu, düzenli ifade bloklarını belirli bir öncelik sırasına göre düzenlemeniz gerektiği anlamına gelir. Daha spesifik veya öncelikli kurallar yukarıda yer almalıdır.
Pratik Uygulamalar ve Kod Örnekleri:
server {
listen 80;
server_name example.com;
# Statik dosyalar için ^~ önceliği (regex aramalarını durdurur)
location ^~ /static/ {
root /var/www/html;
expires 30d;
add_header Cache-Control "public, no-transform";
}
# Resim dosyalarını yakala (büyük/küçük harf duyarsız)
location ~* \.(jpg|jpeg|gif|png|webp|svg)$ {
root /var/www/html/images;
expires 30d;
add_header Cache-Control "public, no-transform";
# Görsel optimizasyon veya CDN yönlendirmesi yapılabilir
}
# PHP dosyalarını yakala (büyük/küçük harf duyarlı)
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
}
# Belirli bir API yolunu yakala ve proxy et
location ~ ^/api/v1/(users|products)/[0-9]+$ {
proxy_pass http://backend_api_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# JWT doğrulama veya rate limiting eklenebilir
}
# Tüm diğer istekler için varsayılan blok
location / {
root /var/www/html/public;
index index.html index.htm index.php;
try_files $uri $uri/ /index.php?$query_string;
}
}
Yukarıdaki örnekte:
location ^~ /static/bloğu, statik dosyaları regex araması yapmadan sunar. Bu, performansı artırır.location ~* \.(jpg|jpeg|gif|png|webp|svg)$bloğu, herhangi bir büyük/küçük harf kombinasyonuyla biten resim dosyalarını yakalar ve bunları/var/www/html/imagesdizininden sunar. Bu, medya dosyaları için özel önbellekleme ve başlık ayarları yapmanızı sağlar.location ~ \.php$bloğu,.phpile biten tüm istekleri PHP-FPM’ye yönlendirir. Bu blok büyük/küçük harf duyarlıdır, çünkü genellikle PHP dosya adları harf duyarlıdır.location ~ ^/api/v1/(users|products)/[0-9]+$bloğu, belirli bir API yol desenini eşleştirmek için daha karmaşık bir düzenli ifade kullanır. Bu,/api/v1/users/123veya/api/v1/products/456gibi istekleri backend API sunucusuna yönlendirir. Regex içindeki yakalama grupları (()) sayesinde, URL’nin belirli kısımlarını değişken olarak kullanmak mümkündür, bu da dinamik yönlendirmeler için çok önemlidir.
Düzenli ifadelerle çalışırken dikkatli olmak önemlidir. Çok geniş veya yanlış yazılmış bir regex, beklenmedik URL’leri eşleştirebilir veya sunucu kaynaklarını gereksiz yere tüketebilir. Düzenli ifadeleri test etmek için online araçlar kullanmak ve yapılandırma dosyalarınızı değiştirdikten sonra Nginx’i sudo nginx -t komutuyla test etmek iyi bir uygulamadır. Bu sayede olası hataların önüne geçebilir ve sunucunuzun istikrarlı çalışmasını sağlayabilirsiniz.
Uzman İpucu: Karmaşık düzenli ifadeler yerine, mümkün olduğunca prefix eşleşmelerini (^~ veya modifiyesiz) tercih edin. Düzenli ifadeler daha fazla CPU tüketir. Eğer regex kullanmanız gerekiyorsa, mümkün olduğunca spesifik olun ve gereksiz yakalama gruplarından kaçının.
Nginx Konum Bloğu Seçiminde En İyi Uygulamalar Nelerdir? (Performans ve Güvenlik İpuçları)
Nginx konum bloklarını doğru bir şekilde yapılandırmak, web uygulamanızın performansını, güvenliğini ve bakım kolaylığını doğrudan etkiler. Bu bölümde, Nginx yapılandırmalarınızı optimize etmek için uygulayabileceğiniz en iyi yöntemleri ve ipuçlarını ele alacağız. Bu uygulamalar, hem yeni başlayanlar hem de deneyimli yöneticiler için yol gösterici olacaktır.
Prioritizasyon Stratejileri ve Çakışan Kurallardan Kaçınma
Nginx’in eşleştirme algoritmasını anladıktan sonra, bloklarınızı bu öncelik sırasına göre düzenlemek kritik önem taşır. Genel kural şudur: en spesifik ve en yüksek öncelikli bloklar (=) en üste, ardından ^~ ile başlayan prefix eşleşmeleri, daha sonra düzenli ifadeler (~, ~*) ve en son olarak da genel prefix eşleşmeleri (/) gelmelidir. Bu sıralama, Nginx’in gereksiz kontroller yapmasını engeller ve doğru bloğun hızlıca seçilmesini sağlar.
# En yüksek öncelik: Tam eşleşmeler
location = /favicon.ico { ... }
location = /robots.txt { ... }
location = / { ... }
# Regex aramalarını durduran prefix eşleşmeleri (statik içerik için ideal)
location ^~ /static/ { ... }
location ^~ /assets/ { ... }
# Düzenli ifade eşleşmeleri (dosyada yukarıdan aşağıya öncelik)
location ~ \.php$ { ... }
location ~* \.(jpg|jpeg|png|gif)$ { ... }
location ~ ^/api/v1/ { ... }
# En düşük öncelik: Genel prefix eşleşmesi (varsayılan)
location / { ... }
Çakışan kurallardan kaçınmak için, özellikle düzenli ifadeleri dikkatli yazmalısınız. Bir URL’nin birden fazla regex bloğuyla eşleşmesi durumunda, Nginx dosyada ilk karşılaştığı regex bloğunu kullanır. Bu nedenle, daha spesifik regex kurallarını daha genel olanlardan önce tanımlamak önemlidir.
try_files Yönergesinin Akıllıca Kullanımı
try_files yönergesi, Nginx’in bir isteği işlerken birden fazla dosya veya dizin varlığını kontrol etmesini ve buna göre yanıt vermesini sağlayan güçlü bir araçtır. Genellikle dinamik uygulamalarda, bir dosya bulunamazsa isteği ana uygulama giriş noktasına yönlendirmek için kullanılır. Bu, özellikle URL rewrite işlemleri ve “temiz URL” yapıları için vazgeçilmezdir.
location / {
root /var/www/html/public;
index index.html index.htm index.php;
# Önce $uri'yi dosya olarak dene, sonra $uri'yi dizin olarak dene,
# eğer ikisi de bulunamazsa /index.php'ye yönlendir
try_files $uri $uri/ /index.php?$query_string;
}
Bu örnek, gelen bir isteğin önce kök dizinde bir dosya olarak aranmasını, sonra bir dizin olarak aranmasını ve eğer hiçbiri bulunamazsa isteği index.php‘ye yönlendirmesini sağlar. ?$query_string eklemek, orijinal sorgu parametrelerinin PHP uygulamasına iletilmesini sağlar.
Güvenlik İpuçları ve Hassas Dosyaların Korunması
Nginx konum blokları, web uygulamanızın güvenliğinde önemli bir rol oynar. Hassas dosyaların (örneğin, .env dosyaları, veritabanı yapılandırmaları, yedekler) doğrudan erişimini engellemek için özel bloklar kullanmalısınız.
# Gizli dosyaları engelle
location ~ /\.ht {
deny all;
}
location ~ /\.env {
deny all;
}
# Yedekleme dosyalarını engelle
location ~ \.(bak|sql|zip|tar\.gz)$ {
deny all;
}
Bu bloklar, .ht ile başlayan dosyaları (Apache .htaccess gibi), .env dosyalarını ve yaygın yedekleme dosyası uzantılarını dışarıdan erişime kapatır. deny all; yönergesi, bu dosyalara erişmeye çalışan tüm isteklere 403 Forbidden yanıtı döndürür.
Mobil Uyumluluk İçin Nginx Konfigürasyonu Nasıl Optimize Edilir?
Nginx doğrudan mobil uyumlu HTML üretmez veya medya sorgularını işlemez; bu, front-end geliştirmenin sorumluluğundadır. Ancak Nginx, mobil uyumlu deneyimi desteklemek için çeşitli optimizasyonlar yapabilir:
- Kullanıcı Aracısına Göre Yönlendirme (User-Agent Based Routing): Nginx, gelen isteğin
User-Agentbaşlığına bakarak farklı cihazlara farklı içerikler sunabilir. Örneğin, mobil cihazlar için daha hafif bir sürüm veya farklı bir API uç noktasına yönlendirme yapılabilir. Ancak bu yöntem, kullanıcı aracısı spoofing’ine karşı hassas olabilir ve bakımı zorlaşabilir. - Optimize Edilmiş Varlık Sunumu: Nginx, mobil cihazlar için optimize edilmiş resimleri (örneğin, WebP formatı) veya daha küçük JavaScript/CSS dosyalarını sunabilir. Bu,
locationblokları içindeUser-AgentveyaAcceptbaşlıklarına göre dinamik olarak yapılabilir. - Önbellekleme (Caching): Mobil ağ koşulları genellikle daha değişkendir. Nginx’in güçlü önbellekleme mekanizmaları, mobil kullanıcılar için içeriğin daha hızlı yüklenmesini sağlayabilir. Statik dosyalar için uzun
expiresbaşlıkları ve dinamik içerik içinproxy_cachekullanımı performansı artırır.
# Mobil cihazlar için farklı bir site köküne yönlendirme (Basit örnek, dikkatli kullanılmalı)
# if ($http_user_agent ~* "(android|blackberry|ipad|iphone|ipod|opera mini|palm|psp|series60|symbian|windows ce|mobile)") {
# set $mobile_site_root "/var/www/html/mobile";
# }
# else {
# set $mobile_site_root "/var/www/html/desktop";
# }
# location / {
# root $mobile_site_root;
# index index.html;
# }
# WebP resimleri için örnek (Accept başlığına göre)
location ~* \.(png|jpg|jpeg)$ {
set $webp_suffix "";
if ($http_accept ~* "webp") {
set $webp_suffix ".webp";
}
try_files $uri$webp_suffix $uri =404;
# root ve diğer ayarlar
root /var/www/html/images;
expires 30d;
}
Yukarıdaki WebP örneği, tarayıcının WebP formatını destekleyip desteklemediğini kontrol eder ve destekliyorsa .webp uzantılı dosyayı sunmaya çalışır. Bu, mobil cihazlarda resimlerin daha hızlı yüklenmesini sağlayabilir. Ancak, if yönergesinin Nginx’te karmaşık mantık için “kötü alışkanlık” olarak görüldüğünü ve basit kullanımlar dışında dikkatli olunması gerektiğini belirtmekte fayda var.
Nginx, bu gibi stratejilerle mobil uyumlu bir kullanıcı deneyiminin temelini oluşturabilir. Ancak, gerçek mobil uyumluluk genellikle duyarlı tasarım (responsive design) ve medya sorguları gibi front-end teknikleriyle sağlanır. Nginx’in görevi, bu tasarımlar için optimize edilmiş varlıkları verimli bir şekilde sunmaktır.
<!-- HTML içerisinde mobil uyumluluk için medya sorgusu örneği -->
<style>
.container {
width: 960px;
margin: 0 auto;
}
@media (max-width: 768px) {
.container {
width: 100%;
padding: 0 15px;
}
img {
max-width: 100%;
height: auto;
}
}
</style>
<div class="container">
<h1>Mobil Uyumlu İçerik</h1>
<p>Bu içerik, ekran boyutuna göre farklı görünecektir.</p>
<img src="/images/hero.jpg" alt="Responsive Image">
</div>
Nginx, yukarıdaki gibi HTML, CSS ve JavaScript dosyalarını mobil cihazlara hızlı ve güvenli bir şekilde ulaştırarak, modern web uygulamalarının mobil uyumlu olmalarına dolaylı olarak katkıda bulunur.
Gerçek Dünya Senaryosu: Yüksek Trafikli Bir E-ticaret Sitesi İçin Nginx Optimizasyonu
Bir e-ticaret sitesi, yüksek eşzamanlı kullanıcı trafiği, statik ve dinamik içeriğin bir arada sunulması, API entegrasyonları, ödeme işlemleri ve güvenlik gibi birçok karmaşık gereksinimi barındırır. Bu senaryoda Nginx’in konum bloğu seçim algoritmalarını doğru bir şekilde uygulamak, sitenin hızlı, güvenli ve ölçeklenebilir olmasını sağlamak için hayati önem taşır. Gelin, hayali bir e-ticaret sitesi olan “ShopMart” için Nginx yapılandırmasını nasıl optimize edebileceğimize bakalım.
Senaryo Detayları:
- ShopMart, PHP tabanlı bir e-ticaret platformu kullanıyor.
- Statik dosyalar (CSS, JS, resimler, fontlar) ayrı bir CDN’den veya Nginx üzerinden yüksek önbellekleme ile sunuluyor.
- API istekleri (ürün bilgileri, sepet işlemleri) ayrı bir mikroservis mimarisine yönlendiriliyor.
- Kullanıcı oturumları ve hassas veriler için HTTPS zorunlu.
- Yönetim paneli (
/admin/) için ek güvenlik önlemleri gerekiyor.
server {
listen 80;
server_name shopmart.com www.shopmart.com;
# Tüm HTTP isteklerini HTTPS'ye yönlendir
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name shopmart.com www.shopmart.com;
ssl_certificate /etc/nginx/ssl/shopmart.com.crt;
ssl_certificate_key /etc/nginx/ssl/shopmart.com.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384";
ssl_prefer_server_ciphers on;
root /var/www/shopmart/public;
index index.html index.php;
# 1. Tam Eşleşmeler (En Yüksek Öncelik)
# Favicon ve robots.txt gibi sık istenen küçük dosyalar için hızlı yanıt
location = /favicon.ico {
root /var/www/shopmart/static;
expires 30d;
access_log off;
log_not_found off;
}
location = /robots.txt {
root /var/www/shopmart/static;
expires 7d;
access_log off;
log_not_found off;
}
# 2. Regex Aramasını Durduran Prefix Eşleşmeleri (Statik İçerik)
# CSS, JS, fontlar gibi statik varlıklar için yüksek önbellekleme ve hızlı sunum
location ^~ /assets/ {
alias /var/www/shopmart/assets/; # Farklı bir dizinden sunum
expires 30d;
add_header Cache-Control "public, no-transform";
access_log off;
log_not_found off;
# MIME tipleri için include mime.types;
}
location ^~ /uploads/ {
root /var/www/shopmart; # /var/www/shopmart/uploads/ yoluna eşleşir
expires 30d;
add_header Cache-Control "public, no-transform";
# Kullanıcı tarafından yüklenen görseller için
}
# 3. Düzenli İfade Eşleşmeleri (Dinamik İçerik ve API'ler)
# PHP uygulaması için tüm .php uzantılı istekleri PHP-FPM'ye yönlendir
location ~ \.php$ {
try_files $uri =404;
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
}
# API isteklerini arka uç mikroservisine yönlendir
location ~ ^/api/v1/(products|cart|users)(.*)$ {
proxy_pass http://shopmart_api_backend$request_uri;
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;
# Rate limiting, JWT doğrulama gibi ek kurallar buraya eklenebilir
}
# Yönetim paneli için ek güvenlik (IP kısıtlaması)
location ^~ /admin/ {
auth_basic "Admin Panel";
auth_basic_user_file /etc/nginx/.htpasswd; # Kullanıcı adı/şifre doğrulama
# allow 192.168.1.0/24; # Sadece belirli bir IP aralığından erişime izin ver
# deny all; # Diğer tüm IP'leri engelle
proxy_pass http://shopmart_admin_backend; # Yönetim paneli ayrı bir backend'de olabilir
proxy_set_header Host $host;
}
# 4. Genel Prefix Eşleşmesi (Varsayılan Davranış)
# Diğer tüm istekler için, dosyayı veya dizini ara, yoksa ana PHP giriş noktasına yönlendir
location / {
try_files $uri $uri/ /index.php?$query_string;
}
# Gizli dosyaların erişimini engelle
location ~ /\.ht {
deny all;
}
location ~ /\.env {
deny all;
}
}
Bu Yapılandırmanın Analizi:
- HTTPS Zorunluluğu: İlk
serverbloğu, tüm HTTP isteklerini otomatik olarak HTTPS’ye yönlendirir, bu da e-ticaret sitesi için güvenlik standartlarını karşılar. - Statik Dosya Optimizasyonu:
location = /favicon.icovelocation = /robots.txtile en sık istenen küçük dosyalar hızla sunulur.location ^~ /assets/velocation ^~ /uploads/blokları, statik varlıkları (CSS, JS, resimler) regex araması yapmadan, yüksek önbellekleme ile sunarak performansı maksimize eder ve sunucu yükünü azaltır.aliasyönergesi, dosya sistemindeki farklı bir yoldan sunum yapmaya olanak tanır. - Dinamik İçerik ve API Yönlendirmesi:
location ~ \.php$bloğu, PHP uygulaması için dinamik istekleri PHP-FPM’ye yönlendirir.location ~ ^/api/v1/(products|cart|users)(.*)$bloğu, düzenli ifade kullanarak belirli API uç noktalarını yakalar ve bunları ayrı bir mikroservis backend’ine (shopmart_api_backend) yönlendirir. Bu, uygulama mimarisinin modülerliğini ve ölçeklenebilirliğini destekler. - Yönetim Paneli Güvenliği:
location ^~ /admin/bloğu, yönetim paneli erişimi için ek güvenlik katmanları ekler.auth_basicile temel HTTP kimlik doğrulaması ve IP kısıtlamaları (yorum satırında) uygulanabilir. Bu, hassas yönetim arayüzünü yetkisiz erişimden korur. - Genel Varsayılan Davranış:
location /bloğu, yukarıdaki spesifik kurallarla eşleşmeyen tüm diğer istekler için varsayılan davranışı tanımlar.try_filesyönergesi, URL rewrite işlemlerini ele alarak temiz URL’lerin çalışmasını sağlar. - Gizli Dosya Koruması:
location ~ /\.htvelocation ~ /\.envgibi bloklar, sunucudaki hassas yapılandırma dosyalarının ve çevre değişkenlerinin dışarıdan erişimini engeller.
Bu yapılandırma, Nginx’in konum bloğu seçim algoritmalarını bilinçli bir şekilde kullanarak, bir e-ticaret sitesinin karmaşık ihtiyaçlarını karşılayan, yüksek performanslı ve güvenli bir altyapı oluşturmanın bir örneğidir. Her blok, belirli bir amaca hizmet eder ve Nginx’in eşleştirme önceliği göz önünde bulundurularak dikkatlice yerleştirilmiştir. Bu sayede ShopMart, yoğun trafik altında bile sorunsuz bir alışveriş deneyimi sunabilir.
Sonuç ve Sıkça Sorulan Sorular
Nginx’in konum bloğu seçim algoritmalarını anlamak ve doğru bir şekilde uygulamak, web sunucusu yönetiminde uzmanlaşmanın temel taşlarından biridir. Bu makalede, Nginx’in gelen istekleri nasıl işlediğini, tam eşleşme (=), prefix eşleşmeleri (^~ ve modifiyesiz) ve düzenli ifadeler (~, ~*) arasındaki öncelik farklarını detaylıca inceledik. Ayrıca, performans optimizasyonu, güvenlik ve gerçek dünya senaryoları üzerinden en iyi uygulamaları ele aldık. Doğru yapılandırılmış konum blokları sayesinde, sunucunuzun performansını artırabilir, güvenlik açıklarını kapatabilir ve web uygulamanızın daha ölçeklenebilir olmasını sağlayabilirsiniz.
Unutmayın ki Nginx yapılandırması sürekli bir optimizasyon sürecidir. Uygulamanızın gereksinimleri değiştikçe, Nginx yapılandırmanızı da gözden geçirmeli ve güncellemeler yapmalısınız. Karmaşık düzenli ifadelerden kaçınmak, statik dosyalar için ^~ kullanmak ve hassas dosyaları korumak gibi temel prensiplere bağlı kalmak, uzun vadede size büyük faydalar sağlayacaktır.
Sıkça Sorulan Sorular (SSS)
1. Nginx’te birden fazla location bloğu eşleşirse hangisi kazanır?
Nginx, eşleşme türüne göre belirli bir öncelik sırası izler: önce tam eşleşmeler (=), sonra regex aramalarını durduran prefix eşleşmeleri (^~), ardından düzenli ifade eşleşmeleri (~, ~*) ve son olarak da en uzun modifiyesiz prefix eşleşmesi. Düzenli ifade blokları arasında, yapılandırma dosyasında ilk tanımlanan (yani yukarıdan aşağıya ilk karşılaşılan) eşleşen blok kazanır.
2. if yönergesini Nginx’te kullanmak neden genellikle önerilmez?
if yönergesi, Nginx’in yapılandırma dilinde “kötü alışkanlık” olarak kabul edilir ve genellikle kaçınılması önerilir. Bunun nedeni, if‘in Nginx’in iç işleyişiyle (özellikle rewrite modülüyle) çakışarak beklenmedik davranışlara veya hatalara yol açabilmesidir. Çoğu durumda, if yerine try_files, map modülü veya daha spesifik location blokları gibi daha güvenli ve öngörülebilir alternatifler mevcuttur.
3. Nginx yapılandırmamı test etmek için hangi komutu kullanmalıyım?
Nginx yapılandırma dosyanızda değişiklik yaptıktan sonra, yeni yapılandırmanın sözdizimsel olarak doğru olup olmadığını kontrol etmek için sudo nginx -t komutunu kullanmalısınız. Bu komut, Nginx’i yeniden başlatmadan önce olası hataları tespit etmenizi sağlar. Eğer test başarılı olursa, Nginx’i sudo systemctl reload nginx veya sudo service nginx reload komutuyla yeniden yükleyebilirsiniz.
4. Statik dosyalarımı Nginx üzerinden sunarken performansı nasıl artırabilirim?
Statik dosyalar için performansı artırmanın birkaç yolu vardır:
location ^~ /static/gibi^~prefix eşleşmeleri kullanarak Nginx’in gereksiz regex aramalarını durdurmasını sağlayın.expiresyönergesi ile uzun tarayıcı önbellekleme süreleri belirleyin (örn:expires 30d;).gzip on;yönergesi ile sıkıştırmayı etkinleştirin.access_log off;velog_not_found off;kullanarak gereksiz günlük kaydını kapatın.- Mümkünse, statik dosyaları bir CDN (İçerik Dağıtım Ağı) üzerinden sunun.
5. Nginx’te bir URL’yi başka bir URL’ye kalıcı olarak nasıl yönlendirebilirim?
Bir URL’yi kalıcı olarak (HTTP 301) yönlendirmek için return 301 yönergesini kullanabilirsiniz. Örneğin:
location /old-path/ {
return 301 /new-path/;
}
Bu, /old-path/ ile başlayan tüm istekleri /new-path/ adresine kalıcı olarak yönlendirecektir. Daha karmaşık yönlendirmeler için düzenli ifadelerle birlikte rewrite yönergesini de kullanabilirsiniz, ancak return daha basit ve performanslıdır.