Skip to content

nginx location test aracı — o blok neden kazanır

Hangi nginx location bloğu kazanır — ve diğerleri neden kaybeder. =, ^~, ~ ve ~* için ücretsiz test aracı, tamamen tarayıcınızda.

Takip Yok Tarayıcıda Çalışır Ücretsiz
Yapılandırmanız tarayıcınızda yerel olarak ayrıştırılır ve hiçbir zaman yüklenmez. Sunucu yapılandırmaları upstream sunucu adları ve yetkilendirme blokları taşır; bu yüzden Network panelini açıp sessiz kaldığını görün — ya da tümüyle çevrimdışı olun.
Gerçek bir yapılandırma hatasını deneyin
Seçilen location
~* \.(gif|jpg|jpeg)$

Yapılandırma sırasında eşleşen ilk düzenli ifade. Uzunluk önemsiz.

nginx gerçekte neyle eşleştirir
İstek hedefi
/documents/1.jpg
Normalleştirilmiş $uri
/documents/1.jpg
Sorgu dizesi $args
—

Eşleşme yalnızca normalleştirilmiş yol üzerinde çalışır. Sorgu dizesi en başta ayrılır ve hiç katılmaz.

O blok neden kazandı
O blok neden kazandı
Satır location Aşama Sonuç Neden
2 = / Tam eşleşme Eşleşme yok = location'ı URI'nin bununla başlamasını değil, tamamının eşit olmasını ister.
3 / Önek Eşleşti ama daha kısa Eşleşiyor ama başka bir önek daha çok karakter eşleştirdi.
4 /documents/ Önek Eşleşti ama daha kısa Eşleşiyor ama başka bir önek daha çok karakter eşleştirdi.
5 ^~ /images/ Önek Eşleşme yok URI bu önekle başlamıyor.
6 ~* \.(gif|jpg|jpeg)$ Düzenli ifade Seçildi Yapılandırma sırasında eşleşen ilk düzenli ifade. Uzunluk önemsiz.

nginx location değiştiricileri: =, ^~, ~ ve ~* karşılaştırması

nginx location değiştiricileri: =, ^~, ~ ve ~* karşılaştırması
Değiştirici Sözdizimi Eşleşme ölçütü Sıra Düzenli ifadeyi durdurur Tipik kullanım
= location = /path Eşitlik 1 Evet / gibi sıcak yollar — mümkün olan en hızlı eşleşme.
^~ location ^~ /path İle başlar 2 Evet Yüklemeler gibi asla bir düzenli ifadeye teslim edilmemesi gereken dizinler.
~ location ~ regex PCRE düzenli ifadesi 3 Hayır Harf durumunun önemli olduğu uzantıya göre yönlendirme.
~* location ~* regex PCRE düzenli ifadesi 3 Hayır Harf durumunun önemli olmadığı uzantıya göre yönlendirme.
(yok) location /path İle başlar 4 Hayır Yola göre genel yönlendirme.
@ location @name Yalnızca dahili — Hayır error_page ve try_files yedekleri.

Sıra sütunu basit bir sıralama değildir. Bir önek location'ı düzenli ifade değerlendirmesini yalnızca ^~ taşıdığında ve kendisi en uzun eşleşme olduğunda durdurur — bir ^~ bloğunun bazen hiçbir şey yapmıyormuş gibi görünmesinin nedeni tam da budur.

nginx location önceliği: çözümleme sırası

nginx location önceliği: çözümleme sırası
# Aşama Aramayı bitirir Ne olur
1 Normalleştirme Hayır Yüzde kodlamasının çözülmesi, . ve .. işlenmesi, tekrarlanan eğik çizgilerin birleştirilmesi. Sorgu dizesi burada ayrılır ve eşleşmeye hiç katılmaz.
2 Tam eşleşme Evet location = /path, eşitlik için karşılaştırılır. Bir isabet aramayı anında bitirir.
3 Otomatik yönlendirme Evet Adı URI artı bir eğik çizgi olan bir proxy location'ı. nginx 301 yanıtlar ve düzenli ifadelere hiç ulaşmaz.
4 Önek Hayır Eşleşen her önek karşılaştırılır ve en uzunu akılda tutulur. Yapılandırma sırası yok sayılır.
5 İç içe Hayır Kazanan öneğin içine inilir. İç içe bir düzenli ifade üst düzeyden önce denenir.
6 Düzenli ifade Evet Düzenli ifadeler yapılandırma sırasıyla denenir ve ilk eşleşme kazanır. Sonradan yazılan daha uzun ya da daha özel bir düzenli ifade hiç çalışmaz.
7 Yedek Evet Hiçbir düzenli ifade eşleşmedi, bu yüzden daha önce akılda tutulan önek kullanılır.
Eşleşme sırası, ^~ kısa devresi, iç içe location'lara iniş, otomatik yönlendirme davranışı ve URI normalleştirmesi nginx'in kendi kaynak koduna karşı denetlendi ve yapılandırmalar nginx 1.27.5 üzerinde çalıştırılarak doğrulandı. — Go Tools Mühendislik Ekibi · Jul 22, 2026

