Prioritas location Nginx: Urutan Pencocokan Dijelaskan

Nginx tidak membaca blok location Anda dari atas ke bawah lalu berhenti pada blok pertama yang cocok. Satu salah paham itulah yang ada di balik hampir semua laporan bug “blok location saya tidak jalan”. Untuk location berjenis prefiks, posisi sebuah blok di dalam file sama sekali tidak berpengaruh. Nginx membandingkan semuanya, lalu menyimpan kecocokan terpanjang.

Prioritas location nginx yang sebenarnya adalah urutan tetap yang terdiri dari empat langkah:

1. Kecocokan persis. Kalau ada location = /path yang sama persis dengan URI, nginx langsung memakainya dan berhenti. Tidak ada perbandingan prefiks, tidak ada regex.
2. Prefiks terpanjang. Nginx membandingkan semua location prefiks (location /path maupun location ^~ /path) yang menjadi awalan URI. Yang terpanjang hanya diingat, belum dipakai.
3. Hubung-singkat ^~. Kalau prefiks yang diingat tadi membawa ^~, nginx melewati seluruh fase regex dan memakai blok itu.
4. Regex, sesuai urutan file. Kalau tidak, nginx mencoba location ~ dan ~* sesuai urutan kemunculannya di konfigurasi, dan kecocokan pertama yang menang. Kalau tidak ada satu pun yang cocok, nginx memakai prefiks yang diingat di langkah 2.

Dua aturan di antaranya menarik ke arah berlawanan: prefiks dipilih berdasarkan panjang tanpa peduli urutan, regex berdasarkan urutan tanpa peduli panjang. Membaca konfigurasi dari atas ke bawah tidak akan pernah memunculkan konflik itu. Kalau Anda ingin jawaban untuk file Anda sendiri, bukan untuk contoh-contoh di bawah, tempelkan saja ke penguji nginx location gratis. Alat itu memutar ulang urutan ini dan menunjukkan pada tahap mana setiap blok yang kalah tersingkir. Alat itu berjalan di browser Anda, jadi konfigurasi produksi yang Anda tempel tidak pernah meninggalkan halaman. Setiap aturan pencocokan yang dijelaskan di sini diverifikasi terhadap nginx 1.27.5 yang sedang berjalan, bukan disalin dari artikel sekunder.

Prioritas location Nginx Sekilas

Ada lima modifier yang ikut serta dalam pencocokan URI, plus satu yang tidak.

Modifier	Sintaks	Cocok berdasarkan	Menghentikan fase regex	Penggunaan umum
=	location = /path	Kesamaan persis	Ya	Jalur padat seperti / atau /favicon.ico
^~	location ^~ /path	Diawali dengan	Ya, kalau ia prefiks terpanjang	Direktori yang tidak boleh sampai ke regex
~	location ~ regex	PCRE, peka huruf besar-kecil	Tidak	Perutean ekstensi saat huruf besar-kecil penting
~*	location ~* regex	PCRE, abai huruf besar-kecil	Tidak	Perutean ekstensi saat huruf besar-kecil tidak penting
(tanpa modifier)	location /path	Diawali dengan	Tidak	Perutean umum berdasarkan path
@	location @name	Tidak pernah cocok lewat URI	—	Target error_page dan try_files

Aturan praktisnya: kecocokan persis mengalahkan segalanya, regex mengalahkan prefiks, dan sesama prefiks bersaing berdasarkan panjang. Satu-satunya pengecualian adalah ^~, dan cakupannya lebih sempit daripada kelihatannya.

Tabel itu baru bisa disebut peringkat dalam arti yang sangat longgar. ^~ memang duduk di atas ~ di sana, padahal blok ^~ rutin kalah oleh regex, karena nginx baru memeriksa modifier itu pada prefiks yang sudah menang berdasarkan panjang.

Algoritma Seleksi Empat Langkah

