Operations 16 min read

Master HAProxy: Step-by-Step Deployment and Configuration Guide

This article provides a comprehensive, hands‑on guide to installing HAProxy, configuring global, defaults, listen, frontend, and backend sections, setting up ACL‑based load balancing, preparing backend web servers, testing the setup, and accessing the HAProxy statistics page.

Raymond Ops
Raymond Ops
Raymond Ops
Master HAProxy: Step-by-Step Deployment and Configuration Guide

HAProxy Deployment Configuration

Topology diagram:

Topology diagram
Topology diagram

Explanation

<code>haproxy服务器 IP:172.16.253.200/16(外网)、192.168.29.140/24(内网)
博客服务器组 IP:192.168.29.130/24、192.168.29.131/24
网站服务器组 IP:192.168.29.120/24、192.168.29.121/24
默认服务器组 IP:192.168.29.110/24、192.168.29.111/24</code>

1 HAProxy Host Configuration

<code># yum install haproxy -y
# vim /etc/haproxy/haproxy.cfg</code>

1. global section

Used to set global parameters related to the HAProxy process and the operating system.

<code>global
    log 127.0.0.1 local2 info   ## global log configuration, local2 is the log device, info is the log level
    chroot /var/lib/haproxy
    pidfile /var/run/haproxy.pid   ## path to the PID file, the user starting HAProxy must have permission to access it
    maxconn 4000   ## maximum concurrent connections per process
    user haproxy   ## user that runs the HAProxy process (UID can be used)
    group haproxy   ## group that runs the HAProxy process (GID can be used)
    daemon   ## run HAProxy as a background daemon
    stats socket /var/lib/haproxy/stats</code>

2. defaults section

Default parameters applied to frontend, backend, and listen sections unless overridden.

<code>defaults
    mode http   ## default operating mode (tcp, http, health)
    log global
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor except 127.0.0.0/8
    option redispatch
    retries 3   ## number of retries for backend servers
    timeout http-request 10s
    timeout queue 1m
    timeout connect 5s
    timeout client 10s   ## maximum wait time for client data
    timeout server 10s   ## maximum wait time for server response
    timeout http-keep-alive 10s   ## keep‑alive duration
    timeout check 2s   ## health‑check timeout for backend servers
    maxconn 3000</code>

3. listen section

This part combines frontend and backend functionality.

<code>listen admin_stats
    bind 0.0.0.0:19088   ## IP and port for the statistics page
    mode http
    log 127.0.0.1 local2 err
    stats refresh 30s   ## auto‑refresh interval for the stats page
    stats uri /haproxy-status   ## URL path for the stats page
    stats realm welcome login Haproxy   ## prompt shown on the login box
    stats auth admin:admin   ## username and password for the stats page
    stats hide-version   ## hide HAProxy version information
    stats admin if TRUE   ## allow manual enable/disable of backends from the page</code>

4. frontend section

Defines the front‑end virtual node that receives client requests. ACL rules can direct traffic to specific backends.

<code>frontend www
    bind *:80   ## listen on all interfaces, port 80
    mode http
    option httplog   ## enable HTTP request logging
    option forwardfor   ## add X-Forwarded-For header with client IP
    option httpclose   ## close the TCP connection after each request
    log global</code>

ACL rules for intelligent load balancing:

<code># Define ACLs
acl host_www hdr_reg(host) -i ^(www\.tb\.com|tb\.com)
acl host_blog hdr_beg(host) -i blog.
# Route based on ACLs
use_backend server_www if host_www
use_backend server_blog if host_blog
default_backend server_default   ## fallback backend</code>

5. backend sections

Define server pools for default, www, and blog services.

<code>backend server_default
    mode http
    option redispatch   ## for cookie‑based persistence environments
    option abortonclose   ## abort long‑running processes in the queue
    balance roundrobin   ## load‑balancing algorithm
    cookie SERVERID   ## insert SERVERID into cookies
    option httpchk GET /check_status.html   ## health check using a specific page
    server default1 192.168.29.110:80 cookie default1 weight 2 check inter 2000 rise 2 fall 3
    server default2 192.168.29.111:80 cookie default2 weight 2 check inter 2000 rise 2 fall 3

backend server_www
    mode http
    option redispatch
    option abortonclose
    balance source   ## source‑IP based algorithm ensures the same client IP always reaches the same backend
    cookie SERVERID
    option httpchk GET /check_status.jsp
    server www1 192.168.29.120:80 cookie www1 weight 6 check inter 2000 rise 2 fall 3
    server www2 192.168.29.121:80 cookie www2 weight 6 check inter 2000 rise 2 fall 3

backend server_blog
    mode http
    option redispatch
    option abortonclose
    balance roundrobin
    cookie SERVERID
    option httpchk GET /check_blog.php
    server blog1 192.168.29.130:80 cookie blog1 weight 5 check inter 2000 rise 2 fall 3
    server blog2 192.168.29.131:80 cookie blog2 weight 5 check inter 2000 rise 2 fall 3</code>

2 Backend Server Configuration

1. Default server

Virtual host configuration:

<code># vim /etc/httpd/conf.d/vhost.conf
<VirtualHost 192.168.29.110:80>
    DocumentRoot "/data/web1"
    <Directory "/data/web1/">
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
</code>

Status page configuration:

<code># echo "This is check_status.page ip:192.168.29.110" > /data/web1/check_status.html</code>

Default page configuration:

<code># echo "This is default page ip:192.168.29.110" > /data/web1/index.html</code>

Repeat the same steps for the other default host (192.168.29.111).

2. Website server

Virtual host configuration for the main website (www.tb.com):

<code># vim /etc/httpd/conf.d/vhost.conf
<VirtualHost 192.168.29.120:80>
    DocumentRoot "/data/web1"
    ServerName www.tb.com
    <Directory "/data/web1/">
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
</code>

Status page configuration:

<code># echo "This is check_status page ip:192.168.29.120" > /data/web1/check_status.jsp</code>

Default page configuration:

<code># echo "This is www page ip:192.168.29.120" > /data/web1/index.html</code>

Apply the same configuration to the second website host (192.168.29.121).

3. Blog server group

Virtual host configuration for the blog sub‑domain:

<code># vim /etc/httpd/conf.d/vhost.conf
<VirtualHost 192.168.29.130:80>
    DocumentRoot "/data/web1"
    ServerName www.blog.tb.com
    <Directory "/data/web1/">
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
</code>

Status page configuration:

<code># echo "This is check_status page ip:192.168.29.130" > /data/web1/check_blog.php</code>

Default page configuration:

<code># echo "This is blog page ip:192.168.29.130" > /data/web1/index.html</code>

Repeat the same steps for the second blog host (192.168.29.131).

3 Testing

1. Start HAProxy

<code># systemctl start haproxy</code>

2. Test website servers

<code># for i in {1..10}; do curl www.tb.com; done
# for i in {1..10}; do curl blog.tb.com; done
# for i in {1..10}; do curl 172.16.253.200; done</code>

The first test shows session persistence – all requests are served by the same web server. The second test demonstrates the round‑robin algorithm for the blog servers. The third test verifies that the default backend returns responses from the default servers (192.168.29.110 and .111).

3. HAProxy statistics page

Access the statistics page at

http://172.16.253.200:19088/haproxy-status

and log in with the credentials defined earlier (admin:admin).

HAProxy statistics login page
HAProxy statistics login page
backendfrontendoperationsLoad BalancingconfigurationACLHAProxy
Raymond Ops
Written by

Raymond Ops

Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.