CDN:Troubleshooting pengambilan asal

Node CDN, yang bertindak sebagai gerbang, mengembalikan error 502 (Bad Gateway) ketika tidak dapat memperoleh respons valid dari server asal. Kegagalan pada tahap mana pun dalam jalur pengambilan asal berikut dapat mengembalikan error 502:

• Server asal tidak mendukung HTTPS (hanya mendengarkan pada port 80), tetapi CDN dikonfigurasi untuk melakukan pengambilan asal melalui HTTPS.

• Port asal tidak sesuai dengan port tempat server asal benar-benar mendengarkan.

• Server asal bergantung pada SNI untuk memilih sertifikat, tetapi CDN tidak membawa nilai SNI atau membawa nilai yang salah.

• Sertifikat SSL server asal telah kedaluwarsa atau tidak valid, atau tidak sesuai dengan nama domain.

• Server asal menggunakan sertifikat tanda tangan sendiri atau sertifikat yang dikeluarkan oleh CA internal, dan validasi TLS selama pengambilan asal gagal.

Langkah troubleshooting:

• Periksa apakah server asal mendukung protokol pengambilan asal saat ini: Jalankan curl -Iv https://domain-asal untuk memverifikasi server asal secara langsung. Jika koneksi ditolak atau timeout, server asal tidak mendukung HTTPS. Ubah protokol asal ke HTTP. Jika server asal mendukung HTTPS dan sertifikat valid, Anda dapat memilih pengambilan asal HTTPS atau protokol Follow.

• Periksa apakah port asal sesuai dengan port tempat server asal mendengarkan: Port asal default adalah 443 untuk HTTPS dan 80 untuk HTTP. Jika server asal menggunakan port kustom (1 hingga 65535), tentukan port yang sesuai dalam konfigurasi protokol asal.

• Periksa konfigurasi SNI asal: Saat server asal menghosting beberapa situs HTTPS pada alamat IP yang sama, server tersebut bergantung pada field SNI (Server Name Indication) dalam proses jabat tangan TLS untuk memilih sertifikat SSL yang sesuai. Jika pengambilan asal CDN tidak membawa nilai SNI atau nilai SNI salah, server asal tidak dapat mencocokkan sertifikat yang benar, proses jabat tangan TLS gagal, dan error 502 dikembalikan.

  Langkah solusi: Masuk ke Konsol CDN, pilih Manajemen Domain, pilih nama domain target, buka Pengaturan Origin, dan aktifkan origin SNI. Masukkan nama domain yang benar-benar digunakan server asal untuk menyediakan layanan (biasanya sama dengan Common Name sertifikat asal). Atur juga host asal ke nama domain asal.

  Selama pengambilan asal, CDN memvalidasi nilai SNI terhadap Common Name dalam sertifikat server asal. Jika kedua nilai benar-benar tidak dapat dicocokkan (misalnya, server asal menggunakan sertifikat pada lapisan akses terpadu), tambahkan Common Name sertifikat ke daftar putih Common Name.

  Catatan

  SNI asal digunakan untuk memilih sertifikat selama proses jabat tangan TLS, sedangkan host asal digunakan untuk routing host virtual di lapisan HTTP. Keduanya memiliki tujuan berbeda, tetapi biasanya diatur ke nama domain asal yang sama.

• Periksa validitas sertifikat SSL pada server asal: Pastikan sertifikat belum kedaluwarsa dan belum dicabut, serta nama domain dalam sertifikat mencakup nama domain asal. Jalankan curl -Iv https://domain-asal 2>&1 | grep -E "expire|subject|issuer" untuk melihat periode validitas, penerbit, dan nama domain yang terikat pada sertifikat. Jika sertifikat telah kedaluwarsa atau tidak sesuai dengan nama domain, perbarui sertifikat di server asal. Jika server asal menggunakan sertifikat tanda tangan sendiri atau sertifikat yang dikeluarkan oleh CA internal, gantilah dengan sertifikat yang dikeluarkan oleh CA tepercaya publik, atau ubah protokol asal ke HTTP.

