CDN:Panduan troubleshooting pengoptimalan kinerja

Masalah kinerja dipengaruhi oleh banyak faktor. Sebelum troubleshooting, pastikan permintaan benar-benar melewati CDN, dan buat kelompok kontrol untuk mempersempit akar penyebab.

Kumpulkan efek akses

Troubleshooting yang dapat direproduksi harus mencatat setidaknya informasi berikut:

• Waktu UTC, wilayah dan ISP klien, IP klien yang disamarkan <CLIENT_IP>, LocalDNS;

• URL permintaan, metode permintaan, kode status, rantai redirect;

• Hasil DNS, IP node yang terhubung sebenarnya;

• X-Cache, X-Swift-CacheTime, Age (jika ada), Via;

• Cache-Control, Pragma, Expires, ETag, Last-Modified, Vary;

• Content-Type, Content-Length, Content-Encoding, Accept-Ranges, Content-Range;

• Durasi DNS, TCP, TLS, TTFB, unduh, dan total;

• Hasil perbandingan permintaan yang sama untuk GET CDN pertama, GET berulang, GET node tertentu, dan GET origin langsung.

curl -sS -D /tmp/cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntime_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\nsize_download=%{size_download}\n' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<CDN_NODE_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<ORIGIN_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip, br' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1023' \
  "https://<CDN_DOMAIN>/<LARGE_RESOURCE_PATH>"

curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"
curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

Kualitas jaringan client-to-node buruk atau anomali penjadwalan

Gejala: ping ke domain yang dipercepat menunjukkan latensi tinggi atau packet loss; pengguna di wilayah atau ISP tertentu lambat; pengguna dijadwalkan ke node jauh.

Penyebab dan troubleshooting yang mungkin:

• Pengaturan wilayah akselerasi salah: Saat wilayah akselerasi diatur ke "Hanya Tiongkok Daratan", pengguna luar negeri dijadwalkan ke node Tiongkok Daratan; saat diatur ke "Global (tidak termasuk Tiongkok Daratan)", pengguna Tiongkok Daratan dijadwalkan ke node luar negeri. Atur wilayah akselerasi ke cakupan yang benar berdasarkan distribusi pengguna (misalnya, "Global").

• Domain belum menyelesaikan pendaftaran ICP: Domain yang belum terdaftar hanya dapat memilih "Global (tidak termasuk Tiongkok Daratan)". Saat pengguna Tiongkok Daratan mengakses melalui node luar negeri, tautannya lebih panjang dan kecepatan mungkin tidak memuaskan. Untuk memberikan akselerasi bagi pengguna Tiongkok Daratan, harap selesaikan pendaftaran ICP terlebih dahulu; jika tidak memungkinkan, pertimbangkan menggunakan Edge Security Acceleration (ESA) untuk mengurangi latensi bagi pengguna Tiongkok Daratan yang mengakses situs luar negeri.

• Pengaturan DNS klien salah: Misalnya, pengguna Tokyo yang menggunakan DNS AS mungkin dijadwalkan ke node AS alih-alih node terdekat. Instruksikan pengguna untuk mengubah ke DNS yang sesuai dengan lokasi dan ISP mereka.

• Fluktuasi jaringan ISP regional: Saat wilayah akselerasi dan DNS sudah benar tetapi akses tetap lambat, kumpulkan informasi traceroute dan MTR untuk mengonfirmasi segmen tautan spesifik tempat latensi terjadi; uji dengan bind ke IP node yang dicapai permintaan pengguna untuk mengonfirmasi apakah node itu sendiri merespons secara normal, lalu gabungkan status hit cache dan ukuran resource untuk analisis lebih lanjut.

Rasio hit cache rendah atau pengambilan asal sering menyebabkan akses lambat

Gejala: Header respons X-Cache adalah MISS, X-Swift-CacheTime bernilai 0; tekanan origin tinggi dan lalu lintas origin tinggi; akses pertama lebih lambat daripada mengakses origin langsung.

Penyebab umum dan solusi pengoptimalan:

• Akses pertama tidak memiliki cache: Node harus mengambil data dari origin pada respons pertama. Kami merekomendasikan menggunakan fitur prefetch URL untuk secara proaktif mengambil konten origin ke node CDN; lihat Purge dan prefetch resource.

• Lalu lintas rendah dan popularitas file tidak mencukupi: Cache node menghapus item paling tidak populer berdasarkan popularitas; resource lalu lintas rendah dihapus lebih awal. Dalam skenario lalu lintas rendah, Anda dapat memperpanjang waktu cache secara tepat atau menggunakan prefetch untuk mempertahankan popularitas.

• Konfigurasi cache tidak masuk akal:

  • Saat tidak ada aturan cache yang dikonfigurasi dan file statis tidak mengembalikan header respons ETag dan Last-Modified, file tersebut tidak dapat di-cache. Harap tambahkan dua header respons ini di origin, atau konfigurasikan aturan cache di sisi CDN; lihat Konfigurasi masa kedaluwarsa cache CDN.

  • Saat tidak ada aturan cache yang dikonfigurasi, kebijakan cache default digunakan, dengan waktu cache maksimum tidak melebihi 3600 detik, yang mudah menyebabkan kadaluwarsa sering dan pengambilan asal. Harap atur waktu cache yang masuk akal berdasarkan bisnis Anda.

  • Saat header respons origin berisi salah satu dari s-maxage=0, max-age=0, no-cache, no-store, private, atau Pragma: no-cache, konten tidak akan di-cache meskipun aturan cache telah dikonfigurasi. Harap ubah header respons origin ke nilai yang dapat di-cache (seperti public), atau aktifkan Ignore Origin No-Cache Header dalam aturan cache CDN.

• URL membawa parameter variabel: Saat URL dengan parameter berbeda mengakses file yang sama, CDN memperlakukannya sebagai resource berbeda dan mengambil dari origin secara terpisah. Harap aktifkan fitur abaikan parameter; lihat Abaikan parameter.

• File besar lambat diambil dari origin: Untuk skenario file besar, kami merekomendasikan mengaktifkan range origin fetch untuk mengoptimalkan efisiensi pengambilan asal; lihat Konfigurasi range origin fetch.

• Refresh cache sering: Refresh cache URL atau direktori yang sering menyebabkan cache node tetap tidak valid dan mengurangi rasio hit. Harap hanya refresh resource yang terpengaruh saat konten diperbarui.

Metode verifikasi: Bind domain pengguna di hosts ke IP origin dan akses langsung, lalu bandingkan waktu muat dengan akses CDN untuk memverifikasi efek akselerasi dan mengonfirmasi apakah bottleneck berada di pengambilan asal atau tautan distribusi. Untuk strategi pengoptimalan rasio hit lebih lanjut, lihat Troubleshooting cache.

Permintaan dinamis lambat

Gejala: Konten dinamis seperti antarmuka API lambat; resource statis cepat tetapi halaman secara keseluruhan dimuat lambat.

Penyebab: CDN tidak dapat meng-cache konten dinamis yang berubah secara real-time. Permintaan dinamis diteruskan ke server origin setiap kali, sehingga akselerasi cache CDN tidak berlaku untuknya. Jika origin itu sendiri lambat, permintaan dinamis akan menjadi lambat secara sinkron.

Solusi:

• Pisahkan konten statis dan dinamis di origin: gunakan domain yang dipercepat CDN untuk resource statis, dan domain yang di-resolve langsung ke origin untuk permintaan dinamis.

• Gunakan Edge Security Acceleration (ESA) untuk mempercepat permintaan dinamis melalui optimasi rute, optimasi transport, dan teknologi lainnya untuk memperpendek rantai origin. Perhatikan bahwa akselerasi dinamis adalah optimasi tautan; jika server origin itu sendiri lambat, origin tetap perlu dioptimalkan.

Pengambilan asal lintas negara atau lintas batas lambat

Gejala: Saat origin dan pengguna utama berada di negara atau wilayah berbeda, kualitas pengambilan asal berfluktuasi, pengambilan asal lambat, dan tingkat kegagalan origin tinggi, memengaruhi cache dan distribusi konten.

