Learn HAProxy - Frontend & Backend Configuration

#Introduction

Episode 3 gave you a simple Hello World. Now it's time to unlock the full power of frontend and backend: how to bind various addresses and ports, write ACLs, and route traffic with use_backend.

By the end of this episode, you'll be able to build a single configuration file with several frontends and backends serving different kinds of traffic — the pattern used by almost every production HAProxy deployment.

#Understanding the Role of Frontend and Backend

#Frontend: The Public Entry Point

The frontend is where HAProxy accepts connections. Every frontend has at least one bind directive that determines the address and port. Example:

frontend web_front
    bind *:80
    bind 10.0.0.5:8080
    mode http
    default_backend web_back

The bind *:80 directive listens on all interfaces on port 80, while bind 10.0.0.5:8080 listens only on a specific address. You can add many binds within a single frontend.

#Backend: The Group of Destination Servers

The backend defines which servers serve the traffic, complete with connection and health parameters:

backend web_back
    balance leastconn
    option httpchk GET /healthz
    server web1 10.0.0.11:80 check inter 2s
    server web2 10.0.0.12:80 check inter 2s
    server web3 10.0.0.13:80 check backup

The server web1 10.0.0.11:80 check inter 2s directive adds a server with an active health check every 2 seconds. A server with the backup keyword is only used when all primary servers are down.

#ACLs and use_backend

#Writing Simple ACLs

An ACL (Access Control List) is a boolean condition used to match requests. Some of the most common ACLs:

frontend web_front
    bind *:80
    mode http
 
    acl is_api   path_beg /api
    acl is_admin host admin.example.com
    acl is_static path_end .png .jpg .css
 
    use_backend api_back     if is_api
    use_backend admin_back   if is_admin
    use_backend static_back  if is_static
    default_backend web_back

The line acl is_api path_beg /api creates an ACL named is_api that is true when the path starts with /api. Then use_backend api_back if is_api routes matching requests to a specific backend.

#Priority and Fallback

use_backend rules are evaluated from top to bottom; the first match wins. If nothing matches, default_backend is used. Order your rules from most specific to most general.

#Multiple Frontends and Backends in One File

#Separating HTTP and HTTPS

It's very common to use two frontends: one for HTTP, one for HTTPS. Although SSL details are only covered in episode 8, you can see the structure now:

frontend http_front
    bind *:80
    mode http
    default_backend web_back
 
frontend https_front
    bind *:443 ssl crt /etc/haproxy/certs/fullchain.pem
    mode http
    http-request redirect scheme https unless { ssl_fc }
    default_backend web_back

Each frontend has its own bind and can use the same or different backends. Backend names don't have to be unique per frontend — in fact, backends are usually shared.

#The listen Section for Simple Services

For a service that has just one entry point and one group of servers, the listen section shortens everything:

listen stats
    bind *:8404
    mode http
    stats enable
    stats uri /stats
    stats refresh 10s

listen stats combines a frontend and a backend in a single block. Here, port 8404 serves HAProxy's statistics page, which we'll cover in episode 7.

#Validation and Refactoring Practice

#Keeping the Configuration Readable

The bigger the configuration, the more discipline matters:

• Give frontends and backends descriptive names, for example api_back instead of b1.
• Group ACLs at the top of the frontend so they're easy to read.
• Use a single main file with clear separators between sections.

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

Run haproxy -c -f /etc/haproxy/haproxy.cfg every time you add a new section, then reload with sudo systemctl reload haproxy.

#Testing with Various Requests

After reloading, test each rule:

curl -s -o /dev/null -w "%{http_code}\n" http://localhost/api/status
curl -s -o /dev/null -w "%{http_code}\n" http://localhost/logo.png

The command curl -s -o /dev/null -w "%{http_code}\n" only prints the HTTP status code, enough to verify that a request is routed to the correct backend.

#Closing

Episode 4 closes out the configuration foundation: you can now build complex frontends and backends, separate traffic with ACLs and use_backend, and keep many sections tidy in a single file.

Key takeaways:

• The frontend is the entry point; the backend is the group of destination servers.
• bind determines which address and port are listened on.
• ACLs express conditions; use_backend executes decisions.
• Rules are evaluated top-down; default_backend is the fallback.
• listen combines a frontend and a backend for simple services.
• Validate with haproxy -c before reloading.

In the next episode we'll cover load balancing algorithms & health checks — the differences between roundrobin, leastconn, source, and uri, how active and passive health checks work, and failover configuration with backup servers.