Solusi: Ubah protokol asal berdasarkan konfigurasi aktual server asal: server asal hanya mendukung HTTP → pilih HTTP (port 80 secara default); server asal mendukung HTTPS dan sertifikat valid → pilih HTTPS (port 443 atau port kustom); server asal mendukung kedua protokol dan sertifikat dikelola dengan baik → Anda dapat memilih protokol Follow. Untuk langkah detail, lihat Configure the origin protocol policy.

Bagaimana cara troubleshooting error 502 saat protokol asal diatur ke Follow?

Saat protokol asal diatur ke Follow, CDN menggunakan protokol yang sama dengan permintaan client untuk pengambilan asal: jika client menggunakan HTTP, CDN menggunakan HTTP untuk pengambilan asal; jika client menggunakan HTTPS, CDN menggunakan HTTPS untuk pengambilan asal. Jika client mengakses CDN melalui HTTPS tetapi server asal tidak mendukung HTTPS, proses jabat tangan TLS gagal dan permintaan pengambilan asal gagal. Masalah ini memiliki penyebab yang sama dengan "Bagaimana cara troubleshooting error 502 yang dikembalikan selama pengambilan asal?" dan dapat didiagnosis dengan langkah troubleshooting yang sama.

Solusi:

• Metode 1: Ubah protokol asal dari Follow ke HTTP agar CDN selalu menggunakan HTTP untuk pengambilan asal.

• Metode 2: Konfigurasikan sertifikat SSL pada server asal agar server asal mendukung akses HTTPS. Untuk informasi lebih lanjut, lihat Configure the origin protocol policy.

Error 504 (Gateway Timeout) menunjukkan bahwa node CDN tidak dapat memperoleh respons dari server asal dalam waktu yang ditentukan selama pengambilan asal.

Penyebab umum meliputi:

• Server asal merespons lambat atau layanan tidak tersedia.

• Permintaan pengambilan asal dijatuhkan oleh perangkat jaringan perantara atau firewall (saat paket SYN dijatuhkan, ini muncul sebagai timeout koneksi).

• Protokol atau port asal salah konfigurasi, sehingga koneksi tidak dapat dibangun (ini biasanya muncul sebagai error 502, tetapi jika firewall diam-diam menjatuhkan paket alih-alih secara aktif menolaknya, ini juga dapat muncul sebagai error 504).

• Batas waktu baca origin terlalu singkat untuk mencakup waktu respons aktual server asal.

Timeout pengambilan asal terbagi menjadi dua fase, yang mengarah ke arah troubleshooting berbeda:

• Timeout fase koneksi: Batas waktu bagi node CDN untuk membangun koneksi TCP dengan server asal adalah 10 detik. Timeout pada fase ini biasanya menunjukkan bahwa server asal tidak mendengarkan pada port asal, firewall atau grup keamanan menjatuhkan paket SYN dari alamat IP pengambilan asal CDN, atau terjadi kehilangan paket parah pada jalur jaringan.

• Timeout fase baca: Koneksi telah dibangun, tetapi server asal tidak mengembalikan respons lengkap dalam batas waktu baca origin (30 detik secara default). Timeout pada fase ini biasanya menunjukkan bahwa server asal memproses permintaan secara lambat, misalnya karena query database lambat, aplikasi backend terblokir, atau beban tinggi pada server asal.

Langkah troubleshooting:

1. Periksa apakah server asal dapat diakses: Jalankan curl -I http(s)://domain-asal atau akses server asal di browser untuk memeriksa waktu respons dan kode status. Jika server asal sendiri merespons lambat atau tidak dapat diakses, perbaiki masalah kinerja atau ketersediaan di server asal terlebih dahulu.