Penyebab: Pengambilan asal lintas batas dipengaruhi oleh kapasitas kabel laut dan kemacetan jaringan publik antar negara.

Solusi: Gunakan Global Accelerator (GA) untuk memberikan akselerasi terarah untuk origin di negara yang sesuai, dan konfigurasikan kebijakan pengambilan asal berbasis wilayah CDN untuk meningkatkan kualitas pengambilan asal saat cache miss. GA mendukung jenis origin seperti ECS, ALB, dan OSS, serta menyediakan solusi seperti Percepat pengembalian ke asal dengan GA dan CDN.

Halaman utama situs web dimuat lambat

Gejala: Permintaan halaman utama berada dalam status Pending dalam waktu lama di Network; setelah halaman utama dikembalikan, resource statis dimuat cepat.

Penyebab: Halaman utama biasanya merupakan resource dinamis atau dikonfigurasi sebagai non-cacheable, sehingga setiap kunjungan kembali ke origin. Saat respons origin lambat, permintaan halaman utama diblokir, dan resource selanjutnya seperti gambar, JS, dan CSS yang dirujuk oleh HTML halaman utama tidak dapat mulai dimuat.

Solusi: Pertama-tama konfirmasi melalui header respons apakah halaman utama mengenai cache (lihat Cara mengidentifikasi arah masalah akses lambat); jika miss, troubleshooting konfigurasi cache sesuai Rasio hit cache rendah atau pengambilan asal sering menyebabkan akses lambat; jika respons origin lambat, optimalkan kinerja origin atau adopsi pemisahan statis/dinamis.

Resource besar dimuat lambat

Gejala: Content Download menyumbang proporsi besar dalam Timing; resource halaman memiliki ukuran total besar.

Solusi: Aktifkan fitur pengoptimalan kinerja (kompresi cerdas, pengoptimalan halaman, dll.) untuk mengurangi ukuran file dan meningkatkan kecepatan pemuatan; lihat Pengoptimalan kinerja. Kompresi cerdas mendukung format berikut: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, text/javascript, image/tiff, image/svg+xml, application/json, application/xml.

Kompresi Gzip tidak berfungsi setelah pengambilan asal

Gejala: Origin (seperti Nginx) telah mengaktifkan kompresi Gzip, dan header respons mengembalikan Content-Encoding: gzip saat klien mengakses origin langsung; saat mengakses melalui CDN dengan header permintaan membawa Accept-Encoding: gzip, deflate, header respons hanya mengembalikan Content-Length, dan kontennya tidak terkompresi.

Penyebab: Permintaan pengambilan asal CDN membawa header permintaan Via untuk mengidentifikasi bahwa permintaan berasal dari server proxy. Modul ngx_http_gzip_module Nginx menggunakan konfigurasi gzip_proxied untuk mengontrol apakah kompresi diaktifkan untuk permintaan proxy. Nilai default konfigurasi ini adalah off, sehingga permintaan pengambilan asal dari CDN tidak mengembalikan konten terkompresi.

Solusi:

1. Atur gzip_proxied any dalam file konfigurasi Nginx (blok http, server, atau location, mana yang berlaku) sehingga semua permintaan dari server proxy dikompresi.

2. Jalankan nginx -t untuk mengonfirmasi konfigurasi benar, lalu jalankan nginx -s reload untuk memuat ulang konfigurasi.

3. Akses melalui CDN dan konfirmasi bahwa header respons berisi Content-Encoding: gzip.

Metode verifikasi: Gunakan curl untuk menguji langsung ke origin — saat tidak mengirim header Via, mengembalikan Content-Encoding: gzip; setelah menambahkan -H 'Via:xxx' untuk mensimulasikan permintaan proxy, hanya mengembalikan Content-Length. Ini mengonfirmasi masalah disebabkan oleh konfigurasi gzip_proxied.

Catatan: Pendekatan troubleshooting sama saat kompresi Brotli tidak berfungsi — konfirmasi apakah origin menolak mengembalikan konten terkompresi untuk permintaan proxy karena header permintaan Via atau konfigurasi seperti gzip_proxied, dan ganti konfigurasi terkait Gzip dengan konfigurasi Brotli yang sesuai.

