Belajar Nginx - Deep Dive Location Block Matching & Priority Rules

#Pendahuluan

Location block adalah otak routing NGINX. Setiap request yang masuk harus dicocokkan ke lokasi yang paling tepat, dan NGINX punya aturan prioritas yang sangat spesifik. Episode 4 ini membedah lima tipe sintaks location dan urutan evaluasinya.

Banyak bug konfigurasi berawal dari salah memahami location: konfigurasi untuk .php yang tidak pernah dieksekusi, static asset yang tertangkap block salah, atau regex yang tidak pernah dipakai. Setelah episode ini, kalian akan memahami mengapa hal itu terjadi dan bagaimana mencegahnya.

#Lima Tipe Sintaks Location Block

#Exact Match

Modifier = membuat pencocokan persis. Ini yang paling cepat dan berprioritas tertinggi:

location = /favicon.ico {
    log_not_found off;
}

location = /favicon.ico hanya cocok untuk URI /favicon.ico, bukan /favicon.ico/ atau /favicon.ico.png. Gunakan exact match untuk URI yang harus ditangani sangat cepat seperti favicon dan halaman 404.

#Preferential Prefix Match

Modifier ^~ menandai prefix match yang diprioritaskan: jika URI cocok dengan prefix ini, NGINX berhenti mencari dan tidak memeriksa regex:

location ^~ /assets/ {
    root /var/www/site;
    expires 30d;
}

#Regex Case-Sensitive dan Case-Insensitive

Modifier ~ mencocokkan pola regex secara case-sensitive, sedangkan ~* secara case-insensitive:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
 
location ~* \.(jpg|jpeg|png|gif|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

location ~ \.php$ menangkap file PHP, dan location ~* menangkap static asset dengan ekstensi apa pun tanpa peduli huruf besar atau kecil.

#Standard Prefix Match

Tanpa modifier, ini pencocokan prefix biasa. NGINX akan mengingat prefix terpanjang yang cocok:

location /docs/ {
    root /var/www;
}

#Aturan Prioritas Evaluasi Location

#Urutan Resmi NGINX

Ketika request masuk, NGINX mengevaluasi lokasi dengan urutan berikut:

1. Exact match dengan modifier = — jika cocok, langsung dipakai.
2. Prefix match dengan modifier ^~ — jika cocok dan paling panjang, dipakai dan pencarian berhenti.
3. Regex (~ dan ~*) — dievaluasi dalam urutan penulisan; regex pertama yang cocok langsung dipakai.
4. Standard prefix match terpanjang — dipakai hanya jika tidak ada regex yang cocok.

Kunci yang sering dilupakan: regex menang atas standard prefix, tapi kalah dari exact match dan preferential prefix match. Mari lihat contoh konkret.

#Studi Kasus Kombinasi Location

#Prediksi Hasil Routing

Pertimbangkan konfigurasi berikut dengan request GET /assets/img/logo.png:

server {
    listen 80;
    server_name example.com;
 
    location /assets/ {
        root /var/www/site;
    }
 
    location ~* \.(png|jpg|css|js)$ {
        expires 30d;
    }
}

Request /assets/img/logo.png cocok dengan standard prefix /assets/, dan juga cocok dengan regex ~* \.(png|jpg|css|js)$. Karena regex dievaluasi setelah prefix, NGINX memilih regex, sehingga header expires 30d berlaku. Jika kalian ingin static asset dilayani tanpa regex, tambahkan ^~:

location ^~ /assets/ {
    root /var/www/site;
    expires 30d;
}

Sekarang ^~ menang karena lebih tinggi prioritasnya dari regex. Inilah cara NGINX memutuskan block mana yang dipakai.

#Pola yang Sering Menjebak

• location / cocok dengan semua URI, jadi selalu dipakai sebagai fallback terakhir.
• Regex bersifat first match: urutan penulisan penting. Tulis regex yang lebih spesifik lebih dulu.
• Location tidak menghormati error_page tujuan yang salah jika mengarah ke URI yang cocok dengan location lain.

#Debugging Pemilihan Location

#Memanfaatkan nginx -T

Untuk melihat konfigurasi lengkap yang akan diterapkan NGINX, jalankan:

sudo nginx -T | less

nginx -T menggabungkan semua file konfigurasi setelah proses include. Kalian bisa melihat apakah location yang ditulis benar-benar berada di server block yang diharapkan.

#Mengukur dengan Access Log

Periksa access log untuk melihat status setiap request dan pastikan routing sesuai harapan:

sudo tail -f /var/log/nginx/access.log

Kombinasi nginx -T dan access log cukup untuk membongkar hampir semua misteri routing location.

#Penutup

Episode 4 membekali kalian logika routing NGINX: lima tipe location dengan modifier yang berbeda, urutan prioritas dari exact match sampai standard prefix, dan cara regex menang atas standard prefix kecuali saat ^~ ikut bermain.

Inti yang harus dibawa pulang:

• location = /path untuk exact match paling cepat.
• location ^~ /path/ memprioritaskan prefix dan menghentikan pencarian regex.
• ~ regex case-sensitive, ~* regex case-insensitive, keduanya first match.
• Standard prefix terpanjang menang bila tidak ada regex yang cocok.
• Urutan prioritas: = lalu ^~ lalu regex lalu prefix terpanjang.
• nginx -T dan access log adalah alat debugging routing terbaik.

Di episode 5 selanjutnya kita akan membahas rewrite rules, redirects, dan URL manipulation — perbedaan return dan rewrite, status 301 versus 302, flag pada rewrite, sampai pola try_files untuk routing aplikasi single page. Bersiap, karena di sinilah URL mulai "berkelahi" dengan NGINX.