CDN:FAQ Terkait Cache

Apa itu mekanisme penghapusan cache (cache eviction)?

Jika resource yang di-cache pada suatu node memiliki popularitas akses rendah—artinya jarang diakses pada node tersebut—resource tersebut dapat dihapus oleh resource yang lebih populer sebelum masa berlaku cache-nya habis.

Apa saja aturan caching default?

Saat suatu node menerima file resource dari origin server, aturan caching berikut diterapkan sesuai urutan prioritas (dari tertinggi ke terendah):

• Jika origin server merespons dengan header pragma:no-cache atau header cache-control yang bernilai no-cache, no-store, atau max-age=0, CDN akan menghormati kebijakan origin server dan tidak menyimpan resource tersebut dalam cache.

• Masa berlaku cache atau masa berlaku kode status yang dikonfigurasi di Konsol.

• Aturan caching lain yang dikonfigurasi di origin server diproses sesuai urutan prioritas berikut: cache-control > expires > last-modified > ETag.

• Jika respons origin mencakup header cache-control dengan nilai max-age atau s-maxage lebih besar dari 0, header cache-control digunakan untuk menetapkan masa berlaku cache. Contohnya: cache-control:max-age=3600. Jika keduanya—max-age dan s-maxage—ada, maka s-maxage yang didahulukan.

• Jika respons origin tidak mencakup header cache-control tetapi mencakup header Expires, header Expires digunakan untuk menetapkan masa berlaku cache. Contohnya: expires:Tue, 25 Nov 2031 17:25:43 GMT.

• Jika respons origin tidak mencakup header cache-control atau Expires tetapi mencakup header last-modified, durasi cache dihitung sebagai (Waktu Saat Ini – last-modified) × 0,1, dengan hasil dibatasi minimal 10 detik dan maksimal 3.600 detik.

• Jika respons origin tidak mencakup header cache-control, Expires, atau last-modified tetapi mencakup header ETag, resource tersebut di-cache selama 10 detik.

• Jika respons origin tidak memiliki header cache-control, expires, last-modified, atau ETag, resource tersebut tidak di-cache secara default.

Dalam kebijakan cache, apa yang dimaksud dengan "origin server"? Apakah ini mengacu pada konfigurasi OSS atau tag HTML <meta>?

"Origin server" mengacu pada header respons HTTP yang dikembalikan oleh server penyimpanan atau server aplikasi backend seperti OSS dan ECS, bukan tag <meta> dalam kode HTML.

Saat menentukan kebijakan cache, CDN hanya membaca header yang dikembalikan oleh origin server dalam respons HTTP, seperti Cache-Control dan Expires. Atribut http-equiv="Cache-Control" dalam tag HTML <meta> hanya memengaruhi browser dan tidak diurai oleh CDN.

Jika keempat sakelar konfigurasi cache (Honor Origin TTL, Ignore Origin No-Cache Header, Follow POP Cache Policy, dan Force Revalidation) dibiarkan dalam keadaan default Off, apakah perilakunya sama dengan konfigurasi sebelumnya yang hanya menetapkan waktu kedaluwarsa?

Ya. Saat keempat sakelar dimatikan (Off), cache konten berdasarkan aturan masa berlaku cache yang dikonfigurasi di Konsol, sesuai dengan perilaku lama. Untuk detail tiap sakelar, lihat deskripsi parameter di Konfigurasi Masa Berlaku Cache CDN.

Saat membuat nama domain yang dipercepat, apakah pemilihan jenis bisnis (misalnya Images & Small Files atau Large File Downloads) menerapkan kebijakan cache default?

Jenis bisnis (misalnya Images & Small Files atau Large File Downloads) yang Anda pilih saat membuat nama domain yang dipercepat memiliki dampak kecil terhadap kebijakan cache default. Tidak dilakukan pra-konfigurasi durasi cache tetap untuk ekstensi file atau jalur tertentu.

Perilaku caching aktual ditentukan oleh konfigurasi Anda di Konsol. Setelah membuat nama domain, buka Konfigurasi Masa Berlaku Cache CDN untuk mengatur aturan caching berdasarkan jenis resource dan frekuensi pembaruan Anda.

Apa perbedaan antara header respons HTTP node dan header respons HTTP origin?

Dalam arsitektur caching, header respons HTTP node dan header respons HTTP origin mengacu pada informasi header HTTP pada tahap berbeda dalam pengiriman data.

• Header respons HTTP node (header respons arah keluar): Header respons HTTP yang dikirim dari node ke client seperti browser. Jika node memiliki konten yang di-cache, konten tersebut langsung dikembalikan ke client tanpa meminta ke origin server.

• Header respons HTTP origin (header respons arah masuk): Header respons HTTP yang dikirim dari origin server ke node. Saat cache pada node kedaluwarsa atau terjadi cache miss, node melakukan origin fetch untuk mengambil konten terbaru. Header yang dikembalikan bersama konten ini dari origin server merupakan header respons HTTP origin.

