All Products
Search

This Product

    CDN:Mengonfigurasi waktu kedaluwarsa cache CDN

    Document Center

    CDN:Mengonfigurasi waktu kedaluwarsa cache CDN

    Last Updated:Jul 28, 2026

    Dengan mengonfigurasi aturan kedaluwarsa cache, Anda dapat mengontrol durasi penyimpanan 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

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

    1. CDN tidak menyimpan cache resource jika server origin 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 server origin 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, aturan lain tidak dievaluasi.

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

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

      Header respons

      Penanganan CDN

      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 stempel waktu 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 disimpan dalam 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 pada permintaan yang mengembalikan kode status 200, 203, 206, 300, 301, 308, atau 410 dari server origin. Untuk menyimpan cache permintaan dengan kode status lain, seperti 404, Anda harus mengonfigurasi perilaku ini 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 Create Rule untuk mengonfigurasi aturan cache.

      Parameter

      Deskripsi

      Default/contoh

      Type

      Tentukan cakupan aturan berdasarkan Directory atau File Extension.
      • Directory: Menetapkan aturan cache seragam untuk semua resource di bawah suatu path.
      • File Extension: Menetapkan aturan cache seragam untuk file jenis 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 disimpan cache).







      0 detik hingga 3 tahun

      Honor Origin TTL

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

      Off

      Ignore Origin No-Cache Header

      Jika diaktifkan, CDN mengabaikan direktif no-cache berikut dari server origin: Cache-Control: no-store, no-cache, atau max-age=0, dan Pragma: no-cache. Resource disimpan dalam 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 saat waktu kedaluwarsa diatur ke 0 detik.
      • Dinonaktifkan (default, setara dengan kebijakan cache no-store): POP tidak menyimpan cache file, dan setiap permintaan harus diteruskan ke server origin untuk mengambil konten.
      • Diaktifkan (setara dengan kebijakan cache no-cache): POP menyimpan cache file, tetapi setiap permintaan harus divalidasi ulang dengan server origin menggunakan mekanisme 304. Ini berguna untuk skenario yang memerlukan validasi real-time namun tetap ingin mengurangi tekanan bandwidth pada server origin.




      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. Disarankan 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

      Mempersempit cakupan aturan lebih lanjut 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 awalan 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 jenis ekstensi tertentu. Jenis 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 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 simpan dalam cache. Untuk menyimpan 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 disimpan dalam cache. Resource yang sudah tersimpan dalam 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 bekerja 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 dengan versi atau hash, seperti style-v2.css atau style-a1b2c3d.css, dan perbarui referensinya di HTML Anda. Metode ini memastikan pengguna menerima konten terbaru segera tanpa perlu melakukan pembersihan cache CDN secara manual, dan merupakan cara yang direkomendasikan untuk memperbarui konten yang disimpan dalam 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 "Client follows CDN cache policy" untuk mengurangi permintaan berulang ke CDN, meningkatkan kecepatan pemuatan, dan menghemat trafik CDN.

    • Hindari durasi cache terlalu pendek: Durasi cache pendek menyebabkan CDN sering melakukan pengambilan asal, yang menghilangkan manfaat akselerasi dan meningkatkan trafik serta biaya server origin 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 usang kepada pemain. Disarankan 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

      Tipe

      Pragma

      HTTP/1.0

      Menunjukkan apakah konten harus disimpan dalam cache. Nilainya biasanya no-cache, artinya file tidak boleh disimpan dalam 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 cache menjadi usang.

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

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

      Respons

      Cache-Control

      HTTP/1.1

      Header respons Cache-Control menyediakan 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 disimpan dalam 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, memungkinkan klien menggunakan salinan cache-nya. Jika resource telah 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, server origin tidak perlu mengirimkan respons lengkap.

      ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

      Respons

    3. Negosiasi konten

      Perangkat lunak caching menggunakan kunci untuk mengindeks objek yang disimpan dalam 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, memungkinkan klien berbeda menerima salinan cache berbeda saat meminta resource yang sama:

      Header

      Versi protokol

      Deskripsi

      Contoh

      Type

      Vary

      HTTP/1.1

      Contoh umum:

      • Server menentukan Vary: Accept-Encoding untuk memberi tahu penerima (misalnya, POP CDN) bahwa ia harus menyimpan cache 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 cache versi resource berbeda berdasarkan jenis browser.

      Vary: Accept-Encoding

      Vary: Accept-Encoding,User-Agent

      Respons

    FAQ

    Cache related FAQs