Apache mod_proxy_balancer Load Balancer Guide

Learn the minimal Apache 2.4 setup needed to load‑balance HTTP traffic using mod_proxy_balancer, including configuration, trust boundaries, and operational checks.

Requirements

To use Apache HTTP Server as a reverse‑proxy load balancer you need:

Apache 2.4 or newer
Modules mod_proxy, mod_proxy_balancer, and a load‑balancing method such as mod_lb>mod_lbmethod_byrequests (alternatives: bytraffic, bybusyness)
Optionally mod_ssl if you want TLS termination at the front‑end
Network reachability between the Apache instance and each backend server

Smallest Suitable Design

The minimal configuration consists of a single Apache listener that forwards all requests to a balancer defined with two backend workers.

# Listen on plain HTTP; change to 443 and add SSL directives if TLS termination is needed\nListen 80\n\n\n    ProxyPreserveHost On\n    ProxyPass / balancer://mycluster/ lbmethod=byrequests\n    ProxyPassReverse / balancer://mycluster/\n\n    # Balancer definition\n    \n        BalancerMember http://10.0.1.11:8080\n        BalancerMember http://10.0.1.12:8080\n        ProxySet lbmethod=byrequests\n    \n\n    # Optional: expose balancer‑manager for monitoring (restrict to trusted IPs)\n    \n        SetHandler balancer-manager\n        Require ip 192.168.0.0/16\n    \n\n

This setup uses the byrequests method, which distributes incoming requests based on the number of requests each worker has handled.

Trust and Data Boundaries

The Apache front‑end is the trust boundary: it terminates the client TCP connection, validates the HTTP request line and headers, and then builds a sanitized proxied request to send to the backend. The backend sees only the proxied request and should not rely on client‑provided headers such as X‑Forwarded‑For unless you explicitly enable and trust them (e.g., with ProxyPreserveHost On or custom RequestHeader directives).

Operational Checks

Enable monitoring to verify health and traffic distribution:

Load mod_status and access the balancer‑manager UI at http://apache-host/balancer-manager to see worker status, enable/disable workers, and adjust load‑factor values.
Configure timeouts, retries, and maxattempts in the ProxyPass line to control how Apache handles unresponsive backends.
Check access logs on each backend; with byrequests you should see roughly equal request counts over a short interval if the workers are healthy and the traffic is uniform.

Failure Modes

Backend unresponsiveness: after the configured number of retries Apache returns HTTP 502 (Bad Gateway) to the client.
Worker drain: if a worker is manually set to “drain” via the balancer‑manager, Apache stops sending new requests to it; existing connections finish, and clients may see 503 (Service Unavailable) if all workers are drained.
Mis‑balanced load: using byrequests with highly variable request sizes can cause uneven resource utilization; consider lbmethod=bytraffic or lbmethod=bybusyness for heterogeneous workloads.

When the Design Would Change

You would revisit this minimal design if any of the following apply:

Sticky sessions are required (e.g., for stateful applications). Add stickysession parameters and possibly ProxySet stickysession=JSESSIONID.
TLS offload is moved to a dedicated device (hardware load balancer or separate TLS termination proxy). In that case Apache would listen on plain HTTP only, and the front‑end trust boundary shifts.
You need more sophisticated health checks (e.g., HTTP‑based checks with specific response codes). Replace simple TCP connectivity with ProxyPass retry and timeout tuned to your application, or use an external health‑check agent.
The traffic pattern demands a different load‑balancing algorithm (consistent hashing, least‑time, etc.). Swap the lbmethod module and adjust the ProxySet line accordingly.

Apache HTTP Server as a Simple Reverse‑Proxy Load Balancer with mod_proxy_balancer