Cara termudah mempelajari urutan pencocokan location nginx adalah lewat satu konfigurasi yang menjalankan semua aturannya sekaligus. Ini contoh dari dokumentasi nginx, dan layak Anda hafalkan:

server {
    location = /                   { return 200 "A\n"; }
    location /                     { return 200 "B\n"; }
    location /documents/           { return 200 "C\n"; }
    location ^~ /images/           { return 200 "D\n"; }
    location ~* \.(gif|jpg|jpeg)$  { return 200 "E\n"; }
}

Lima permintaan ini menghasilkan lima jawaban berbeda:

Permintaan	Pemenang	Alasan
/	A	Kecocokan persis. Pencarian langsung berakhir.
/index.html	B	Tidak ada regex yang cocok, jadi prefiks yang diingat yang dipakai.
/documents/document.html	C	Prefiksnya lebih panjang daripada /.
/images/1.gif	D	^~ memenangi tahap prefiks, jadi regex tidak pernah berjalan.
/documents/1.jpg	E	Regex mengalahkan prefiks yang lebih panjang tetapi tanpa ^~.

Bandingkan dua baris terakhir. /images/ dan /documents/ sama-sama prefiks, dan keduanya jadi kecocokan terpanjang bagi permintaannya masing-masing. Satu permintaan jatuh ke blok prefiks, satunya lagi jatuh ke regex. Bedanya cuma dua karakter.

Langkah 2 adalah bagian yang sering dilewati orang: nginx tidak memakai prefiks terpanjang, ia hanya mengingatnya. Blok itu baru berstatus kandidat, dan fase regex masih bisa merebut permintaannya. Hanya langkah 1, 3, dan 4 yang mengakhiri pencarian.

Mengapa “prefiks terpanjang” dihitung per karakter, bukan per segmen path

Perbandingan prefiks adalah perbandingan string biasa. Ia tidak tahu bahwa / memisahkan segmen path, dan ia tidak berhenti di batas segmen. Dengan konfigurasi ini:

server {
    location /static  { }
    location /static/ { }
}

permintaan ke /staticfoo dilayani oleh location /static. URI-nya diawali tujuh karakter itu, jadi cocok. /static/ sama sekali tidak cocok, karena tidak ada garis miring di posisi tersebut. Permintaan ke /static/x berjalan sebaliknya dan mengambil /static/, yang lebih panjang di antara keduanya.

Konsekuensinya, location /static juga menguasai /static-backup, /staticfiles, dan apa pun yang kebetulan diawali huruf yang sama. Kalau yang Anda maksud memang sebuah direktori, tulis garis miring di akhir lalu tambahkan location persis untuk path telanjangnya:

server {
    location /static/ { root /var/www; }
    location = /static { return 301 /static/; }
}

Sebagian besar tutorial memakai contoh path yang rapi sehingga hal ini tidak pernah terlihat, dan itulah sebabnya ia begitu sering lolos dari code review. Penguji nginx location menampilkan setiap blok yang cocok beserta jumlah karakter yang dicocokkan masing-masing, jadi Anda bisa melihat langsung prefiks mana yang menelan saudaranya.

Apa Arti ^~ Sebenarnya (dan Apa yang Bukan)

Deskripsi yang paling sering beredar tentang modifier ^~ di location nginx adalah “modifier ini membuat blok tersebut lebih diprioritaskan daripada regex”. Kalimat itu cukup dekat dengan kebenaran untuk menyesatkan orang.

Yang sebenarnya dilakukan ^~ selama perbandingan prefiks berlangsung: sama sekali tidak ada. Ia tidak memperpanjang kecocokan, dan tidak mengangkat bloknya di atas prefiks lain saat nginx menentukan prefiks mana yang diingat. Nginx baru memeriksanya setelah itu, pada satu prefiks yang sudah menang berdasarkan panjang. Kalau pemenang itu membawa ^~, nginx melewati fase regex. Kalau tidak, fase regex berjalan seperti biasa.

