HAProxy Adalah: Fungsi, Cara Kerja & Konfigurasi Dasar

Satu server web yang tadinya lapang akhirnya penuh juga. Anda menambah server kedua dengan aplikasi yang sama persis. Lalu muncul dua pertanyaan yang tidak bisa dihindari: siapa yang memutuskan permintaan pengunjung dikirim ke server mana, dan siapa yang tahu kalau salah satunya mati? Keduanya sudah dijawab sejak 2001, dan jawabannya bernama HAProxy. HAProxy adalah perangkat lunak yang sampai hari ini berdiri di depan sebagian situs tersibuk di dunia, membagi permintaan sekaligus menjaga agar tidak ada yang dikirim ke server yang sudah mati.

Apa Itu HAProxy?

HAProxy adalah perangkat lunak reverse proxy dan load balancer sumber terbuka yang membagi permintaan pengunjung ke sekumpulan server, baik untuk trafik HTTP maupun TCP. Namanya singkatan dari High Availability Proxy — proxy yang bertugas menjaga layanan tetap tersedia.

Kata proxy di dalamnya perlu diperjelas. Proxy adalah perantara yang meneruskan permintaan atas nama pihak lain. Kalau ia mewakili pengguna saat menghubungi internet, ia disebut forward proxy; kalau ia mewakili server saat menghadapi pengunjung, ia disebut reverse proxy. HAProxy jenis kedua: pengunjung mengira berbicara dengan situs Anda, padahal yang menjawab adalah HAProxy. Perbedaan keduanya dibahas lebih lengkap di artikel proxy.

Proyeknya digarap Willy Tarreau, kontributor kernel Linux, sejak tahun 2000 dengan rilis pertama pada 16 Desember 2001. Kodenya ditulis dalam bahasa C dan dilepas dengan lisensi GPL versi 2, sedangkan berkas header yang bisa diekspor memakai LGPL. Situs resminya menyebut HAProxy sebagai standar de-facto untuk load balancer sumber terbuka, dan sebagian besar distribusi Linux arus utama sudah membundelnya. GitHub, Reddit, Stack Overflow, Slack, dan Speedtest.net tercatat memakainya.

Angka performanya terukur. Pada pengujian resmi di instance AWS berprosesor Arm 64 core, HAProxy meneruskan 2,04 juta permintaan HTTP per detik dengan tambahan latensi sekitar 400 mikrodetik. Untuk server 6–8 core, 200.000 sampai 500.000 permintaan per detik adalah angka yang wajar.

Cara Kerja HAProxy: Frontend, Backend, dan Dua Mode Kerjanya

Seluruh perilaku HAProxy diatur lewat satu berkas, umumnya /etc/haproxy/haproxy.cfg. Isinya terbagi ke beberapa jenis bagian, dan empat di antaranya paling sering Anda tulis:

1. global: Pengaturan tingkat proses — jumlah thread, soket administrasi, TLS bawaan, dan tujuan log.
2. defaults: Nilai bawaan yang diwarisi bagian di bawahnya, seperti mode kerja dan batas waktu tunggu.
3. frontend: Sisi yang menghadap pengunjung. Di sinilah HAProxy mendengarkan port tertentu, membaca permintaan, lalu memutuskan permintaan itu dilempar ke kelompok server mana.
4. backend: Kelompok server tujuan beserta aturan pembagian dan cara mengecek kesehatannya.

Alur satu permintaan berjalan berurutan dari atas ke bawah:

Permintaan masuk ke frontend HAProxy, lalu backend memilih server sesuai algoritma balance dan hasil health check.

Seberapa dalam HAProxy boleh membaca isi trafik ditentukan direktif mode. Pada mode tcp, ia bekerja di lapisan transport: hanya melihat alamat dan port, lalu mengalirkan byte tanpa membuka isinya. Cara ini cepat dan bisa dipakai untuk protokol apa pun, termasuk basis data.

Pada mode http, HAProxy membongkar permintaan sehingga bisa membaca nama host, path URL, header, dan cookie. Dari situ ia sanggup mengirim permintaan /api ke kelompok server tersendiri. Perbedaan kedua lapisan ini dibahas lebih dalam di artikel load balancing.