Bu sayfadaki seçim kuralları ikincil yazılardan alınmak yerine çalışan bir nginx 1.27.5 üzerinde doğrulandı ve motor, bu koşulardan türetilen birim testleriyle kapsanıyor.

nginx location eşleşmesi: kısa cevaplar

nginx düzenli ifade location'larını önek eşleşmelerinden önce mi işler?

Hayır — önce önek location'ları denetlenir, ama eşleşen bir düzenli ifade yine de kazanır. nginx önce tüm önek location'larını denetler ve en uzun eşleşmeyi aklında tutar, ardından düzenli ifade location'larını dosyada göründükleri sırayla değerlendirir. Eşleşen ilk düzenli ifade kazanır. Hiçbiri eşleşmezse akılda tutulan önek location'ı kullanılır. Tek istisna ^~ değiştiricisidir: en uzun eşleşen önek bunu taşıyorsa düzenli ifade aşaması tümüyle atlanır.

nginx'te location bloklarının sırası önemli mi?

Yalnızca düzenli ifade location'ları için. Önek location'ları — = ve ^~ dahil — en uzun eşleşmeye göre seçilir, dolayısıyla dosyadaki sıraları önemsizdir. Düzenli ifade location'ları yukarıdan aşağıya denenir ve ilk eşleşme kazanır, dolayısıyla bir düzenli ifade bloğunu taşımak hangisinin çalışacağını değiştirir. Daha genel bir ifadenin altına konan daha özel bir ifade asla yürütülmez.

^~ değiştiricisi gerçekte ne yapar?

Önceliği yükseltmek yerine nginx'i önek eşleşmesinden sonra durdurur. En uzun eşleşen önek location'ı ^~ taşıyorsa nginx düzenli ifade aşamasını atlar ve o bloğu kullanır. Önek eşleşmesini uzatmaz, onu diğer öneklerin üstüne de çıkarmaz — yalnızca düzenli ifade değerlendirmesini bastırır. Daha uzun bir düz önek de eşleştiğinde bir ^~ bloğunun hiçbir şey yapmıyormuş gibi görünmesinin nedeni budur: onun yerine daha uzun olan akılda tutulur ve o hiçbir şeyi bastırmaz.

location /static ile location /static/ aynı şey mi?

Hayır — /static aynı zamanda /staticfoo ile de eşleşir. Önek eşleşmesi bir yol parçası sınırı değil, düz bir dize karşılaştırmasıdır; bu yüzden location /static aynı zamanda /staticfiles ve /static-backup yollarını da sunar. Ayrı bir konu: /static/ bir proxy_pass ile kullanıldığında, sondaki eğik çizgi olmadan /static için gelen istek, herhangi bir düzenli ifade değerlendirilmeden önce /static/ adresine 301 yönlendirmesi alır.

nginx eşleşmeden önce %2F kodunu çözüp çift eğik çizgileri birleştirir mi?

Evet — eşleşme ham istek üzerinde değil, normalleştirilmiş URI üzerinde çalışır. nginx bir location seçmeden önce %XX kodlarını çözer, . ve .. ifadelerini işler ve tekrarlanan eğik çizgileri sıkıştırır. Çözülen bir %2F gerçek bir ayırıcıya dönüşür ve bu işleme katılır, dolayısıyla /a/b%2F..%2Fzz adresi /a/zz olarak eşleştirilir. Sorgu dizesi en başta ayrılır ve eşleşmeye hiç katılmaz.

nginx location bloğu nedir?

Bir location bloğu, URI'si bir desenle eşleşen isteğe ne yapılacağını nginx'e söyler. Bir server bloğu genellikle birkaç tanesini barındırır ve ilginç olan her birinin ne yaptığı değil, nginx'in hangisini seçtiğidir — çünkü seçim kuralları çoğu kişinin varsaydığı kurallar değildir.

Beş biçim vardır. location = /path yalnızca URI'nin tamamı eşit olduğunda eşleşir. location /path o karakterlerle başlayan her URI ile eşleşir. location ^~ /path aynı önek karşılaştırmasıdır, üstüne bir etki daha ekler. location ~ regex ve location ~* regex bir PCRE desenini, sırasıyla harf durumuna duyarlı ve duyarsız biçimde uygular. location @name URI eşleşmesine hiç katılmaz ve yalnızca try_files ile error_page için hedef olarak vardır.

