Konten Lama Masih Muncul dari Satu ISP, Purge Cache Sendiri atau Eskalasi ke CDN?

Pelanggan bilang website-nya masih menampilkan versi lama, tapi cuma kalau dibuka dari satu ISP. Dari WiFi kantor sudah benar, dari data seluler provider tertentu masih tampilan minggu lalu. Support pertama biasanya langsung purge cache di CDN, lalu bingung saat laporan yang sama masuk lagi. Pertanyaannya sebenarnya bukan cuma purge atau tidak, tapi cache mana yang sedang menyajikan konten lama itu. Di artikel ini kita urutkan pengecekannya: dari gejala yang dilihat pelanggan, ke header response, sampai keputusan apakah cukup ditangani sendiri atau perlu tiket ke penyedia CDN.

Kenapa gejalanya bisa terikat ke satu ISP

Konten lama yang hanya muncul dari satu jaringan hampir selalu berarti request dari jaringan itu dilayani oleh lapisan yang berbeda. Ada empat kandidat yang paling umum. Pertama, cache di sisi perangkat pelanggan, yaitu cache browser atau service worker (script yang bisa menyimpan halaman di browser dan menyajikannya tanpa ke server). Ini sering terlihat seperti masalah ISP karena pelanggan kebetulan mengetes dari HP yang sama saat pindah jaringan. Kedua, DNS. Resolver milik ISP bisa masih menyimpan record lama, sehingga pengguna ISP itu diarahkan ke server atau IP yang sudah tidak dipakai. Kalau baru saja ada migrasi atau ganti record, kemungkinan ini perlu dicek dulu. Penjelasan lengkapnya ada di Kenapa Website Masih ke Server Lama Padahal TTL Sudah Diturunkan. Ketiga, PoP (Point of Presence, lokasi node edge CDN) yang berbeda. CDN memilih node terdekat berdasarkan jaringan pengguna. Beberapa ISP besar di Indonesia, misalnya Telkom lewat lini wholesale-nya, bekerja sama dengan penyedia CDN global agar konten dilayani dari PoP domestik atau node di dalam backbone mereka. Jadi wajar kalau pengguna satu ISP selalu mendarat di node yang sama, dan node itu bisa saja masih memegang salinan lama. Keempat, proxy cache di jaringan ISP itu sendiri. Ini relevan terutama untuk situs yang masih dilayani lewat HTTP biasa. Untuk HTTPS, perangkat di tengah jalur tidak bisa membaca atau meng-cache isi response tanpa memutus TLS, jadi kemungkinan ini jauh lebih kecil.

Pertanyaan yang perlu diajukan ke pelanggan

Sebelum menyentuh dashboard CDN, kumpulkan beberapa jawaban. Ini memangkas setengah kemungkinan tanpa perlu akses apa pun. Tanyakan URL persisnya, bukan cuma nama domain. Halaman beranda dan halaman produk bisa punya aturan cache yang berbeda. Tanyakan juga apakah sudah dicoba di mode incognito atau browser lain di perangkat yang sama, dan apakah perangkat lain di jaringan ISP yang sama juga melihat versi lama. Kalau incognito sudah benar, arah masalahnya ke browser atau service worker, bukan ke CDN. Terakhir, catat waktu kejadian lengkap dengan zona waktunya. Detail ini terlihat sepele, tapi nanti jadi kunci kalau tiket harus diteruskan ke CDN.

Bandingkan header dari origin dan dari jaringan pelanggan

Langkah intinya adalah membandingkan dua response: satu langsung dari origin (server asli tempat website di-host), satu lagi lewat jalur yang dipakai pelanggan. Header yang kita perhatikan:

age: berapa detik objek sudah tersimpan di cache yang menyajikannya.
etag dan last-modified: penanda versi konten. Kalau berbeda dengan origin, berarti salinannya beda.
cache-control: instruksi cache dari origin, misalnya max-age.
Header khusus CDN, misalnya cf-cache-status dan cf-ray di Cloudflare, atau x-cache di beberapa CDN lain. Nama dan formatnya tergantung vendor.

Dari server atau laptop kita, ambil header origin dengan memaksa curl ke IP origin lewat --resolve, lalu ambil juga lewat jalur publik normal. Ganti contoh.com dan IP dengan milik situs yang dicek.

BASH

# Langsung ke origin, melewati CDN (ganti IP dengan IP origin)
curl -sv -o /dev/null --resolve contoh.com:443:203.0.113.10 https://contoh.com/halaman 2>&1 | grep -iE 'trying|connected to|^< '

# Lewat jalur publik normal (DNS dan CDN seperti pengunjung biasa)
curl -sv -o /dev/null https://contoh.com/halaman 2>&1 | grep -iE 'trying|connected to|^< '

Perintah kedua juga yang kita minta dijalankan pelanggan dari jaringan ISP bermasalah. Di macOS dan Linux, curl biasanya sudah tersedia. Di Windows versi baru ada curl.exe bawaan, meskipun grep tidak ada. Untuk Windows, cukup minta pelanggan menjalankan curl -sv -o NUL https://contoh.com/halaman lalu mengirim seluruh output-nya. Semua perintah ini read-only, aman dijalankan. Baris Trying menunjukkan IP mana yang dihubungi. Ini sama pentingnya dengan header. Hasil dari jaringan pelanggan kira-kira seperti berikut (contoh format output, bukan kejadian nyata):