Pertimbangan dengan pengoptimalan halaman: Jika Anda juga mengaktifkan pengoptimalan halaman, perhatikan bahwa kompresi origin dan pengoptimalan halaman saling eksklusif; CDN tidak dapat melakukan pengoptimalan halaman setelah origin mengembalikan konten terkompresi. Pilih antara kompresi origin (menghemat bandwidth origin) dan pengoptimalan halaman (mengurangi ukuran HTML) berdasarkan prioritas bisnis.

Pengoptimalan halaman tidak berfungsi saat pengoptimalan halaman dan kompresi Gzip diaktifkan bersamaan

Gejala: Pengoptimalan halaman diaktifkan. Saat curl dikirim tanpa header permintaan Accept-Encoding, HTML yang dikembalikan dioptimalkan; tetapi saat diakses dari browser (yang secara default mengirim Accept-Encoding: gzip), konten yang dikembalikan tidak dioptimalkan.

Penyebab:

• Origin mengembalikan konten terkompresi Gzip: Browser secara default membawa header permintaan Accept-Encoding: gzip, dan CDN meneruskan header ini saat mengambil dari origin. Saat origin telah mengaktifkan Gzip, origin mengembalikan konten terkompresi. Node CDN tidak mendekompresi konten yang sudah dikompresi oleh origin sebelum melakukan pengoptimalan halaman, sehingga pengoptimalan halaman tidak dapat berlaku saat origin mengembalikan konten terkompresi.

• Kompresi cerdas CDN tidak menghalangi pengoptimalan halaman: Kompresi cerdas CDN berjalan setelah pengoptimalan halaman; keduanya tidak bertentangan. Gejala ini hanya muncul saat origin telah mengembalikan konten terkompresi — pra-kompresi origin mencegah CDN melakukan pengoptimalan halaman, dan tidak terkait dengan kompresi cerdas sisi CDN.

Solusi:

• Opsi 1: Pastikan origin tidak mengembalikan konten terkompresi Gzip untuk permintaan pengambilan asal CDN. Untuk origin Nginx, ubah parameter gzip_proxied sehingga permintaan dari server proxy tidak mengembalikan konten terkompresi.

• Opsi 2: Dalam konfigurasi CDN, hapus Accept-Encoding dari header permintaan HTTP origin sehingga origin mengembalikan konten tidak terkompresi dan CDN melakukan pengoptimalan halaman.

Catatan: Setelah origin berhenti mengembalikan konten terkompresi, CDN dapat mengompresi respons klien melalui fitur kompresi cerdas, mencapai pengoptimalan halaman dan kompresi transmisi sekaligus.

Eksepsi Bisnis Setelah Mengaktifkan Parameter Abaikan

Gejala: Setelah mengaktifkan abaikan parameter, otentikasi gagal, data pengguna tercampur, konten cache salah dikembalikan, atau pemrosesan gambar menjadi tidak valid.

Penyebab: Setelah abaikan parameter diaktifkan, CDN memperlakukan permintaan dengan parameter berbeda sebagai resource yang sama untuk caching. Jenis parameter URL berikut tidak boleh diabaikan secara global:

• Identifier identitas pengguna (seperti UID, Token, Session ID): mengabaikannya menyebabkan kegagalan otentikasi atau data pengguna tercampur.

• Diferensiasi konten dinamis (seperti versi ?v=1, nomor halaman ?page=2): mengabaikannya mengembalikan konten cache salah.

• Direktif pemrosesan origin (seperti parameter pemrosesan gambar OSS x-oss-process): mengabaikannya membuat parameter pemrosesan tidak valid dan mengembalikan resource asli yang tidak diproses.

Troubleshooting dan solusi:

1. Hapus atau nonaktifkan konfigurasi abaikan parameter.

2. Lakukan refresh cache (refresh URL atau refresh direktori) untuk membersihkan cache lama di node tepi.

3. Jika beberapa parameter perlu dipertahankan, gunakan mode pertahankan parameter tertentu dan atur parameter kunci (seperti x-oss-process, token) sebagai yang dipertahankan. Untuk detail fitur abaikan parameter, lihat Abaikan parameter.