Seçim aşamalar hâlinde ilerler. Önce URI normalleştirilir: yüzde kodlaması çözülür, . ve .. işlenir, tekrarlanan eğik çizgiler birleştirilir, sorgu dizesi ayrılır. Sonra URI'ye eşit bir = location'ı aramayı anında bitirir. Ardından eşleşen her önek karşılaştırılır ve en uzunu akılda tutulur — yapılandırmadaki sıranın burada hiçbir payı yoktur. Akılda tutulan önek ^~ taşıyorsa nginx durur ve onu kullanır. Aksi hâlde düzenli ifade location'ları dosyada göründükleri sırayla denenir ve sonradan gelen ne kadar özel olursa olsun ilk eşleşme kazanır. Hiçbiri eşleşmezse akılda tutulan önek kullanılır.

Bu kuralların ikisi ters yönlere çeker ve kafa karışıklığı tam orada yaşar: önekler sıradan bağımsız olarak uzunluğa, düzenli ifadeler uzunluktan bağımsız olarak sıraya göre seçilir. Yukarıdan aşağıya doğru okunduğunda kusursuz görünen bir yapılandırma yine de bir isteği amaçlamadığınız yere yönlendirebilir ve ne kadar yeniden okursanız okuyun bu ortaya çıkmaz. Bu sayfa tüm diziyi kendi yapılandırmanız üzerinde yeniden oynatır ve her bloğun nerede elendiğini gösterir.

# From the nginx documentation. Which block serves each request?
server {
    location = /                   { }   # A
    location /                     { }   # B
    location /documents/           { }   # C
    location ^~ /images/           { }   # D
    location ~* \.(gif|jpg|jpeg)$  { }   # E
}

#   /                        -> A   exact match, search ends here
#   /index.html              -> B   no regex matched, longest prefix used
#   /documents/document.html -> C   longer prefix than B
#   /images/1.gif            -> D   ^~ won the prefix stage, regex skipped
#   /documents/1.jpg         -> E   regex beats the longer prefix C

# The last two lines are the whole lesson: identical-looking prefixes
# behave differently because only one of them carries ^~.

Öne çıkan özellikler

Kaybeden her blok, elendiği aşamayla birlikte

Yazdığınız her location için bir satır çıkar: eşleşti ama daha kısa, bir ^~ öneki kazandığı için atlandı, daha erken bir düzenli ifade eşleştiği için ulaşılamaz ya da yalnızca eşleşme yok. Diğerlerinin neden kaybettiğini bilmek soruyu asıl çözen şeydir.

Dört aşamalı karar zinciri, yeniden oynatılmış

Normalleştirme, tam eşleşme, en uzun önek belleği, ^~ kısa devresi, dosya sırasıyla düzenli ifadeler ve yedek adım soyut olarak anlatılmak yerine kendi yapılandırmanız üzerinde ayrı adımlar hâlinde gösterilir.

^~ kısa devresi görünür kılınmış

Bir ^~ öneki düzenli ifade aşamasını bastırdığında atlanan her düzenli ifade sessizce yok olmak yerine atlandı diye etiketlenir — ve ^~ daha uzun bir düz önek kazandığı için uygulanamadığında bu da gösterilir.

İç içe location'lar düzleştirilmeden çözülür

nginx kazanan öneğin içine iner ve çocuklarını arar, dolayısıyla iç içe bir düzenli ifade üst düzeydekinden önce çalışır. İç içe bloklar tabloda girintilerini korur, böylece yapı okunur kalır.

Yalnızca PCRE'de olan sözdizimi baştan saptanır

Tarayıcılar PCRE değil ECMAScript düzenli ifadeleri çalıştırır. Atomik gruplar, iyelik niceleyicileri, POSIX sınıfları ve \A ile \K gibi kaçış dizileri sessizce yanlış değerlendirilmek yerine işaretlenir; böylece kendinden emin bir yanlış cevap asla gerçek diye sunulmaz.

Hiçbir şey yüklenmez — tarayıcınızda çalışır

Sunucu yapılandırmaları upstream sunucu adları, iç portlar ve yetkilendirme kuralları taşır. Ayrıştırma, bağımlılığı ve ağ çağrısı olmayan düz bir dize işidir; her yapımda çalışan otomatik bir sözleşme testiyle doğrulanır.

Bu soruyu yanıtlamanın başka yolları

nginx -T

Komut satırı

Tümüyle çözülmüş yapılandırmayı döker; gerçekte neyin yüklü olduğunu bulmak için paha biçilmezdir. Belirli bir URI'nin hangi location'ı seçtiğini söylemez — bu sayfanın doldurduğu boşluk tam olarak budur.

error_log ... debug

Çalışan sunucu

Ulaşılabilecek en yetkili cevap: "using configuration" satırı nginx'in gerçekten seçtiği bloğu adıyla verir. Root yetkisi, bir yeniden yükleme ve erişebildiğiniz bir sunucu ister — yani öncesinde değil, dağıtımdan sonra cevap verir.

Yapılandırma sözdizimi denetleyicileri

Barındırılan hizmet

Dosyanın tamamını denetlemekte ve güvenlik kurallarında güçlüdür. Genellikle sunucu tarafında çalışırlar; bu da iç sunucu adları ve sertifika yolları içeren bir yapılandırmayı yüklemek anlamına gelir.

