Kami pernah menerima telepon panik dari tim marketing sebuah toko online saat kampanye besar dimulai — halaman melambat saat traffic melonjak. Kami cepat menyelidik dan menemukan bahwa cache yang tepat di depan situs bisa menyelesaikan masalah dalam hitungan menit.

Dalam panduan ini kita jelaskan bagaimana varnish bekerja sebagai reverse proxy pada port 80 sementara web server dipindah ke port 8080. Tujuannya: menurunkan TTFB, mengurangi beban server, dan menjaga pages tetap cepat saat spike. Kami juga akan membahas VCL production-grade, integrasi plugins seperti Proxy Cache Purge, serta langkah uji untuk tim teknis.

Ringkasan Penting

• Kombinasi varnish dan wordpress meningkatkan stability saat traffic tinggi.
• Kami membahas arsitektur — port 80 untuk proxy, port 8080 untuk server.
• Panduan mencakup VCL, filter parameter tracking, TTL, dan header X-Cacheable.
• Termasuk integrasi plugin dan verifikasi teknis untuk konten dinamis.
• Hasil yang diharapkan: TTFB turun, biaya operasional lebih efisien, waktu muat lebih baik.
• Untuk informasi tambahan tentang solusi cache tingkat aplikasi, lihat plugin cache rekomendasi.

Mengenal reverse proxy dan cache: dasar yang perlu dipahami sebelum mengonfigurasi WordPress

Sebelum menyentuh konfigurasi, penting memahami peran reverse proxy dalam arsitektur. Lapisan ini menerima semua requests http dari internet, menerapkan kebijakan, lalu memutuskan apakah meneruskan ke backend atau menyajikan dari cache.

Apa yang dilakukan proxy dan cache pada level teknis

Kami gunakan contoh paling umum: sebuah HTTP reverse proxy yang bekerja sebagai front-end accelerator. Sistem ini menyimpan objek di memori untuk menyajikan konten lebih cepat.

Manfaat: TTFB menurun, beban server berkurang, dan situs tetap stabil saat lonjakan trafik. Dengan backend polling dan mekanisme grace, konten bisa tetap tersaji saat origin bermasalah.

“Reverse proxy menyaring request, menegakkan aturan cache, lalu meneruskan ke host origin bila perlu.”

Ringkasan jenis caching

• Page cache — halaman siap saji.
• Browser cache — penyimpanan lokal pengguna.
• Object & bytecode cache — mempercepat proses aplikasi.
• CDN & reverse proxy — distribusi dan akselerasi di tepi jaringan.

Kami akan lanjutkan ke VCL — varnish configuration language — untuk membuat aturan normalisasi URL, TTL berbeda, dan pengecualian area login serta cart.

Arsitektur “varnish and wordpress” yang tepat untuk Indonesia: di server yang sama atau terpisah

Di Indonesia, pemilihan antara satu server atau beberapa tier perlu penilaian praktis. Pilihan utama: menempatkan varnish pada mesin yang sama dengan website, atau di mesin terpisah sebagai proxy server.

Satu server—Varnish dan website berdampingan—lebih hemat biaya. Deployment lebih sederhana. Monitoring dan backup jadi lebih mudah. Untuk websites dengan traffic medium dan banyak users baca konten, pola ini sering cukup.

Multi-server—proxy server terpisah—memberi skalabilitas dan isolasi beban. Perlu orkestrasi health checks, manajemen SSL, dan aturan firewall. Pastikan backend hanya dapat diakses dari host proxy (allowlist IP).

• Port mapping standar: proxy di port 80/443, web server di port 8080.
• DNS harus menunjuk ke layer proxy, bukan langsung ke backend host.
• Mulai di satu server; rancang migrasi ke arsitektur terpisah saat traffic tumbuh.

Kami sarankan memulai di satu server dengan backend di 127.0.0.1:8080 — lalu evolusi ke tier terpisah saat diperlukan. Untuk kebutuhan hosting, lihat hosting PHP sebagai referensi layanan.

