Varnish Cache Adalah: Cara Kerja, Fungsi & Error 503

Setiap kali seseorang membuka sebuah halaman website, server di baliknya biasanya membangun halaman itu dari nol. Kode PHP dijalankan, database ditanya, hasilnya disusun menjadi HTML. Pekerjaan itu masuk akal untuk satu pengunjung. Persoalannya muncul ketika seribu orang meminta halaman yang sama dalam satu menit, dan server mengulang perhitungan yang sama seribu kali. Di titik inilah sebuah lapisan tambahan menjadi masuk akal, dan Varnish Cache adalah perangkat lunak paling dikenal untuk peran tersebut.

Sebagian pembaca justru sampai di sini karena melihat tulisan "Varnish cache server" di layar bersama pesan error yang membingungkan. Baik pertanyaan apa itu Varnish Cache maupun asal-usul tulisan tersebut akan kita jawab berurutan.

Varnish Cache Adalah Lapisan Cepat di Depan Web Server Anda

Varnish Cache adalah web application accelerator (pemercepat aplikasi web) yang bekerja sebagai caching HTTP reverse proxy. Sebutan lain yang sama seringnya dipakai adalah HTTP accelerator. Ia berdiri di depan web server Anda, menerima permintaan pengunjung lebih dulu, lalu menjawabnya dari salinan halaman yang tersimpan di memori. Web server dan bahasa pemrogramannya baru dilibatkan ketika salinan itu tidak ada atau sudah kedaluwarsa.

Dokumentasi resminya menyebut Varnish mempercepat pengiriman "dengan faktor 300 sampai 1.000 kali, tergantung arsitektur Anda". Angka itu perlu dibaca lengkap dengan syaratnya, sebab yang dibandingkan adalah halaman hasil olahan PHP dan database dengan halaman yang dikirim langsung dari memori. Situs yang sejak awal ringan tidak akan merasakan lonjakan sebesar itu.

Perlu ditegaskan bahwa Varnish bukan web server. Ia tidak membaca berkas dari disk, tidak menjalankan PHP, dan tidak mengenal struktur direktori situs Anda. Karena itu ia selalu dipasangkan dengan Nginx atau Apache di belakangnya, bukan menggantikan keduanya.

Kata "reverse" menandakan arah kerjanya. Proxy biasa berdiri di sisi pengguna, sedangkan reverse proxy berdiri di sisi server dan mewakili server saat menghadapi pengunjung. Perbedaan posisi ini dibahas di artikel proxy, sementara konsep penyimpanan sementara yang mendasarinya ada di artikel cache.

Proyeknya dimulai pada 2005 di divisi daring koran Norwegia Verdens Gang, dengan Poul-Henning Kamp sebagai arsitek utamanya. Versi 1.0 dirilis September 2006 dengan lisensi BSD dua klausa.

Kenapa Layar Anda Bertuliskan "Varnish Cache Server"

Halaman yang membuat banyak orang mencari Varnish umumnya seragam bentuknya. Ada judul besar Error 503 Backend Fetch Failed, lalu subjudul Guru Meditation diikuti deretan angka bernama XID. Di paling bawah terdapat baris kecil bertuliskan "Varnish cache server".

Halaman itu bukan buatan pemilik situs. Ia halaman bawaan yang tertulis di dalam kode Varnish, pada bagian bernama vcl_builtin_synth. Setiap pemasangan yang belum diberi halaman error sendiri menampilkan tulisan sama persis — karena itu halaman ini terlihat identik di situs-situs yang tidak berhubungan.

Halaman error bawaan Varnish: Error 503 Backend Fetch Failed, Guru Meditation berisi XID, penutup Varnish cache server.

Arti pesannya spesifik. Angka 503 berarti layanan tidak tersedia, sedangkan "Backend Fetch Failed" berarti Varnish gagal mengambil jawaban dari server di belakangnya. Dengan kata lain, Varnish sendiri hidup dan sehat; yang bermasalah adalah web server, aplikasi, atau database. Kalau Varnish ikut mati, yang muncul justru halaman gagal terhubung dari peramban.

