All Products
Search

This Product

    CDN:Mengonfigurasi waktu kedaluwarsa cache CDN

    Document Center

    CDN:Mengonfigurasi waktu kedaluwarsa cache CDN

    Last Updated:Jun 11, 2026

    Dengan mengonfigurasi aturan kedaluwarsa cache, Anda dapat mengontrol durasi caching resource di titik kehadiran (POP) CDN guna menyeimbangkan kesegaran konten, kinerja akses, dan biaya pengambilan asal. Dokumen ini menjelaskan cara mengonfigurasi dan memvalidasi aturan cache, memberikan panduan troubleshooting, serta merinci praktik terbaik.

    Cara kerja

    Ketika permintaan mencapai titik kehadiran (POP) CDN, sistem menggunakan proses berprioritas berikut untuk menentukan apakah akan menyajikan salinan dari cache atau mengambil konten terbaru dari origin server.

    1. CDN tidak melakukan cache resource jika origin server merespons dengan pragma:no-cache, cache-control:no-cache (atau no-store, atau max-age=0).

    2. Aturan cache yang dikonfigurasi di Konsol CDN memiliki prioritas lebih tinggi, kecuali jika origin server secara eksplisit mengirimkan direktif no-cache seperti yang dijelaskan di atas.

      • Logika prioritas saat beberapa aturan cache di Konsol cocok dengan satu permintaan:

        Skenario

        Logika prioritas

        Contoh

        Bobot berbeda

        Aturan dengan bobot lebih tinggi (1–99) memiliki prioritas lebih tinggi.

        Aturan A (direktori /image/, bobot 50) dan Aturan B (ekstensi file .jpg, bobot 90) sama-sama cocok dengan image/a.jpg. Aturan B diterapkan karena memiliki bobot lebih tinggi.

        Bobot sama

        Aturan yang dibuat lebih awal memiliki prioritas lebih tinggi.

        Anda mengonfigurasi aturan direktori (/static/) dan aturan ekstensi file (.js) untuk sebuah nama domain, keduanya dengan bobot 60. Jika aturan direktori dibuat sebelum aturan ekstensi file, permintaan untuk /static/app.js akan cocok dengan aturan direktori.

      • Saat permintaan cocok dengan satu aturan cache, tidak ada aturan lain yang dievaluasi.

      • Secara default, jika origin server merespons dengan Pragma: no-cache atau Cache-Control: no-cache/no-store/max-age=0, POP CDN tidak menyimpan resource tersebut dalam cache. Untuk memaksa caching, pilih Ignore Origin No-Cache Header saat mengonfigurasi aturan kedaluwarsa cache.

    3. CDN menghormati header respons HTTP dari origin server jika permintaan tidak cocok dengan aturan apa pun di Konsol CDN, atau jika aturan yang cocok memiliki opsi Honor Origin TTL diaktifkan. Prioritas header respons, dari tertinggi ke terendah, adalah sebagai berikut: cache-control > expires > last-modified > ETag.

      Header respons

      CDN penanganan

      Catatan dan contoh

      Cache-Control

      Menggunakan s-maxage (durasi cache CDN) terlebih dahulu, lalu max-age.

      Contoh: s-maxage=86400, max-age=3600

      Expires

      Menentukan waktu kedaluwarsa. Ini hanya digunakan jika header Cache-Control tidak ada.

      Contoh: Expires: Wed, 21 Oct 2025 07:28:00 GMT

      Last-Modified

      Header Last-Modified adalah timestamp yang menunjukkan kapan resource terakhir dimodifikasi.

      Durasi cache dihitung sebagai berikut:

      (Waktu Saat Ini – last-modified) × 0,1. Durasi yang dihitung kemudian dibatasi antara minimum 10 detik dan maksimum 3.600 detik.

      Contoh: Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT

      ETag

      ETag adalah pengenal unik yang dihasilkan oleh server untuk versi spesifik suatu resource, biasanya berupa hash atau nomor versi.

      Secara default, resource dengan ETag di-cache selama 10 detik.

      Contoh: ETag: "abc123"

    4. Kebijakan no-cache CDN: Jika permintaan tidak cocok dengan aturan cache apa pun di Konsol CDN dan server origin tidak mengembalikan header respons cache seperti Cache-Control, maka CDN menerapkan kebijakan no-cache.

    Catatan

    CDN hanya menerapkan kebijakan cache untuk permintaan yang mengembalikan kode status 200, 203, 206, 300, 301, 308, atau 410 dari origin server. Untuk menyimpan respons dengan kode status lain—seperti 404—dalam cache, Anda harus mengonfigurasi perilaku tersebut di Cache Configuration > Status Code Expiration.

    Prosedur

    Konsol (disarankan)

    1. Di Konsol CDN, buka halaman Domain Names dan klik Manage di samping nama domain target.

    2. Di halaman Cache > Cache Expiration, klik Add untuk mengonfigurasi aturan cache.

      image

      Parameter

      Deskripsi

      Default/contoh

      Type

      Tentukan cakupan aturan berdasarkan Directory atau File Extension.
      • Directory: Menetapkan aturan cache seragam untuk semua resource di bawah path tertentu.
      • File Extension: Menetapkan aturan cache seragam untuk file dengan tipe tertentu.

      Directory, File Extension

      Object

      Masukkan nilai berdasarkan tipe yang dipilih:
      • Directory: Harus diawali garis miring maju (/), misalnya /static/. Satu garis miring maju (/) cocok dengan semua path. Anda hanya dapat menambahkan satu direktori dalam satu waktu.
      • File Extension: Masukkan satu atau beberapa ekstensi file, dipisahkan koma, misalnya jpg,png,css. Entri bersifat case-sensitive dan tidak mendukung simbol vertikal (|) atau simbol lainnya.

      /static/, jpg,png,css

      Expire In

      Durasi cache untuk resource di POP. Durasi maksimum adalah tiga tahun.
      • Untuk resource statis yang jarang diperbarui (misalnya, gambar, installer), tetapkan durasi ≥ 1 bulan.
      • Untuk resource statis yang sering diperbarui (misalnya, file JS/CSS), tetapkan durasi lebih pendek, seperti 1 hingga 7 hari.
      • Untuk konten dinamis (misalnya, halaman PHP/JSP), tetapkan durasi menjadi 0 detik (tidak di-cache).


      0 detik hingga 3 tahun

      Honor Origin TTL

      Secara default dinonaktifkan. Jika diaktifkan, kebijakan cache origin server memiliki prioritas lebih tinggi dan menggantikan aturan ini.

      Off

      Ignore Origin No-Cache Header

      Jika diaktifkan, CDN mengabaikan direktif no-cache berikut dari origin server: Cache-Control: no-store, no-cache, atau max-age=0, dan Pragma: no-cache. Resource di-cache sesuai aturan di Konsol.

      Off

      Follow POP Cache Policy

      Jika diaktifkan, CDN mengembalikan kebijakan cache efektifnya, seperti max-age=3600, ke klien dalam header respons.

      Off

      Force Revalidation

      Pengaturan ini hanya berlaku ketika waktu kedaluwarsa diatur ke 0 detik.
      • Dinonaktifkan (default, setara dengan kebijakan cache no-store): POP tidak melakukan cache file, dan setiap permintaan harus diteruskan ke origin server untuk mengambil konten.
      • Diaktifkan (setara dengan kebijakan cache no-cache): POP melakukan cache file, tetapi setiap permintaan harus divalidasi ulang dengan origin server menggunakan mekanisme 304. Ini berguna untuk skenario yang memerlukan validasi real-time namun tetap ingin mengurangi tekanan bandwidth pada origin server.

      Off

      Weight

      Prioritas aturan. Nilainya berkisar antara 1 hingga 99, di mana nilai lebih tinggi menunjukkan prioritas lebih tinggi. Saat beberapa aturan cocok dengan resource yang sama, aturan dengan bobot lebih tinggi memiliki prioritas lebih tinggi. Jika bobotnya sama, aturan yang dibuat lebih awal memiliki prioritas lebih tinggi. Kami menyarankan menetapkan bobot tinggi untuk path atau ekstensi file spesifik dan bobot rendah untuk direktori root (/) untuk mencapai kontrol detail halus.

      1 hingga 99

      Rule Condition

      Persempit lebih lanjut cakupan aturan berdasarkan parameter permintaan seperti header dan parameter URL. Secara default tidak digunakan. Untuk mengonfigurasi kondisi, gunakan Rule Engine. Saat kondisi aturan dirujuk, pencocokan didasarkan pada prioritas kondisi terkait, bukan urutan konfigurasi fitur itu sendiri.

      Do not use

    Logika pencocokan aturan cache

    Aturan kedaluwarsa cache CDN mendukung dua tipe aturan dengan perilaku pencocokan berbeda:

    • Directory: Menggunakan pencocokan prefiks path. Misalnya, mengonfigurasi /static/ cocok dengan semua resource di bawah direktori tersebut (seperti /static/image/1.jpg dan /static/css/style.css). Mengonfigurasi / cocok dengan semua path. Path direktori harus diawali garis miring maju (/). Setiap aturan hanya mendukung satu direktori.

    • File Extension: Menggunakan pencocokan ekstensi eksak. Masukkan ekstensi tanpa titik, dan pisahkan beberapa ekstensi dengan koma (misalnya, jpg,css,js). Ekstensi hanya mendukung karakter alfanumerik, tanpa batasan tipe ekstensi tertentu. Tipe-tipe berikut semuanya dapat dikonfigurasi:

      • Ekstensi resource statis umum: jpg, png, gif, css, js, html

      • Ekstensi file font: ttf, otf, woff, woff2, eot

      • Ekstensi halaman dinamis: php, aspx, jsp

      • Ekstensi alfanumerik lainnya

    Catatan

    Perhatikan hal-hal berikut mengenai pencocokan aturan cache:

    • Saat beberapa aturan cache cocok dengan permintaan yang sama (misalnya, aturan direktori dan aturan ekstensi file), aturan dengan Weight lebih tinggi memiliki prioritas lebih tinggi. Aturan dengan bobot sama diselesaikan berdasarkan urutan pembuatan (aturan yang lebih awal menang). Untuk detailnya, lihat bagian "Cara kerja" di atas.

    • Jika Anda mengaitkan kondisi aturan (dikonfigurasi di Rule Engine) dengan aturan cache, beberapa kondisi menggunakan logika AND — permintaan harus memenuhi semua kondisi agar cocok.

    • Jika Anda menetapkan aturan no-cache umum untuk semua ekstensi dinamis (seperti aspx), pastikan hal tersebut tidak memengaruhi resource statis yang ingin Anda cache. Untuk melakukan cache file font, tambahkan aturan khusus dengan ekstensi seperti ttf,otf,woff,woff2,eot.

    API

    Panggil operasi API BatchSetCdnDomainConfig untuk mengonfigurasi beberapa nama domain secara batch. Untuk informasi lebih lanjut tentang cara mengonfigurasi parameter untuk fitur lain, lihat Domain name configuration functions.

    Terapkan perubahan aturan segera

    Aturan baru atau yang dimodifikasi hanya berlaku untuk resource yang baru di-cache. Resource yang telah di-cache sebelumnya tetap menggunakan kebijakan cache lama hingga masa berlakunya habis.

    Untuk menerapkan aturan baru secara langsung di seluruh jaringan, Anda harus membersihkan cache yang ada secara manual. Jika Anda mengubah aturan, lakukan operasi purge menggunakan fitur Purge and Prefetch resources. Jika Anda menambahkan aturan baru, lakukan operasi prefetch menggunakan fitur prefetch resource.

    Verifikasi

    Setelah menyelesaikan konfigurasi, Anda dapat menggunakan perintah curl atau alat developer browser untuk memeriksa header respons HTTP suatu resource guna memverifikasi bahwa caching berfungsi sesuai harapan.

    1. Jalankan perintah verifikasi

    Jalankan perintah berikut di terminal Anda untuk menguji konfigurasi.

    curl -I "https://your.domain.com/path/to/file.jpg"

    2. Interpretasi header respons utama

    Header respons

    Deskripsi

    X-Cache

    Menunjukkan apakah permintaan mengenai cache CDN.
    - HIT: Cache hit.
    - MISS: Cache miss. Resource diambil dari origin.

    Cache-Control

    Setelah Anda mengaktifkan "Client Follows CDN Cache Policy", header ini menampilkan direktif caching yang diteruskan CDN ke browser, seperti max-age=3600.

    X-Swift-CacheTime

    Total durasi cache yang dikonfigurasi untuk resource di POP, dalam detik.

    Praktik terbaik

    • Gunakan nama file berbasis versi (disarankan): Saat memperbarui resource statis seperti style.css, gunakan nama file baru yang mencakup versi atau hash, misalnya style-v2.css atau style-a1b2c3d.css, lalu perbarui referensinya di HTML Anda. Pendekatan ini memastikan pengguna langsung menerima konten terbaru tanpa perlu membersihkan cache CDN secara manual, sehingga menjadi metode yang direkomendasikan untuk memperbarui konten yang di-cache.

    • Terapkan pemisahan konten dinamis dan statis: Gunakan nama domain atau path direktori berbeda untuk resource dinamis dan statis. Konfigurasikan aturan cache terpisah dengan bobot tinggi untuk masing-masing guna menghindari konflik kebijakan. Misalnya, tetapkan durasi cache panjang untuk semua resource di direktori /static/ dan nonaktifkan cache untuk resource di direktori /api/.

    • Manfaatkan cache browser secara efektif: Aktifkan opsi "Client follows CDN cache policy" untuk mengurangi permintaan berulang ke CDN, mempercepat pemuatan, dan menghemat trafik CDN.

    • Hindari durasi cache yang terlalu pendek: Durasi cache yang singkat menyebabkan CDN sering melakukan pengambilan asal, sehingga menghilangkan manfaat akselerasi serta meningkatkan lalu lintas dan biaya pada origin server Anda.

    • Berhati-hatilah dengan durasi cache panjang: Durasi cache panjang dapat mencegah klien menerima pembaruan konten tepat waktu. Untuk konten yang perlu sering diperbarui, pastikan untuk membersihkan cache atau menggunakan nama file berbasis versi.

    • Skenario file kecil: Untuk resource file kecil di industri game (seperti file konfigurasi dan paket aset) yang jarang diperbarui (misalnya, mingguan atau dua minggu sekali), tetapkan waktu kedaluwarsa cache menjadi 15 hari atau sesuaikan dengan siklus pembaruan resource aktual. Hal ini menyeimbangkan kecepatan pembaruan dan kinerja akselerasi. Durasi cache terlalu pendek menyebabkan pengambilan asal sering terjadi dan mengurangi manfaat akselerasi; durasi terlalu panjang dapat menyajikan konten kedaluwarsa kepada pemain. Kami menyarankan menggunakan fitur purge and prefetch untuk memperbarui cache secara proaktif saat konten diperbarui.

    Mekanisme kontrol cache HTTP

    Protokol HTTP menggunakan tiga jenis header untuk kontrol cache:

    1. Validasi waktu kedaluwarsa

      Saat klien meminta resource dari server, kedua pihak menyepakati waktu kedaluwarsa untuk resource tersebut. Sebelum waktu ini, salinan cache dianggap valid. Setelah waktu ini, salinan cache menjadi tidak valid.

      Dalam HTTP, header berikut umum digunakan untuk mengontrol kedaluwarsa cache:

      Header

      Versi protokol

      Deskripsi

      Contoh

      Type

      Pragma

      HTTP/1.0

      Menunjukkan apakah konten harus di-cache. Nilainya biasanya no-cache, artinya file tidak boleh di-cache. Sering digunakan untuk kompatibilitas dengan server yang hanya mendukung protokol HTTP/1.0.

      Pragma:no-cache

      Permintaan/Respons

      Expires

      HTTP/1.0

      Header respons Expires menentukan tanggal dan waktu ketika konten yang di-cache menjadi kedaluwarsa.

      Jika digunakan tanggal tidak valid, seperti 0, artinya resource sudah kedaluwarsa.

      Expires: Wed, 21 Oct 2022 07:28:00 GMT

      Respons

      Cache-Control

      HTTP/1.1

      Header respons Cache-Control memberikan kontrol cache fleksibel melalui berbagai direktif dan merupakan header utama yang digunakan klien modern, seperti browser, untuk tujuan ini.

      Tiga contoh berikut menunjukkan bahwa file tidak boleh di-cache:

      • Cache-Control:no-cache

      • Cache-Control:no-store

      • Cache-Control:max-age=0

      Contoh validitas cache 1 jam: Cache-Control:max-age=3600

      Permintaan/Respons

    2. Validasi tag resource

      Server menyertakan tag resource (seperti ETag) dalam respons awalnya. Saat klien meminta resource yang sama lagi, klien mengirimkan kembali tag ini ke server untuk validasi. Jika resource tidak berubah, server merespons dengan kode status HTTP 304, sehingga klien dapat menggunakan salinan cache-nya. Jika resource berubah, server mengirimkan konten baru.

      Dalam HTTP, header berikut umum digunakan untuk mengontrol versi cache:

      Header

      Versi protokol

      Deskripsi

      Contoh

      Tipe

      Last-Modified

      HTTP/1.0

      Menunjukkan waktu modifikasi terakhir resource.

      Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

      Respons

      ETag

      HTTP/1.1

      Memberikan pengenal unik untuk versi spesifik suatu resource.

      Membandingkan ETag dapat menentukan apakah resource telah berubah. Jika tidak, origin server tidak perlu mengirimkan respons lengkap.

      ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

      Respons

    3. Negosiasi konten

      Perangkat lunak caching menggunakan kunci untuk mengindeks objek yang di-cache di disk. Dalam HTTP/1.0, URL resource digunakan sebagai kunci. Namun, representasi berbeda dari suatu resource dapat ada di URL yang sama. Untuk membedakannya, diperlukan informasi tambahan dari klien, seperti header Accept-Language dan Accept-Charset. Untuk mendukung negosiasi konten, HTTP/1.1 memperkenalkan header Vary dalam pesan respons. Header ini mencantumkan header permintaan mana yang diperlukan untuk negosiasi konten.

      Negosiasi konten biasanya menggunakan header HTTP Vary untuk membedakan salinan cache yang berbeda, sehingga klien berbeda dapat menerima salinan cache berbeda saat meminta resource yang sama:

      Header

      Versi protokol

      Deskripsi

      Contoh

      Tipe

      Vary

      HTTP/1.1

      Contoh umum:

      • Server menentukan Vary: Accept-Encoding untuk memberi tahu penerima (misalnya, POP CDN) bahwa server harus menyimpan dua versi resource: terkompresi dan tidak terkompresi. Saat klien meminta resource yang sama dari CDN, browser lama dapat menerima resource tidak terkompresi untuk menghindari masalah kompatibilitas, sedangkan browser baru dapat menerima resource terkompresi untuk mengurangi trafik transfer data.

      • Server menentukan Vary: User-Agent untuk mengidentifikasi jenis browser yang mengirim permintaan. Hal ini memberi tahu penerima (misalnya, POP CDN) untuk menyimpan versi berbeda dari resource berdasarkan jenis browser.

      Vary: Accept-Encoding

      Vary: Accept-Encoding,User-Agent

      Respons

    FAQ

    Cache related FAQs