2. Identifikasi fase mana yang memakan waktu: Jalankan perintah berikut:

   curl -o /dev/null -s -w "time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" http(s)://domain-asal/path-resource

   time_connect adalah waktu yang dibutuhkan untuk membangun koneksi TCP, time_starttransfer adalah waktu yang dibutuhkan untuk menerima byte pertama, dan time_total adalah waktu total.

   • Jika time_connect sudah sangat besar, troubleshooting jaringan dan firewall sebagai masalah fase koneksi.

   • Jika time_starttransfer jauh lebih besar daripada time_connect, pemrosesan bisnis di server asal lambat. Optimalkan server asal.

   • Jika time_total jauh lebih besar daripada time_starttransfer, badan respons terlalu besar atau bandwidth egress server asal tidak mencukupi.

3. Periksa konfigurasi protokol dan port asal: Pastikan protokol dan port asal yang dikonfigurasi di CDN sesuai dengan konfigurasi tempat server asal benar-benar mendengarkan. Jika port asal salah atau server asal tidak mendengarkan pada port tersebut, CDN mengembalikan error 504 setelah permintaan timeout.

4. Periksa firewall atau grup keamanan server asal: Jika server asal melakukan throttle atau memblokir rentang alamat IP pengambilan asal CDN, beberapa permintaan mungkin timeout. Kebijakan yang diam-diam menjatuhkan paket SYN secara khusus muncul langsung sebagai timeout fase koneksi. Tambahkan rentang alamat IP pengambilan asal CDN ke daftar putih server asal (lihat What are the CDN origin fetch node IP addresses).

5. Periksa kualitas jalur jaringan antara node CDN dan server asal: Jitter jaringan, kehilangan paket, atau masalah routing penyedia layanan mungkin ada antara node CDN dan server asal. Gunakan alat seperti MTR atau traceroute untuk menganalisis jalur (hubungi dukungan teknis Alibaba Cloud untuk memulai diagnostik dari sisi node CDN).

6. Tingkatkan batas waktu baca origin: Jika waktu respons server asal mendekati default 30 detik, Anda dapat meningkatkan origin HTTP request timeout di Konsol CDN untuk mengurangi error 504. Nilainya dapat dikonfigurasi hingga maksimal 150 detik, tetapi kami menyarankan agar tidak melebihi 60 detik. Gunakan ini hanya sebagai mitigasi sementara. Solusi mendasar tetap mengoptimalkan kinerja respons server asal.

Error 503 (Service Temporarily Unavailable) menunjukkan bahwa server asal sementara tidak dapat memproses permintaan. Error 503 yang diterima selama pengambilan asal CDN biasanya disebabkan oleh sisi server asal:

• Program layanan web di server asal tidak normal, belum dimulai, atau sedang restart.

• Beban pada server asal terlalu tinggi (CPU, memori, atau jumlah koneksi jenuh).

• Batas laju permintaan per-IP atau batas koneksi bersamaan dikonfigurasi di server asal.

• Kebijakan keamanan seperti perangkat lunak keamanan server (Yunsuo atau SafeDog), WAF, atau firewall di server asal memblokir alamat IP pengambilan asal CDN.

• Server asal telah memasuki mode maintenance atau sedang dideploy.

Langkah troubleshooting:

1. Bind file hosts untuk mereproduksi masalah dengan mengakses server asal secara langsung: Modifikasi file hosts lokal untuk mengarahkan nama domain yang dipercepat ke alamat IP server asal, lalu akses nama domain tersebut. Jika akses langsung ke server asal juga mengembalikan error 503, masalah berada di sisi server asal, dan node CDN itu sendiri dapat dikecualikan.

2. Periksa apakah layanan web di server asal normal: Pastikan proses layanan web seperti NGINX, Apache, atau IIS berjalan dan mendengarkan pada port yang sesuai (80/443 atau port kustom). Jika proses layanan tidak normal atau belum dimulai, restart layanan dan periksa log layanan untuk menemukan penyebabnya.

3. Periksa beban dan konfigurasi batas laju server asal: Beban CPU, memori, atau koneksi yang tinggi di server asal, atau batas permintaan per-IP (seperti modul limit_req atau limit_conn NGINX), dapat menyebabkan error 503 dikembalikan untuk permintaan pengambilan asal CDN. Evaluasi apakah Anda perlu menambah sumber daya atau menyesuaikan ambang batas batas laju berdasarkan volume trafik Anda.

   Catatan

   Permintaan pengambilan asal CDN datang secara terkonsentrasi dari sekumpulan terbatas alamat IP node pengambilan asal, dan mudah disalahartikan sebagai akses frekuensi tinggi dari satu IP saat server asal melakukan throttle berdasarkan IP. Kami menyarankan agar Anda menetapkan ambang batas batas laju yang lebih tinggi untuk rentang alamat IP pengambilan asal CDN, atau mengecualikannya secara langsung.

