Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah Cloud CDN

Pelajari langkah-langkah pemecahan masalah yang mungkin berguna jika Anda mengalami masalah berikut saat menggunakan Cloud CDN.

Jika masalah yang Anda lihat terkait dengan backend eksternal, lihat juga Memecahkan masalah backend eksternal dan masalah NEG internet.

Masalah dan solusi umum

Bagian ini menjelaskan beberapa masalah umum dan solusinya.

Respons tidak di-cache

Jika respons tidak di-cache, periksa terlebih dahulu apakah Cloud CDN diaktifkan untuk layanan backend atau bucket backend Anda. Saat Anda mengaktifkan Cloud CDN, mungkin perlu waktu beberapa menit sebelum respons mulai di-cache.

Cloud CDN hanya menyimpan respons dengan konten yang dapat di-cache ke dalam cache. Informasi ini disampaikan dalam header respons HTTP, yang dikombinasikan dengan konfigurasi backend. Saat mengonfigurasi header respons kustom dengan cdn_cache_status, Anda dapat mengamati status cache di log Cloud CDN dan menentukan apakah respons ditayangkan sebagai akibat dari cache yang tidak ditemukan.

Jika respons untuk URL tidak di-cache, periksa header mana yang ditampilkan untuk URL tersebut, dan cara cacheability dikonfigurasi untuk backend Anda.

Ada beberapa cara untuk memeriksa header respons:

Di Google Chrome, panel jaringan DevTools
Di Mozilla Firefox, Developer Tools Network Monitor
Alat command line seperti curl atau GNU Wget

Contoh berikut menunjukkan penggunaan curl untuk memeriksa header respons HTTP untuk http://example.com/style.css:

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

Membandingkan header ini dengan persyaratan konten yang dapat di-cache menunjukkan bahwa respons tidak memiliki header Cache-Control yang diperlukan (dengan asumsi bahwa mode cache disetel ke USE_ORIGIN_HEADERS).

Metode untuk menetapkan header bergantung pada jenis server origin. Jika Anda menjalankan server web di Compute Engine, lihat dokumentasi software server web untuk mengetahui detail tentang cara mengonfigurasi header respons. Untuk Cloud Storage, menandai objek sebagai dibagikan secara publik akan menyebabkan header yang sesuai dikirim.

Setelah mengonfigurasi ulang server origin untuk menambahkan header yang diperlukan, Anda dapat menggunakan curl lagi untuk memeriksa hasilnya:

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

Respons terakhir dalam contoh ini menyertakan header Age. Cloud CDN menambahkan header Age ke respons yang ditayangkan dari cache. Di sini, header menunjukkan bahwa respons berhasil ditayangkan dari cache menggunakan entri cache yang dibuat dua detik yang lalu.

Selain itu, jika ETags diaktifkan di instance backend, Cloud CDN mengandalkan ETag untuk mengonfirmasi keaktualan objek. Jika instance backend menayangkan ETag yang berbeda pada objek yang sama, Cloud CDN akan menghitung ketidakcocokan sebagai cache yang tidak ditemukan dan memuat ulang objek. Untuk mencegah hal ini, instance backend harus menayangkan ETag yang sama atau ETag harus dinonaktifkan.

Untuk memeriksanya, jalankan curl berulang kali dan perhatikan perubahan pada nilai ETag:

curl -s -D - -o /dev/null http://example.com/image.png

Output:

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

Output:

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

Objek Cloud Storage tidak dapat diakses

Untuk memberikan akses ke objek di Cloud Storage, Anda harus mengonfigurasi URL yang ditandatangani atau memberi bucket dan semua objeknya akses publik untuk allUsers.

Jika memutuskan untuk memberikan akses allUsers, Anda dapat memverifikasi akses tingkat objek sebagai berikut.

Konsol

Di konsol Google Cloud, buka browser Cloud Storage.
Buka browser Penyimpanan
Klik bucket untuk melihat halaman Detail bucket.
Di kolom Akses publik, arahkan kursor ke ikon tanda seru, lalu klik Edit akses.

Untuk setiap objek dalam bucket, pastikan izin berikut telah ditetapkan:
- Entity: User
- Nama: allUsers
- Akses: Pembaca

Untuk mempelajari kontrol akses untuk Cloud Storage lebih lanjut, lihat dokumentasi Identity and Access Management (IAM) untuk Cloud Storage.

Untuk mempelajari URL yang ditandatangani lebih lanjut, lihat Menggunakan URL yang ditandatangani.

Jika objek dapat diakses tetapi tidak di-cache, lihat Respons tidak di-cache.