Artinya, prefiks polos yang lebih panjang diam-diam melumpuhkannya:

server {
    location ^~ /a/    { }
    location /a/b/     { }
    location ~ \.php$  { }
}

Permintaan ke /a/b/x.php ditangani oleh ~ \.php$. /a/b/ adalah prefiks cocok terpanjang, jadi itulah yang diingat nginx; modifier polosnya mengizinkan fase regex; regex cocok lebih dulu dan merebut permintaan itu. Blok ^~ tetap ada di file dan tetap terlihat protektif, padahal ia sama sekali tidak berpengaruh pada permintaan ini.

Ubah URI-nya menjadi /a/x.php dan konfigurasi yang sama berperilaku sepenuhnya berbeda: sekarang ^~ /a/ yang jadi kecocokan terpanjang, nginx melewati fase regex, dan blok ^~ menang. File yang sama dan bentuk permintaan yang sama bisa berujung pada hasil yang berlawanan.

Bedanya berakibat nyata. Penggunaan klasik ^~ adalah menjauhkan direktori yang bisa ditulisi dari sebuah interpreter:

server {
    location ^~ /uploads/ { }
    location ~ \.php$     { fastcgi_pass unix:/run/php-fpm.sock; }
}

Hapus ^~ dan permintaan ke /uploads/evil.php meluncur lurus ke PHP-FPM. Itulah pola di balik deretan panjang laporan upload-to-RCE, dan jarak antara rentan dan aman cuma dua karakter. Itu juga sebabnya kasus “^~ yang dilumpuhkan” penting: menambahkan prefiks polos yang lebih panjang seperti location /uploads/thumbs/ membuka kembali lubang itu untuk semua yang ada di bawahnya, dan diff yang melakukannya terlihat sama sekali tidak berbahaya.

Perhatikan cakupannya juga. ^~ hanya menekan regex yang dideklarasikan pada levelnya sendiri; ia tidak pernah menekan regex yang bersarang di dalam bloknya sendiri, dan ^~ pada location bersarang tidak bisa melindungi dari regex yang dideklarasikan di level server. Coba aktif-nonaktifkan modifier itu di penguji nginx location lalu perhatikan pemenangnya berubah. Alat itu memberi label pada setiap regex yang dilewati, jadi blok yang kalah tetap kelihatan di tabel.

Location Regex: Urutan Mengalahkan Spesifisitas

Regex pada location nginx memakai ~ untuk pencocokan yang peka huruf besar-kecil dan ~* untuk yang abai huruf besar-kecil. Sebaliknya, pencocokan prefiks di Linux selalu peka huruf besar-kecil. (Pada filesystem yang abai huruf besar-kecil seperti macOS, nginx membandingkan prefiks secara abai huruf besar-kecil dan memaksa setiap location regex berperilaku seperti ~*. Kalau Anda mengembangkan di Mac lalu men-deploy ke Linux, perbedaan itu bisa menyembunyikan aturan yang rusak sampai ia terlanjur rilis.)

Aturan yang menjebak banyak orang adalah yang ini: nginx mengevaluasi regex sesuai urutan kemunculannya di file konfigurasi, dan kecocokan pertama mengakhiri pencarian. Spesifisitas pola, panjangnya, maupun anchoring-nya tidak berpengaruh sama sekali terhadap urutan itu.

server {
    location ~ ^/a       { }
    location ~ ^/a/b/c$  { }
}

Permintaan ke /a/b/c diambil oleh ~ ^/a. Blok kedua cocok persis dengan URI-nya, jauh lebih presisi, dan tidak akan pernah jalan untuk permintaan apa pun. Itu konfigurasi mati yang diterima nginx -t tanpa sepatah kata pun.