Pilihan mode bukan sekadar soal kecepatan. Beberapa fitur hanya hidup di mode http, dan memakainya di mode tcp tidak selalu memunculkan error — sebagiannya hanya menghasilkan peringatan yang mudah terlewat saat proses dijalankan.

Konfigurasi Minimal HAProxy dan Cara Mengujinya

Berikut konfigurasi paling sederhana yang benar-benar berfungsi — satu pintu masuk di port 80, dua server tujuan, dan satu halaman statistik.

global
    log /dev/log local0

defaults
    mode    http
    log     global
    option  httplog
    timeout connect 5s
    timeout client  30s
    timeout server  30s

frontend web_masuk
    bind *:80
    default_backend server_aplikasi

backend server_aplikasi
    balance roundrobin
    option httpchk GET /health
    server app1 10.0.0.11:8080 check
    server app2 10.0.0.12:8080 check

listen statistik
    bind *:8404
    stats enable
    stats uri /haproxy?stats

Bagian listen di baris terakhir adalah bentuk ringkas: satu bagian yang sekaligus menjadi frontend dan backend, biasa dipakai untuk keperluan sederhana seperti halaman statistik.

Sebelum diterapkan, uji dulu berkasnya. Perintahnya sederhana, tetapi punya satu jebakan:

haproxy -c -f /etc/haproxy/haproxy.cfg

Kalau konfigurasi Anda benar, perintah di atas tidak mencetak apa pun. Dokumentasi resmi menyatakan opsi -c memang tidak melaporkan pesan sukses secara bawaan. Untuk memunculkan kalimat "Configuration file is valid", tambahkan -V sehingga menjadi haproxy -c -V -f /etc/haproxy/haproxy.cfg. Layar kosong berarti aman, bukan berarti perintahnya gagal jalan. Kalau pengujian ini Anda taruh di dalam skrip, baca nilai exit status-nya, bukan keluaran teksnya.

Untuk halaman statistik, alamat bawaan yang dikompilasi ke dalam HAProxy adalah /haproxy?stats. Dokumentasinya menganjurkan agar stats uri selalu ditulis eksplisit, karena nilai itu bisa berbeda tergantung cara paketnya dibangun. Port 8404 dan 1936 yang sering muncul di berbagai contoh hanyalah konvensi.

Praktik yang Perlu Anda Terapkan di Produksi

Tiga hal berikut hampir selalu dibutuhkan begitu HAProxy melayani pengunjung sungguhan, dan ketiganya biasanya baru disadari setelah ada yang bermasalah.

Teruskan alamat asli pengunjung. Setelah HAProxy berdiri di depan, aplikasi Anda melihat semua permintaan seolah datang dari HAProxy. Log akses jadi seragam, pembatasan per-IP di aplikasi salah sasaran, dan fitur yang bergantung pada lokasi pengunjung berhenti bekerja. Perbaikannya satu baris di bagian defaults atau backend:

option forwardfor

Baris itu menyisipkan header X-Forwarded-For berisi alamat asli pengunjung. Aplikasi di belakang tetap perlu dikonfigurasi untuk membacanya, karena menerima bukan berarti memakai.

Tentukan di mana koneksi TLS diakhiri. Pada TLS termination, HAProxy memegang sertifikat dan membuka enkripsi, sehingga ia bisa membaca path URL untuk pengarahan Layer 7 dan server di belakang cukup melayani HTTP biasa. Pada SSL passthrough, HAProxy bekerja di mode tcp dan meneruskan koneksi terenkripsi apa adanya: sertifikat tetap di server dan enkripsi utuh dari ujung ke ujung, tetapi HAProxy jadi buta terhadap isi permintaan. Pilih termination kalau Anda butuh pengarahan berbasis URL, passthrough kalau ada tuntutan kepatuhan yang melarang enkripsi dibuka di tengah jalan.

TLS termination membuat HAProxy membuka enkripsi, sedangkan SSL passthrough meneruskannya utuh sampai server web.

