:Konfigurasikan kebijakan cache HTTP Nginx

Kasus penggunaan 1: Tetapkan caching jangka panjang untuk sumber daya statis

# Tetapkan caching jangka panjang untuk sumber daya statis
# - Untuk nama file yang berisi hash konten (misalnya, main.a1b2c3d4.js), disarankan cache 1 tahun dengan immutable.
location ~* "\.[a-f0-9]{8,}\.(css|js|png|jpg|jpeg|gif|svg|webp|ico|woff|woff2)$" {
    # Untuk sumber daya dengan hash yang dihasilkan oleh build tools: cache selama 1 tahun, browser tidak pernah melakukan revalidasi.
    add_header Cache-Control "public, max-age=31536003, immutable" always;
    access_log off;
}

# - Untuk nama file yang tetap dan jarang berubah (misalnya, logo.png), gunakan cache 30 hari.
location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|ico|woff|woff2)$ {
    # Untuk sumber daya statis umum tanpa hash: cache selama 30 hari, memungkinkan caching oleh CDN dan browser.
    add_header Cache-Control "public, max-age=2592000" always;
    access_log off;
}

Kasus penggunaan 2: Konfigurasikan kebijakan cache untuk dokumen HTML atau titik masuk Single-Page Application (SPA)

Jangan tetapkan cache jangka panjang untuk halaman HTML, terutama file entri SPA seperti index.html, karena kontennya berubah setiap kali ada Penerapan baru. Namun, untuk menyeimbangkan performa, Anda dapat mengizinkan browser menyimpan cache file tersebut dengan mewajibkannya melakukan revalidasi terhadap server sebelum setiap penggunaan.

# Untuk file HTML yang diminta langsung
location ~* \.html$ {
    # Mengizinkan caching oleh browser, tetapi mewajibkan revalidasi dengan server sebelum setiap penggunaan.
    # 'private' mencegah proxy perantara (seperti CDN) menyimpan cache respons ini.
    # Server harus menyediakan header ETag atau Last-Modified untuk mendukung validasi.
    add_header Cache-Control "private, no-cache, must-revalidate" always;
}

Kasus penggunaan 3: Nonaktifkan caching untuk konten dinamis atau informasi sensitif

Untuk konten yang dihasilkan secara dinamis atau berisi data sensitif—seperti endpoint API, halaman profil pengguna, atau halaman pembayaran—Anda harus menonaktifkan caching baik di browser maupun di semua proxy perantara, termasuk CDN dan cache bersama. Penonaktifan ini mencegah kebocoran informasi dan inkonsistensi data.

# Contoh: Untuk skrip PHP dinamis (sesuaikan path sesuai kebutuhan)
location ~ \.php$ {
    # ... Konfigurasi PHP-FPM lainnya ...

    # Nonaktifkan semua caching: Browser, proxy, dan CDN tidak boleh menyimpan respons.
    # 'no-store' adalah direktif kontrol cache paling ketat.
    add_header Cache-Control "no-store" always;
}

Mengapa perubahan Cache-Control Nginx saya tidak berlaku setelah memuat ulang konfigurasi?

Hal ini biasanya terjadi karena salah satu dari tiga alasan: respons lama sedang dilayani dari cache, Nginx belum benar-benar memuat ulang konfigurasi baru (sudo nginx -s reload), atau blok location lain memiliki prioritas lebih tinggi.

Untuk memecahkan masalah ini, ikuti langkah-langkah berikut:

1. Verifikasi respons langsung dari server. Gunakan curl untuk melewati cache browser, CDN, atau proxy apa pun dan periksa header yang dikirim langsung dari server Anda.

   curl -I http://your-url

   Ini menunjukkan header Cache-Control yang sebenarnya dikirim oleh server.

2. Pastikan konfigurasi Nginx telah dimuat ulang dengan sukses. Setelah melakukan perubahan, Anda harus menjalankan sudo nginx -s reload agar perubahan diterapkan.

3. Periksa prioritas pencocokan blok location. Nginx memproses blok location dalam urutan tertentu. Permintaan mungkin cocok dengan aturan yang lebih umum secara tak terduga. Ingat bahwa pencocokan ekspresi reguler (seperti ~* \.(css|js)$) memiliki prioritas lebih tinggi daripada pencocokan awalan (seperti location /static/). Permintaan untuk /static/app.js bisa saja salah ditangani oleh aturan regex jika muncul dalam konfigurasi Anda.

Bagaimana cara mencegah Nginx menyimpan cache endpoint API dinamis yang cocok dengan aturan aset statis?

Hal ini terjadi ketika ekspresi reguler luas untuk aset statis, seperti ~* \.js$, juga cocok dengan path API dinamis, misalnya /api/user.js.

Untuk memperbaikinya, buat aturan location Anda lebih spesifik.

1. Batasi path: location ~* ^/static/.*\.(css|js)$

2. Pastikan blok location untuk antarmuka dinamis, seperti /api/ atau \.php$, memiliki prioritas pencocokan lebih tinggi atau secara eksplisit menonaktifkan caching.

Apa cara yang benar untuk menetapkan kebijakan Cache-Control berbeda untuk jenis file berbeda tanpa konflik blok location?

Menggunakan beberapa blok location untuk menetapkan kebijakan cache berdasarkan jenis file dapat menyebabkan konflik akibat prioritas pencocokan location Nginx. Solusi yang lebih bersih dan andal adalah menggunakan map untuk menentukan logika caching berdasarkan Content-Type respons.

Solusi: Gabungkan kebijakan tersebut. Anda dapat menggunakan map untuk menetapkan cache secara dinamis berdasarkan tipe konten:

# Di blok http
map $sent_http_content_type $cache_control {
    ~^image/    "public, max-age=2592000";
    text/css    "public, max-age=2592000";
    application/javascript "public, max-age=2592000";
    default     "no-cache";
}

# Di blok server
add_header Cache-Control $cache_control always;