Perbedaan utamanya terletak pada cakupannya: header node mengontrol perilaku caching antara client dan CDN, sedangkan header origin mengontrol perilaku caching antara origin server dan CDN. Keduanya digunakan bersama untuk mengaktifkan kontrol cache yang presisi dan efisien. Untuk informasi lebih lanjut tentang header respons arah masuk, lihat Modifikasi Header Respons Arah Masuk.

Apakah mendukung caching multi-salinan? Bagaimana cara kerjanya?

CDN mendukung caching multi-salinan secara default. Origin server harus menyertakan header Vary untuk memberi tahu node CDN header permintaan mana yang digunakan untuk membuat salinan cache terpisah.

Sebagai contoh, saat client mengirim permintaan dengan Accept-Encoding: gzip, origin server mengembalikan konten terkompresi gzip. Jika client lain mengirim Accept-Encoding: br, origin server mengembalikan konten terkompresi Brotli. Untuk menyimpan versi berbeda ini secara terpisah, origin server harus menyertakan header Vary untuk menentukan header permintaan mana yang membedakan salinan tersebut. Dalam kasus ini, origin server harus menetapkan Vary: Accept-Encoding, yang menginstruksikan CDN untuk menyimpan dan melayani salinan cache berbeda berdasarkan nilai header permintaan Accept-Encoding.

Bagaimana cara menerapkan aturan caching secara global?

Anda dapat menerapkan aturan caching secara global dengan mengonfigurasi masa berlaku cache. Tetapkan Type ke Directory dan masukkan garis miring maju (/) di bidang Object untuk mencocokkan semua direktori. Untuk detailnya, lihat Konfigurasi Masa Berlaku Cache CDN.

Tiga FAQ berikut membahas skenario terkait untuk menonaktifkan atau membatasi caching CDN. Pilih yang sesuai dengan kasus penggunaan Anda:

• No-cache situs penuh — Nonaktifkan caching untuk semua resource pada suatu domain.

• Caching hanya file statis — Cache file statis sambil meneruskan permintaan dinamis ke origin.

• Passthrough spesifik jalur — Nonaktifkan caching untuk direktori, API, atau jalur resource dinamis tertentu.

Bagaimana cara menonaktifkan caching untuk seluruh domain?

Untuk menonaktifkan caching untuk seluruh nama domain di Alibaba Cloud CDN, tetapkan masa berlaku cache untuk semua jalur menjadi 0 dan pastikan aturan ini memiliki bobot tertinggi. Ikuti langkah-langkah berikut:

• Pada tab Cache Expiration, klik Create Rule.

• Type: Pilih Directory.

• Object: Masukkan / untuk mencocokkan semua jalur.

• Expire In: Masukkan 0s.

• Pertahankan pengaturan default untuk parameter lainnya.

• Klik OK untuk menyelesaikan konfigurasi.

Jika permintaan ke Alibaba Cloud sesuai dengan beberapa aturan caching, hanya aturan dengan prioritas tertinggi yang berlaku. Prioritas ditentukan dalam urutan berikut: bobot > waktu pembuatan aturan.

Jika Anda memiliki beberapa aturan di halaman Cache Expiration, pastikan aturan no-cache untuk seluruh domain memiliki Weight tertinggi (yang memberinya prioritas tertinggi).

Bagaimana cara mengonfigurasi CDN agar hanya menyimpan cache file statis (seperti gambar, CSS, dan JS) sementara halaman dinamis diteruskan ke origin server?

Gunakan pendekatan "allowlist/blocklist" berbasis bobot:

• Buat aturan caching statis berprioritas tinggi: Tambahkan satu atau beberapa aturan dengan Type diatur ke "File Extension" dan Object diatur ke ekstensi file statis seperti jpg,png,css,js. Tetapkan durasi cache panjang (misalnya, 1 bulan) dan Weight tinggi (misalnya, 90–99).

• Buat aturan no-cache dinamis berprioritas rendah: Tambahkan aturan dengan Type diatur ke "Directory" dan Object diatur ke / (direktori root). Tetapkan Expire In ke 0 detik (tidak di-cache) dan berikan Weight rendah (misalnya, 1–10).

• Optimalkan untuk jalur dinamis tertentu: Jika jalur dinamis tertentu seperti /api/ atau /wp-admin/ tidak boleh di-cache, tambahkan aturan direktori terpisah untuk tiap jalur, tetapkan durasi cache ke 0 detik, dan berikan Weight tertinggi (misalnya, 99) untuk memastikan aturan tersebut dicocokkan terlebih dahulu.

Bagaimana cara mengonfigurasi passthrough (tanpa caching) untuk resource dinamis, API, atau direktori tertentu?

Untuk skenario konten dinamis berbeda, Anda dapat menetapkan masa berlaku cache ke 0 detik agar permintaan diteruskan ke origin server:

• Nonaktifkan caching untuk halaman dan API dinamis: Untuk konten dinamis seperti halaman PHP, halaman ASP.NET, endpoint API, komunikasi real-time (koneksi berdurasi panjang), dan API upload backend, tambahkan aturan File Extension. Masukkan ekstensi terkait (misalnya, php,aspx,jsp) dan tetapkan Expire In ke 0 detik. Ini memastikan setiap permintaan menuju origin server, mencegah masalah seperti CAPTCHA tidak valid, status login tak terduga, atau unggahan gambar gagal akibat konten dinamis yang di-cache.