Jadi kebiasaan yang perlu dibangun: urutkan regex dari yang paling spesifik ke yang paling umum, dan jaga daftarnya tetap pendek. Pola yang luas di bagian atas membuat semua yang ada di bawahnya tak terjangkau, dan karena diff yang cuma menukar urutan baris terbaca tidak berbahaya, regresinya cenderung muncul saat beres-beres, bukan saat menggarap fitur.

Anchoring pantas mendapat kehati-hatian yang sama. location ~ /admin tidak punya anchor di ujung mana pun, jadi ia mencari di posisi mana saja dalam URI dan dengan senang hati cocok dengan /public/admin/x. Tulis ~ ^/admin kalau yang Anda maksud adalah awal URI. Anchor hanya di akhir, seperti pada ~ \.php$, wajar dan benar untuk perutean berdasarkan ekstensi.

Beberapa detail PCRE yang sering ditebak salah oleh intuisi ala JavaScript:

• nginx mengompilasi pola location dengan PCRE, tanpa mode UTF maupun multiline, jadi pola bekerja pada level byte dan ^ hanya menempel ke awal URI.
• $ pada PCRE juga cocok tepat sebelum newline di akhir. URI yang berakhir dengan %0A tetap memenuhi \.php$, dan itu cara yang sudah dikenal untuk menyelinap melewati aturan yang bertumpu pada ekstensi file.
• Konstruksi yang tidak punya padanan di JavaScript cukup umum di PCRE: atomic group (?>…), quantifier posesif a*+, modifier inline seperti (?i), kelas POSIX seperti [[:alpha:]], dan escape seperti \A, \z, \K, dan \Q…\E.
• Pola yang mengandung { atau } harus diberi tanda kutip. location ~ ^/a{2}$ gagal dimuat dengan pesan unknown directive "2}$", karena kurung kurawal keburu mengakhiri token. Tulis location ~ "^/a{2}$".

Capture group bekerja persis seperti yang Anda harapkan, dan $1 dan seterusnya tersedia di dalam blok:

upstream backend {
    server 127.0.0.1:8080;
}

server {
    location ~ ^/user/(\d+)/profile$ {
        proxy_pass http://backend/profiles/$1;
    }
}

Kalau Anda masih men-debug polanya sendiri, bukan posisinya di dalam file, uji dulu di penguji regex; cheat sheet regex membahas sintaksnya secara mendalam.

Langkah yang Semua Orang Lewatkan: Normalisasi URI

Sebelum memeriksa satu pun location, nginx menulis ulang target permintaan. Pola Anda diadu dengan path yang sudah dinormalisasi, bukan dengan byte yang tiba di kabel. Hampir tidak ada tutorial yang menyinggung ini, padahal justru inilah yang menentukan cukup banyak kasus “location saya tidak cocok”.

Normalisasi melakukan empat hal: memisahkan query string, mendekode persen pada path, menyelesaikan segmen . dan .., serta merapatkan garis miring berulang.

Target permintaan	$uri ternormalisasi	Catatan
//a//x	/a/x	Garis miring berulang digabung
/a/../b/x	/b/x	.. diselesaikan sebelum pencocokan
/a/b%2F..%2Fzz	/a/zz	%2F didekode jadi pemisah sungguhan dan ikut dalam resolusi
/a/%2e%2e/b/x	/b/x	%2E didekode jadi titik yang ikut berperan
/a%20b/x	/a b/x	%20 menjadi spasi sungguhan
/a+b/x	/a+b/x	+ bukan spasi di dalam path
/a?x=/b	/a	Query string dipisahkan lebih dulu
/a%3Fx=1	/a?x=1	%3F tetap literal; query string-nya kosong

Tiga karakter hasil dekode jadi pengecualian: nginx menuliskan %25, %23, dan %3F kembali apa adanya, tanpa menafsirkannya ulang. Itulah sebabnya /a%3Fx=1 berakhir dengan tanda tanya di dalam path dan $args yang kosong.