Konten pribadi di-cache, atau konten yang di-cache salah

Jika Anda mengetahui alasan server origin menayangkan konten pribadi atau salah dan Anda dapat memperbaiki masalah tersebut, Anda dapat membatalkan validasi cache Cloud CDN menggunakan proses berikut:

Pastikan server origin tidak lagi menampilkan konten pribadi atau salah.
Minta invalidasi cache untuk memberi tahu Cloud CDN agar berhenti menayangkan konten yang di-cache.

Untuk informasi selengkapnya, lihat Ringkasan pembatalan validasi cache.

Cloud CDN hanya meng-cache respons dengan konten yang dapat disimpan dalam cache dan hanya menayangkan respons dari cache hingga waktu habis masa berlaku yang ditentukan dalam respons. Jika tidak tahu alasan konten di-cache atau tidak dapat memperbaiki masalah dengan cepat, sebaiknya nonaktifkan Cloud CDN hingga Anda dapat memahami dan memperbaiki masalahnya, lalu aktifkan kembali. Untuk informasi selengkapnya tentang konten yang di-cache dan berapa lama konten tersebut di-cache, lihat Ringkasan penyimpanan ke dalam cache.

Rasio cache ditemukan rendah

Untuk performa dan skalabilitas, penting untuk mengoptimalkan rasio hit cache. Jika Anda mengalami rasio hit cache yang lebih rendah dari yang diharapkan, pastikan Anda mengikuti praktik terbaik untuk mengoptimalkan rasio hit cache.

Gunakan tabel berikut untuk memahami beberapa kemungkinan alasan rasio hit cache yang rendah dan potensi perbaikannya.

Alasan	Komentar	Perbaikan
Konten Anda tidak dapat di-cache.	Respons yang dapat di-cache adalah respons HTTP yang dapat disimpan oleh Cloud CDN.	Pastikan konten Anda dapat di-cache.
Mode cache tidak optimal untuk aplikasi Anda.	Cloud CDN memiliki beberapa mode cache.	Jika Anda tidak menggunakan header kontrol cache untuk mengontrol perilaku caching, praktik terbaik yang direkomendasikan adalah mengizinkan Cloud CDN menyimpan semua konten statis ke dalam cache.
Ada sedikit traffic.	Selama pengujian dan eksperimen, jumlah traffic yang Anda hasilkan cenderung rendah. Google memiliki cache terdistribusi global, dan permintaan dari lokasi geografis yang berbeda akan diarahkan ke lokasi frontend Google yang berbeda. Di setiap lokasi frontend, Google mungkin memiliki beberapa instance cache terpisah.	Pastikan volume traffic yang cukup dikirim ke Google untuk mengisi semua cache yang relevan. Selama pengujian, pastikan untuk membuat shard traffic berdasarkan URL sehingga semua traffic untuk setiap kumpulan permintaan akan diarahkan ke Google. Jangan membuat shard secara acak untuk setiap permintaan ke penyedia CDN yang berbeda.
Respons untuk URL tertentu tidak di-cache.	Cloud CDN menggabungkan URI permintaan lengkap ke dalam kunci cache-nya, sehingga `http://example.com/cat.jpg?color=orange` dan `http://example.com/cat.jpg?color=gray` memiliki entri cache terpisah.	Selalu gunakan satu URL untuk resource tertentu. Jika Anda perlu meneruskan parameter ke JavaScript yang berjalan di halaman yang dapat di-cache, sebaiknya gunakan ID fragmen, bukan string kueri.
Cache tidak perlu di-shard karena kolom header `Vary`.	Kolom header `Vary` dalam respons menjelaskan bagian pesan permintaan mana (selain metode, kolom header `Host`, dan target permintaan) yang dapat memengaruhi proses server asal untuk memilih dan merepresentasikan respons. Misalnya, Anda mungkin ingin menggunakan header `Vary: Accept-Encoding` jika menayangkan konten yang berbeda kepada klien yang dapat menangani respons yang dikompresi dan yang tidak dapat.	Gunakan header respons `Vary` hanya jika diperlukan.
Anda tidak menggunakan kunci cache kustom.	Secara default, Cloud CDN menggunakan URL permintaan lengkap untuk membuat kunci cache. Anda dapat menyesuaikan kunci cache untuk menyertakan atau menghapus kombinasi protokol, host, dan string kueri. Misalnya, jika dua domain menggunakan konten statis yang sama, Anda dapat membuat kunci cache kustom yang menghilangkan kolom host.	Gunakan kunci cache kustom, jika diperlukan.