• Nonaktifkan caching untuk direktori tertentu: Untuk mencapai efek serupa dengan "menonaktifkan akselerasi" untuk direktori tertentu seperti /api/ atau /wp-admin/, tambahkan aturan Directory. Masukkan jalur direktori target dan tetapkan masa berlaku ke 0 detik. CDN tidak mendukung penonaktifan akselerasi langsung untuk direktori, tetapi konfigurasi ini memaksa permintaan diteruskan ke origin server.

• Prioritas untuk root dan subdirektori: Untuk hanya menyimpan cache subdirektori tertentu (misalnya, /static/) sementara tidak menyimpan cache resource lain di bawah direktori root /, konfigurasikan dua aturan terpisah. Berikan Weight tinggi (misalnya, 99) untuk aturan /static/. Lalu, buat aturan untuk direktori root / dengan masa berlaku cache 0 detik dan bobot rendah (misalnya, 1). Jika caching situs penuh menyebabkan masalah pada API dinamis, hapus aturan caching situs penuh tersebut dan gantilah dengan konfigurasi caching berdasarkan ekstensi file atau direktori statis tertentu.

• Masalah caching untuk SPA dan halaman HTML: Jika aplikasi halaman tunggal (SPA) mengembalikan error 404 atau mengalami pengalihan login tak terduga, periksa apakah caching dikonfigurasi untuk .html atau index.html. Nonaktifkan cache untuk file HTML (tetapkan masa berlaku ke 0 detik) atau hapus header Cache-Control dari respons origin, lalu lakukan pembersihan cache.

Apakah menetapkan aturan caching ekstensi file .aspx ke 0 detik menonaktifkan caching untuk seluruh situs?

Jika semua halaman di situs Anda berakhiran ekstensi .aspx, menetapkan masa berlaku cache untuk .aspx ke 0 secara efektif menonaktifkan caching untuk seluruh situs.

Hindari menggunakan ekstensi file umum untuk aturan seluruh situs. Sebaliknya, konfigurasikan aturan caching untuk jalur file atau direktori tertentu. Misalnya, tetapkan durasi cache panjang untuk direktori /static/ dan buat aturan terpisah untuk menonaktifkan caching (0 detik) untuk endpoint API dinamis seperti /api.aspx.

Bagaimana cara mengonfigurasi durasi cache untuk robots.txt dan sitemap.xml?

File-file ini secara langsung memengaruhi cara mesin pencari melakukan crawling terhadap situs Anda, sehingga Anda harus mengonfigurasi durasi cache terpisah berdasarkan frekuensi pembaruannya. Ini mencegah aturan default menyimpan cache terlalu lama, yang dapat menunda penemuan pembaruan situs Anda.

Jika sitemap Anda sering diperbarui, tetapkan durasi cache tidak lebih dari 1 jam. Jika aturan dalam file robots.txt Anda stabil, Anda dapat menetapkan durasi cache lebih panjang.

Haruskah saya mengaktifkan atau menonaktifkan sakelar Follow POP Cache Policy?

Sakelar ini mengontrol apakah kebijakan caching-nya sendiri (misalnya, max-age=3600) diteruskan ke browser client melalui header respons:

• Off (default): Node tetap menyimpan cache resource berdasarkan aturan yang dikonfigurasi tetapi tidak menyertakan kebijakan ini dalam header respons yang dikirim ke browser. Dalam kasus ini, perilaku caching browser ditentukan semata-mata oleh header yang Anda konfigurasi di fitur Modify Outbound Response Header.

• On: Mengirim header seperti Cache-Control ke browser, sehingga browser dan node menggunakan kebijakan caching yang sama.

Jika Anda telah mengonfigurasi header yang diinginkan untuk client di fitur Modify Outbound Response Header dan perilakunya sesuai harapan, biarkan sakelar ini dalam keadaan default Off. Aktifkan jika Anda ingin browser menggunakan kembali kebijakan tersebut untuk mengurangi permintaan berulang.

Bagaimana cara melakukan caching file besar?

CDN mendukung caching untuk skenario unduhan file besar. Anda dapat mengonfigurasi aturan masa berlaku cache untuk menyimpan file-file ini di node dalam jangka waktu lama, yang meningkatkan rasio hit cache dan mengurangi biaya origin fetch.

Rekomendasi konfigurasi:

• Durasi cache: Untuk file besar yang jarang diperbarui, tetapkan masa berlaku cache satu bulan atau lebih lama.

• Direktif no-cache origin server: Pastikan origin server tidak mengembalikan direktif seperti Cache-Control: no-cache, no-store, atau max-age=0. Jika Anda tidak dapat mengontrol origin server, pilih opsi Ignore Origin No-Cache Header dalam aturan caching.