Muat ulang, jangan hidupkan ulang. Setelah konfigurasi lolos haproxy -c, terapkan dengan systemctl reload haproxy. Perintah ini menyalakan proses baru sambil membiarkan proses lama menyelesaikan koneksi yang berjalan. systemctl restart haproxy memutus semuanya seketika, termasuk unggahan yang setengah jalan.

Algoritma Load Balancing dan Kapan Memakainya

Direktif balance di dalam backend menentukan server mana yang dipilih untuk tiap permintaan baru. Pilihan yang paling sering dipakai:

1. roundrobin: Server dipakai bergiliran menurut bobotnya, dan bobot itu bisa diubah saat proses berjalan. Satu batas yang jarang terlihat sampai infrastruktur membesar: algoritma ini dibatasi 4.095 server aktif per backend.
2. static-rr: Bergiliran juga, tetapi bobotnya tidak bisa diubah saat berjalan. Sebagai gantinya tidak ada batas jumlah server dan pemakaian CPU-nya sekitar satu persen lebih hemat.
3. leastconn: Server dengan koneksi aktif paling sedikit yang menerima permintaan berikutnya.
4. source: Alamat IP pengunjung dihitung menjadi angka, lalu dibagi total bobot server yang hidup. Pengunjung yang sama selalu mendarat di server yang sama selama daftar server tidak berubah.
5. uri, url_param, dan hdr: Keputusan diambil dari path URL, parameter, atau isi header. Berguna agar permintaan ke sumber daya yang sama selalu jatuh ke server yang sama, sehingga cache tiap server tetap efektif.

Ada satu hal yang sering terbalik dalam praktik. leastconn kerap dipilih karena terdengar paling cerdas, padahal dokumentasi resmi HAProxy menganjurkannya untuk protokol bersesi panjang seperti LDAP, SQL, dan sesi terminal, lalu menyebutnya kurang cocok untuk protokol bersesi pendek seperti HTTP. Untuk situs web biasa, roundrobin adalah titik awal yang benar.

Jebakan kedua tidak terlihat dari perilaku situs. Algoritma yang membaca Layer 7 — uri, url_param, dan hdr — hanya bekerja kalau backend berada di mode http. Ditulis di backend mode tcp, konfigurasi itu tidak ditolak. HAProxy diam-diam menggantinya dengan round robin dan hanya menaruh satu baris peringatan saat dijalankan:

Layer 7 hash not possible for backend 'nama_backend' (needs 'mode http'). Falling back to round robin.

Situs tetap melayani pengunjung, tetapi pembagian yang Anda kira berbasis URL sebenarnya bergiliran biasa. Membaca log saat pertama kali menjalankan HAProxy adalah kebiasaan yang murah dan berguna.

Untuk aplikasi yang menyimpan status login di server masing-masing, pembagian merata justru merepotkan. Di sinilah stick-table dipakai untuk sticky session: HAProxy mencatat pengunjung mana sudah mendarat di server mana, lalu menahannya di sana. Cara ini bekerja, tetapi memindahkan penyimpanan session ke tempat terpusat seperti Redis hampir selalu lebih sehat.

Health Check: Alasan Huruf "HA" Bisa Dipertanggungjawabkan

Membagi permintaan ke dua server tidak ada gunanya kalau HAProxy tetap mengirim pengunjung ke server yang sudah mati. Karena itu kata check di akhir baris server adalah bagian terpenting dari konfigurasi mana pun. Begitu aktif, tiga angka bawaan berikut berlaku:

• inter 2000 milidetik: jarak antar-pemeriksaan.
• rise 2: server dinyatakan hidup setelah dua pemeriksaan berhasil berturut-turut.
• fall 3: server dinyatakan mati setelah tiga pemeriksaan gagal berturut-turut.

Konsekuensinya bisa Anda hitung sendiri: server yang mati baru benar-benar keluar dari rotasi setelah sekitar enam detik, dan selama enam detik itu sebagian pengunjung masih diarahkan ke sana. Kalau layanan Anda tidak menoleransi jeda selama itu, perkecil inter atau turunkan fall. Perlu diperhatikan, pemeriksaan yang terlalu rapat menambah beban ke server yang sedang diperiksa.