Belgeleri okumak

Başvuru

nginx belgeleri algoritmayı tam olarak anlatır ve bir kez okunmaya değer. Hatalar, algoritmayı sekiz bloğa ve bir URI'ye elle uygularken sızar, çünkü kuralların ikisi ters yönleri gösterir.

nginx location eşleşme örnekleri

Düzenli ifade daha uzun bir öneki yener

location /documents/  ·  location ~* \.(gif|jpg|jpeg)$  ·  GET /documents/1.jpg
~* \.(gif|jpg|jpeg)$ wins

/documents/ öneki eşleşir ve dosyadaki en uzun önektir, bu yüzden nginx onu aklında tutar — sonra yine de düzenli ifadeleri değerlendirir ve isteği eşleşen ilkine verir. Uzunluk, düzenli ifade aşamasına kaybeder. O önek ^~ /documents/ diye yazılmış olsaydı hiçbir düzenli ifade çalışmayacaktı. Bu, nginx belgelerindeki örnektir ve içselleştirilmeye en değer olanıdır.

PHP çalıştıran yükleme dizini

location /uploads/  ·  location ~ \.php$ { fastcgi_pass ... }  ·  GET /uploads/evil.php
~ \.php$ wins — the upload lands in the interpreter

/uploads/ öneki eşleşir ama düz bir önek düzenli ifade aşamasını durdurmaz, dolayısıyla birinin yüklediği dosya doğrudan PHP-FPM'e gider. location ^~ /uploads/ yazmak düzenli ifade aşamasını kısa devre yaptırır ve bu kapıyı kapatır. Bu varsayımsal değil: uzun bir yüklemeden RCE'ye zinciri raporunun arkasındaki biçim tam olarak budur ve savunmasızla güvenli arasındaki fark iki karakterdir.

Sessizce hiçbir şey yapmayan ^~

location ^~ /a/  ·  location /a/b/  ·  location ~ \.php$  ·  GET /a/b/x.php
~ \.php$ wins — the ^~ never applied

^~ düzenli ifade aşamasını yalnızca kendisi eşleşen en uzun önekken bastırır. Burada /a/b/ daha uzundur, dolayısıyla nginx'in aklında tuttuğu odur ve onun düz değiştiricisi düzenli ifade aşamasının çalışmasına izin verir. ^~ bloğu hâlâ dosyada durur, hâlâ koruyucu görünür ve bu istek üzerinde hiçbir etkisi yoktur. Yapılandırmayı yukarıdan aşağıya okumak bunu göstermez; önek uzunluklarını karşılaştırmak gösterir.

/static aynı zamanda /staticfoo yakalar

location /static  ·  location /static/  ·  GET /staticfoo
/static wins

Önek eşleşmesi yol parçalarını değil karakterleri karşılaştırır. /staticfoo, /static ile başladığı için eşleşir; /static/ ise hiç eşleşmez çünkü URI'de o konumda eğik çizgi yoktur. Sadece aynı harflerle başlayan bir yolun altındaki her şey o blok tarafından sunulur — bir /static kuralının /static-backup sunmaya başlaması böyle olur.

En iyi düzenli ifade değil, ilki kazanır

location ~ ^/a  ·  location ~ ^/a/b/c$  ·  GET /a/b/c
~ ^/a wins; ~ ^/a/b/c$ is unreachable

Düzenli ifadeler dosyada göründükleri sırayla değerlendirilir ve ilk eşleşme aramayı bitirir. İkinci blok daha özeldir ve bu URI ile tam olarak eşleşir; yine de hiçbir istek için asla çalışmayacaktır. Önek location'ları sıradan bağımsız olarak uzunluğa göre, düzenli ifade location'ları ise özgüllükten bağımsız olarak sıraya göre seçilir. Bu iki kuralı karıştırmak, biri dosyayı derleyip topladıktan sonra bir kuralın "çalışmayı bırakmasının" alışılmış nedenidir.

Kodlanmış dizin geçişi eşleşmeden önce çözülür

location /a/  ·  location /b/  ·  GET /a/b%2F..%2Fzz
$uri becomes /a/zz, so /a/ wins

nginx, herhangi bir location'a bakmadan önce yüzde kodlamasını çözer, . ve .. ifadelerini işler ve tekrarlanan eğik çizgileri birleştirir. %2F gerçek bir ayırıcıya çözülür ve sonra bu işleme katılır, dolayısıyla bu hedef /a/b/ içinde kalmaz — /a/zz üzerine düşer. Normalleştirilmiş $uri yerine yazdığınız hedefle eşleştirmek burada yanlış cevabı verir.