4. Periksa apakah kebijakan keamanan memblokir alamat IP pengambilan asal CDN: Kebijakan keamanan seperti grup keamanan, firewall, WAF, atau perangkat lunak keamanan server di server asal mungkin mengidentifikasi alamat IP pengambilan asal CDN sebagai trafik abnormal dan memblokirnya. Cari catatan dari alamat IP node CDN di log pemblokiran, dan tambahkan rentang alamat IP pengambilan asal CDN ke daftar putih (untuk cara mendapatkannya, lihat What are the CDN origin fetch node IP addresses).

5. Refresh cache CDN: Jika error 503 masih dikembalikan setelah server asal pulih, lakukan refresh URL. Untuk kode status seperti 500, 502, 503, dan 504, prioritas caching CDN adalah: jangan cache saat server asal mengembalikan Set-Cookie → cache sesuai waktu kedaluwarsa kode status yang dikonfigurasi di konsol jika dikonfigurasi → jika tidak, cache sesuai header respons Pragma, Cache-Control, dan Expires server asal → cache selama 1 detik secara default jika tidak ada kondisi sebelumnya yang berlaku. Oleh karena itu, secara default error 503 tidak menyebabkan dampak persisten. Namun, jika waktu kedaluwarsa kode status yang panjang dikonfigurasi untuk kode status 5xx di konsol, respons abnormal terus disimpan dalam cache hingga kedaluwarsa. Dalam kasus ini, refresh secara manual atau atur waktu cache kode status 5xx ke 0 (lihat Configure expiration for HTTP status codes).

Gejala

Server asal biasanya membedakan situs virtual berdasarkan header permintaan Host. Jika host asal yang dikonfigurasi di CDN tidak sesuai dengan nama domain yang diharapkan oleh server asal, server asal mungkin mengembalikan error seperti 404, 403, atau 500.

Langkah troubleshooting

1. Periksa apakah host asal sesuai dengan konfigurasi host virtual server asal

   • NGINX: Periksa apakah server_name berisi nama domain yang dikonfigurasi sebagai host asal.

   • Apache: Periksa ServerName / ServerAlias di <VirtualHost>.

   • IIS: Di IIS Manager, pilih situs web target > Bindings, dan periksa apakah bidang "Host name" sesuai dengan host asal.

2. Refresh cache CDN

Setelah Anda memodifikasi konfigurasi host asal, lakukan refresh URL untuk menghapus respons error yang mungkin telah disimpan dalam cache.

Gejala: Situs web mengembalikan error "Too many redirects" atau "ERR_TOO_MANY_REDIRECTS", atau resource seperti gambar, file CSS, dan file JavaScript gagal dimuat.

Penyebab: Server asal secara aktif merespons dengan pengalihan paksa HTTP-ke-HTTPS (aturan umum dalam layanan seperti aaPanel, WAF, dan NGINX), tetapi protokol asal CDN diatur ke HTTP. Akibatnya, jalur permintaan membentuk loop:

Client → CDN → CDN melakukan pengambilan asal melalui HTTP (port 80) → server asal mengembalikan pengalihan 301 ke HTTPS → jika follow pengalihan 301/302 asal tidak dikonfigurasi, CDN mengembalikan 301 ke client → browser mengikuti pengalihan ke HTTPS → pengambilan asal melalui CDN melalui HTTP terjadi lagi → server asal mengembalikan 301 lain → ... browser mengalihkan berulang kali dan akhirnya melaporkan ERR_TOO_MANY_REDIRECTS. Jika fitur follow pengalihan 301/302 asal diaktifkan, node CDN mengikuti pengalihan berulang kali di jalur pengambilan asal dan mengembalikan 301 ke pengguna setelah batas jumlah follow tercapai, yang juga membentuk loop. Untuk informasi lebih lanjut tentang fitur follow pengalihan, lihat Configure 301/302 redirection.