Bentuk pemeriksaannya bisa disesuaikan. option httpchk GET /health membuat HAProxy meminta satu halaman tertentu dan menilai kode balasannya — jauh lebih bermakna daripada sekadar mengecek port terbuka. Untuk layanan non-web tersedia option mysql-check, option pgsql-check, option ldap-check, dan tcp-check.

Kemampuan ini yang membuat HAProxy menonjol. Nginx versi sumber terbuka hanya menyediakan pemeriksaan pasif: server ditandai bermasalah setelah permintaan pengunjung gagal, lewat max_fails yang bawaannya 1 dan fail_timeout bawaan 10 detik. Pemeriksaan aktif yang berjalan sendiri tanpa menunggu pengunjung jadi korban hanya ada di Nginx Plus yang berbayar.

Membaca Error 503, 502, dan 504 dari Sisi HAProxy

Karena berdiri paling depan, halaman error yang dilihat pengunjung sering kali berasal dari HAProxy, bukan dari aplikasi. Arti tiga kode yang paling sering muncul, menurut dokumentasi resminya:

Perbedaan 503 di HAProxy dengan 503 pada web server biasa perlu digarisbawahi. Halaman bawaannya berbunyi "No server is available to handle this request", dan itu bukan berarti aplikasi Anda kelebihan beban. Artinya seluruh server di backend sedang bertanda mati menurut health check. Penyebabnya justru sering bukan servernya: alamat pemeriksaan yang salah, halaman /health yang membalas 401 karena terkena aturan autentikasi, atau option httpchk yang menunjuk path tidak ada.

503 berarti tidak ada server sehat, 502 jawaban server rusak, dan 504 server diam sampai timeout habis.

Kolom ketiga di tabel berasal dari termination state pada log HAProxy — dua sampai empat karakter tepat sebelum jumlah koneksi aktif. Membiasakan diri membacanya memisahkan "server menolak" dari "server kelamaan" tanpa perlu menebak. Halaman statistik memberi konfirmasi visualnya, karena server bertanda merah di sana adalah yang gagal health check. Untuk pemantauan berkelanjutan, HAProxy menyediakan metrik yang bisa dibaca Prometheus dan disimpan riwayatnya lewat Zabbix.

HAProxy Sendiri Bisa Menjadi Titik Kegagalan Tunggal

Hal ini paling sering luput justru karena namanya menenangkan. Huruf HA di depan menjanjikan ketersediaan tinggi untuk server di belakangnya, bukan untuk HAProxy. Anda menyiapkan tiga server aplikasi supaya tidak bergantung pada satu mesin, tetapi seluruh trafik tetap melewati satu proses HAProxy di satu mesin. Ketika mesin itu mati, ketiga server sehat tadi tidak berguna sama sekali.

Penanganannya sudah baku: dua node HAProxy dengan satu alamat yang bisa berpindah di antara keduanya. Alamat itu disebut virtual IP, yaitu alamat yang tidak melekat permanen ke satu mesin. Di Linux, keepalived yang mengurusnya lewat protokol VRRP (Virtual Router Redundancy Protocol).

HAProxy aktif-pasif: virtual IP menempel di node aktif dan berpindah ke node pasif lewat keepalived.

Susunan di atas adalah aktif-pasif: satu node bekerja, satu menunggu. Ada juga aktif-aktif yang memakai beberapa virtual IP sekaligus agar kedua node sama-sama menerima trafik, tetapi ia menuntut pembagian di sisi DNS. Untuk mayoritas kebutuhan, aktif-pasif sudah cukup.

Satu hal perlu disiapkan bersamanya. Kalau backend memakai stick-table, kedua node harus saling menyalin tabel itu lewat bagian peers. Tanpa itu, perpindahan virtual IP membuat pengunjung kehilangan penempatannya dan berpotensi terlempar keluar dari sesi login.

Konsekuensi biayanya perlu dihitung sejak awal: dua server aplikasi ditambah dua node HAProxy berarti empat mesin. Node HAProxy tidak menuntut spesifikasi besar, hanya jaringan stabil dan akses root, sehingga VPS Indonesia adalah cara paling hemat memulainya.

Peta Versi HAProxy dan Masa Dukungannya