Instal, ubah port, dan siapkan backend: langkah awal konfigurasi Varnish di atas Apache/Nginx

Tahap awal melibatkan instalasi paket, verifikasi service, dan migrasi web server ke port internal. Kita mulai dari server Linux berbasis Ubuntu dengan urutan perintah berikut untuk install varnish dan memastikan layanan aktif:

• sudo apt update
• sudo apt install varnish
• sudo systemctl status varnish — verifikasi service berjalan

Setelah terpasang, peta port: cache harus listen pada port 80, sedangkan web server kita pindahkan ke port 8080. Ini memastikan semua http request masuk lewat layer cache terlebih dulu.

Untuk Apache: ubah baris Listen 80 menjadi Listen 8080 di configuration file utama.

Ganti setiap <VirtualHost *:80> ke <VirtualHost *:8080>, lalu restart:

• sudo systemctl restart apache2

Untuk Nginx: sesuaikan setiap server block dari listen 80; ke listen 8080; dan jalankan sudo systemctl restart nginx.

Contoh systemd ExecStart yang jelas membantu binding:

“/usr/sbin/varnishd -a :80 -b 127.0.0.1:8080 -T localhost:6082”

Definisi backend di file /etc/varnish/default.vcl harus menunjuk ke host internal:

Setelah perubahan, restart service terkait: sudo systemctl restart apache2 atau sudo systemctl restart nginx, lalu sudo systemctl restart varnish.

Kami sarankan menyimpan perubahan konfigurasi di version control. Lakukan pengecekan cepat dengan ss -ltnp atau netstat -tulpen untuk memastikan hanya cache yang exposed di port 80. Juga cek firewall/security group — backend harus bersifat internal saja.

Untuk referensi layanan dan perbandingan arsitektur, lihat penjelasan tentang perbedaan web server dan web hosting.

Integrasi dengan WordPress: plugin Proxy Cache Purge, aturan purge, dan kontrol cookie

Saat menautkan layer cache ke CMS, langkah integrasi plugin menentukan kecepatan invalidasi konten. Kita pandu proses pemasangan singkat sehingga tim editorial bisa menerbitkan tanpa menunggu lama.

Memasang dan mengaktifkan

Masuk ke dashboard: Plugins > Add New, cari “Proxy Cache Purge”, klik Install Now, lalu Activate. Plugin ini mengirim HTTP PURGE ke cache front-end saat konten diperbarui.

Bagaimana PURGE bekerja

Plugin mengirim request PURGE; VCL memprosesnya sebagai ban literal atau ban regex bila header X-Purge-Method=regex hadir. Pastikan ACL hanya mengizinkan IP trusted—contoh: localhost, 127.0.0.1, ::1—untuk menghindari penyalahgunaan.

Cookie dan pengecualian halaman dinamis

Bypass cache untuk halaman login, cart, checkout, my-account, wp-admin, serta endpoint WooCommerce. Hapus cookie pada static assets; pertahankan cookie autentikasi pada rute dinamis agar user tetap tersinkron.

Kami sarankan naming pola purge konservatif dan audit berkala pada aturan purge serta cookie. Sebagai alternatif sinkronisasi, pertimbangkan Varnish Add-On by WP Rocket untuk workflow editorial yang rapi.

VCL WordPress yang andal: normalisasi URL, TTL, static files, dan header X-Cacheable

Kami menyimpan vcl file utama di /etc/varnish/default.vcl. File ini set backend default ke { .host="127.0.0.1"; .port="8080"; } dan mendefinisikan ACL purge untuk “localhost”, “127.0.0.1”, serta “::1”. Lokasi file ini menjadi sumber kebenaran untuk semua aturan caching dan hardening.