• Pra-ambil file besar: Permintaan awal untuk file besar mungkin memiliki latensi tinggi. Sebelum distribusi, kirimkan tugas prefetch untuk mendorong file ke node terlebih dahulu.

Bagaimana cara mengonfigurasi Cross-Origin Resource Sharing (CORS) melalui header respons HTTP?

Tetapkan header respons HTTP yang sesuai untuk mengizinkan resource diakses oleh permintaan dari origin berbeda. Untuk informasi lebih lanjut, lihat Konfigurasi Cross-Origin Resource Sharing.

Bagaimana cara memeriksa apakah telah menyimpan cache suatu resource?

Anda dapat memeriksa header respons HTTP berikut untuk menentukan apakah Alibaba Cloud telah menyimpan cache suatu resource:

• X-Cache: Menunjukkan apakah permintaan mengenai cache. Nilai HIT menunjukkan cache hit. Nilai MISS, atau tidak adanya header ini, menunjukkan cache miss.

• Age: Menunjukkan berapa lama (dalam detik) file telah di-cache di node. Header ini tidak ada untuk objek yang telah di-purge atau permintaan pertama kali. Nilai Age 0 menunjukkan cache telah kedaluwarsa dan memerlukan origin fetch untuk revalidasi.

• X-Swift-CacheTime: Menunjukkan waktu cache maksimum yang diizinkan untuk file di node. Anda dapat menghitung sisa waktu cache: X-Swift-CacheTime – Age.

• X-Swift-SaveTime: Menunjukkan waktu (dalam GMT) saat resource pertama kali di-cache di node. Untuk mengonversi ke Waktu Standar Tiongkok (UTC+8), tambahkan 8 jam.

Anda dapat menggunakan salah satu metode berikut untuk melihat header respons HTTP ini dan memeriksa apakah konten Anda di-cache di CDN:

Metode 1: Gunakan alat developer browser (seperti Chrome DevTools)

Di panel Network, periksa Response Headers. Fokus pada header terkait cache CDN: Age, X-Cache, X-Swift-Cachetime, dan X-Swift-Savetime.

Response Headers
Access-Control-Allow-Origin:    *
Age:    860
Ali-Swift-Global-Savetime:    1704259214
Cache-Control:    max-age=28800,s-maxage=3600
Content-Encoding:    gzip
Content-Length:    2618
Content-Md5:    /h0oxujZUUo1P8gMA893oQ==
Content-Type:    text/html
Date:    Wed, 03 Jan 2024 05:20:14 GMT
Eagleid:    db9062a517042600741495981e
Server:    Tengine
Timing-Allow-Origin:    *
Vary:    Accept-Encoding
Via:    cache49.l2cn3032[0,0,200-0,H], cache8.l2cn3032[3,0], cache8.l2cn3032[3,0], ens-cache16.cn3573[0,0,200-0,H], ens-cache17.cn3573[43,0]
X-Cache:    HIT TCP_MEM_HIT dirn:10:498457979
X-Oss-Hash-Crc64ecma:    1068125902847643907
X-Oss-Object-Type:    Normal
X-Oss-Request-Id:    6594EE8E1FC2C239355F41E1
X-Oss-Server-Time:    3
X-Oss-Storage-Class:    Standard
X-Source-Scheme:    https
X-Swift-Cachetime:    3600
X-Swift-Savetime:    Wed, 03 Jan 2024 05:20:14 GMT

Metode 2: Gunakan perintah curl

Jalankan perintah berikut untuk memeriksa header respons CDN untuk suatu resource:

curl -v "http://example.com/path/to/response.html"

Berikut adalah contoh output curl:

F:\test>curl http://cdn.xxx.top/pic_03.jpg -v
* Host cdn.xxx.top:80 was resolved.
* IPv6: (none)
* IPv4: 1xxx
*   Trying 1xxx:80...
* Connected to cdn.xxx.top (xxx) part 80
> GET /pic_03.jpg HTTP/1.1
> Host: cdn.xxx.top
> User-Agent: curl/8.9.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: Tengine
< Content-Type: image/jpeg
< Content-Length: 8775526
< Connection: keep-alive
< Date: Mon, 26 May 2025 02:21:59 GMT
< x-oss-request-id: 68xxx9A
< x-oss-cdn-auth: success
< Accept-Ranges: bytes
< ETag: "Bxxx2"
< Last-Modified: Tue, 03 Sep 2024 06:20:19 GMT
< x-oss-object-type: Normal
< x-oss-storage-class: Standard
< Via: cache20.l2cn3032[0,0,200-0,H], cache10.cn3573[0,0,200-0,H], cache10.cn3573[1,0]
< Age: 424
< X-Cache: HIT TCP_HIT dirn:0:698837654
< X-Swift-CacheTime: 2592000
< Timing-Allow-Origin: *
< EagleId: 08xxx51
<
* Connection #0 to host cdn.xxx.top left intact
< x-oss-hash-crc64ecma: 12xxx58
< x-oss-storage-class: Standard
< x-oss-server-time: 228
< Via: ens-cache3.12cn7857[1863,1862,206-0,M], ens-cache38.12cn7857[1863,0], ens-cache20.cn6692[0,0,200-0,H], ens-cache4.cn6692[14,0]
< Age: 424
< Ali-Swift-Global-Savetime: 1748226119
< X-Cache: HIT TCP_HIT dirn:7:286737139 mlen:0
< X-Swift-SaveTime: Mon, 26 May 2025 02:21:59 GMT
< X-Swift-CacheTime: 2592000
< Timing-Allow-Origin: *
< EagleId: 7xxx220e