Dua bentuk target bahkan tidak pernah sampai ke tahap seleksi location. Segmen .. yang memanjat melewati root dan escape tidak valid seperti %00 sama-sama dijawab 400 sebelum pencocokan dimulai.

Bagian ini penting kalau Anda memakai blok location sebagai batas kontrol akses, karena path yang Anda tulis diadu dengan path hasil resolusi:

server {
    location /a/ { }
    location /b/ { }
}

Permintaan ke /a/b%2F..%2Fzz tidak tinggal di bawah /a/b/. Ia ternormalisasi menjadi /a/zz dan ditangani oleh location /a/. Bernalar berdasarkan target mentah alih-alih $uri memberi jawaban yang salah di sini, dan “jawaban yang salah” dalam konteks kontrol akses punya nama tersendiri. Sebelum Anda mengandalkan location /admin untuk melindungi apa pun, pastikan dulu seperti apa path ternormalisasinya. Penguji nginx location menampilkan target mentah, $uri ternormalisasi, dan query string yang dipisahkan sebagai tiga baris tersendiri. Kalau yang Anda perlukan cuma soal encoding, URL decoder menangani bagian itu saja.

Satu konsekuensi lagi yang sering luput: query string tidak pernah ikut dalam pencocokan. location /search?q= tidak mungkin cocok dengan permintaan ke /search?q=1, karena seleksi hanya pernah melihat /search. Untuk bercabang berdasarkan parameter, baca $arg_name di dalam blok.

Lima Konfigurasi yang Tidak Bekerja Seperti Dugaan Anda

Blok ^~ yang kalah oleh prefiks polos yang lebih panjang

Gejala: direktori ^~ terlihat terlindungi, tetapi regex tetap menangani permintaan di dalamnya. Penyebab: nginx hanya memeriksa ^~ pada prefiks yang sudah menang berdasarkan panjang. Prefiks polos yang lebih panjang justru yang diingat, dan ia tidak menekan apa pun. Perbaikan: pasang ^~ pada prefiks yang lebih panjang juga, atau hapus prefiks yang lebih panjang itu.

# Broken: /a/b/x.php goes to the regex
location ^~ /a/    { }
location /a/b/     { }
location ~ \.php$  { }

# Fixed: /a/b/x.php goes to ^~ /a/b/
location ^~ /a/    { }
location ^~ /a/b/  { }
location ~ \.php$  { }

Prefiks tanpa garis miring di akhir yang menelan saudaranya

Gejala: blok yang diniatkan untuk satu direktori juga melayani path yang cuma kebetulan diawali huruf yang sama. Penyebab: pencocokan prefiks membandingkan karakter, bukan segmen path, jadi location /app juga cocok dengan /application. Perbaikan: tulis garis miring di akhir, lalu tambahkan location = /app kalau path telanjangnya juga perlu ditangani.

Regex spesifik yang ditaruh di bawah regex luas

Gejala: aturan yang presisi tidak pernah aktif, dan tidak ada error yang muncul di mana pun. Penyebab: nginx mencoba regex sesuai urutan file dan kecocokan pertama mengakhiri pencarian, jadi semua yang berada di bawah pola luas jadi tak terjangkau. Perbaikan: pindahkan pola spesifik ke atas pola luas, atau perketat pola luasnya dengan anchor.

Regex yang ditulis setelah ^~

Gejala: aturan deny termuat mulus tetapi tidak memblokir apa pun. Penyebab: ^~ menerima prefiks literal, bukan pola. nginx tidak pernah protes; bloknya memang tidak pernah cocok dengan URI mana pun. Perbaikan: gunakan modifier regex.

# Broken: matches nothing, loads without error
location ^~ "\.php$" { deny all; }

# Fixed
location ~ \.php$ { deny all; }

Menganggap query string ikut serta

Gejala: location yang mengandung ? tidak pernah cocok. Penyebab: normalisasi memisahkan query string lebih dulu, dan seleksi location hanya berjalan terhadap path. Perbaikan: cocokkan berdasarkan path, lalu periksa $arg_name di dalam blok.