Istilah Guru Meditation dipinjam dari pesan error komputer Amiga era 1980-an, dan di Varnish ia sekadar label untuk blok informasi teknis. Isinya adalah XID, yaitu nomor identitas transaksi. Nomor itu tidak berguna bagi pengunjung, tetapi dipakai pengelola server untuk mencari catatan permintaan tersebut di varnishlog.

Penyebabnya biasanya salah satu dari empat hal. Web server di belakang benar-benar mati, atau aplikasi menjawab terlalu lama sampai melewati batas waktu tunggu. Bisa juga server kehabisan memori, atau alamat backend di konfigurasi Varnish menunjuk ke port yang salah.

Angka yang menyertainya tidak selalu 503. Halaman bertanda tangan sama bisa memuat error 403, dan artinya berbeda. Permintaan Anda ditolak — oleh aturan di VCL atau oleh backend — bukan karena backend tidak terjangkau.

Kalau Anda hanya pengunjung situs tersebut, tidak ada yang bisa diperbaiki dari sisi Anda. Menghapus cache peramban maupun mengganti DNS tidak berpengaruh, karena masalahnya ada di server tujuan.

Cara Kerja Varnish Cache: Hit, Miss, dan Antrean Digabung

Alur kerjanya berputar pada dua peristiwa. Ketika permintaan masuk, Varnish menyusun kunci pencarian dari alamat URL dan nama host. Kalau objek dengan kunci itu ada dan masih berlaku, terjadi cache hit: jawaban dikirim langsung tanpa menyentuh web server. Kalau tidak ada, terjadi cache miss — permintaan diteruskan ke backend, jawabannya disalin ke memori, lalu dikirim ke pengunjung.

Karena kuncinya dibentuk dari URL dan host, dua alamat yang berbeda satu karakter disimpan sebagai dua objek terpisah. Inilah sebabnya situs dengan banyak parameter pelacakan di URL sering memiliki tingkat keberhasilan cache yang rendah.

Alur Varnish memakai URL dan nama host sebagai kunci: cache hit dikirim dari memori, cache miss diambil ke web server.

Ada satu perilaku yang berguna saat trafik melonjak, yaitu penggabungan antrean atau request coalescing. Ketika seratus pengunjung meminta halaman yang sama pada detik yang sama, Varnish hanya mengirim satu permintaan ke backend. Sisanya ditahan, lalu dilayani dengan hasil yang sama. Ini berjalan otomatis tanpa perlu dikonfigurasi.

Pelengkapnya adalah grace mode. Ketika sebuah objek lewat masa berlakunya, Varnish boleh tetap menyajikan versi lama itu sesaat sambil mengambil versi baru di belakang layar. Pengunjung tetap mendapat jawaban cepat.

VCL dan Aturan Bawaan yang Diam-Diam Melewatkan Cache

Perilaku Varnish diatur lewat VCL (Varnish Configuration Language), bahasa konfigurasi kecil yang dikompilasi menjadi kode mesin sebelum dijalankan. Karena itu aturan serumit apa pun tetap dieksekusi dalam hitungan mikrodetik.

Yang sering luput dipahami: aturan yang Anda tulis tidak menggantikan aturan bawaan Varnish. Keduanya digabung, dan yang bawaan tetap ikut berjalan sesudahnya. Empat di antaranya rutin membuat pemilik situs bingung.

Empat aturan bawaan Varnish yang melewatkan cache: metode selain GET dan HEAD, header Cookie, Authorization, Set-Cookie.

1. Hanya GET dan HEAD yang dipertimbangkan: Metode lain, termasuk POST, langsung diteruskan ke backend tanpa disimpan. Ini memang seharusnya begitu, karena pengiriman formulir tidak boleh dijawab dari salinan lama.
2. Ada header Cookie, permintaan dilewatkan: Komentar di kode sumbernya berbunyi "berisiko untuk disimpan secara bawaan". Inilah aturan yang paling sering menggigit. Satu skrip analitik yang menanamkan cookie sudah cukup membuat seluruh kunjungan tidak pernah tersimpan.
3. Ada header Authorization, permintaan dilewatkan: Halaman yang dilindungi kata sandi tidak akan pernah masuk cache. Ini pengaman yang perlu, bukan kekurangan.
4. Respons dengan Set-Cookie tidak disimpan: Kalau aplikasi menanamkan cookie sesi pada setiap kunjungan, termasuk kunjungan anonim, tidak ada satu halaman pun yang tersimpan.