Konfigurasi abaikan parameter tidak berlaku setelah modifikasi

Gejala: Setelah memodifikasi konfigurasi abaikan parameter, akses masih abnormal atau lalu lintas origin belum berkurang.

Penyebab: Setelah konfigurasi dimodifikasi, file yang sudah di-cache di node tepi tidak diperbarui secara otomatis; cache lama masih merespons sesuai kebijakan lama.

Langkah troubleshooting:

1. Konfirmasi konfigurasi disimpan: Masuk ke konsol CDN, buka kembali halaman konfigurasi abaikan parameter, dan konfirmasi konfigurasi saat ini sesuai dengan keadaan yang diharapkan.

2. Periksa konflik dengan Cache Key kustom: Cache Key kustom menggantikan konfigurasi abaikan parameter. Jika Cache Key kustom diaktifkan, konfigurasi abaikan parameter tidak akan berlaku. Harap konfirmasi bahwa keduanya tidak diaktifkan secara bersamaan.

3. Lakukan refresh cache: Di halaman Purge dan prefetch resource, lakukan refresh URL atau refresh direktori. Konfigurasi baru hanya dapat berlaku sepenuhnya setelah cache lama dibersihkan.

4. Verifikasi efek konfigurasi: Jalankan curl -I "full URL" dan periksa header respons X-Cache untuk mengonfirmasi status hit cache sesuai harapan.

Konten pemrosesan gambar OSS atau pengambilan frame video salah

Gejala: Saat menggunakan pemrosesan gambar OSS (seperti x-oss-process=image/resize,w_200) atau pengambilan frame video, akses mengembalikan gambar atau video asli yang tidak diproses, atau permintaan dengan parameter pemrosesan berbeda mengembalikan konten yang sama.

Penyebab: Setelah abaikan parameter diaktifkan untuk domain CDN, tautan gambar asli dan tautan dengan parameter pemrosesan di-cache sebagai resource yang sama, menyebabkan konten salah.

Solusi: Dalam konfigurasi abaikan parameter konsol CDN, atur parameter x-oss-process ke mode pertahankan parameter tertentu, sehingga URL dengan parameter pemrosesan gambar di-cache secara terpisah dan tidak bertentangan dengan cache gambar asli. Setelah memodifikasi konfigurasi, refresh cache (lihat Konfigurasi abaikan parameter tidak berlaku setelah modifikasi).

Status hit cache tidak konsisten setelah mengaktifkan abaikan parameter

Gejala: Abaikan parameter diaktifkan, tetapi status hit cache tidak konsisten di berbagai klien; beberapa permintaan menunjukkan X-Cache MISS.

Penyebab yang mungkin:

1. URL membawa parameter otentikasi dinamis yang tidak diabaikan: Misalnya, URL memiliki parameter otentikasi seperti auth_key yang diatur sebagai dipertahankan. Setiap permintaan memiliki nilai otentikasi berbeda, sehingga CDN tetap mengenalinya sebagai resource berbeda.

2. Akses pertama tidak memiliki cache di node: Resource belum di-cache di node tepi tersebut, sehingga akses pertama pasti menunjukkan MISS.

3. Perbedaan header permintaan klien: Misalnya, Accept-Encoding berbeda dapat memicu caching multi-salinan (versi Gzip dan non-Gzip di-cache secara terpisah). Jika origin mengembalikan Vary: User-Agent, permintaan dari UA berbeda juga akan di-cache secara terpisah.

4. Konflik dengan Cache Key kustom: Cache Key kustom menggantikan konfigurasi abaikan parameter; saat keduanya diaktifkan, abaikan parameter tidak berlaku.

Metode troubleshooting: Di klien, jalankan curl -I "full URL" dan bandingkan header respons X-Cache dan X-Swift-CacheTime untuk mengonfirmasi status cache. Solusi: Konfirmasi bahwa konfigurasi abaikan parameter benar (diaktifkan dan parameter kunci dipertahankan), pastikan strategi header permintaan klien konsisten, dan konfirmasi bahwa Cache Key kustom tidak diaktifkan secara bersamaan.