location /search {
    if ($arg_q = "") { return 400; }
}

Debugging: Cari Tahu Blok Mana yang Benar-Benar Menang

Log debug memberi jawaban paling otoritatif, sekaligus paling repot disiapkan: butuh binary yang dibangun dengan dukungan debug. Periksa dulu:

nginx -V 2>&1 | grep -o with-debug

Lalu aktifkan dan grep baris yang menyebut blok terpilih:

error_log /var/log/nginx/debug.log debug;

grep "using configuration" /var/log/nginx/debug.log

Probe lewat response header lebih cepat dan tidak menuntut build debug. Tandai setiap kandidat, lalu baca kembali header-nya:

location ^~ /uploads/ {
    add_header X-Debug-Location "uploads-caret" always;
    return 204;
}
location ~ \.php$ {
    add_header X-Debug-Location "php-regex" always;
    return 204;
}

curl -sI --path-as-is 'http://localhost/uploads/evil.php' | grep -i x-debug-location

--path-as-is itu penting: tanpanya curl dengan senang hati menyelesaikan .. untuk Anda, dan Anda berakhir menguji URI yang berbeda dari yang Anda maksud. Kalau Anda sedang merangkai sesuatu yang lebih rumit, generator perintah cURL menuliskan flag-nya untuk Anda, dan contekan curl mencakup sisanya. Kalau probe-nya balik berupa redirect atau 404 alih-alih header Anda, rujukan kode status HTTP biasanya bisa memberi tahu modul mana yang menghasilkannya.

nginx -T mencetak konfigurasi yang sudah tergabung sepenuhnya, lengkap dengan semua file include. Begitulah cara Anda mengetahui urutan regex Anda yang sebenarnya setelah enam file dirakit jadi satu, dan urutan itu jarang sama dengan urutan di file yang sedang Anda sunting.

nginx -T | grep -n "location"

Reproduksi kegagalannya di penguji nginx location sebelum Anda menyunting server. Beriterasi terhadap konfigurasi yang belum Anda deploy lebih cepat daripada satu siklus reload, dan tabel keputusannya menyebut pada tahap mana setiap blok tersingkir.

Location Bersarang, try_files, dan Apa yang Tidak Mereka Ubah

Location bersarang menjalankan algoritma yang sama satu level lebih dalam. Begitu sebuah location prefiks menang, nginx turun ke anak-anaknya dan mengulang pencarian di sana, jadi ia mencoba regex bersarang sebelum regex di level induk:

server {
    location ~ \.php$ { }
    location /a/ {
        location ~ \.php$ { return 200 "nested\n"; }
    }
}

/a/x.php ditangani oleh blok bersarang. Penyarangan juga punya efek yang kurang kentara: ia bisa membuat prefiks yang secara global lebih panjang jadi tak terjangkau, karena nginx hanya masuk ke pemenang di tiap level. Kalau location /a/bb/ bersarang di dalam location /a/, dan ada saudara location /a/b di level luar, permintaan ke /a/bb/x jatuh ke /a/b. Perbandingan di level luar terjadi lebih dulu, dan /a/b memenangkannya. Penelusuran ke dalam yang tidak menemukan apa-apa juga tidak mundur kembali; induknya tetap memegang permintaan itu.

try_files dan rewrite bukan bagian dari seleksi. Keduanya berjalan di dalam blok yang sudah menang, dan tidak bisa menjangkau balik untuk mengubah hasilnya. Kalau sebuah permintaan tidak pernah tiba di blok yang memuat try_files Anda, direktif itu tidak relevan, dan biang keladinya biasanya regex ~ \.php$ yang merebut permintaan sebelum blok prefiks sempat dapat giliran. Ada satu pengecualian: redirect internal (rewrite … last, atau lompatan error_page) memulai ulang pencocokan, sehingga URI hasil penulisan ulang diadu lagi dengan daftar location dari awal.