nginx location test aracı nasıl kullanılır

  1. 1

    server bloğunu yapıştırın

    Bütün bir server bloğunu ya da yalnızca üzerinde düşündüğünüz location bloklarını bırakın. İç içe location'lar anlaşılır ve özgün satır numaraları korunur, böylece tablo dosyanızla örtüşür.

  2. 2

    İstek URI'sini girin

    Yolu ağdan geldiği biçimde, yüzde kodlaması ve sorgu dizesi dahil yazın. Tablonun üstündeki üç satır, eşleşmeden önce nasıl normalleştirildiğini gösterir.

  3. 3

    Önce kazananı, sonra kaybedenleri okuyun

    Karar kartı seçilen bloğu ve tek satırlık nedeni verir. Altındaki karar tablosu diğer her bloğu açıklar: hangi aşamada elendiğini ve nedenini.

  4. 4

    Tanılamayı denetleyin

    Bağlanmamış düzenli ifadeler, sondaki eğik çizgisi eksik önekler, düzenli ifade deseni taşıyan bir ^~, ulaşılamaz kopyalar ve bir PHP düzenli ifadesiyle erişilebilen yükleme dizinleri raporlanır.

  5. 5

    Tam durumu paylaşın

    Bağlantıyı kopyala, yapılandırmayı ve URI'yi URL parçasına kodlar; böylece bir iş arkadaşınız tam olarak sizin baktığınız şeyi açar. Parçalar hiçbir zaman sunucuya iletilmez.

Sık yapılan nginx location hataları

^~ değiştiricisinin daha uzun bir öneki geçmesini beklemek

^~ yalnızca uzunlukta zaten kazanmış olan önekte denetlenir. Daha uzun bir düz önek önce kazanır ve düzenli ifade aşaması sanki ^~ yokmuş gibi çalışır.

✗ Yanlış 
location ^~ /a/ { }
location /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ~ \.php$
✓ Doğru 
location ^~ /a/ { }
location ^~ /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ^~ /a/b/

Sondaki eğik çizgisi olmayan bir öneğin komşuları yakalaması

Önek eşleşmesi yol parçalarını değil karakterleri karşılaştırır, dolayısıyla blok aynı harflerle başlayan her komşu yolu da sunar.

✗ Yanlış 
location /static { root /var/www; }
# also serves /staticfoo and /static-backup
✓ Doğru 
location /static/ { root /var/www; }
location = /static { return 301 /static/; }

Özel düzenli ifadeyi genel olanın altına koymak

Düzenli ifadeler dosya sırasıyla denenir ve ilk eşleşme aramayı bitirir, dolayısıyla daha kesin blok hiçbir istek için yürütülmez.

✗ Yanlış 
location ~ ^/api { }
location ~ ^/api/v2/users$ { }
# the second is unreachable
✓ Doğru 
location ~ ^/api/v2/users$ { }
location ~ ^/api { }

^~ değiştiricisinden sonra düzenli ifade yazmak

^~ harfi harfine bir önek alır. nginx dosyayı hiç şikâyet etmeden yükler ve blok basitçe hiçbir şeyle eşleşmez; bu da incelemede fark edilmesini zorlaştırır.

✗ Yanlış 
location ^~ "\.php$" { deny all; }
✓ Doğru 
location ~ \.php$ { deny all; }

Sorgu dizesinin eşleşmeye katıldığını varsaymak

Sorgu dizesi normalleştirme sırasında ayrılır, dolayısıyla bir location onun üzerinden asla eşleşemez. Bunun yerine blok içinde $arg_name değerini okuyun.

✗ Yanlış 
location /search?q= { }
# never matches anything
✓ Doğru 
location /search {
    if ($arg_q = "") { return 400; }
}

nginx location test aracıyla neler yapabilirsiniz

Bir yapılandırmayı üretime çıkmadan denetleyin
Düzenlediğiniz ama henüz dağıtmadığınız bir server bloğunun yönlendirmesini gözden geçirin. Burada yakalanan arıza, yalnızca belirli bir URI biçiminde ortaya çıkan türdendir; yeniden yükleme sonrası duman testinin tam da kaçırmaya eğilimli olduğu tür.
Bir kuralın neden çalışmayı bıraktığını bulun
Eskiden çalışan ve artık çalışmayan bir düzenli ifade neredeyse her zaman sıranın kurbanıdır: ya bir şey daha erken eşleşmiştir ya da üstünde bir ^~ belirmiştir. Tablo bloğu ulaşılamaz olarak işaretler ve isteği alan bloğu adıyla verir.
Bir yükleme ya da medya dizinini denetleyin
Yüklemeden yürütmeye giden biçimi yeniden üreten hazır ayarı yükleyin, sonra kendi yollarınızı yapıştırın. Yazmaya açık bir dizinin içinde bir PHP düzenli ifadesi istekleri alıyorsa tanılama bunu söyler ve iki bloğu da adıyla verir.
Bir inceleme yorumunu kanıtla kapatın
Bağlantıyı kopyala, tam yapılandırmayı ve URI'yi URL parçasında yakalar. Bunu bir pull request'e bırakmak, öncelik tartışmasını herkesin yeniden çalıştırabileceği bir karar tablosuyla değiştirir.
Seçim algoritmasını öğretin
İki başvuru tablosu, gösterebileceğiniz durağan ve taranabilir malzemedir; hazır ayar düğmeleri ise her tuzağı bir sunucuyu bozmaya gerek kalmadan gösterir. Özellikle ^~ örneği tartışmayı hızla bitirme eğilimindedir.