Ada beberapa pengisian cache untuk konten yang sama

Secara umum, Anda dapat mengurangi jumlah pengisian cache dengan meningkatkan waktu habis masa berlaku respons yang dapat di-cache. Dengan hal-hal lainnya tetap sama, Anda akan melihat lebih sedikit pengisian cache untuk respons dengan Cache-Control: public, max-age=86400 daripada respons dengan Cache-Control: public, max-age=1.

Untuk informasi selengkapnya tentang waktu habis masa berlaku, lihat Waktu habis masa berlaku dan permintaan validasi. Untuk informasi tentang cara mengonfigurasi header respons yang sesuai, lihat dokumentasi untuk software server web Anda.

Cloud CDN mengoperasikan banyak cache di seluruh dunia, dan entri cache lama secara rutin dihapus untuk memberi ruang bagi konten baru. Akibatnya, beberapa pengisian cache per resource diharapkan sebagai bagian dari operasi normal.

Kompresi tidak berfungsi

Cloud CDN menawarkan kompresi dinamis untuk origin yang tidak dapat mengompresi responsnya. Jika memungkinkan, sebaiknya gunakan kompresi di origin karena mengurangi biaya pengisian cache.

Jika respons yang ditayangkan oleh Cloud CDN tidak dikompresi, tetapi seharusnya dikompresi, pastikan software server web yang berjalan di instance Anda dikonfigurasi untuk mengompresi respons. Secara default, beberapa software server web secara otomatis menonaktifkan kompresi untuk permintaan yang menyertakan header Via. Kehadiran header Via menunjukkan bahwa permintaan diteruskan oleh proxy. Proxy HTTP seperti Application Load Balancer eksternal menambahkan header Via ke setiap permintaan seperti yang diwajibkan oleh spesifikasi HTTP. Untuk mengaktifkan kompresi, Anda mungkin harus mengganti konfigurasi default server web untuk memberi tahu server untuk mengompresi respons meskipun permintaan memiliki header Via.

Jika Anda menggunakan software server web nginx, ubah file konfigurasi nginx.conf untuk mengaktifkan kompresi. Lokasi file ini bergantung pada tempat nginx diinstal. Di banyak distribusi Linux, file disimpan di /etc/nginx/nginx.conf.

Agar kompresi nginx berfungsi dengan Load Balancer Aplikasi eksternal, tambahkan dua baris berikut ke bagian http nginx.conf:

gzip_proxied any;
gzip_vary on;

Baris pertama mengaktifkan kompresi bahkan untuk permintaan yang diteruskan oleh proxy seperti Load Balancer Aplikasi eksternal.
Baris kedua menambahkan header Vary: Accept-Encoding ke respons. Vary: Accept-Encoding memberi tahu proxy penyimpanan dalam cache seperti Cloud CDN bahwa mereka harus mempertahankan entri cache terpisah untuk varian resource yang dapat dikompresi dan tidak dikompresi.

Setelah mengubah nginx.conf, Anda harus memulai ulang nginx sebelum menggunakan konfigurasi baru. Di banyak distribusi Linux, Anda dapat memulai ulang nginx dengan menjalankan sudo service nginx restart atau /etc/init.d/nginx restart.

Respons dihentikan dengan error byte_range_caching_aborted

Saat Cloud CDN menyusun respons dari beberapa permintaan rentang byte, Cloud CDN akan memeriksa apakah rentang tersebut berasal dari versi resource yang sama dengan membandingkan header respons ETag dan Last-Modified. Jika Cloud CDN mendapati bahwa nilai salah satu header tidak konsisten dengan rentang yang telah ditayangkan ke klien, Cloud CDN akan membatalkan respons.

Jika Anda melihat respons yang dihentikan secara tidak terduga, entri log Cloud Logging dengan statusDetails byte_range_caching_aborted, atau instance Anda menampilkan respons 412 Precondition Failed, pastikan software server web yang berjalan di semua instance virtual machine (VM) Anda menampilkan nilai ETag dan Last-Modified yang sama untuk resource tertentu.

Saat menayangkan file dari disk, software server web biasanya memperoleh nilai ETag dan Last-Modified dari waktu perubahan file. Dalam hal ini, Anda dapat memastikan bahwa instance VM melaporkan nilai yang konsisten dengan menggunakan image yang sama untuk semua instance. Untuk mengetahui detail tentang cara software server web menentukan nilai ETag dan Last-Modified, lihat dokumentasi software server web Anda.

Memecahkan masalah cookie yang ditandatangani

Masalah berikut dapat terjadi saat Anda menggunakan cookie bertanda tangan.