Solusi (pilih salah satu):

• Solusi A: Buat CDN menggunakan HTTPS untuk pengambilan asal. Prasyarat: server asal memiliki sertifikat SSL valid dan mendengarkan secara normal pada port 443. Ubah port asal ke 443 dan atur protokol asal ke HTTPS. Jika server asal mendengarkan beberapa nama domain, atur juga SNI asal dan host asal ke nama domain yang dipercepat atau nama domain asal.

• Solusi B: Nonaktifkan pengalihan paksa di server asal dan pertahankan komunikasi HTTP. Masuk ke server asal dan nonaktifkan aturan yang memaksa pengalihan HTTP ke HTTPS. Pertahankan protokol asal CDN sebagai HTTP dan port asal sebagai 80. Koneksi antara client dan CDN masih dapat menggunakan HTTPS, selama CDN dan server asal sepakat pada protokol yang sama.

Operasi tambahan (disarankan terlepas dari solusi yang Anda pilih): Jalankan tugas refresh URL untuk menghapus respons pengalihan yang disimpan dalam cache agar konfigurasi baru berlaku segera. Setelah konfigurasi dimodifikasi, konfigurasi tersebut perlu didistribusikan ke semua node di jaringan, yang biasanya membutuhkan beberapa menit. Selama periode ini, beberapa node mungkin masih mengembalikan respons pengalihan lama. Untuk kebijakan cache default CDN untuk berbagai kode status, lihat Configure expiration for HTTP status codes.

Entri ini hanya berlaku untuk skenario di mana loop pengalihan muncul hanya setelah Anda mengonfigurasi host asal atau SNI asal. Jika loop pengalihan terjadi sebelum Anda mengonfigurasinya, lihat entri sebelumnya "Apa yang harus saya lakukan jika terjadi loop pengalihan (ERR_TOO_MANY_REDIRECTS) selama pengambilan asal CDN setelah server asal dikonfigurasi untuk mengalihkan HTTP ke HTTPS?" Akar penyebabnya tetap bahwa server asal telah mengaktifkan pengalihan paksa HTTP-ke-HTTPS sementara CDN melakukan pengambilan asal melalui HTTP. Setelah Anda memodifikasi host asal atau SNI asal, server asal mencocokkan situs yang diharapkan dan aturan pengalihan paksa mulai berlaku, sehingga loop muncul. Troubleshoot sebagai berikut:

• Nonaktifkan pengalihan HTTPS paksa di server asal: Masuk ke konsol manajemen server asal (misalnya, aaPanel), buka pengaturan HTTPS, dan nonaktifkan opsi "Force HTTPS" atau "HTTP to HTTPS redirect".

• Pastikan host asal dan SNI asal konsisten dan benar: Di halaman pengaturan asal, atur host asal dan SNI asal ke nama domain yang benar (biasanya nama domain asal) dan pertahankan kedua nilai konsisten agar permintaan pengambilan asal memenuhi ekspektasi server asal.

• Refresh cache CDN: Setelah Anda menyesuaikan konfigurasi, refresh cache CDN untuk menghapus respons pengalihan yang disimpan dalam cache.

Error ini menunjukkan bahwa izin akses bucket OSS adalah privat, dan permintaan tanpa signature tidak dapat membaca objek di bucket tersebut. Bucket privat menyediakan otentikasi akses dan mencegah permintaan tidak sah mengonsumsi trafik. Oleh karena itu, kami tidak menyarankan mengubah bucket menjadi public read hanya untuk menghilangkan error ini.

Solusi: Aktifkan fitur Configure origin fetch from a private OSS bucket untuk nama domain yang dipercepat. Setelah fitur diaktifkan, CDN secara otomatis menggunakan peran layanan AliyunCDNAccessingPrivateOSSRole untuk membawa signature saat mengakses bucket privat, dan pengguna akhir tidak memerlukan signature tambahan saat mengakses resource melalui CDN. Jalur operasi: Konsol CDN > Domain Management > nama domain target > Origin Settings > Origin fetch from private OSS buckets.