HAProxy merilis dua versi besar setiap tahun, sekitar Mei dan November. Aturannya mudah diingat: versi minor bernomor genap adalah LTS (Long Term Support) yang dirawat lima tahun, yang ganjil hanya 12 sampai 18 bulan. Versi yang masih dirawat per Agustus 2026:

Untuk server produksi, pilih versi LTS. Per Agustus 2026, 3.2 adalah pilihan paling aman karena sudah matang dan dirawat sampai 2030, sementara 3.4 layak dipertimbangkan kalau Anda memulai dari nol.

Perlu diperhatikan, paket bawaan distribusi Linux umumnya tertinggal satu sampai dua siklus. Debian 12 masih membawa 2.6 dan Debian 13 membawa 3.0. Ubuntu 22.04 membawa 2.4 yang sudah tidak lagi tercantum di daftar versi yang dirawat, sedangkan Ubuntu 24.04 membawa 2.8.

Kalau Anda membutuhkan versi terbaru, ambil dari repositori resmi HAProxy, bukan dari repositori bawaan sistem. Jalan lain adalah image Docker resminya, yang menyediakan tag haproxy:lts untuk selalu mengarah ke rilis LTS terkini. Di Kubernetes, HAProxy tersedia sebagai ingress controller resmi yang dipasang lewat Helm, dengan aturan pengarahan ditulis sebagai objek Kubernetes alih-alih berkas haproxy.cfg.

Tiga perubahan berikut benar-benar mengubah cara memakainya:

1. Versi 2.5 menghapus nbproc: Model banyak proses digantikan nbthread karena boros memori, melipatgandakan health check, tidak bisa menyinkronkan stick table, dan tidak akan pernah mendukung QUIC. Konfigurasi lama yang masih memuat nbproc langsung gagal dijalankan di 2.5 ke atas.
2. Versi 3.2 menambahkan dukungan ACME bawaan: HAProxy bisa mengurus sendiri penerbitan dan perpanjangan sertifikat TLS dari Let's Encrypt atau ZeroSSL. Fiturnya masih eksperimental dan harus diaktifkan lewat expose-experimental-directives.
3. Versi 3.4 memperkenalkan dynamic backends: Backend bisa ditambah dan dihapus saat proses berjalan tanpa memuat ulang.

HAProxy vs Nginx: Beda Peran, Beda Pilihan

Perbandingan ini harus dimulai dari satu kenyataan yang menentukan segalanya: HAProxy bukan web server. Ia tidak menyajikan berkas dari disk. Tidak ada direktori root untuk gambar, CSS, atau berkas unduhan; yang bisa ia kembalikan sendiri hanyalah halaman error dan balasan kecil yang ditulis di konfigurasi. Ini keputusan desain, bukan fitur yang belum sempat dikerjakan.

Nginx berdiri di posisi berbeda. Ia web server penuh yang juga bisa menjadi reverse proxy dan load balancer. Perbandingannya lebih jujur kalau dilihat per sumbu:

Panduan memilihnya menyempit ke tiga situasi. Pilih Nginx kalau satu mesin yang sama harus sekaligus menyajikan berkas statis dan meneruskan permintaan ke aplikasi. Pilih HAProxy kalau tugasnya murni membagi beban ke banyak server dan Anda membutuhkan health check aktif serta statistik terperinci tanpa membayar lisensi. Pakai keduanya pada susunan yang lebih besar: HAProxy di paling depan sebagai pembagi beban, Nginx di tiap server aplikasi untuk menyajikan berkas statis.

Di lingkungan container, dua nama lain ikut masuk percakapan. Traefik menemukan sendiri tujuan barunya dari label container tanpa berkas konfigurasi diubah, sedangkan Envoy lazim dipakai sebagai fondasi service mesh. Keduanya menukar kesederhanaan satu berkas haproxy.cfg dengan integrasi yang lebih otomatis.

Kelemahan HAProxy yang Perlu Anda Pertimbangkan

Empat batas berikut sebaiknya Anda ketahui sebelum memutuskan, bukan setelah konfigurasi berjalan setengah jalan.