Solusinya bukan mematikan aturan bawaan, melainkan membersihkan cookie yang tidak dibutuhkan sebelum aturan itu dijalankan. Dokumentasi resminya mencontohkan penghapusan cookie analitik dengan ekspresi reguler.

Tiga Angka Bawaan yang Perlu Anda Ubah Lebih Dulu

Varnish dirancang untuk berhati-hati, dan nilai bawaannya mencerminkan sikap itu. Tiga angka berikut hampir selalu perlu disesuaikan.

Tiga nilai bawaan Varnish yang perlu diubah: TTL 120 detik, kapasitas cache 100 MB, dan masa tenggang 10 detik.

Masa berlaku objek 120 detik. Parameter default_ttl bernilai 2 menit. Halaman yang tidak memberi instruksi lewat header Cache-Control hanya bertahan dua menit di memori, dan itu terlalu pendek untuk artikel yang jarang berubah. Cara yang lebih rapi bukan menaikkan angka ini membabi buta. Kirim Cache-Control yang benar dari aplikasi: satu jam untuk artikel, satu hari untuk berkas gambar.

Kapasitas cache 100 MB. Tanpa opsi -s, Varnish hanya menyediakan 100 MB penyimpanan, dan situs dengan beberapa ratus halaman bergambar memenuhinya dalam hitungan menit. Perintah varnishstat menyediakan penghitung n_lru_nuked yang naik setiap kali objek dibuang karena kehabisan tempat. Kalau angka itu terus bertambah, kapasitasnya memang kurang.

Sebagai patokan awal, alokasikan seperempat sampai sepertiga memori server untuk cache. Pada VPS 2 GB, -s malloc,512m adalah titik yang aman.

Angka itu sengaja tidak agresif. Dokumentasi resminya memperingatkan bahwa pemakaian memori sebenarnya bisa dua sampai empat kali angka yang Anda tulis, akibat fragmentasi pengalokasi memori. Menetapkan 1,5 GB pada server 2 GB adalah cara cepat membuatnya kehabisan memori.

Masa tenggang 10 detik. Parameter default_grace menentukan berapa lama versi lama boleh disajikan sambil versi baru diambil. Sepuluh detik hanya cukup menahan lonjakan sesaat, terlalu pendek untuk menolong saat backend benar-benar bermasalah. Kalau tujuannya menjaga situs tetap tampil, naikkan nilai ini lewat VCL sampai hitungan jam.

Varnish Tidak Bisa Menerima HTTPS Sendirian

Ini fakta arsitektural yang menentukan seluruh rencana pemasangan. Pada jalur sumber terbuka, opsi pendengar Varnish hanya menerima dua protokol: HTTP biasa dan protokol PROXY. Tidak ada TLS di daftar itu. Varnish tidak bisa memegang sertifikat, tidak bisa membuka enkripsi, dan tidak bisa mendengarkan port 443 secara langsung.

Konsekuensinya, sebuah komponen lain harus berdiri di depan Varnish untuk mengakhiri enkripsi. Ada tiga pilihan yang lazim. Hitch dibuat oleh pengembang Varnish khusus untuk keperluan ini. HAProxy dipakai sebagai contoh di tutorial TLS resmi proyeknya, sedangkan Nginx dipilih karena biasanya sudah terpasang.

Varnish tidak menerima HTTPS: port 443 masuk ke pengakhir TLS, diteruskan ke Varnish port 6081, lalu web server 8080.

Susunannya menjadi berlapis. Pengunjung mengakses port 443 pada pengakhir TLS, koneksi dibuka di sana, lalu diteruskan ke Varnish sebagai HTTP biasa.

Detail yang mudah terlewat adalah alamat IP pengunjung. Setelah melewati perantara, semua permintaan yang sampai ke Varnish terlihat berasal dari alamat lokal yang sama. Protokol PROXY mengatasinya dengan menitipkan alamat asli di awal koneksi. Tanpa itu, pembatasan laju dan pemblokiran berbasis IP menjadi tidak berarti.