Jika bucket OSS Anda dienkripsi dengan Key Management Service (KMS), Anda harus memberikan izin tambahan kepada peran pengambilan asal CDN untuk menggunakan kunci KMS. Jika tidak, CDN tidak dapat mendekripsi dan mengakses file-file ini, dan error This request is forbidden by kms. dikembalikan.

Solusi:

1. Masuk ke Konsol RAM. Pada panel navigasi kiri, pilih Identities > Roles.

2. Di daftar peran, temukan peran AliyunCDNAccessingPrivateOSSRole dan klik Grant Permission.

   Catatan

   Jika Anda tidak dapat menemukan peran tersebut, fitur pengambilan asal dari bucket OSS privat belum pernah diaktifkan. Pertama-tama aktifkan fitur tersebut seperti yang dijelaskan di Configure origin fetch from a private OSS bucket. Peran akan dibuat secara otomatis. Lalu kembali untuk melakukan langkah ini.

3. Di daftar kebijakan izin, pilih System Policy, cari dan tambahkan AliyunKMSCryptoUserAccess, lalu klik Grant permissions.

4. Gunakan fitur Refresh and Prefetch. Setelah tugas refresh selesai, akses kembali resource tersebut.

Masalah ini terjadi saat ketiga kondisi berikut terpenuhi: izin bucket OSS adalah privat, hosting situs web statis OSS diaktifkan, dan Configure origin fetch from a private OSS bucket diaktifkan di CDN. Saat Anda mengakses path root nama domain yang dipercepat (misalnya, https://example.com/), error 403 Forbidden dikembalikan, dan header respons berisi x-tengine-error: You are forbidden to list buckets.

Penyebab: Fitur pengambilan asal dari bucket OSS privat CDN bertentangan dengan konfigurasi homepage default hosting situs web statis OSS.

Solusi:

• Solusi 1: Jika Anda tidak memerlukan hosting situs web statis OSS, nonaktifkan konfigurasi hosting situs web statis untuk bucket tersebut. Untuk instruksi, lihat Static website hosting.

• Solusi 2: Jika Anda perlu mempertahankan hosting situs web statis, konfigurasikan aturan penulisan ulang URI di CDN untuk mencegah permintaan pengambilan asal yang menargetkan direktori root: atur Path to Be Rewritten ke ^/$, atur Target Path ke /index.html, dan atur Flag ke Redirect. Setelah aturan dikonfigurasi, saat client meminta path root, node CDN mengembalikan pengalihan 302 yang menginstruksikan client untuk meminta /index.html. Untuk langkah detail, lihat Rewrite access URLs.

Gejala: Server asal menggunakan pengalihan 302 untuk menyajikan antarmuka yang sesuai berdasarkan jenis perangkat client. Setelah CDN diaktifkan, respons 302 disimpan dalam cache saat pengguna pertama mengakses resource tersebut. Pengguna pada jenis perangkat lain yang mengakses URL yang sama kemudian mengenai halaman 302 pengguna pertama yang disimpan dalam cache, sehingga fitur adaptasi perangkat berhenti bekerja.

Solusi A (disarankan): Jangan simpan respons 302 dalam cache. Konfigurasikan CDN agar tidak menyimpan URL yang diminta pertama kali dalam cache, dan simpan halaman setelah pengalihan 302 dalam cache. Anda dapat mengonfigurasi server asal agar tidak menyimpan halaman awal dalam cache (kebijakan no-cache server asal memiliki prioritas tinggi untuk CDN). Selama respons halaman tersebut berisi salah satu header respons berikut, halaman tersebut tidak disimpan dalam cache:

• Cache-control:no-cache, no-store

• Cache-control:max-age=0

• pragma:no-cache

• Cache-control:private

Solusi B: Konfigurasikan CDN agar tidak menyimpan URL awal dalam cache. Jika Anda tidak dapat memodifikasi header respons server asal, gabungkan konfigurasi cache CDN untuk direktori dan ekstensi nama file dengan prioritasnya untuk mengatur waktu cache URL pengalihan awal ke 0, sementara URL lain tetap disimpan dalam cache secara normal.

Solusi C: Gunakan kunci cache kustom untuk membedakan jenis perangkat. Jika Anda ingin mempertahankan kemampuan caching alih-alih mengambil dari asal setiap kali, konfigurasikan kunci cache kustom yang mencakup dimensi jenis perangkat, sehingga perangkat PC dan mobile masing-masing memiliki salinan cache independen. Untuk metode konfigurasi, lihat Custom cache key.

Penyebab yang mungkin adalah server asal bergantung pada parameter URL atau header Host tertentu untuk logikanya, sementara perilaku default CDN dapat menyebabkan parameter hilang atau header Host tidak sesuai. Troubleshoot sebagai berikut:

1. Periksa konfigurasi parameter URL di aturan cache: Jika server asal bergantung pada parameter URL untuk pengalihan atau logika, perhatikan fitur "Ignore Parameters" CDN. Ignore Parameters hanya memengaruhi kunci cache. Permintaan pengambilan asal tetap membawa parameter URL lengkap. Oleh karena itu, masalahnya bukan "server asal tidak dapat memproses permintaan karena parameter hilang," tetapi "permintaan dengan parameter berbeda mengenai cache yang sama dan menerima konten yang tidak sesuai dengan parameter saat ini." Kami menyarankan agar Anda menonaktifkan Ignore Parameters, atau mempertahankan parameter yang memengaruhi logika bisnis, sehingga permintaan dengan parameter berbeda disimpan dalam cache secara independen (lihat Ignore parameters).

2. Atur host asal ke nama domain yang diharapkan oleh server asal: Ini memastikan bahwa server asal mengidentifikasi header host permintaan dengan benar dan memproses logika pengalihan.

3. Jalankan tugas refresh direktori atau refresh URL: Setelah Anda memodifikasi konfigurasi, jalankan tugas refresh direktori atau refresh URL untuk menerapkan konfigurasi baru.

Gejala: Unduhan file besar terputus, unduhan yang dapat dilanjutkan gagal, atau pencarian video mengembalikan error atau diputar dari awal.

Penyebab: Setelah pengambilan asal Range diaktifkan, node CDN mengirim permintaan slice dengan header Range ke server asal. Jika server asal tidak mendukung permintaan Range (mengabaikan header Range dan mengembalikan 200 dengan konten lengkap), atau Content-Range yang dikembalikan tidak sesuai dengan range yang diminta, pengecualian cache atau kegagalan permintaan client dapat terjadi.

Langkah-langkah Pemecahan Masalah:

1. Verifikasi apakah server asal mendukung permintaan Range: Jalankan curl -I -H "Range: bytes=0-1023" http(s)://domain-asal/path-resource. Jika 206 Partial Content dikembalikan dengan header Content-Range yang benar, server asal mendukung Range. Jika 200 OK dikembalikan dengan file lengkap, server asal mengabaikan permintaan Range.

2. Sesuaikan konfigurasi pengambilan asal Range berdasarkan kemampuan server asal: Jika server asal tidak mendukung Range, pertama-tama modifikasi server asal agar merespons dengan slice 206 dengan benar, atau nonaktifkan fitur pengambilan asal Range CDN terlebih dahulu, untuk menghindari CDN mengirim permintaan slice yang tidak dapat ditangani server asal. Jalur konfigurasi: Konsol CDN > Domain Management > nama domain target > Video Settings > Range Origin Fetch. Sakelar ini dinonaktifkan secara default. Untuk informasi lebih lanjut, lihat Configure range origin fetch.

3. Periksa apakah header respons server asal stabil: Pengambilan asal Range memerlukan server asal untuk mengembalikan Content-Length, ETag, dan Last-Modified yang stabil untuk resource yang sama, sehingga CDN dapat menentukan bahwa slice tersebut milik versi file yang sama. Jika server asal menghasilkan konten secara dinamis dan tidak dapat menyediakan header respons ini, pengambilan asal Range tidak dapat diandalkan.

4. Periksa apakah slice yang disimpan dalam cache telah dihapus: Saat pengambilan asal Range digunakan, jika node CDN menerima kode status non-206 dari server asal, node tersebut menghapus file slice yang disimpan dalam cache (timeout pengambilan asal tidak menyebabkan penghapusan). Oleh karena itu, jika server asal secara intermiten mengembalikan respons 5xx, slice yang disimpan dalam cache dihapus berulang kali. Ini muncul sebagai unduhan yang terputus berulang kali dan trafik pengambilan asal yang tidak normal tinggi. Untuk informasi lebih lanjut, lihat Configure expiration for HTTP status codes.

Gejala

Saat diakses melalui CDN, halaman rusak, atau browser melaporkan kegagalan decoding (ERR_CONTENT_DECODING_FAILED).

Penyebab

• Server asal mengembalikan konten terkompresi (gzip/br) tanpa mengatur header respons Content-Encoding. CDN mengompresi konten yang sudah terkompresi lagi sebelum mengembalikannya, menyebabkan pengecualian decoding di client.

• Content-Encoding yang dideklarasikan oleh server asal tidak sesuai dengan encoding aktual.

Langkah troubleshooting

1. Bandingkan header respons server asal dan CDN

# Akses langsung ke server asal
curl -I -H "Accept-Encoding: gzip" https://<domain-asal>/<path-resource>

# Akses melalui CDN
curl -I -H "Accept-Encoding: gzip" https://<nama-domain-yang-dipercepat>/<path-resource>

Periksa apakah Content-Encoding, Content-Length, dan Content-Type konsisten di kedua sisi.

2. Periksa konfigurasi kompresi cerdas CDN

Jika server asal sudah mengembalikan konten terkompresi (header respons berisi Content-Encoding: gzip), CDN tidak boleh mengompresinya lagi. Jika terjadi kompresi ganda, periksa apakah "Intelligent Compression" diaktifkan di Konsol CDN, atau nonaktifkan kompresi di sisi CDN dan biarkan server asal menangani kompresi sepenuhnya.

3. Perbaiki header respons server asal

Pastikan bahwa setiap kali server asal mengembalikan konten terkompresi, server tersebut juga mengatur header Content-Encoding yang benar. Jika tidak, CDN tidak dapat mengidentifikasi bahwa konten sudah terkompresi.

Gejala

Saat pengguna berbeda mengakses halaman yang sama, satu pengguna menerima informasi sesi pengguna lain (seperti status login yang tertukar), atau status login langsung kedaluwarsa setelah login.

Penyebab

Server asal mengembalikan header Set-Cookie dalam respons halaman dinamis. Jika respons ini disimpan dalam cache oleh CDN, pengguna lain yang mengenai cache menerima Cookie yang bukan milik mereka, yang mencampuradukkan informasi sesi.

Solusi

1. Konfigurasikan server asal agar tidak menyimpan respons yang berisi Set-Cookie dalam cache

Tambahkan Cache-Control: no-store atau Cache-Control: private ke halaman dinamis di server asal untuk mencegah CDN menyimpan respons yang berisi informasi spesifik pengguna dalam cache.

2. Konfigurasikan aturan cache di sisi CDN

Di Konsol CDN, konfigurasikan aturan "Do Not Cache" untuk halaman dinamis (seperti .php, .jsp, atau path /api/) untuk memastikan bahwa permintaan ini selalu kembali ke server asal.

3. Gunakan fitur Modify Inbound Response Headers CDN untuk menghapus header respons

Jika Anda memastikan bahwa Set-Cookie tidak berarti untuk skenario caching CDN (seperti cookie pelacakan), Anda dapat mengonfigurasi fitur Modify Inbound Response Headers di sisi CDN untuk menghapus header respons Set-Cookie sebelum disimpan dalam cache. Pastikan bahwa ini tidak memengaruhi logika bisnis.