mod_proxy & mod_proxy_balancer: Apache as a Reverse Proxy and Load Balancer

Web Servers Fundamentals Chapter 6 showed a single ProxyPass/ProxyPassReverse pair pointing at one backend, and named mod_proxy_balancer without ever configuring it. This chapter is the real thing: a genuine multi-backend pool, the algorithms that decide which member handles each request, how Apache detects a failed backend, session affinity, and one very easy-to-miss directive that breaks a surprising number of real proxied applications.

A Real Backend Pool: <Proxy balancer://...>

<Proxy balancer://mycluster> names a pool the same way Nginx's own upstream {} block does (Nginx In Depth Chapter 4) — each BalancerMember line is one backend, and ProxyPass/ProxyPassReverse now point at the named balancer instead of a single address. ProxySet lbmethod=byrequests picks the load-balancing algorithm.

Load Balancing Algorithms

Apache ships three real lbmethod options: byrequests (the default) distributes requests in round-robin fashion, optionally weighted per member. bytraffic balances based on bytes actually transferred rather than raw request count — a better fit when requests vary hugely in payload size, since ten tiny requests and one huge upload aren't equivalent load. bybusyness routes each new request to whichever member currently has the fewest active in-flight requests — the right choice when backend response times vary widely, since a member stuck on one slow request won't keep receiving new ones under round robin's blind rotation.

Health Checks and Member Status

When a BalancerMember fails to respond, Apache automatically marks it in an error state and stops routing new requests to it — no external health-check tool required for this basic case. By default it retries that member again after 60 seconds (configurable via a member's own retry= parameter), giving a recovering backend a chance to rejoin the pool automatically rather than needing a manual restart of the whole proxy layer.

Sticky Sessions

A backend that keeps session state in its own local memory — rather than in a shared, external store — needs every request from the same client to land on the same backend instance, or that state effectively disappears mid-session. stickysession (matched against a cookie or URL parameter, here ROUTEID) pairs each client with one specific route=-tagged member and keeps routing that client there. This is a real trade-off, not a free feature: it works against true load balancing, since a client's traffic no longer distributes freely once it's pinned. Backends that instead keep session state in a shared external store (e.g. Redis) don't need sticky sessions at all — the state is available to whichever member happens to handle the next request.

Hands-On Exercises