Encoding

Saat membuat tanda tangan, permintaan tiba-tiba ditolak karena ketidakcocokan tanda tangan.

Saat mengenkode nilai URL dan Signature, pastikan Anda menggunakan varian aman untuk URL base64. Base64 Standar gagal jika karakter yang dihasilkan tidak aman untuk URL. Padding diterima.

Penandatanganan

Permintaan Anda ditolak oleh Cloud CDN.

Pastikan Anda menggunakan HMAC-SHA-1 sebagai algoritma penandatanganan, dan bukan varian HMAC lainnya.
Pastikan parameter KeyName (peka huruf besar/kecil) cocok dengan nama kunci yang valid untuk layanan backend atau bucket backend) yang digunakan oleh Cloud CDN.
Jangan tanda tangani parameter kueri saat membuat dan menandatangani URLPrefix. Pastikan URLPrefix hanya berisi komponen skema, host, dan jalur (sebagian) URL.
Pastikan blok tanda tangan—URLPrefix, Expires, KeyName, dan Signature itu sendiri—adalah bagian terakhir cookie yang dibatasi :.
Pastikan URLPrefix, Expires, KeyName, dan Signature terjadi dalam urutan tersebut.
Jangan sertakan karakter tanda bintang (*) di akhir URLPrefix dalam cookie yang ditandatangani.

Cookie

Browser biasanya membatasi cookie hingga 4 KB per domain, dengan batas total 50 cookie per domain. Perhatikan cookie lain yang Anda berikan dan minta klien untuk mengirimnya karena banyak server web juga memiliki batas header permintaan maksimum.
Pastikan Anda menggunakan karakter titik dua (:), titik kode Unicode U+003A, sebagai pemisah untuk parameter bernama dalam cookie yang ditandatangani, dan bukan karakter ampersand (&).
Pastikan stempel waktu Expires pada cookie yang Anda berikan tidak terlalu singkat. Periode validitas kurang dari satu hingga dua menit mungkin rentan terhadap masalah kemiringan jam antara aplikasi yang menerbitkan dan infrastruktur Cloud CDN.
Pastikan Anda tidak menetapkan beberapa cookie untuk Domain dan Path yang sama dengan nilai yang berbeda. Tetapkan satu cookie per pengguna dengan nilai awalan URL yang mencakup semua konten yang perlu diakses pengguna.

Pesan error

Bagian ini memberikan informasi tentang beberapa pesan error umum dan cara menyelesaikannya.

Error pembatalan validasi cache

Kode error Catatan

Kode error	Catatan
`Invalid value for field 'resource.path'`	Format nilai jalur tidak valid. Jalur harus diawali dengan `/`, tidak boleh berisi `?` atau `#`, dan hanya boleh memiliki satu `*`, yang harus berupa karakter akhir setelah `/`. Jalur tidak boleh lebih dari 1.024 karakter. Jika Anda menerima error ini, periksa nilai jalur dan perbaiki error format apa pun. Error ini hanya membahas format jalur. Jalur yang memiliki format yang valid, tetapi tidak ada, masih diperlakukan sebagai valid.
`Rate Limit Exceeded`	Cloud CDN membatasi kecepatan operasi invalidasi cache yang dapat dilakukan. Hanya satu pembatalan validasi per menit yang diizinkan. Namun, setiap operasi dapat menentukan pola jalur yang cocok dengan jumlah objek apa pun.

Invalid value for field 'resource.path'

Format nilai jalur tidak valid. Jalur harus diawali dengan /, tidak boleh berisi ? atau #, dan hanya boleh memiliki satu *, yang harus berupa karakter akhir setelah /.

Jalur tidak boleh lebih dari 1.024 karakter. Jika Anda menerima error ini, periksa nilai jalur dan perbaiki error format apa pun.

Error ini hanya membahas format jalur. Jalur yang memiliki format yang valid, tetapi tidak ada, masih diperlakukan sebagai valid.

Rate Limit Exceeded Cloud CDN membatasi kecepatan operasi invalidasi cache yang dapat dilakukan. Hanya satu pembatalan validasi per menit yang diizinkan. Namun, setiap operasi dapat menentukan pola jalur yang cocok dengan jumlah objek apa pun.

Masalah umum

Invalidasi cache dibatasi kapasitasnya hingga satu invalidasi per peta URL per menit.

Solusi: Tunggu minimal satu menit sebelum mencoba membatalkan validasi peta URL lain.

Untuk mengetahui informasi selengkapnya tentang pembatasan kapasitas pembatalan validasi cache, lihat Batasan.