Dalam respons ini, X-Cache: HIT TCP_HIT menunjukkan cache hit CDN. Age: 424 menunjukkan bahwa resource telah disimpan dalam cache selama 424 detik. X-Swift-CacheTime: 2592000 menunjukkan bahwa masa berlaku cache adalah 2.592.000 detik (30 hari).

Setelah mengonfigurasi aturan caching, mengapa permintaan uji tetap mengalami cache miss atau menuju origin server?

Ikuti langkah-langkah berikut untuk troubleshooting:

• Periksa status konfigurasi: Pastikan status konfigurasi cache di Konsol menunjukkan "Configured."

• Verifikasi prioritas aturan: Jika terdapat beberapa aturan, pastikan aturan yang sesuai dengan jalur target memiliki bobot tertinggi. Misalnya, aturan untuk direktori tertentu seperti /static/ harus memiliki bobot lebih tinggi daripada aturan default untuk direktori root (/).

• Periksa header respons origin: Jika origin server mengembalikan Cache-Control: no-cache/no-store/max-age=0 atau Pragma: no-cache, dan opsi Ignore Origin No-Cache Header tidak diaktifkan, CDN mengikuti direktif origin dan tidak menyimpan cache resource tersebut. Aktifkan opsi ini atau sesuaikan konfigurasi origin server Anda.

• Konfirmasi metode permintaan: Gunakan permintaan GET (misalnya, curl -voa) untuk pengujian, bukan permintaan HEAD (misalnya, curl -I). Permintaan HEAD mungkin tidak memicu logika caching node L1 untuk isi resource, yang dapat menghasilkan hasil MISS palsu.

• Periksa parameter URL: Jika URL berisi parameter kueri, periksa apakah fitur Ignore URL Parameters diaktifkan. Jika dinonaktifkan, URL dengan parameter berbeda dianggap sebagai resource berbeda. Jika diaktifkan, dianggap sebagai resource yang sama.

Setelah saya memodifikasi aturan caching, status menunjukkan "Configuring." Apakah ini normal? Apakah memengaruhi layanan saya?

• Status konfigurasi: Setelah Anda menambahkan atau memodifikasi aturan caching, wajar jika Status aturan menunjukkan "Configuring." Ini menandakan konfigurasi sedang disebarluaskan ke node CDN di seluruh jaringan. Status biasanya berubah menjadi "Configured" dalam beberapa menit. Jika tetap tidak berubah dalam waktu lama, muat ulang halaman untuk memeriksa status terbaru.

• Dampak layanan: Memodifikasi aturan caching tidak memengaruhi ketersediaan layanan yang sudah ada. Aturan baru hanya berlaku untuk permintaan baru. Konten yang sudah di-cache di node CDN tetap dilayani berdasarkan kebijakan sebelumnya hingga cache kedaluwarsa. Jika Anda ingin aturan baru segera berlaku untuk semua permintaan, lakukan pembersihan cache untuk menghapus cache lama.

Apakah cache di node diperbarui secara otomatis setelah file di origin server diubah?

Tidak. Mengubah file di origin server tidak secara otomatis memperbarui cache di node secara real time. Pembaruan cache bergantung pada kebijakan caching yang dikonfigurasi.

• Node memperbarui cache mereka berdasarkan masa berlaku cache yang dikonfigurasi. Jika cache untuk suatu resource belum kedaluwarsa, perubahan di origin server tidak langsung tercermin di cache. Untuk informasi lebih lanjut, lihat Konfigurasi Masa Berlaku Cache CDN.

• Anda dapat secara manual membersihkan cache untuk memaksa permintaan berikutnya diarahkan ke origin server guna mendapatkan konten terbaru.

• Di Konsol: Purge dan Prefetch Resource

• Melalui pemanggilan API: RefreshCache

Setelah menetapkan Cache-Control: no-cache, apakah pengguna dapat mengakses file terbaru tanpa menghapus cache browser?

Tidak dijamin. Cache-Control: no-cache hanya menginstruksikan client untuk mengirim permintaan cache kondisional ke CDN untuk setiap permintaan. Jika node masih memiliki salinan file yang di-cache dan belum kedaluwarsa, mungkin mengembalikan konten yang di-cache secara langsung atau melakukan origin fetch untuk validasi. Jika file di origin server telah diperbarui tetapi cache belum diperbarui, pengguna mungkin masih melihat file lama.

Setelah Anda memperbarui file di origin server, lakukan operasi purge atau prefetch di Konsol (lihat Purge dan Prefetch Resource). Ini memaksa node untuk mengambil resource terbaru dari origin server, memastikan pengguna mengakses file terbaru.

