Untuk melewati cache Edge Security Acceleration (ESA) pada sumber daya yang sesuai dengan aturan cache default, buat aturan untuk memfilter permintaan dan atur Cache Eligibility ke Bypass Cache.
Jika tidak ada aturan atau konfigurasi cache yang ditetapkan, caching pada titik keberadaan (POPs) ESA mengikuti aturan cache default.
Skenario
Jika server origin Anda memiliki sumber daya yang tidak ingin di-cache di POPs ESA—misalnya sumber daya dinamis yang setiap permintaannya harus mengambil konten terbaru dari origin—konfigurasikan aturan bypass cache untuk sumber daya tersebut. Melewati cache untuk sumber daya dinamis meningkatkan kinerja akses.
Aturan kelayakan cache menentukan apakah suatu permintaan di-cache oleh node tepi ESA. Kasus penggunaan umum meliputi:
Static resource caching — Tingkatkan kinerja dengan meng-cache file gambar, CSS, dan JavaScript di node tepi.
Dynamic content bypass — Pastikan halaman login, API, dan konten personalisasi tidak di-cache.
Dynamic-static separation — Cache aset statis sekaligus lewati permintaan dinamis ke server origin.
Selective no-cache — Cegah file atau path tertentu agar tidak di-cache.
Prosedur
Di Konsol ESA, pilih Websites. Di kolom Website, klik situs target.
Di panel navigasi sebelah kiri, pilih .
Klik Create Rule dan masukkan Rule Name.
Di bagian If requests match..., tetapkan atribut permintaan yang sesuai. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan, lihat Composition of a rule expression.
Di area Cache Eligibility , pilih kebijakan cache dan klik OK.
Bypass Cache: Semua permintaan melewati cache POP dan mengambil langsung dari origin, sehingga Anda dapat melihat sumber daya terbaru dari server origin secara real time. Saat diaktifkan, hanya pengaturan Browser Cache TTL yang berlaku.
Eligible for Cache: Semua permintaan yang memenuhi syarat dilayani dari node cache POP alih-alih dari origin. Hal ini menghindari jalur pengambilan asal yang panjang, mengurangi latensi, dan meningkatkan kinerja akses.
Opsi dan batasan kelayakan cache
Bypass Cache
Saat Bypass Cache dipilih:
Permintaan yang sesuai diteruskan langsung ke server origin tanpa disimpan di node tepi ESA.
Hanya pengaturan Browser Cache TTL yang berlaku. Fitur terkait cache lainnya (seperti Cache Deception Defense dan Serve Stale Content) dinonaktifkan untuk aturan ini.
ESA tidak mendukung konfigurasi perilaku no-cache berdasarkan header respons HTTP (seperti
X-Fallback) atau penanda komentar HTML. Gunakan kondisi pencocokan berbasis header permintaan atau berbasis URL sebagai gantinya.
Perilaku cache default
Saat tidak ada aturan cache yang dikonfigurasi, atau saat tidak ada aturan yang cocok dengan permintaan, ESA menerapkan perilaku default berikut:
Permintaan mengikuti kebijakan cache default ESA.
Permintaan dinamis dengan URL yang diakhiri
/diteruskan ke server origin secara default.Saat server origin mengembalikan header respons
no-cache, respons tersebut tidak di-cache.
Fitur cache lanjutan
Fitur-fitur berikut dinonaktifkan secara default dan harus diaktifkan secara manual dalam aturan cache:
Cache Deception Defense: Melindungi dari serangan cache deception.
Serve Stale Content: Memungkinkan ESA menyajikan konten cache yang kedaluwarsa saat origin sementara tidak tersedia.
Contoh konfigurasi umum
Contoh berikut mencakup skenario frekuensi tinggi untuk mengonfigurasi kelayakan cache.
Contoh 1: Bypass cache untuk API dinamis
Skema: Cegah titik akhir API dinamis agar tidak di-cache di node tepi.
Konfigurasi:
Kondisi Pencocokan: jalur URL berisi
/api, ATAU jalur URL berisi/prod-api/, ATAU ekstensi nama file sama denganphpCache Eligibility: Bypass Cache
Saat menentukan ekstensi nama file, jangan sertakan tanda titik. Masukkan php, bukan .php.
Contoh 2: Bypass cache untuk halaman admin dan login
Skema: Cegah halaman admin WordPress, antarmuka manajemen CMS, atau titik akhir login agar tidak di-cache.
Konfigurasi:
Match Condition: Path URL contains
/wp-admin, ATAU path URL contains/admin, ATAU path URL contains/loginCache Eligibility: Bypass Cache
Tempatkan aturan ini di urutan teratas daftar aturan untuk memastikan prioritasnya lebih tinggi daripada aturan caching sumber daya statis umum.
Contoh 3: Cache path root SPA
Skema: ESA tidak meng-cache URL tanpa ekstensi (seperti /) secara default. Untuk meng-cache konten text/html untuk aplikasi halaman tunggal (SPAs):
Konfigurasi:
Kondisi Pencocokan: Header permintaan
Acceptberisitext/htmlCache Eligibility: Eligible for Cache
Cache TTL: Atur sesuai frekuensi pembaruan SPA Anda.
Contoh 4: Bypass cache untuk file tertentu
Skenario: Mencegah file tertentu, seperti sitemap.xml, agar tidak di-cache.
Konfigurasi:
Match Condition: Path URL contains
sitemap(tanpa ekstensi nama file), ATAU ekstensi nama file equalsxml(masukkanxml, bukan.xml)Cache Eligibility: Bypass Cache
Contoh 5: Pemisahan dinamis-statis
Skema: Cache aset statis sekaligus pastikan permintaan dinamis diteruskan ke origin.
Pendekatan yang direkomendasikan:
Hapus semua aturan cache situs penuh yang ada.
Buat aturan untuk meng-cache sumber daya statis. Misalnya, cocokkan ekstensi nama file equals salah satu dari
jpg,png,css, ataujs.Buat aturan terpisah untuk melewati cache pada titik akhir API dinamis. Misalnya, cocokkan path URL contains
/api.
Pendekatan ini mencegah permintaan dinamis secara tidak sengaja di-cache.
Catatan konfigurasi
Satu Cache TTL per aturan — Satu aturan cache hanya dapat menentukan satu Cache TTL. Jika ekstensi nama file atau direktori berbeda memerlukan durasi cache berbeda, buat aturan terpisah untuk masing-masing.
Kemandirian aturan — Menonaktifkan atau menghapus aturan cache tertentu tidak memengaruhi perilaku caching untuk sumber daya lainnya. ESA terus mencocokkan aturan yang tersisa secara berurutan.
Mengurangi beban origin — Konfigurasikan aturan bypass cache untuk konten dinamis dan aktifkan aturan cache untuk sumber daya statis guna meminimalkan permintaan yang diteruskan ke server origin.
Prioritas penerapan sub-modul — Dalam fitur Cache Rules, prioritas penerapan sub-modul dari tinggi ke rendah adalah: POST Cache > Bypass Cache > Sub-modul lainnya. Saat POST Cache diaktifkan, permintaan diproses melalui alur kerja caching sumber daya statis, dan fitur Bypass Cache menjadi tidak efektif.
FAQ
Mengapa aturan bypass cache saya tidak berlaku?
Periksa hal berikut:
Kondisi pencocokan salah: Verifikasi ekspresi aturan. Kesalahan umum meliputi:
Kondisi OR secara tidak sengaja mencocokkan permintaan dari domain lain.
Nilai ekstensi nama file atau path diformat secara salah. Misalnya,
.phpalih-alihphp.
Karakteristik permintaan tidak ada: Jika aturan bergantung pada header permintaan tertentu (seperti
sec-fetch-site), pastikan permintaan klien aktual menyertakan header ini.Prioritas aturan tidak mencukupi: ESA mengevaluasi aturan dari atas ke bawah. Jika aturan bypass cache berada di bawah aturan caching TTL panjang, aturan sebelumnya mungkin sudah cocok terlebih dahulu. Pindahkan aturan bypass cache ke posisi lebih atas dalam daftar.
Cache belum dibersihkan setelah perubahan aturan: Setelah mengubah aturan, bersihkan URL atau direktori yang terpengaruh di Konsol ESA. Menyegarkan browser Anda tidak membatalkan konten yang di-cache di node tepi.
Batasan paket: Edisi Gratis mungkin tidak menjamin penerapan aturan yang konsisten. Pertimbangkan untuk meningkatkan ke paket berbayar.
Pendekatan verifikasi: Periksa header respons
Serveruntuk memastikan apakah permintaan diproses oleh node tepi ESA. Gunakan jendela browser penyamaran untuk menghilangkan gangguan cache browser lokal.
Mengapa saya tidak bisa login, atau mengapa halaman dialihkan secara salah setelah mengaktifkan ESA?
Penyebab: Ini biasanya terjadi ketika aturan cache seluruh situs atau aturan cache yang dikonfigurasi secara tidak tepat menyebabkan cookie login, data sesi, atau respons API dinamis di-cache di node tepi ESA.
Resolusi:
Tangguhkan atau hapus aturan cache seluruh situs yang mencurigakan.
Buat aturan Bypass Cache khusus untuk halaman login, titik akhir CAPTCHA, dan path admin. Tempatkan aturan ini di urutan teratas daftar aturan agar memiliki prioritas tertinggi.
Di Konsol ESA, bersihkan cache untuk URL yang terpengaruh.
Verifikasi perbaikan menggunakan jendela browser penyamaran.
Jika masalah tetap berlanjut meskipun konfigurasi sudah benar: Periksa logika bisnis server origin Anda. Misalnya, pastikan logika pengalihan 302 mengenali status login dengan benar. Jika server origin tidak menangani status login dengan benar, hal ini berada di luar cakupan ESA.
Apa perbedaan antara "equals" dan "contains" dalam kondisi pencocokan?
Jenis pencocokan | Perilaku |
Equals | Pencocokan eksak terhadap path URL yang ditentukan. Secara otomatis juga mencocokkan semua sub-path. Misalnya, mengonfigurasi |
Contains | Pencocokan fuzzy. Setiap URL yang mengandung string yang ditentukan di mana saja akan dicocokkan. |
Untuk pencocokan hostname, baik Equals maupun Contains menghasilkan hasil yang setara dan dapat digunakan secara bergantian.
Mengapa mengaktifkan aturan cache membuat probing berhasil, tetapi menonaktifkannya menyebabkan timeout?
Saat aturan cache aktif, node tepi ESA melayani permintaan langsung dari cache, sehingga mengurangi beban pada server origin.
Saat aturan cache dinonaktifkan, semua permintaan—termasuk permintaan dinamis ber-volume tinggi—langsung menuju server origin secara real time. Dalam pengujian beban konkurensi tinggi, hal ini dapat membebani server origin dan menyebabkan timeout permintaan.
Perilaku ini mencerminkan bottleneck kinerja server origin, bukan masalah ESA. Untuk mengatasi hal ini:
Konfigurasikan aturan cache untuk mengurangi volume permintaan yang diteruskan ke origin.
Aktifkan JS Challenge atau Intelligent Rate Limiting untuk melindungi server origin dari permintaan konkuren berlebihan.
Dokumentasi terkait
Fitur terkait aturan memiliki variasi dalam prioritas efektif, reentrancy, dan granularitas efektif. Untuk detailnya, lihat Properties of Rule-Related Features.