nginx location seçimi nasıl çalışır

Normalleştirme, herhangi bir location'a bakılmadan önce olur
URI'nin yüzde kodlaması çözülür, . ve .. parçaları işlenir ve tekrarlanan eğik çizgiler birleştirilir; ancak bundan sonra bir location seçilir. Çözülen bir %2F gerçek bir ayırıcıya dönüşür ve bu işleme katılır, dolayısıyla /a/b%2F..%2Fzz adresi /a/zz olarak eşleştirilir. Çözülen üç karakter istisnadır ve harfi harfine kalır: %25, %23 ve %3F — bu yüzden /a%3Fx=1 adresinin yolunda soru işareti bulunur ve sorgu dizesi boştur. Burada + boşluk değildir; yalnızca %20 boşluktur. Kökün üstüne çıkan dizin geçişi ve geçersiz kaçış dizisi, eşleşme başlamadan önce 400 ile reddedilir.
Önek uzunluğu karar verir, yapılandırma sırası vermez
Eşleşen her önek location'ı karşılaştırılır ve dosyada ilk ya da son sırada olmasına bakılmaksızın en uzunu kazanır. Karşılaştırma yol parçalarına göre değil karakterlere göredir, dolayısıyla /static, /staticfoo ile eşleşir. Kazanan hemen kullanılmak yerine akılda tutulur, çünkü düzenli ifade aşaması onu hâlâ geçersiz kılabilir.
^~ düzenli ifadeleri bastırır; önceliği yükseltmez
Bu değiştirici yalnızca uzunlukta zaten kazanmış olan önekte denetlenir. Daha uzun bir düz önek de eşleşiyorsa akılda tutulan o olur ve düzenli ifade aşaması her zamanki gibi çalışır — ^~ bloğunun istek üzerinde hiçbir etkisi kalmaz. ^~ değiştiricisini iç içe bir location'a koymak dış düzeyde bildirilmiş bir düzenli ifadeye karşı korumaz ve kendi bloğunun içine yerleştirilmiş düzenli ifadeleri asla bastırmaz.
Düzenli ifadeler dosya sırasıyla çalışır ve ilk eşleşme aramayı bitirir
nginx düzenli ifade location'larını yazıldıkları sırada tutar ve sıralamaz. Özgüllük, uzunluk ve bağlama, hangisinin önce deneneceğine etki etmez; dolayısıyla geniş bir desenin altına konan kesin bir desen ölü yapılandırmadır. Eşleşen bir düzenli ifade location'ının içine de inilir, dolayısıyla ona iç içe yazılmış location'lar sonrasında aranır.
PCRE ile ECMAScript aynı dil değildir
nginx location düzenli ifadelerini PCRE ile, UTF ve çok satırlı kip olmadan derler; dolayısıyla desenler baytlar üzerinde çalışır ve ^ yalnızca URI'nin başına bağlanır. Bir fark güvenlik açısından ağırlık taşır: PCRE'de $ sondaki satır sonundan hemen önce de eşleşir, dolayısıyla %0A ile biten bir URI, bir JavaScript motorunun reddedeceği durumda bile \.php$ desenini karşılar. Bu davranış burada taklit edilir ve raporlanır, çünkü dosya uzantısına dayalı kuralların yanından sıyrılmanın bilinen bir yoludur.

nginx location için iyi uygulamalar

Yazılabilir dizinleri düz önekle değil ^~ ile koruyun
Yükleme kabul eden her dizine location ^~ /uploads/ gerekir; böylece düzenli ifade aşaması saklanan bir dosyayı bir yorumlayıcıya veremez. Düz bir önek eşdeğer görünür ama değildir.
Dizin öneklerine sondaki eğik çizgiyi verin
/staticfoo ve /static-backup yollarının aynı blok tarafından sunulmasını bilerek istemiyorsanız location /static yerine location /static/ yazın. Çıplak yolun da işlenmesi gerektiğinde ayrı bir location = /static ekleyin.
Düzenli ifadeleri en özelden en genele doğru sıralayın
İlk eşleşme kazanır, dolayısıyla kesin bir desenin üstündeki geniş bir desen kesin olanı ulaşılamaz kılar. Düzenli ifadeleri az tutmak ve bilinçli sıralamak, sonradan örtüşmeleri çözmeye çalışmaktan daha kolay sürdürülür.
Yol öneki eşleştirmesi gereken düzenli ifadeleri bağlayın
location ~ /admin URI'nin herhangi bir yerinde arar ve /public/admin/x ile eşleşir. Başlangıcı kastediyorsanız ~ ^/admin yazın. Yalnızca sonda bağlamak uzantıya göre yönlendirmede olağan ve doğrudur.
Her yeniden sıralamadan sonra yönlendirmeyi yeniden denetleyin
Blokları taşımak önekler için güvenlidir ve düzenli ifadelerin davranışını değiştirir. Yalnızca satır sırasını değiştiren bir fark incelemede zararsız göründüğü için, etkilenen URI'leri yeniden çalıştırmak bunu yakalamanın en ucuz yoludur.