Pengaturan di sini berhubungan langsung dengan sertifikat SSL. Perlu dicatat, distribusi Varnish Cache dari Varnish Software kini sudah menyertakan pengakhiran TLS di dalam prosesnya sendiri. Perbedaan itu kita bahas di bagian terakhir.

Memastikan Cache Bekerja: X-Varnish, Age, dan Via

Setelah terpasang, pertanyaan berikutnya selalu sama: apakah cache-nya benar-benar bekerja? Jawabannya bisa didapat dari luar server, hanya dengan membaca header jawaban:

curl -sD - -o /dev/null \
  https://contoh-situs.co.id/

Baris yang paling menentukan adalah X-Varnish. Varnish selalu menyertakannya, tetapi isinya berbeda tergantung hasil pencarian:

• Dua angka berarti cache hit. Angka pertama adalah nomor transaksi permintaan Anda, angka kedua nomor transaksi yang dahulu menaruh objek itu ke cache.
• Satu angka berarti cache miss. Objeknya belum ada, sehingga permintaan diteruskan ke backend.

Ini cara tercepat memastikan Varnish bukan sekadar meneruskan lalu lintas. Muat halaman yang sama dua kali; kalau permintaan kedua masih menampilkan satu angka, ada aturan yang mencegah penyimpanan. Cookie adalah tersangka pertama.

Dua header pendamping melengkapi gambarannya: Age menunjukkan umur objek di cache, dan Via menandakan jawaban melewati perantara. Dari sisi server, varnishstat menampilkan penghitung hit dan miss, sementara varnishlog menelusuri satu permintaan berdasarkan XID.

Membersihkan Isi Cache: PURGE dan Ban

Keluhan yang paling sering muncul setelah Varnish aktif adalah halaman lama yang masih tampil padahal isinya sudah diperbarui. Ini akibat wajar dari menyimpan salinan, dan Varnish menyediakan dua cara resmi untuk membuangnya.

Cara pertama adalah purge, yaitu membuang satu objek beserta variannya lewat permintaan HTTP bermetode PURGE. Kemampuan ini berbahaya bila terbuka untuk umum, sehingga dokumentasi resminya menekankan pembatasan lewat daftar alamat IP yang diizinkan.

Cara kedua adalah ban, yaitu menandai banyak objek sekaligus dengan sebuah ekspresi. Seluruh alamat berawalan /kategori/berita, misalnya, bisa dinyatakan tidak berlaku dalam satu perintah. Ban tidak menghapus objek dari memori; yang tertandai dianggap kedaluwarsa saat berikutnya diminta.

Varnish Cache vs Redis, CDN, dan Cache Bawaan Hosting

Keempatnya sering dianggap saling menggantikan, padahal bekerja pada lapisan berbeda dan bisa berjalan bersamaan.

Perbandingan Varnish dengan Redis paling sering ditanyakan, dan jawabannya terletak pada apa yang disimpan. Varnish menyimpan halaman jadi, sehingga aplikasi tidak dijalankan sama sekali saat terjadi hit. Redis menyimpan bahan setengah jadi: aplikasi tetap berjalan, tetapi tidak perlu menanyai database berulang kali. Pada situs besar keduanya dipakai bersama.

Pada layanan web hosting berbasis LiteSpeed, manfaat yang dicari dari Varnish sebagian besar sudah tersedia lewat mesin cache bawaannya. Memasang Varnish di sana pun memang tidak bisa dilakukan.

Varnish Cache di WordPress: Bagian yang Sering Gagal

Kombinasi Varnish dan WordPress bisa memberi hasil dramatis, tetapi persoalan cookie tadi muncul dalam bentuk paling nyata di sini. Pengunjung yang tidak login umumnya tidak membawa cookie, sehingga halamannya aman disimpan. Begitu seseorang login, WordPress menanamkan cookie sesi bernama wordpress_logged_in_ diikuti kode acak. Aturan bawaan Varnish melewatkan permintaan bercookie tersebut, dan itu justru perilaku yang benar: dasbor administrator tidak boleh dijawab dari salinan bersama.