Bagaimana cara mencapai pembaruan cache tingkat menit atau hampir real-time?

Ikuti langkah-langkah berikut untuk mencapai pembaruan tingkat menit:

• Di Konsol, tetapkan masa berlaku cache pendek untuk file target (misalnya, 60 detik).

• Aktifkan sakelar Force Revalidation.

• Nonaktifkan sakelar Honor Origin TTL.

Jika sebelumnya Anda mengonfigurasi durasi cache lebih lama, Anda harus membersihkan cache lama menggunakan fitur Purge dan Prefetch Resource agar konfigurasi baru segera berlaku.

Jika Anda memerlukan pembaruan real-time tingkat milidetik, gunakan nama file berbasis versi di origin server, seperti style-a1b2c3d.css, alih-alih menyesuaikan kebijakan cache. Untuk informasi lebih lanjut, lihat Konfigurasi Masa Berlaku Cache CDN.

Apakah saya perlu mengubah masa berlaku saat cache tidak diperbarui?

Anda tidak perlu mengubah masa berlaku. Ikuti dua langkah berikut agar pembaruan satu kali segera berlaku:

• Aktifkan sakelar Force Revalidation dan nonaktifkan sakelar Honor Origin TTL.

• Kirimkan tugas purge untuk file yang sesuai di halaman Purge dan Prefetch Resource.

Operasi ini hanya menghapus konten cache lama. Permintaan berikutnya melakukan origin fetch untuk mengambil resource terbaru, dan permintaan selanjutnya tetap mengenai cache seperti biasa.

Saya menetapkan masa berlaku cache ke 0 di Konsol, tetapi kontennya tetap usang. Mengapa?

Menetapkan masa berlaku cache ke 0 di Konsol bertujuan agar setiap permintaan mengambil konten terbaru dari origin server. Jika Anda masih menerima konten usang, penyebabnya mungkin salah satu dari berikut:

• Cache browser: Browser mungkin telah menyimpan cache konten lama. Hapus cache browser Anda atau uji dalam mode penyamaran.

• Waktu tunda propagasi konfigurasi: Setelah Anda menetapkan durasi cache ke 0, pengaturan baru mungkin memerlukan waktu untuk disebarluaskan ke semua node. Jika node belum menerima perubahan tersebut, node tersebut mungkin masih melayani konten cache usang.

• Cache origin server: Origin server mungkin memiliki mekanisme caching sendiri. Jika cache origin server tidak diperbarui tepat waktu, node mungkin mengambil konten usang selama origin fetch.

• Waktu tunda penghapusan cache node: Resource yang telah di-cache sebelum Anda mengubah konfigurasi mungkin memerlukan waktu untuk dihapus. Anda dapat secara manual membersihkan cache untuk segera mengambil konten terbaru. Untuk informasi lebih lanjut, lihat Purge dan Prefetch Resource.

Mengapa aturan caching saya tidak berlaku?

Jika Anda telah mengonfigurasi aturan caching tetapi tampaknya tidak berfungsi, masalahnya mungkin disebabkan oleh salah satu alasan berikut:

• Waktu tunda propagasi: Perubahan pada aturan caching memerlukan waktu untuk disebarluaskan di seluruh jaringan. Tunggu hingga aturan sepenuhnya aktif sebelum memverifikasi.

• Mekanisme pembaruan cache: Aturan baru tidak langsung berlaku untuk konten yang sudah di-cache. Aturan tersebut hanya berlaku setelah konten cache yang ada kedaluwarsa.

• Pembersihan cache tidak dilakukan: Setelah mengubah pengaturan cache, jika Anda tidak secara manual membersihkan cache, pengguna terus menerima konten cache lama hingga kedaluwarsa secara alami. Untuk informasi lebih lanjut, lihat Purge dan Prefetch Resource.

• Header respons cache tidak sesuai: Periksa header respons HTTP dari origin server Anda untuk memastikan header Cache-Control dan Expires diatur dengan benar.

• Prioritas aturan caching: Jika permintaan sesuai dengan beberapa aturan, prioritas ditentukan oleh: bobot > waktu pembuatan aturan.

• Saat terdapat beberapa aturan caching, tetapkan bobot berbeda untuk tiap aturan guna mengontrol prioritas eksekusi. Bobot yang lebih tinggi menunjukkan prioritas yang lebih tinggi.

• Untuk aturan dengan bobot yang sama, aturan yang dibuat lebih awal didahulukan, terlepas dari jenis aturannya.

Contoh konfigurasi: Aturan caching berikut dikonfigurasi untuk nama domain yang dipercepat demo.aliyun.com. Saat node mengambil resource http://demo.aliyun.com/image/example.png dari origin server, kedua aturan berikut sesuai. Karena kedua aturan memiliki bobot yang sama, aturan yang dibuat lebih awal didahulukan. Aturan untuk direktori /image dibuat lebih awal, sehingga sistem menerapkan aturan berjenis direktori. Daftar konfigurasi aturan caching menunjukkan dua aturan:

