All Products
Search

This Product

    CDN:Troubleshooting cache

    Document Center

    CDN:Troubleshooting cache

    Last Updated:Sep 01, 2026

    Topik ini merangkum metode troubleshooting untuk skenario cache CDN berdasarkan gejala: caching tidak berlaku dan cache miss, rasio hit cache rendah serta rasio pengambilan asal tinggi, pengecualian header respons dan CORS, pengecualian video dan file besar, serta konten tidak diperbarui dan pengecualian akses.

    Langkah awal umum

    Catatan

    Topik ini berlaku untuk Alibaba Cloud CDN, dengan nama domain yang dipercepat telah terdaftar dan resolusi CNAME telah berlaku. Jika Anda menggunakan Dynamic Route for CDN (DCDN), beberapa titik masuk konfigurasi dan nama fitur mungkin berbeda. Merujuklah pada tampilan Konsol aktual.

    Item pemeriksaan berikut berlaku untuk sebagian besar masalah cache. Kami menyarankan Anda menyelesaikannya satu per satu sebelum memulai troubleshooting untuk menghindari kesimpulan salah akibat gangguan lingkungan:

    Item pemeriksaan

    Deskripsi

    Verifikasi bahwa resolusi CNAME benar

    Jalankan dig accelerated-domain dan pastikan resolusi akhir mengarah ke CNAME yang ditetapkan oleh CDN, tanpa sisa record A/AAAA yang mengarah ke server origin.

    Verifikasi bahwa konfigurasi telah berlaku secara global

    Status aturan di Konsol harus Success. Penyebaran konfigurasi ke POP di seluruh dunia biasanya memerlukan waktu 3 hingga 5 menit.

    Kesampingkan cache browser lokal

    Uji dalam mode penjelajahan pribadi atau gunakan curl untuk menghindari gangguan dari cache browser.

    Bersihkan cache CDN yang ada

    Konfigurasi baru hanya berlaku untuk permintaan baru setelah berlaku. Untuk resource yang sudah di-cache berdasarkan kebijakan sebelumnya, kirimkan refresh URL atau refresh direktori melalui Refresh and prefetch.
    Catatan

    Topik ini menggunakan pengaturan waktu kedaluwarsa cache menjadi 0 detik sebagai langkah darurat di beberapa tempat. Waktu kedaluwarsa 0 berarti setiap permintaan memicu pengambilan asal, yang secara signifikan meningkatkan beban pada server origin dan mengurangi efek akselerasi. Kami menyarankan Anda hanya menggunakannya untuk konten dinamis yang benar-benar memerlukan respons real-time, seperti endpoint API. Jangan konfigurasikan secara global untuk resource statis.

    Menentukan apakah cache terkena (hit)

    Sebelum melakukan troubleshooting masalah cache, periksa header respons untuk mengonfirmasi status cache resource tersebut:

    • Gunakan permintaan GET untuk memeriksa header respons: Jalankan curl -v -o /dev/null "http(s)://accelerated-domain/resource-path". Permintaan curl -I (permintaan HEAD) mungkin tidak memicu logika cache aktual untuk badan resource di POP dalam beberapa skenario, sehingga menyebabkan kesimpulan salah berupa cache miss. Kami menyarankan Anda menggunakan permintaan GET untuk verifikasi.

    • Periksa X-Cache untuk menentukan status hit: HIT menunjukkan cache hit. MISS atau tidak adanya field ini menunjukkan cache miss, artinya permintaan memicu pengambilan asal.

    • Periksa Age dan X-Swift-CacheTime untuk menentukan durasi cache tersisa: Age menunjukkan jumlah detik resource telah di-cache di POP, dan harus diinterpretasikan bersama dengan X-Cache. Jika X-Cache adalah MISS dan Age adalah 0, permintaan memicu pengambilan asal. Jika X-Cache adalah HIT tetapi Age adalah 0, resource di-cache kurang dari 1 detik yang lalu. X-Swift-CacheTime menunjukkan total durasi cache yang diizinkan. Durasi tersisa sama dengan X-Swift-CacheTime dikurangi Age.

    • Konfirmasi bahwa permintaan melewati CDN: Jika header respons Server menampilkan identifikasi origin, seperti AliyunOSS atau nginx, dan header respons CDN seperti X-Cache dan X-Swift-CacheTime tidak ada, permintaan melewati POP CDN dan langsung menuju server origin. Jalankan dig accelerated-domain atau nslookup accelerated-domain untuk mengonfirmasi hasil resolusi akhir. Simpan hanya record CNAME yang ditetapkan oleh CDN, dan hapus record A/AAAA yang mengarah ke IP server origin serta record CNAME yang mengarah ke nama domain server origin.

    Caching tidak berlaku dan cache miss

    Apakah permintaan masih memicu pengambilan asal atau cache miss setelah Anda mengonfigurasi aturan cache?

    Langkah troubleshooting:

    1. Konfirmasi bahwa konfigurasi telah berlaku: Setelah Anda menambahkan atau mengubah aturan cache, status aturan menunjukkan Configuring, artinya konfigurasi sedang disebarkan ke POP di seluruh dunia. Status biasanya berubah menjadi Success dalam beberapa menit. Jangan terburu-buru memverifikasi aturan sebelum konfigurasi berlaku.

    2. Konfirmasi bahwa aturan baru berlaku untuk resource target: Aturan baru hanya berlaku untuk permintaan baru. Resource yang sudah di-cache di POP terus dilayani berdasarkan kebijakan sebelumnya hingga kedaluwarsa. Untuk segera menerapkan aturan, pertama-tama bersihkan cache sebelumnya melalui Refresh and prefetch.

    3. Periksa prioritas pencocokan aturan: Saat permintaan cocok dengan beberapa aturan, hanya satu aturan yang berlaku. Secara default, aturan dengan bobot lebih tinggi memiliki prioritas. Saat bobot sama, aturan yang dibuat belakangan biasanya memiliki prioritas (merujuk pada deskripsi aktual di Konsol). Pastikan aturan yang dicocokkan oleh path target memiliki bobot tertinggi. Misalnya, bobot direktori spesifik (/static/) harus lebih tinggi daripada direktori root (/).

    4. Periksa apakah header respons origin melarang caching: Jika server origin mengembalikan Cache-Control: no-cache, no-store, max-age=0, atau Pragma: no-cache, CDN mengikuti arahan origin secara default. Untuk dampak berbagai arahan terhadap perilaku pengambilan asal, lihat tabel berikut. Anda dapat mengaktifkan Ignore no-cache headers from the origin server dalam aturan cache untuk memaksakan caching berdasarkan aturan Konsol, atau sesuaikan konfigurasi server origin untuk menghapus arahan no-cache untuk resource statis.

    5. Periksa bagaimana parameter URL diproses: Jika URL berisi parameter dan Ignore parameters dinonaktifkan, URL dengan parameter berbeda dianggap sebagai resource berbeda, yang mengurangi rasio hit cache. Anda dapat mengaktifkan Ignore parameters atau Retain specified parameters.

    6. Periksa apakah direktori root dikonfigurasi salah sebagai tidak di-cache: Jika aturan untuk direktori root / memiliki bobot tertinggi dan waktu kedaluwarsa 0 detik, semua permintaan memicu pengambilan asal.

    Pada langkah 4 di atas, berbagai arahan no-cache dari server origin memiliki dampak sangat berbeda terhadap perilaku pengambilan asal. Evaluasi beban pada server origin berdasarkan arahan aktual:

    Origin response header

    Perilaku CDN

    Dampak pada server origin

    Cache-Control: no-store

    Caching sepenuhnya dilarang. Setiap permintaan mengambil resource lengkap dari server origin.

    Server origin menanggung seluruh tekanan traffic.

    Cache-Control: no-cache atau max-age=0

    POP diizinkan menyimpan salinan cache, tetapi harus melakukan validasi ulang dengan server origin sebelum setiap penggunaan. Saat validasi berhasil, server origin mengembalikan 304 (tanpa badan respons), dan overhead jauh lebih kecil daripada pengambilan asal penuh.

    Jumlah pengambilan asal tidak berkurang, tetapi setiap pengambilan hanya merupakan permintaan kondisional kecil, sehingga tekanan bandwidth masih dapat dikelola.

    Pragma: no-cache

    Arahan kompatibilitas HTTP/1.0. Efeknya mirip dengan no-cache.

    Sama seperti di atas.

    Waktu kedaluwarsa cache diatur ke 0, tetapi konten yang saya akses masih bukan yang terbaru?

    Tujuan mengatur waktu kedaluwarsa ke 0 adalah agar setiap permintaan mengambil konten terbaru dari server origin. Jika konten lama masih dikembalikan, lakukan troubleshooting sebagai berikut:

    1. Kesampingkan cache browser lokal: Bersihkan cache browser atau gunakan mode penjelajahan pribadi untuk menguji kembali, dan pastikan konten lama dikembalikan oleh POP, bukan browser.

    2. Bersihkan cache yang ada sebelum perubahan konfigurasi: Resource yang di-cache sebelum Anda mengubah konfigurasi tidak dihapus secara otomatis. Kirimkan tugas refresh URL melalui Refresh and prefetch.

    3. Periksa apakah server origin memiliki cache sendiri: Server origin (misalnya, cache Nginx atau cache tingkat aplikasi) mungkin mengembalikan konten lama, sehingga CDN mengambil data kedaluwarsa selama pengambilan asal.

    4. Konfirmasi bahwa konfigurasi telah berlaku secara global: Status aturan harus Success. Penyebaran konfigurasi ke semua POP memerlukan waktu beberapa menit.

    5. Konfirmasi bahwa permintaan mengenai POP yang diharapkan: Pengguna dari ISP berbeda atau di wilayah berbeda mungkin mengenai POP berbeda. Uji di beberapa wilayah secara terpisah, atau gunakan log waktu nyata CDN dan IP POP dalam respons untuk mengidentifikasi masalah lebih lanjut.

    Saya mengonfigurasi kunci cache kustom untuk membedakan permintaan mobile dan PC, tetapi tidak berlaku?

    1. Periksa kelengkapan konfigurasi: Kunci cache kustom biasanya memerlukan pengaturan kondisi aturan berdasarkan karakteristik permintaan (seperti User-Agent) lalu menambahkan variabel kunci cache berbeda ke setiap aturan. Konfirmasi bahwa karakteristik permintaan klien mobile dan PC diidentifikasi dengan benar, dan kondisi pencocokan kedua aturan tidak saling tumpang tindih.

    2. Tunggu konfigurasi berlaku: Setelah Anda mengirimkan konfigurasi, tunggu 5 hingga 10 menit agar disinkronkan secara global.

    3. Refresh cache sebelumnya: Resource yang di-cache berdasarkan kunci cache sebelumnya sebelum perubahan konfigurasi tidak kedaluwarsa secara otomatis. Kirimkan tugas refresh (kami menyarankan Anda menggunakan refresh direktori).

    4. Verifikasi di klien: Bersihkan cache browser dan coba lagi, lalu periksa apakah X-Cache dalam header respons adalah MISS.

    5. Uji dengan perangkat nyata: Kirim permintaan menggunakan User-Agent aktual perangkat berbeda, bukan hanya mengubah ukuran jendela browser (User-Agent yang diemulasikan browser mungkin berbeda dari perangkat nyata).

    Catatan

    Custom cache key bertentangan dengan Ignore parameters: saat keduanya dikonfigurasi, fitur ignore parameters tidak berlaku. Jika Anda sudah menggunakan kunci cache kustom, konfigurasikan kebijakan penanganan parameter permintaan di dalamnya, bukan mengaktifkan Ignore parameters secara terpisah.

    Rasio hit cache adalah 0 karena respons berisi Set-Cookie. Bagaimana cara mengatasinya?

    Penyebab: Saat respons origin berisi header respons Set-Cookie, CDN tidak meng-cache respons tersebut secara default, sehingga menghasilkan rasio hit cache 0.

    Penting

    Menghapus Set-Cookie adalah operasi berisiko tinggi. Header respons ini membawa logika bisnis kritis seperti mempertahankan sesi login pengguna, autentikasi sesi, dan pelacakan perilaku. Menghapusnya secara global dapat menyebabkan kegagalan login, keranjang belanja hilang, dan error autentikasi. Evaluasi cakupan dampak sebelum melanjutkan.

    Solusi yang direkomendasikan (berdasarkan prioritas):

    • Perbaiki di sisi origin (direkomendasikan): Buat server origin berhenti mengembalikan Set-Cookie untuk resource statis seperti gambar, CSS, JavaScript, dan font. Ini adalah solusi mendasar. Tidak memengaruhi manajemen sesi endpoint dinamis dan meningkatkan rasio hit cache.

    • Hapus berdasarkan path di sisi CDN: Jika server origin tidak dapat disesuaikan, hapus header respons ini di sisi CDN hanya untuk path resource statis seperti /static/, *.css, dan *.js untuk menghindari memengaruhi endpoint dinamis.

    Langkah-langkah untuk menghapus header berdasarkan path di sisi CDN:

    1. Login ke Konsol CDN. Di halaman Domain Names, temukan nama domain target dan klik Manage.

    2. Di panel navigasi kiri halaman detail domain, klik Origin Settings dan buka tab Modify incoming response headers.

    3. Klik Add, batasi kondisi aturan ke path resource statis, pilih Delete untuk operasi header respons, dan masukkan Set-Cookie sebagai nama header respons.

    4. Setelah konfigurasi selesai, gunakan Refresh and prefetch untuk membersihkan respons lama yang di-cache agar aturan baru berlaku.

    Jika rasio hit cache masih tidak membaik setelah konfigurasi, periksa hal berikut: apakah Ignore no-cache headers from the origin server diaktifkan dalam aturan cache, dan apakah Ignore parameters diaktifkan untuk mencegah resource yang sama terpecah menjadi beberapa objek cache akibat parameter kueri berbeda. Untuk aturan cache default CDN, lihat Configure CDN cache expiration.

    Rasio hit cache rendah dan rasio pengambilan asal tinggi

    Rasio hit cache rendah, rasio pengambilan asal tinggi, atau bandwidth origin jenuh?

    Rasio hit cache rendah berarti sebagian besar permintaan memicu pengambilan asal. Jalur jaringan publik yang tidak stabil dapat menurunkan efek akselerasi dan memberikan tekanan beban pada server origin. Lakukan troubleshooting sebagai berikut:

    1. Periksa apakah server origin mengembalikan arahan no-cache: Ini adalah penyebab paling umum rasio hit rendah dan bandwidth origin jenuh. Jika server origin mengembalikan Cache-Control: no-cache, no-store, max-age=0, atau Pragma: no-cache, CDN mengikuti arahan origin dan tidak meng-cache resource, sehingga setiap permintaan memicu pengambilan asal. Anda dapat mengaktifkan Ignore no-cache headers from the origin server dalam konfigurasi waktu kedaluwarsa cache untuk memaksakan caching berdasarkan aturan Konsol, atau sesuaikan konfigurasi server origin.

    2. Periksa apakah aturan cache dikonfigurasi salah: Konfirmasi bahwa waktu kedaluwarsa cache untuk direktori root / tidak diatur ke 0 detik dengan bobot tertinggi. Jika tidak, semua permintaan memicu pengambilan asal.

    3. Periksa apakah URL berisi parameter variabel: Parameter yang berubah setelah tanda tanya dalam URL menyebabkan konten yang sama dianggap sebagai resource berbeda. Mengaktifkan Ignore parameters menggabungkan permintaan tersebut menjadi satu objek cache. Untuk informasi lebih lanjut, lihat item berikutnya.

    4. Konfigurasikan resource statis dan dinamis secara terpisah: Atur durasi cache panjang (misalnya 30 hari) untuk resource statis seperti gambar, CSS, JavaScript, dan font, dan atur waktu kedaluwarsa ke 0 detik untuk konten dinamis seperti PHP, JSP, dan endpoint API.

    5. Aktifkan range origin fetch untuk file besar: Untuk file besar seperti video dan paket instalasi, pastikan range origin fetch diaktifkan agar POP tidak mengambil seluruh file dari server origin untuk setiap permintaan. Sebelum mengaktifkan fitur ini, konfirmasi bahwa server origin mendukung permintaan range (yaitu, dapat mengembalikan 206 Partial Content). Mengaktifkan fitur ini saat server origin tidak mendukung permintaan range dapat menyebabkan kegagalan permintaan atau konten abnormal.

    6. Periksa apakah QPS bisnis terlalu rendah: Ruang disk POP terbatas, dan resource yang jarang diakses akan digantikan oleh resource populer, yang memicu pengambilan asal. Untuk nama domain dengan QPS hanya belasan, kami menyarankan Anda mengirimkan tugas prefetch melalui Refresh and prefetch agar resource tetap berada di POP.

    X-Cache permintaan halaman utama selalu MISS, menyebabkan rasio hit cache rendah. Bagaimana cara mengatasinya?

    Gejala: Rasio hit keseluruhan halaman rendah. Header respons menunjukkan bahwa X-Cache adalah MISS untuk permintaan utama, tetapi HIT untuk file individual di halaman tersebut.

    Penyebab: URL berisi parameter yang berubah pada setiap permintaan, seperti timestamp. Saat fitur ignore parameters dinonaktifkan, CDN memperlakukan setiap URL dengan parameter berbeda sebagai resource independen dan tidak dapat menggunakan ulang cache. Misalnya, nilai setelah ?_t= dalam http://example.com/movie/res/ArrowScene.ccbi?_t=1699999999 berbeda untuk setiap permintaan.

    Solusi: Aktifkan Ignore parameters di Konsol CDN. Setelah Anda mengaktifkan fitur ini, parameter dikecualikan dari perhitungan objek cache, dan permintaan untuk resource yang sama dengan parameter berbeda mengenai cache yang sama. Jika bisnis Anda bergantung pada beberapa parameter, pilih Retain specified parameters untuk mengabaikan hanya yang tidak relevan.

    Apa saja kemungkinan penyebab penurunan mendadak rasio hit cache?

    Penyebab umum fluktuasi jangka pendek atau penurunan berkelanjutan rasio hit:

    • Refresh cache dilakukan: Refresh manual atau otomatis membersihkan cache di POP, sehingga penurunan rasio hit dalam periode singkat adalah hal yang diharapkan. Saat resource di-cache kembali, rasio hit biasanya pulih secara otomatis dalam beberapa jam.

    • Terjadi lonjakan bandwidth: Peningkatan traffic tajam dalam periode singkat membawa banyak permintaan pertama kali, yang meningkatkan pengambilan asal dan menurunkan rasio hit.

    • Banyak konten baru diakses: Saat POP sering meminta resource yang diakses untuk pertama kali, pengambilan asal tidak dapat dihindari dan rasio hit menurun.

    • Aturan cache disesuaikan: Memodifikasi kebijakan cache, terutama memperpendek waktu kedaluwarsa, memengaruhi rasio hit.

    • URL berisi parameter variabel: Parameter yang berubah memecah konten yang sama menjadi beberapa objek cache.

    • Waktu kedaluwarsa cache tidak dikonfigurasi dengan tepat: Jika konfigurasi tidak membedakan resource berdasarkan frekuensi pembaruan, cache kedaluwarsa terlalu dini.

    Pengecualian header respons dan CORS

    Saya mengonfigurasi Access-Control-Allow-Origin, tetapi permintaan masih melaporkan error CORS?

    Jika Anda telah mengonfigurasi header respons CORS di CDN tetapi klien masih melaporkan error CORS dan header respons tidak berisi field yang dikonfigurasi, kemungkinan penyebab dan solusinya adalah sebagai berikut:

    • Konfigurasi belum berlaku: Konfirmasi bahwa konfigurasi disimpan dan status aturan adalah Success.

    • Konfigurasi belum sepenuhnya disebarkan: Perubahan konfigurasi header respons outbound biasanya berlaku dalam waktu 5 menit. Tunggu dan coba lagi. Konfigurasi ini hanya memengaruhi respons yang diterima klien, bukan perilaku cache POP, sehingga tidak diperlukan refresh atau prefetch (prefetch tidak mengubah header respons resource yang sudah di-cache).

    • Header respons server origin bertentangan dengan konfigurasi CDN: Jika server origin juga mengembalikan header respons CORS, header tersebut mungkin saling menimpa. Kami menyarankan Anda menggunakan konfigurasi CORS yang konsisten di server origin dan CDN, atau atur Allow Duplicate ke No di Modify outbound response headers agar nilai yang dikonfigurasi di CDN menimpa nilai yang dikembalikan oleh server origin.

    • Browser meng-cache respons sebelumnya: Bersihkan cache browser atau gunakan mode penjelajahan pribadi untuk menguji.

    • Konfigurasi domain wildcard tidak didukung: Setelah Anda mengaktifkan validasi CORS, Anda hanya dapat mengonfigurasi satu nama domain wildcard, atau beberapa nama domain eksak yang dipisahkan koma. Memisahkan beberapa nama domain wildcard dengan koma tidak didukung.

    • Nilai Access-Control-Allow-Origin tidak sesuai dengan Origin permintaan: Jika browser melaporkan "The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin", origin yang diizinkan yang dikembalikan tidak sesuai dengan origin permintaan aktual. Anda dapat mengatasi ini dengan cara berikut:

      • Di Modify outbound response headers, konfigurasi ulang Access-Control-Allow-Origin dan atur Allow Duplicate ke No agar nilai baru menimpa nilai sebelumnya yang dikembalikan oleh server origin.

      • Jika bisnis Anda mengizinkan, konfigurasikan header respons ini untuk secara dinamis mengembalikan nilai Origin dalam permintaan agar origin yang diizinkan selalu sesuai dengan origin permintaan. Setelah konfigurasi selesai, tunggu sekitar 5 menit agar berlaku. Tidak diperlukan refresh cache.

    Untuk cara mengonfigurasi berbagi sumber daya lintas asal, lihat Configure cross-origin resource sharing.

    Header respons kustom tidak berlaku?

    • Konfirmasi bahwa permintaan melewati POP CDN: Periksa apakah resolusi DNS hanya menyimpan record CNAME yang disediakan oleh CDN dan apakah record resolusi langsung untuk origin seperti OSS telah dihapus. Jika traffic langsung menuju server origin, header respons yang dikonfigurasi di CDN tidak berlaku.

    • Konfirmasi bahwa Anda mengonfigurasi header respons outbound, bukan inbound: Header respons inbound hanya berlaku untuk komunikasi antara server origin dan POP CDN, dan pengguna akhir tidak mengetahuinya. Untuk memengaruhi respons yang diterima pengguna akhir, konfigurasikan Modify outbound response headers.

    • Konfirmasi apakah server origin mengembalikan header respons: CDN meneruskan header respons origin secara default. Jika server origin tidak mengembalikan header tersebut, CDN juga tidak mengembalikannya. Untuk memaksa header respons disertakan terlepas dari apakah server origin mengembalikannya, pilih operasi Add di Modify outbound response headers.

    • Jika Content-Type tidak berlaku, periksa metadata di server origin: Jika server origin (seperti OSS) tidak menentukan Content-Type yang benar saat file diunggah, metadata yang diperoleh selama pengambilan asal tidak sesuai ekspektasi Anda. Periksa pengaturan Content-Type yang digunakan saat file diunggah.

    • Konfirmasi bahwa Anda telah menunggu konfigurasi berlaku: Perubahan konfigurasi header respons outbound biasanya berlaku dalam waktu 5 menit, dan hanya memengaruhi respons yang diterima klien, bukan perilaku cache POP, sehingga tidak diperlukan refresh atau prefetch (prefetch tidak mengubah header respons resource yang sudah di-cache).

    Untuk cara mengonfigurasi header respons outbound dan deskripsi parameternya, lihat Modify outbound response headers.

    Halaman menjadi kacau setelah akselerasi CDN. Bagaimana cara menanganinya?

    Penyebab: Header respons Content-Type yang dikembalikan oleh server origin tidak secara benar menentukan pengkodean karakter, dan klien mengurai konten dengan pengkodean salah, yang menyebabkan halaman kacau.

    Solusi 1 (direkomendasikan, perbaiki di sumber): Ubah konfigurasi server origin untuk memastikan bahwa Content-Type berisi deklarasi pengkodean karakter yang benar saat HTML dikembalikan.

    Solusi 2 (tulis ulang di sisi CDN):

    1. Login ke Konsol CDN. Di halaman Domain Names, temukan nama domain target dan klik Manage.

    2. Di Modify incoming response headers, tambahkan aturan untuk menulis ulang Content-Type path yang cocok menjadi text/html; charset=utf-8.

    3. Setelah konfigurasi selesai, gunakan Refresh and prefetch untuk merefresh resource yang di-cache di path tersebut agar POP meng-cache-nya kembali dengan tipe yang benar.

    Catatan

    Menulis ulang Content-Type dengan header respons inbound memperbaiki tipe selama tahap pengambilan asal, dan POP meng-cache resource kembali dengan tipe yang benar. Jika Anda menggunakan header respons outbound, tipe yang disimpan di cache POP masih salah dan hanya ditimpa saat pengiriman, yang kurang menyeluruh. Selain itu, header respons inbound tidak mendukung konfigurasi domain wildcard.

    Saya mengonfigurasi header respons untuk mengontrol unduhan atau pratinjau video, tetapi tidak berlaku. Apa yang harus saya lakukan?

    Anda dapat mengonfigurasi header respons Content-Disposition menggunakan fitur Modify outbound response headers untuk mengontrol perilaku unduhan atau pratinjau video: jika diatur ke attachment; filename='video.mp4', unduhan dipicu saat pengguna mengakses resource; jika diatur ke inline, resource dipratinjau langsung di browser.

    Jika konfigurasi tidak berlaku, periksa item berikut:

    1. Kondisi pencocokan mesin aturan: Pastikan kondisi pencocokan aturan menargetkan path URI (misalnya, berisi /video-origin/20260414) alih-alih hanya mencocokkan string kueri. Mesin aturan menentukan apakah konfigurasi berlaku dengan mengidentifikasi informasi path dalam permintaan pengguna.

    2. POP meng-cache header respons sebelumnya: Content-Disposition secara langsung memengaruhi perilaku browser. Jika konfigurasi tidak berlaku 5 menit setelah disimpan, pertama-tama kesampingkan cache browser lokal (coba lagi dalam mode penjelajahan pribadi) dan konfirmasi bahwa status aturan adalah Success.

    File JavaScript salah ditangani sebagai text/html. Bagaimana cara mengatasinya?

    Penyebab: Saat server origin pertama kali mengembalikan file JavaScript, header respons Content-Type salah diatur ke text/html. Setelah CDN meng-cache tipe yang salah, browser mengurai file JavaScript sebagai text/html, yang menyebabkan tampilan kacau atau error eksekusi. Pada kunjungan kedua, halaman kembali normal karena server origin memperbaiki Content-Type atau CDN mengambil tipe yang benar dari server origin lagi.

    Solusi:

    1. Di Modify incoming response headers di Konsol CDN, tambahkan aturan untuk mencocokkan path file JavaScript (seperti *.js) dan ganti paksa Content-Type dengan application/javascript.

    2. Setelah konfigurasi selesai, gunakan Refresh and prefetch untuk merefresh cache file JavaScript agar aturan baru segera berlaku.

    Catatan

    Masalah ini memiliki akar penyebab yang sama dengan halaman kacau (server origin mengembalikan Content-Type yang salah). Dalam kedua kasus, kami menyarankan Anda memperbaiki konfigurasi server origin terlebih dahulu, dan hanya menulis ulang header dengan header respons inbound jika server origin tidak dapat disesuaikan.

    Pengecualian video dan file besar

    ERR_CONTENT_LENGTH_MISMATCH terjadi selama pemutaran video?

    Penyebab: Panjang file yang di-cache di POP tidak sesuai dengan konten aktual di server origin, atau server origin mengembalikan header respons Content-Length abnormal. Ini paling sering terjadi saat server origin memperbarui file video tetapi CDN masih mengembalikan versi yang di-cache sebelumnya.

    Solusi:

    • Di halaman Refresh and prefetch, kirimkan tugas refresh untuk URL video untuk membersihkan cache sebelumnya di POP.

    • Jika server origin adalah OSS, Anda dapat mengaktifkan fitur Automatic CDN cache refresh di Konsol OSS agar refresh cache CDN dipicu secara otomatis saat file di server origin diperbarui.

    • Periksa stabilitas server origin untuk memastikan tidak secara intermiten mengembalikan nilai Content-Length abnormal. Anda dapat menjalankan curl -I beberapa kali langsung ke server origin untuk membandingkan dan memverifikasi.

    Apakah normal melihat banyak kode status 206 atau beberapa pengambilan asal di log?

    Ya. Pemutar video dan alat unduh biasanya menggunakan permintaan range untuk memuat resource dalam segmen. Setiap permintaan hanya mengambil sebagian konten, dan server mengembalikan 206 Partial Content. Bahkan saat permintaan mengenai cache CDN, kode status yang dikembalikan adalah 206, yang bukan error.

    Catatan penagihan: Selama klien mengirim permintaan ke CDN dan menerima data, traffic tersebut dihitung sebagai traffic outbound CDN terlepas dari apakah permintaan mengenai cache.

    Saran optimasi: Pastikan range origin fetch diaktifkan agar POP dapat mengambil dan meng-cache segmen dari server origin sesuai kebutuhan, yang meningkatkan rasio hit untuk permintaan segmen berikutnya. Selain itu, konfigurasikan header Cache-Control yang tepat di server origin (seperti max-age=86400) untuk menggunakan cache browser lokal dan mengurangi permintaan duplikat.

    Pengecualian konten dan akses

    Sumber daya statis sudah masuk cache, namun halaman utama masih lambat dimuat?

    Penyebab: Resource statis seperti gambar, file CSS, dan file JavaScript mengenai cache dan dipercepat secara normal, tetapi homepage (path root /) biasanya tidak memiliki aturan cache. Setiap permintaan mengambil homepage dari server origin, sehingga kecepatan loading sepenuhnya bergantung pada waktu pemrosesan server origin.

    Solusi: Tambahkan aturan waktu kedaluwarsa cache untuk direktori root nama domain yang dipercepat agar konten homepage juga di-cache di POP:

    Penting

    Solusi berikut hanya berlaku untuk homepage yang murni statis atau pseudo-statis, seperti situs resmi dan blog. Jika homepage berisi konten dinamis spesifik pengguna seperti status login atau rekomendasi personalisasi, meng-cache direktori root dapat menyebabkan pengguna melihat konten pengguna lain, yang mengarah pada kebocoran informasi. Untuk homepage dinamis, gunakan ESI (Edge Side Includes) atau arsitektur pemisahan statis-dinamis.

    1. Di tab Cache Expiration, tambahkan aturan, atur tipe ke Directory, dan atur alamat ke /.

    2. Atur waktu kedaluwarsa berdasarkan frekuensi pembaruan konten homepage, misalnya dari 30 detik hingga beberapa menit.

    3. Sesuaikan bobot aturan agar bobot aturan direktori root lebih rendah daripada aturan untuk path spesifik (seperti /static/) untuk menghindari menimpa aturan cache untuk resource statis.

    Setelah konfigurasi berlaku, POP mengembalikan konten homepage secara langsung alih-alih mengambilnya dari server origin untuk setiap permintaan. Untuk instruksi konfigurasi detail, lihat Configure CDN cache expiration.

    Akses melalui CDN mengembalikan hasil berbeda dari akses langsung ke server origin?

    Penyebab: Saat POP cache miss, POP meneruskan permintaan klien dan menambahkan parameter spesifik ke header permintaan, seperti Via dan X-Forwarded-For. Beberapa server origin mengembalikan respons berbeda berdasarkan parameter ini. Misalnya, server origin mungkin memeriksa apakah permintaan berisi header Via untuk mengidentifikasi permintaan proxy dan menanganinya secara berbeda.

    Langkah troubleshooting:

    1. Temukan header yang menyebabkan perbedaan: Pertama, akses server origin langsung dan catat responsnya. Lalu gunakan curl untuk mengakses server origin dengan header yang ditambahkan CDN, ganti dan uji satu per satu hingga Anda mereproduksi hasil yang tidak konsisten.

    2. Sesuaikan konfigurasi server origin: Periksa bagaimana server web origin memproses header tersebut dan ubah logikanya berdasarkan kebutuhan bisnis Anda.

    3. Atau hapus header di sisi CDN: Jika header tersebut tidak diperlukan oleh bisnis Anda, Anda dapat menghapusnya di Konsol CDN.

    File yang diunduh melalui CDN tidak konsisten dengan file di server origin (pembaruan dengan nama sama). Bagaimana cara mengatasinya?

    Penyebab: Server origin melakukan pembaruan dengan nama sama pada file (konten file diubah tetapi nama file tidak diubah). Sebelum cache kedaluwarsa, POP CDN masih mengembalikan cache sebelumnya secara langsung, sehingga file yang diunduh tidak konsisten dengan file di server origin.

    Solusi:

    1. Solusi 1: Refresh cache secara manual. Setelah server origin melakukan pembaruan dengan nama sama, kirimkan refresh URL di halaman Refresh and prefetch (cocok untuk resource tunggal dan berlaku cepat) atau refresh direktori (cocok untuk seluruh direktori dan cakupan luas, tetapi sementara meningkatkan tekanan pengambilan asal pada server origin).

    2. Solusi 2: Paksa refresh untuk melewati 304. Jika konten file di server origin berubah tetapi timestamp Last-Modified tidak diperbarui, POP CDN menerima 304 Not Modified setelah validasi permintaan kondisional (If-Modified-Since), menentukan bahwa file tidak berubah, dan tidak memperbarui cache. Dalam kasus ini, refresh URL normal mungkin tidak berlaku. Anda harus memanggil API RefreshObjectCaches dan atur parameter Force ke true untuk memaksa mengambil file lengkap dari server origin.

    3. Solusi 3: Gunakan pemberian nama versi (direkomendasikan sebagai solusi jangka panjang). Kami menyarankan server origin menghindari pembaruan dengan nama sama. Sebagai gantinya, tambahkan nomor versi atau hash ke nama file (seperti style.v2.css atau app.abc123.js), atau sertakan pengenal versi dalam parameter URL (seperti ?v=20260828).

    4. Solusi 4: Aktifkan refresh otomatis untuk origin OSS. Jika server origin adalah OSS, Anda dapat mengaktifkan Automatic CDN cache refresh di Konsol OSS. Saat objek di origin OSS diperbarui dengan nama sama, URL CDN yang sesuai akan direfresh secara otomatis.

    Catatan

    Saat Anda menggunakan parameter versi URL, jangan aktifkan Ignore parameters di CDN secara bersamaan. Jika tidak, parameter versi diabaikan dan solusi ini menjadi tidak efektif. Jika bisnis Anda harus mengabaikan parameter lain, gunakan Retain specified parameters sebagai gantinya dan pertahankan parameter versi.

    Mengapa halaman 404 kustom muncul saat saya mengakses resource?

    Saat server web mengembalikan kode status HTTP 404, server tersebut secara otomatis mengarahkan ke halaman 404, yang menunjukkan bahwa resource yang diminta tidak ada di server origin. Penyebab umum meliputi: aturan pembuatan URL berubah, file diganti nama atau dipindahkan, tautan berisi kesalahan ketik, situs web tidak dapat diakses di port yang diminta, atau kebijakan lockdown ekstensi layanan web atau kebijakan pemetaan MIME memblokir permintaan.

    Jika halaman yang Anda akses berisi banyak resource dan hanya sebagian yang tidak dapat diakses, halaman tersebut tidak mengarahkan ke halaman 404 secara keseluruhan. Untuk cara mengonfigurasi halaman error kustom, lihat Configure custom error pages.

    Redirect domain atau redirect loop terjadi setelah saya mengonfigurasi halaman 403 kustom. Bagaimana cara menanganinya?

    Saat Anda mengonfigurasi halaman error kustom untuk kode status 403, mengonfigurasi tautan redirect langsung dalam pengaturan halaman error dapat menyebabkan redirect domain atau redirect loop. Gunakan metode berikut sebagai gantinya:

    1. Konfigurasikan redirect menggunakan fitur Access URL Rewrite alih-alih mengatur tautan redirect di halaman error kustom.

    2. Atur path yang akan ditulis ulang ke / dan arahkan path target ke halaman 403 statis yang benar, misalnya /error/403.html.

    Penting

    Pastikan halaman error 403 itu sendiri dapat diakses dan tidak memicu redirect 403 lainnya. Jika tidak, redirect loop terjadi dan halaman tidak dapat diakses sama sekali.

    Apa yang harus dilakukan jika masalah tetap belum terselesaikan

    Sebelum mengirimkan tiket, kami menyarankan Anda menemukan masalah sendiri dengan cara berikut:

    • Periksa log waktu nyata: Di Konsol, periksa status cache, status pengambilan asal, dan distribusi kode respons permintaan spesifik untuk menentukan URL atau periode waktu mana masalah terkonsentrasi.

    • Gunakan tool diagnostik Konsol: Masukkan URL bermasalah untuk deteksi guna cepat mendapatkan informasi resolusi, pengambilan asal, dan header respons.

    • Lakukan pengujian perbandingan: Akses resource yang sama melalui CDN dan langsung dari server origin secara terpisah, bandingkan perbedaan header respons dan konten, dan tentukan apakah masalah berada di sisi CDN atau server origin.

    Jika masalah tetap belum terselesaikan setelah troubleshooting mandiri, kami menyarankan Anda mengumpulkan informasi berikut sebelum mengirimkan tiket untuk mempercepat identifikasi:

    • Nama domain yang dipercepat dan URL permintaan spesifik.

    • Output lengkap curl -v yang mereproduksi masalah (termasuk header permintaan dan header respons).

    • Perkiraan waktu, wilayah, dan ISP saat masalah terjadi.

    • Jenis server origin (OSS, ECS, SLB, server origin pihak ketiga, dll.) dan apakah server origin mendukung permintaan range.

    • Langkah troubleshooting yang telah Anda coba dan hasil setiap langkah.

    • Jika masalah melibatkan rasio hit cache, berikan tangkapan layar rasio hit di Konsol dan rentang waktu yang sesuai.