Yang perlu ditulis di VCL karena itu bukan aturan untuk melewatkan pengguna yang login, melainkan aturan untuk membuang cookie yang tidak penting dari pengunjung anonim. Cookie analitik, persetujuan, dan pelacak iklan tidak dibutuhkan WordPress untuk menyusun halaman publik.

Bentuknya kira-kira seperti ini, dijalankan sebelum aturan bawaan sempat memeriksa cookie:

sub vcl_recv {
    # buang cookie analitik dan persetujuan
    set req.http.Cookie = regsuball(
        req.http.Cookie,
        "(^|;\s*)(_ga|_gid|_fbp)=[^;]*", "");
    if (req.http.Cookie ~ "^\s*$") {
        unset req.http.Cookie;
    }
}

Setelah dibersihkan, kunjungan anonim kembali memenuhi syarat untuk disimpan.

Dua hal lagi perlu disiapkan. Pertama, mekanisme pembersihan otomatis; tanpa plugin penghubung, halaman depan tidak berubah sampai masa berlakunya habis meski artikel baru sudah terbit. Kedua, kehati-hatian pada toko daring: halaman keranjang belanja dan halaman akun harus dipastikan tidak ikut tersimpan. Satu kesalahan aturan bisa membuat isi keranjang seorang pembeli tampil di layar pembeli lain.

Varnish Cache atau Vinyl Cache? Nama yang Berubah pada 2026

Ada satu perkembangan yang perlu diketahui sebelum Anda mencari dokumentasi atau memasang paketnya. Proyek sumber terbukanya berganti nama menjadi Vinyl Cache. Pengumumannya menyertai rilis 8.0 pada September 2025, dan prosesnya tuntas pada rilis 9.0 tanggal 16 Maret 2026. Bersamaan dengan itu, repositori kode resminya dipindahkan dari GitHub ke server mandiri di code.vinyl-cache.org. Tim pengelolanya tidak berubah, masih dipimpin Poul-Henning Kamp bersama Walid Boudebouda dan Nils Goroll.

Sementara itu, perusahaan Varnish Software meneruskan merek Varnish Cache untuk distribusi turunannya sendiri. Pernyataan resminya menyebut Varnish Cache sebagai distribusi hilir dari proyek Vinyl Cache. Distribusi itu menambahkan rilis dukungan jangka panjang dan perkakas tambahan, termasuk pengakhiran TLS yang tadi disinggung.

Akibat praktisnya ada dua. Kini ada dua garis rilis bernomor 9.0 yang berbeda isinya, sehingga menyebut "Varnish 9" tidak lagi cukup spesifik. Selain itu, dokumentasi hasil pencarian bisa berasal dari dua situs berbeda. Periksa versi yang terpasang dengan varnishd -V sebelum mengikuti panduan mana pun.

Untuk pemasangan tersedia tiga jalur: paket bawaan distribusi Linux, repositori resmi vendor, atau image container. Di Ubuntu dan Debian, perintah apt install varnish mengambil versi dari repositori distribusi yang biasanya tertinggal beberapa rilis, jadi periksa dulu apakah versinya masih didukung. Ketiganya menuntut akses root, sehingga Varnish hanya bisa dijalankan di VPS atau server sendiri. Kalau Anda belum memilikinya, VPS Indonesia adalah titik awal yang wajar. Sekalian aktifkan HTTP/2 di pengakhir TLS di depannya, karena Varnish sendiri melayani koneksi lokal.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Varnish memberi hasil besar, tetapi menuntut hal-hal yang tidak selalu sepadan untuk setiap situs.

1. Isi cache lenyap saat layanan dimuat ulang: Penyimpanannya berada di memori. Setiap restart mengosongkannya, dan beban penuh kembali jatuh ke backend selama beberapa menit berikutnya.
2. VCL adalah bahasa yang harus dipelajari: Ia bukan daftar nilai, melainkan bahasa dengan alur sendiri. Menyalin contoh tanpa memahaminya adalah cara paling umum menciptakan masalah baru.
3. Menambah satu komponen ke dalam rantai: Karena tidak menangani HTTPS sendiri, susunan minimalnya tiga lapis — dan setiap lapis bisa gagal.
4. Salah aturan bisa berakibat serius: Menyimpan halaman yang seharusnya pribadi berarti membocorkan data satu pengguna ke pengguna lain.
5. Tidak tersedia di hosting bersama: Tanpa akses root Varnish tidak bisa dipasang, dan panel hosting umum tidak menyediakannya sekali klik.
6. Manfaatnya kecil untuk aplikasi yang benar-benar dinamis: Halaman yang berbeda untuk tiap pengguna hanya menghasilkan sedikit cache hit. Redis memberi hasil lebih besar.