• Konten: jpg,png, Jenis: File Extension, Masa Berlaku: 1 bulan, Bobot: 10, Status: Configured.

• Konten: /image, Jenis: Directory, Masa Berlaku: 1 hari, Bobot: 10, Status: Configuring. Untuk kedua aturan, Honor Origin TTL, Ignore Origin No-Cache Header, Follow POP Cache Policy, dan Force Revalidation dinonaktifkan. Tiap aturan mendukung operasi Modify dan Delete.

Saya telah mengonfigurasi header respons Access-Control-Allow-Origin, tetapi masih mengalami masalah CORS. Mengapa?

Jika Anda telah mengonfigurasi header respons origin seperti Access-Control-Allow-Origin di Alibaba Cloud CDN, tetapi client tetap mengalami masalah lintas-origin dan header yang dikonfigurasi tidak muncul dalam respons, masalahnya mungkin disebabkan oleh salah satu hal berikut:

Kemungkinan penyebab

• Konfigurasi salah atau tidak efektif: Konfigurasi mungkin salah atau belum sepenuhnya disebarluaskan.

• Cache CDN: Node CDN mungkin melayani respons lama dengan header usang.

• Masalah origin server: Header respons lintas-origin dari origin server bertentangan dengan konfigurasi CDN.

• Cache browser: Browser telah menyimpan cache respons lama.

Solusi

• Verifikasi konfigurasi: Pastikan konfigurasi CDN diatur dengan benar dan telah berlaku.

• Bersihkan cache CDN: Gunakan fitur Purge and Prefetch untuk menghapus cache, lalu akses kembali resource tersebut. Untuk informasi lebih lanjut, lihat Purge dan Prefetch Resource.

• Periksa pengaturan origin server: Pastikan origin server tidak mengembalikan header respons lintas-origin yang bertentangan dengan konfigurasi CDN Anda. Gunakan pengaturan header CORS yang konsisten di origin server dan CDN Anda.

• Hapus cache browser: Hapus cache browser Anda, atau uji dalam mode penyamaran.

Bagaimana cara troubleshooting error ERR_CONTENT_LENGTH_MISMATCH saat pemutaran video?

• Penyebab: Error ini biasanya terjadi karena file yang di-cache di node CDN memiliki panjang berbeda dengan konten aktual di origin server, atau origin server mengembalikan header respons Content-Length yang tidak normal. Hal ini umum terjadi saat file video diperbarui di origin server, tetapi CDN masih melayani versi cache lama.

• Solusi:

• Di halaman Purge dan Prefetch di Konsol CDN, kirimkan permintaan purge untuk URL video guna menghapus cache usang dari node CDN.

• Jika origin server Anda adalah OSS, Anda dapat mengaktifkan refresh cache CDN otomatis. Fitur ini secara otomatis memicu purge cache CDN setelah file di origin server diperbarui.

• Periksa stabilitas dan konsistensi respons origin server Anda untuk memastikan tidak mengembalikan Content-Length yang tidak normal secara intermiten.

• Tentang kode status 206: Pemutar video biasanya menggunakan permintaan Range untuk memuat konten video dalam segmen. Wajar jika CDN mengembalikan kode status 206 Partial Content, bahkan jika permintaan mengenai cache CDN.

File statis mengenai cache, tetapi homepage tetap dimuat lambat. Mengapa?

Resource statis (gambar, CSS, JS, dll.) mengenai cache dan dipercepat sebagaimana mestinya, tetapi homepage (jalur root /) tetap memerlukan beberapa detik untuk dimuat. Hal ini biasanya terjadi karena tidak ada aturan caching yang dikonfigurasi untuk permintaan homepage, sehingga setiap kunjungan memaksa pengambilan data dari origin server. Kecepatan pemuatan kemudian bergantung pada waktu pemrosesan origin server.

Solusi: Tambahkan aturan masa berlaku cache untuk direktori root nama domain yang dipercepat Anda. Ini memungkinkan node menyimpan cache konten homepage dan mengurangi jumlah origin fetch.

• Pada tab Cache Expiration, klik Create Rule.

• Type: Pilih Directory.

• Object: Masukkan /.

• Expire In: Tetapkan durasi berdasarkan frekuensi pembaruan homepage Anda, misalnya 30 detik hingga beberapa menit.

• Weight: Jika terdapat aturan caching lain, tetapkan bobot rendah untuk aturan ini (misalnya, 1) untuk mencegahnya menggantikan aturan caching untuk resource statis.

• Klik OK untuk menyelesaikan konfigurasi.

Setelah konfigurasi berlaku, konten homepage Anda di-cache oleh node. Kunjungan berikutnya dilayani langsung dari node, menghilangkan kebutuhan origin fetch pada setiap kunjungan dan secara signifikan meningkatkan kecepatan pemuatan homepage. Untuk informasi lebih lanjut tentang konfigurasi masa berlaku cache, lihat Konfigurasi Masa Berlaku Cache CDN.

Bagaimana cara memperbaiki rasio hit cache rendah yang disebabkan oleh parameter URL variabel?