Terakhir, 301 yang Anda dapat saat meminta sebuah direktori tanpa garis miring di akhir bukanlah kegagalan pencocokan. Ada dua mekanisme terpisah yang menghasilkannya. Kalau sebuah location yang namanya berakhir dengan / membawa proxy_pass atau direktif *_pass lain, permintaan ke path yang sama tanpa garis miring dijawab dengan 301 saat seleksi, sebelum regex mana pun dievaluasi, dan query string tetap dipertahankan:

server {
    location /user/ { proxy_pass http://backend/; }
}
# GET /user?x=1  ->  301 to /user/?x=1

Menambahkan location = /user mematikan redirect itu. Terpisah dari itu, modul static file mengeluarkan 301-nya sendiri ketika sebuah path merujuk ke direktori nyata di disk, dan itu bergantung pada filesystem Anda, bukan pada konfigurasi Anda.

FAQ

Apa saja lima modifier location nginx?

Lima modifier location nginx adalah = untuk pencocokan persis, ^~ untuk prefiks yang melewati fase regex, tanpa modifier untuk prefiks biasa, ~ untuk regex yang peka huruf besar-kecil, dan ~* untuk yang abai huruf besar-kecil. Bentuk keenam, location @name, tidak pernah ikut dalam pencocokan URI dan hanya ada sebagai target bagi error_page dan try_files.

Apakah kecocokan persis = membuat nginx lebih cepat?

Location dengan kecocokan persis langsung mengakhiri pencarian, melewati pemindaian prefiks dan seluruh evaluasi regex. Penghematannya nyata, tetapi terlalu kecil untuk terasa. Ia layak ditulis untuk endpoint yang dihantam ribuan kali per detik, seperti health check atau /favicon.ico. Setumpuk blok = untuk halaman biasa lebih banyak menambah kerumitan konfigurasi daripada manfaat yang dibawanya.

Bisakah saya menulis modifier location tanpa spasi, seperti ~*^/api?

Bisa. location ~*^/api/ dan location ~* ^/api/ berarti persis sama, karena nginx memotong modifier dari depan nama dan mencocokkan modifier terpanjang lebih dulu, sehingga ~* dikenali sebelum ~. Beri spasi juga tidak ada ruginya. Modifier yang menempel terbaca seperti bagian dari pola, dan orang yang me-review konfigurasi Anda gampang salah membacanya.

Apa beda root dan alias di dalam blok location?

root menambahkan seluruh URI ke direktorinya, sedangkan alias menggantikan prefiks yang cocok dengan direktori itu. Dengan location /static/ { root /var/www; } permintaan ke /static/x.css mencari /var/www/static/x.css; ganti ke alias /var/www/assets/; dan ia mencari /var/www/assets/x.css. Dengan alias, beri garis miring di akhir pada location dan path sekaligus, atau jangan beri sama sekali pada keduanya.

Bisakah satu permintaan cocok dengan lebih dari satu blok location?

Beberapa blok bisa cocok, tetapi tepat satu yang menangani permintaan. nginx membandingkan setiap location prefiks dan, bila perlu, setiap location regex, lalu menyerahkan permintaan itu ke satu-satunya pemenang. Blok yang kalah tidak mewariskan direktifnya, jadi apa pun yang Anda butuhkan di mana-mana harus tinggal di level server atau http, atau Anda tulis ulang di tiap blok.

Apakah nginx -t memberi tahu location mana yang akan cocok?

Tidak. nginx -t memeriksa sintaks dan validitas konfigurasi; ia tidak pernah menyimulasikan permintaan, jadi ia tidak melaporkan apa pun soal urutan pencocokan. Untuk mengetahui blok mana yang memiliki sebuah URI, baca log debug, tambahkan response header sementara, atau tempelkan konfigurasinya ke penguji nginx location lalu baca alasan setiap blok menang atau kalah.