Pertanyaan yang Sering Muncul Seputar Varnish Cache

Varnish cache server artinya apa saat muncul di layar?

Itu halaman error bawaan Varnish: situs tersebut memakai Varnish, dan server di belakangnya sedang tidak menjawab. Yang muncul selalu berupa Varnish cache server error dengan kode tertentu, umumnya 503 atau 403. Kalau Anda pengunjung, tidak ada yang bisa diperbaiki selain mencoba lagi nanti; kalau Anda pemiliknya, periksa apakah web server dan aplikasinya berjalan normal.

Apakah Varnish Cache sama dengan CDN?

Tidak. Varnish berjalan di satu server milik Anda, sedangkan CDN menyebar salinan ke banyak lokasi geografis. Keduanya sering dipakai bersamaan, bahkan sebagian penyedia CDN memakai Varnish di dalam infrastrukturnya.

Bisakah Varnish dipasang di hosting bersama?

Tidak bisa. Varnish memerlukan akses root untuk mengubah port layanan dan menjalankan proses sendiri, dan hosting bersama tidak memberikannya. Alternatif terdekatnya adalah mesin cache bawaan web server, seperti di server LiteSpeed.

Berapa RAM yang perlu disiapkan untuk Varnish?

Sisihkan seperempat sampai sepertiga memori server untuk cache; pada VPS 2 GB, 512 MB adalah titik awal yang aman. Jangan menetapkan mendekati kapasitas total, karena pemakaian sebenarnya bisa dua sampai empat kali lipat.

Kenapa halaman tidak berubah setelah artikel diperbarui?

Karena Varnish masih menyajikan salinan lama sampai masa berlakunya habis. Bersihkan dengan permintaan PURGE, atau ban untuk sekelompok alamat sekaligus. Untuk jangka panjang, pasang mekanisme pembersihan otomatis setiap konten diperbarui.

Varnish vs Nginx: masih perlu Varnish kalau sudah pakai Nginx?

Belum tentu. Nginx punya cache sendiri lewat proxy_cache dan fastcgi_cache, dan untuk banyak situs itu sudah memadai. Tiga hal membedakannya. Cache Nginx bawaannya disimpan di disk, penggabungan antrean lewat proxy_cache_lock mati secara bawaan, dan penghapusan objek dengan proxy_cache_purge hanya tersedia pada Nginx Plus yang berbayar. Varnish menyimpan di memori, menggabungkan antrean secara otomatis, serta menyediakan PURGE dan ban tanpa biaya tambahan.

Sekarang namanya Varnish Cache atau Vinyl Cache?

Keduanya ada dan berbeda. Vinyl Cache adalah kelanjutan proyek sumber terbuka yang dahulu bernama Varnish Cache, sedangkan Varnish Cache kini merujuk pada distribusi turunan yang dikelola perusahaan Varnish Software. Periksa versi di server Anda dengan varnishd -V sebelum mengikuti dokumentasi tertentu.

Kesimpulan

Varnish Cache adalah lapisan reverse proxy yang menyajikan halaman langsung dari memori, sehingga web server dan database hanya bekerja saat benar-benar diperlukan. Hasilnya bergantung pada dua hal yang sering diabaikan: aturan bawaan yang melewatkan permintaan bercookie, dan nilai bawaan yang terlalu berhati-hati.

Varnish masuk akal ketika Anda mengelola VPS sendiri, punya banyak halaman dinamis yang isinya sama untuk semua pengunjung, dan siap mempelajari VCL secukupnya. Sebaliknya, pilihan lain lebih hemat usaha dalam tiga keadaan. Situs Anda ada di hosting bersama, halamannya hampir seluruhnya pribadi, atau Anda belum ingin menambah komponen ke dalam rantai layanan.

Semoga artikel ini membantu.