Belajar Nginx - Rewrite Rules, Redirects & URL Manipulation

#Pendahuluan

Tidak selamanya URL di public tetap sama selamanya. Kadang website pindah ke domain baru, path berubah, atau framework modern membutuhkan semua request mengarah ke satu entry point. Episode 5 ini membahas rewrite rules, redirects, dan URL manipulation di NGINX.

Kalian akan belajar kapan memakai return, kapan memakai rewrite, apa beda status 301 dan 302, bagaimana flag last, break, redirect, dan permanent bekerja, serta pola try_files yang menyelamatkan semua aplikasi single page. Semua konsep ini adalah senjata paling sering dipakai di konfigurasi NGINX dunia nyata.

#return vs rewrite

#return: Cepat dan Prediktif

Directive return menghentikan pemrosesan dan mengirim respons langsung ke klien. Ini cara paling efisien untuk melakukan redirect:

server {
    listen 80;
    server_name old-example.com;
    return 301 https://example.com$request_uri;
}
 
location = /old-path {
    return 301 /new-path;
}

return 301 /new-path; mengirim status 301 beserta header Location. Karena tidak ada pemrosesan tambahan, return sangat cepat dan mudah diprediksi. Gunakan return untuk semua kasus yang tidak butuh manipulasi URL berbasis regex.

#rewrite: Manipulasi Berbasis Regex

rewrite mengganti URL dengan pola regex dan mengarahkan ulang pemrosesan:

server {
    listen 80;
    server_name example.com;
 
    rewrite ^/product/([0-9]+)$ /product.php?id=$1 last;
}

rewrite dapat mengubah URL berkali-kali dalam satu request, sehingga lebih fleksibel tapi juga lebih rawan salah. Aturan praktis: kalau cukup dengan return, jangan pakai rewrite.

#HTTP Redirect Status: 301 vs 302

#Permanen vs Sementara

• 301 Moved Permanently: memberitahu browser dan search engine bahwa URL sudah pindah selamanya. Cache browser mengingat pengalihan ini, cocok untuk migrasi domain dan pindah ke HTTPS.
• 302 Found: pengalihan sementara. URL lama tetap dianggap valid, cocok untuk redirect kondisi tertentu seperti A/B testing atau halaman maintenance.

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}
 
location /maintenance {
    return 302 https://example.com/status-page;
}

Pilih status dengan hati-hati. Salah memakai 301 saat fitur sebenarnya kembali bisa membuat browser meng-cache redirect yang salah dalam waktu lama.

#Flag pada Directive rewrite

#last, break, redirect, permanent

Directive rewrite punya empat flag:

• last: menghentikan pemrosesan rewrite saat ini dan mencari location baru yang cocok.
• break: menghentikan pemrosesan rewrite tanpa mencari location baru.
• redirect: mengirim redirect 302 (hanya berlaku saat rewrite di context server atau location).
• permanent: mengirim redirect 301.

server {
    listen 80;
    server_name example.com;
 
    rewrite ^/blog/(.+)$ /post/$1 permanent;
    rewrite ^/post/(.+)$ /post/index.php?slug=$1 break;
}

Tanpa flag, rewrite berhenti di aturan berikutnya dalam context yang sama, lalu mengevaluasi location. Pahami urutan ini agar tidak menciptakan rewrite loop yang menyebabkan status 500.

#Konfigurasi Single Page Application (SPA) Routing

#Masalah URL Framework Modern

React, Vue, Angular, dan Next.js memakai client-side routing. URL seperti /dashboard tidak ada sebagai file fisik di server — semuanya di-handle oleh JavaScript di browser. Tanpa konfigurasi khusus, memuat ulang halaman /dashboard akan menghasilkan 404.

#Solusi dengan try_files

Directive try_files mencoba daftar path secara berurutan, dan fallback ke path terakhir jika semuanya gagal:

server {
    listen 80;
    server_name app.example.com;
    root /var/www/app/dist;
    index index.html;
 
    location / {
        try_files $uri $uri/ /index.html;
    }
}

Urutan try_files $uri $uri/ /index.html; artinya: coba file persis URI, lalu coba direktori URI, dan jika keduanya tidak ada, kirim index.html. Inilah pola standar SPA. Untuk API backend, cukup tambahkan location terpisah yang meneruskan request ke reverse proxy.

#Contoh Gabungan Lengkap

#Rewrite, Redirect, dan SPA dalam Satu Server

Gambaran lengkap penggunaan ketiganya dalam satu server block:

server {
    listen 80;
    server_name example.com;
 
    return 301 https://example.com$request_uri;
}
 
server {
    listen 443 ssl;
    server_name example.com;
 
    root /var/www/app/dist;
    index index.html;
 
    location / {
        try_files $uri $uri/ /index.html;
    }
 
    location /api/ {
        proxy_pass http://localhost:3000;
    }
 
    location = /old-path {
        return 301 /new-path;
    }
}

Perhatikan pembagian kerja: return untuk redirect sederhana, try_files untuk SPA, dan proxy_pass untuk API. Setiap alat dipakai sesuai keunggulannya.

#Penutup

Episode 5 menuntaskan perang URL: kalian bisa memilih return untuk redirect cepat dan prediktif, rewrite untuk manipulasi regex, membedakan 301 dan 302, memahami empat flag rewrite, dan merutekan SPA dengan pola try_files.

Inti yang harus dibawa pulang:

• return lebih cepat dan sederhana; rewrite fleksibel tapi kompleks.
• 301 untuk permanen, 302 untuk sementara.
• Flag last, break, redirect, dan permanent mengontrol alur rewrite.
• SPA butuh try_files $uri $uri/ /index.html;.
• API dan asset statis sebaiknya dipisah lewat location tersendiri.
• Rewrite loop menghasilkan status 500 — selalu uji dengan nginx -t.

Di episode 6 selanjutnya kita akan membahas NGINX sebagai reverse proxy — perbedaan forward proxy dan reverse proxy, directive proxy_pass, penerusan header penting ke backend, serta manajemen timeout dan buffering.