Masalah ini mungkin terjadi jika fitur Ignore URL Parameters tidak diaktifkan untuk layanan CDN Anda. Untuk informasi lebih lanjut, lihat Rasio hit cache CDN rendah akibat parameter variabel dalam URL.

Faktor apa saja yang dapat menurunkan rasio hit cache?

Faktor-faktor berikut dapat menurunkan rasio hit cache Alibaba Cloud:

• Pembersihan cache: Operasi pembersihan cache manual atau otomatis dapat menyebabkan penurunan sementara pada rasio hit cache.

• Puncak bandwidth mendadak: Puncak bandwidth mendadak dapat mendistribusikan permintaan ke lebih banyak node CDN, yang banyak di antaranya mungkin belum memiliki konten di-cache, menyebabkan lebih banyak origin fetch dan rasio hit cache lebih rendah.

• Permintaan pertama kali untuk konten baru: Jika node CDN sering menerima permintaan pertama kali untuk konten baru, jumlah origin fetch meningkat, yang menurunkan rasio hit cache.

• Penyesuaian aturan caching: Modifikasi kebijakan caching CDN, seperti menetapkan masa berlaku cache tidak sesuai atau salah mengonfigurasi aturan caching, dapat menurunkan rasio hit cache.

• Parameter variabel dalam URL: Jika URL berisi parameter setelah tanda tanya (?), variasi parameter tersebut menyebabkan CDN memperlakukan tiap URL unik sebagai resource berbeda, menurunkan rasio hit cache meskipun permintaan mengarah ke konten yang sama.

• Masa berlaku cache yang tidak sesuai: Jika Anda tidak menetapkan masa berlaku cache yang sesuai untuk file statis berdasarkan frekuensi pembaruannya, resource yang di-cache mungkin kedaluwarsa terlalu dini, yang mengurangi rasio hit cache.

Untuk informasi lebih lanjut tentang faktor yang memengaruhi rasio hit cache, lihat Tingkatkan rasio hit cache CDN. Untuk konfigurasi spesifik, lihat Purge dan Prefetch Resource, Ignore URL Parameters, dan Konfigurasi Masa Berlaku Cache CDN.

Bagaimana cara troubleshooting rasio hit cache rendah, laju origin-fetch tinggi, atau bandwidth origin jenuh?

• Periksa header respons cache origin: Jika origin server mengembalikan Cache-Control: no-cache, Cache-Control: no-store, Cache-Control: max-age=0, atau Pragma: no-cache, CDN secara default mengikuti direktif origin dan tidak menyimpan cache resource tersebut. Ini memaksa origin fetch untuk setiap permintaan dan merupakan penyebab paling umum dari rasio hit cache rendah serta bandwidth origin server yang jenuh.

• Aktifkan Ignore Origin No-Cache Header: Di pengaturan masa berlaku cache di Konsol CDN, pilih opsi ini. Saat diaktifkan, CDN mengabaikan direktif no-cache dari origin server, seperti Cache-Control: no-cache, no-store, dan max-age=0, serta header Pragma: no-cache. Sebagai gantinya, CDN menyimpan cache konten berdasarkan aturan yang dikonfigurasi di Konsol.

• Tinjau konfigurasi aturan cache: Periksa apakah Anda secara tidak sengaja menetapkan masa berlaku cache untuk direktori root (/) ke 0 detik. Jika aturan direktori root memiliki bobot tertinggi dan masa berlaku 0 detik, semua permintaan memicu origin fetch.

• Optimalkan untuk file besar: Untuk file besar seperti video, pastikan fitur origin-fetch Range diaktifkan. Ini mencegah CDN mengambil seluruh file dari origin server untuk setiap permintaan.

• Beda antara resource dinamis dan statis: Tetapkan durasi cache panjang (misalnya, satu bulan) untuk resource statis seperti gambar, file CSS, dan JS. Tetapkan masa berlaku cache ke 0 detik untuk menonaktifkan caching untuk konten dinamis seperti halaman PHP atau JSP.

Mengapa saya melihat banyak kode status 206 atau beberapa origin fetch di log untuk pemutaran video atau unduhan file besar?

Ini adalah perilaku normal.

• Kode status 206: Pemutar video dan alat unduh biasanya menggunakan permintaan Range untuk memuat resource dalam segmen. Untuk tiap permintaan tersegmentasi, server mengembalikan kode status 206 Partial Content. CDN juga mengembalikan kode status 206 saat melayani segmen dari cache-nya.

• Biaya traffic: Data apa pun yang ditransfer dari CDN ke client ditagih sebagai lalu lintas arah keluar, terlepas dari apakah permintaan mengenai cache atau tidak.

• Rekomendasi optimasi: Pastikan fitur origin-fetch Range diaktifkan. Ini memungkinkan node CDN menarik dan menyimpan cache segmen dari origin server sesuai permintaan, yang meningkatkan rasio hit cache untuk permintaan segmen berikutnya. Selain itu, konfigurasikan header Cache-Control yang sesuai di client atau origin server untuk memanfaatkan cache browser dan mengurangi permintaan berulang.