Pada vcl_recv kita normalisasi query dengan std.querysort dan menghapus tracking parameters seperti utm_, gclid, fbclid. Kita juga unset header proxy untuk mitigasi httpoxy dan set header X-Forwarded-Proto agar backend melihat skema http yang benar.

Di vcl_backend_response injeksi header x-url dan x-host. Aturan TTL default ditetapkan 1 jam bila tidak ada Cache-Control. Untuk asset statis (css, js, images, fonts, pdf) kita set TTL 1 hari, unset Set-Cookie, dan hapus cookie Wordfence tertentu supaya cached content aman.

• Bypass cache untuk rute sensitif: wp-admin, wp-login.php, wp-cron.php, cart, checkout.
• Atur PURGE: terima request dari ACL, dukung X-Purge-Method=regex untuk ban.
• Set header X-Cacheable di vcl_deliver untuk debugging — nilai YES/NO dan alasan.

“X-Cacheable: YES — TTL 3600; X-Cache-Reason: hit”

Pastikan configuration file menunjuk backend host 127.0.0.1:8080 untuk konsistensi port. Setelah edit, uji sintaks VCL dan terapkan changes dengan systemctl restart apache2/nginx lalu systemctl restart varnish. Untuk deployment dan orkestrasi server, integrasi ke cluster Proxmox bisa mempermudah rollback dan automasi purge pada pipeline CI/CD.

Uji, monitoring, dan optimasi berkelanjutan untuk performa maksimal

Sebelum mengklaim perbaikan, kita verifikasi dengan langkah sederhana dan berulang. Pengujian cepat menjaga kestabilan saat menerapkan perubahan pada file VCL atau policy cache.

Verifikasi cepat — jalankan command curl -I http://domain untuk memeriksa header X-Varnish dan X-Cacheable. Header ini memberi tahu apakah sebuah request dilayani dari cache atau origin.

Monitoring runtime dan metrik dasar

Kita gunakan varnishstat untuk baseline: hit ratio, backend fetches, serta latency. Catat metrik sebelum dan sesudah perubahan untuk membandingkan performance.

jalankan varnishtop untuk melihat URL yang paling sering menerima requests. Ini membuka peluang normalisasi dan aturan caching tambahan.

Tuning TTL, grace, dan backend polling

Tetapkan TTL berbeda per jenis konten — static assets lebih lama, halaman dinamis lebih pendek. Gunakan grace untuk menjaga halaman tetap tersaji saat backend down.

• Lakukan changes kecil: deploy, amati metrik, dokumentasikan dampak.
• Restart service jika perlu: sudo systemctl restart varnish dan sudo systemctl restart apache2 atau nginx.
• Uji beban ringan setelah modifikasi kritikal untuk memastikan server menahan trafik.

“Ukur, ubah sedikit, amati lagi — siklus ini menurunkan risiko dan meningkatkan keandalan.”

Kami juga sarankan menyimpan strategi rollback untuk VCL dan konfigurasi. Untuk referensi arsitektur dan diagram hosting, lihat diagram hosting.

Kesimpulan

Kesimpulan

Implementasi yang disiplin akan mengubah pengalaman users dan beban server secara nyata. Pasang dan configure varnish di port 80 dengan backend pada port 8080 untuk menurunkan TTFB dan mempercepat pages.

Atur VCL sebagai sumber kebenaran, gunakan plugin Proxy Cache Purge untuk invalidasi saat pages berubah, dan pantau performa lewat varnishstat atau varnishtop. Verifikasi cepat bisa dilakukan dengan curl untuk memeriksa header X-Varnish dan X-Cacheable.

Manfaat bisnis: websites lebih cepat, biaya infrastruktur terkendali, dan pengalaman pengguna meningkat—semua berdampak pada metrik konversi. Mulai di satu server, ukur hasil, lalu skala ke proxy server terpisah bila perlu.

Butuh referensi arsitektur atau penjelasan cache lebih lengkap? Baca panduan cara kerja sistem cache dan lihat contoh diagram hosting sebelum deploy produksi.