nginx location test aracı SSS

nginx'in hangi location'ı seçtiğini nasıl anlarım?
Yapılandırmayı ve isteğin URI'sini bu test aracına yapıştırın; kazanan bloğu ve diğer her bloğun neden elendiğini görün. Çalışan bir sunucuda error_log /var/log/nginx/debug.log debug; satırını ekleyin ve seçilen location'ı adıyla veren "using configuration" satırını arayın. İki yaklaşım farklı sorulara cevap verir: günlük, canlı bir sunucunun ne yaptığını söyler; bu sayfa ise henüz yayına almadığınız bir yapılandırmanın ne yapacağını söyler.
nginx location düzenli ifadem neden çalışmıyor?
Genellikle üç nedenden biri yüzünden ve karar tablosu hangisi olduğunu söyler. Daha önceki bir düzenli ifade zaten eşleşmiştir, dolayısıyla sizinki hiç çalışmamıştır — düzenli ifadeler dosya sırasıyla denenir ve ilk eşleşme kazanır. Ya da en uzun eşleşen önek ^~ taşıyordur ve düzenli ifade aşaması tümüyle atlanmıştır. Ya da düzenli ifade doğrudur ama URI sandığınız gibi değildir: eşleşme, yüzde kodlaması çözülmüş ve .. işlenmiş, sorgu dizesi çıkarılmış normalleştirilmiş yol üzerinde çalışır.
Tam eşleşmem neden tetiklenmiyor?
= ile yazılan bir location, URI'nin desenle başlamasını değil, tamamının eşit olmasını ister. location = /a/, /a ile eşleşmez ve location = /a, /a/b ile eşleşmez. Sondaki eğik çizgiler burada sıradan karakterlerdir, dolayısıyla iki biçim farklı dizelerdir. Tam eşleşen bir location bulunduğunda arama anında durur ve geri kalan hiçbir şey karşılaştırılmaz bile.
nginx bir location bloğunda sorgu dizesini eşleştirir mi?
Hayır. Sorgu dizesi normalleştirme sırasında ayrılır ve location seçimi yalnızca yol üzerinde çalışır. location = /a ifadesinin /a?x=/b isteğiyle eşleşmesinin nedeni budur. Bir parametreye göre dallanmanız gerekiyorsa blok içinde $arg_name ya da $args değerini okumalısınız. Bilmeye değer bir incelik: %3F yolda kalan gerçek bir soru işaretine çözülür, dolayısıyla /a%3Fx=1 adresinin sorgu dizesi boştur ve yolunda ? vardır.
nginx location içinde JavaScript düzenli ifade sözdizimi kullanabilir miyim?
Hayır — nginx PCRE kullanır ve aradaki farklar önemlidir. Bu sayfa yalnızca ECMAScript düzenli ifadelerinin bulunduğu tarayıcınızda çalışır, bu yüzden yalnızca PCRE'de olan yapılar sessizce yanlış değerlendirilmek yerine saptanıp işaretlenir: atomik gruplar, iyelik niceleyicileri, (?i) gibi satır içi değiştiriciler, [[:alpha:]] gibi POSIX sınıfları ve JavaScript'in sessizce sıradan harf olarak okuduğu \A ile \K gibi kaçış dizileri. Bir location işaretlendiğinde kalan adaylar yine nginx'in sırasıyla değerlendirilir, ama o bloğun kararının gerçek bir sunucuda denetlenmesi gerekir. Desenin kendisini yazıyorsanız düzenli ifade test aracı ECMAScript sözdizimini ayrıntısıyla ele alır.
nginx location önek eşleşmeleri büyük/küçük harfe duyarlı mı?
Linux'ta evet — location /Static/, /static/x ile eşleşmez. macOS ve Cygwin gibi büyük/küçük harfe duyarsız dosya sistemlerinde nginx önekleri harf durumuna bakmadan karşılaştırır ve ayrıca her düzenli ifade location'ını ~* gibi davranmaya zorlar. Bu sayfa, üretim sunucularının neredeyse her zaman çalıştırdığı Linux davranışını modeller. Mac üzerinde geliştirip Linux'a dağıtıyorsanız bu fark, bozuk bir kuralı yayına çıkana dek gizleyebilir.
try_files hangi location bloğunun seçildiğini değiştirir mi?
Hayır. Location seçimi önce biter; try_files sonra, zaten kazanmış olan bloğun içinde çalışır. Bir istek try_files yazdığınız bloğa hiç ulaşmıyorsa yönerge önemsizdir — alışılmış neden, yedeği taşıyan önek bloğu iş yapamadan isteği alan bir ~ \.php$ düzenli ifadesidir. Sonradan verilen bir iç yönlendirme ise eşleşmeyi yeniden başlatır, dolayısıyla yeniden yazılmış bir URI location listesine baştan tekrar sokulur.
Eğik çizgisiz bir dizin istediğimde nginx neden 301 döndürüyor?
Bunu iki farklı mekanizma üretir. Adı / ile biten bir location proxy_pass ya da başka bir *_pass yönergesi taşıyorsa, aynı yola eğik çizgisiz gelen istek, herhangi bir düzenli ifade değerlendirilmeden önce, location seçimi sırasında 301 ile yanıtlanır. Bundan ayrı olarak statik dosya modülü, yol diskteki gerçek bir dizine çözüldüğünde 301 verir. Birincisi burada görünür; ikincisi dosya sisteminize bağlıdır. location = /path eklemek birincisini bastırır.
İç içe location blokları sonucu değiştirir mi?
Evet ve gözden kaçması kolay bir biçimde. nginx kazanan önek location'ının içine iner ve çocuklarını arar, dolayısıyla iç içe bir düzenli ifade üst düzeydeki düzenli ifadelerden önce denenir. Dıştaki bloğun ^~ taşıması onu kendi içindeki düzenli ifadelerden korumaz ve dış düzeydeki bir kardeş önce kazandığında iç içelik, genel olarak daha uzun bir öneki ulaşılamaz kılabilir. İç içe bloklar burada, yazdığınız girintinin aynısıyla modellenir.
nginx yapılandırmam bir yere yükleniyor mu?
Hayır. Ayrıştırma ve eşleştirme, düz dize işlemleriyle tarayıcınızda yerel olarak yapılır — sunucu çağrısı yoktur ve hiçbir şey saklanmaz. Bu, çoğu araçtan daha çok burada önem taşır, çünkü gerçek bir server bloğu upstream sunucu adları, iç portlar, sertifika yolları ve yetkilendirme kuralları içerir. Sözümüze güvenmek zorunda değilsiniz: tarayıcınızın geliştirici araçlarını açın ve siz yazarken Network panelinin sessiz kaldığını izleyin ya da bağlantıyı tümüyle kesip test etmeye devam edin. Hiçbir dış isteğin bulunmadığı, her yapımda çalışan otomatik bir sözleşme testiyle de güvence altına alınır, dolayısıyla sessizce geri gidemez.