1. Load balancing UDP tidak ada di edisi gratis: Membagi trafik UDP seperti DNS, NTP, dan RADIUS disediakan sebagai modul HAProxy Enterprise yang berbayar. Ini kebalikan dari Nginx sumber terbuka yang justru bisa mengerjakannya lewat modul stream.
2. Tidak ada firewall aplikasi web bawaan: Penyaringan serangan tingkat aplikasi (Web Application Firewall atau WAF) menuntut ModSecurity lewat mekanisme SPOE, atau modul Enterprise. HAProxy menyediakan bahan mentahnya — pembatasan laju permintaan, daftar izin berbasis IP, dan pencatatan di stick table — tetapi menyusunnya menjadi perlindungan utuh adalah pekerjaan Anda.
3. Tidak ada antarmuka grafis (GUI) resmi yang gratis: Seluruh konfigurasi ditulis manual di berkas teks. Data Plane API menyediakan antarmuka REST untuk mengubahnya secara terprogram, tetapi antarmuka visual terpusat untuk mengelola banyak node adalah produk berbayar. Halaman statistik bawaan hanya membaca dan sedikit mengubah status server, bukan menyunting konfigurasi.
4. Kurva belajarnya nyata: Sintaks ACL, urutan evaluasi http-request, dan perbedaan perilaku antar-mode menuntut waktu belajar tersendiri. Untuk satu situs di satu server, HAProxy hanya menambah komponen yang harus dirawat tanpa manfaat sepadan.

Pertanyaan Seputar HAProxy

Apa kepanjangan HAProxy? HAProxy adalah singkatan dari High Availability Proxy, yang berarti proxy untuk ketersediaan tinggi.

Apa bedanya HAProxy dengan proxy biasa? Proxy biasa umumnya berdiri di sisi pengguna dan meneruskan permintaan ke internet. HAProxy berdiri di sisi server: ia menerima permintaan pengunjung, lalu memilih satu dari beberapa server tujuan berdasarkan algoritma dan hasil health check. Kemampuan memilih tujuan inilah yang membuatnya disebut load balancer, bukan sekadar proxy.

Apakah HAProxy gratis? Ya. Edisi community dilepas dengan lisensi GPL versi 2 dan bebas dipakai termasuk untuk keperluan komersial. Edisi Enterprise dari HAProxy Technologies menambahkan modul UDP, WAF, manajemen bot, pengelolaan banyak klaster, dan dukungan teknis 24 jam.

Berapa server minimal untuk memakai HAProxy? Dua server aplikasi ditambah satu node HAProxy, jadi tiga mesin. Kalau HAProxy sendiri ingin dibuat tahan gangguan, siapkan empat.

Apakah HAProxy bisa dijalankan di Windows? Tidak secara langsung. HAProxy dirancang untuk Linux. Menjalankannya di Windows berarti lewat WSL, mesin virtual, atau container — semuanya menjalankan Linux di dalamnya.

Apakah HAProxy berguna kalau server saya hanya satu? Bisa. Sebagai reverse proxy tunggal, ia tetap berguna untuk mengakhiri koneksi TLS, mengarahkan beberapa domain ke aplikasi berbeda, dan membatasi laju permintaan. Meski begitu, manfaat utamanya baru terasa setelah ada lebih dari satu server tujuan.

Kesimpulan

HAProxy adalah reverse proxy dan load balancer sumber terbuka yang membagi permintaan pengunjung ke sekumpulan server, dengan health check aktif yang menjaga permintaan tidak nyasar ke mesin yang sudah mati. Kekuatannya ada pada fokus: ia tidak berusaha menjadi web server, sehingga bisa mengerjakan pembagian beban dengan sangat baik tanpa biaya lisensi.

Kalau Anda memakainya, dua hal layak disiapkan sejak awal. Pertama, health check yang mengukur kesehatan aplikasi, bukan sekadar port yang terbuka — di sinilah sebagian besar error 503 lahir. Kedua, pasangan node dengan virtual IP, karena huruf HA di depan namanya menjanjikan ketersediaan untuk server di belakangnya, bukan untuk HAProxy itu sendiri.

Semoga artikel ini membantu.