TEXT

*   Trying 203.0.113.50:443...
* Connected to contoh.com (203.0.113.50) port 443
< HTTP/2 200
< date: Mon, 02 Nov 2026 10:00:00 GMT
< cache-control: public, max-age=14400
< age: 9800
< etag: "abc123"
< last-modified: Mon, 26 Oct 2026 08:00:00 GMT
< cf-cache-status: HIT
< cf-ray: 0123456789abcdef-CGK

Di contoh ini, CDN menjawab dengan HIT, objek sudah tersimpan cukup lama, dan etag-nya bisa dicocokkan dengan hasil dari origin. Di Cloudflare, akhiran pada cf-ray biasanya menunjukkan kode lokasi PoP yang melayani request, jadi kita tahu node mana yang perlu dipersoalkan.

Membaca hasilnya dan memutuskan langkah

Setelah dua response ada di tangan, polanya biasanya jatuh ke salah satu kondisi ini.

Yang terlihat di jaringan pelanggan	Arti paling mungkin	Langkah
IP di baris `Trying` bukan IP CDN atau masih IP server lama	Resolver ISP masih memegang record lama	Masalah DNS, purge CDN tidak membantu
Header CDN ada, status HIT, `etag` atau `last-modified` lebih lama dari origin	PoP itu masih menyimpan salinan lama	Purge sendiri dulu, lalu tes ulang
Setelah purge, PoP yang sama tetap HIT dengan versi lama, PoP lain sudah baru	Purge tidak sampai atau tidak diterapkan di node itu	Eskalasi ke penyedia CDN
Header khas CDN tidak ada, muncul `via` atau `x-cache` dari perangkat lain, situs masih HTTP	Ada proxy cache di jalur ISP	Bukan wewenang CDN, pertimbangkan pindah ke HTTPS
Header dari curl sudah sama dengan origin, tapi browser tetap lama	Cache browser atau service worker	Bersihkan data situs di browser, cek service worker

Soal purge, mulailah dari yang paling sempit: purge URL spesifik yang dilaporkan, baru purge semua kalau memang perlu. Purge semua berarti seluruh trafik berikutnya jatuh ke origin sampai cache terisi lagi. Pada situs yang ramai, ini bisa membebani server, jadi pilih waktunya. Beberapa support suka menambahkan query string acak seperti ?v=123 untuk memastikan versi terbaru keluar. Ini bisa membantu sebagai tes, tapi hasilnya tergantung cache key di CDN. Ada konfigurasi yang mengabaikan query string, sehingga hasilnya tetap HIT dari salinan lama. Jangan jadikan ini satu-satunya bukti. Perhatikan juga cache-control dari origin. Kalau HTML dikirim dengan max-age yang panjang, CDN memang berhak menyimpannya selama itu, dan setiap update konten akan selalu butuh purge. Itu bukan bug CDN, melainkan konsekuensi aturan yang kita kirim sendiri. Menurutku, untuk halaman HTML yang sering berubah, umur cache yang lebih pendek biasanya lebih tenang daripada mengandalkan purge setiap kali.

Data yang dilampirkan saat eskalasi ke CDN

Eskalasi baru masuk akal setelah kita purge sendiri dan bisa menunjukkan bahwa satu lokasi tetap menyajikan versi lama sementara origin dan lokasi lain sudah benar. Tiket tanpa bukti seperti ini biasanya dibalas dengan saran untuk purge lagi. Lampirkan data berikut supaya tim CDN bisa langsung menelusuri node yang bermasalah:

URL lengkap yang bermasalah, termasuk path dan query string bila ada.
Waktu kejadian dengan zona waktu yang jelas, idealnya dalam UTC.
Output curl lengkap dari jaringan pelanggan, termasuk IP edge dan header identitas request seperti cf-ray atau request ID sejenis dari vendor lain.
Output curl dari jaringan lain yang sudah menampilkan versi baru, sebagai pembanding.
Header dari origin langsung, untuk membuktikan origin sudah menyajikan versi baru.
Kapan purge dilakukan, metodenya (per URL, per tag, atau semua), dan hasilnya.
Nama ISP dan perkiraan kota pelanggan, tanpa data pribadi yang tidak diperlukan.

Poin 3 dan 6 biasanya yang paling menentukan. Tanpa IP edge dan request ID, tim CDN harus menebak node mana yang dimaksud. Tanpa catatan purge, mereka tidak bisa memastikan apakah purge memang tidak sampai atau belum pernah dilakukan.

Urutan yang bisa dibawa ke meja support

Ketika laporan konten lama datang dari satu ISP, jangan langsung purge lalu menutup tiket. Tanyakan dulu URL, waktu, dan hasil incognito. Ambil header dari origin dan dari jaringan pelanggan, lihat IP yang dihubungi, lalu bandingkan age, etag, dan status cache-nya. Kalau IP-nya salah, itu urusan DNS. Kalau PoP masih HIT dengan salinan lama, purge sendiri. Kalau setelah purge node yang sama masih bertahan, barulah eskalasi dengan bukti lengkap. Cara ini membuat purge jadi keputusan yang terukur, dan tiket ke CDN berisi data yang bisa langsung ditindaklanjuti.