İlgili Araçlar

Tüm araçları görüntüleyin →

cURL Komut Oluşturucu ve Yapılandırıcı

Web & API

Tarayıcınızda curl komutları oluşturun — yöntem, başlık, kimlik doğrulama ve gövde ayarlayın, anında kopyalamaya hazır komut alın. Bearer, POST JSON, dosya yükleme için ön ayarlar. Ücretsiz, gizli, kayıt gerektirmez.

htpasswd Oluşturucu — bcrypt, Apache MD5 (apr1), Basic Auth

Web & API

bcrypt, Apache MD5 (apr1), SHA-1 ve daha fazlasıyla htpasswd girdisi oluşturun. Apache, nginx ve Docker için yapıştırmaya hazır yapılandırma alın. Tarayıcınızda %100 çalışır — yükleme yok.

Open Graph ve Meta Etiketi Oluşturucu

Web & API

Open Graph, Twitter Card ve SEO meta etiketlerini canlı Google, Facebook ve X önizlemesiyle çevrimiçi oluşturun. %100 ücretsiz, tarayıcıda çalışır, kayıt yok — kodu kopyalayıp yapıştırın.

traceparent Çözücü — W3C Trace Context

Web & API

Hex basamağı saymayı bırakın. Ücretsiz çevrimiçi traceparent çözücü — tarayıcınızda çalışır, yükleme yok. Trace ID, span ID, 8 trace-flags biti, tracestate, Datadog/X-Ray/B3.

AES Şifre Çözme Aracı — OpenSSL ve CryptoJS Uyumlu

Güvenlik Araçları

AES şifreli metnini online çözün — GCM/CBC/CTR, parola veya ham anahtar, OpenSSL ve CryptoJS "U2FsdGVkX1" biçimini otomatik algılar. %100 tarayıcıda, anahtarlar sayfadan asla çıkmaz.

AES Şifreleme Aracı — GCM, CBC ve CTR

Güvenlik Araçları

Ücretsiz online AES şifreleme — AES-128/192/256, GCM/CBC/CTR, parola (PBKDF2) veya ham anahtar. %100 tarayıcınızda çalışır; hiçbir şey yüklenmez.