How to Setup a Load-Balanced Apache Cluster (6 Step Quick-Start Guide)

This article details how to setup a load-balanced Apache cluster.

A load-balanced Apache cluster allows you to distribute incoming web traffic across multiple web servers, improving performance, scalability, redundancy, and availability. Instead of relying on a single Apache server, requests are intelligently distributed among multiple backend servers. If one server fails, traffic can automatically be redirected to healthy servers.

This guide demonstrates how to deploy a production-ready load-balanced Apache cluster using Apache HTTP Server‘s built-in reverse proxy and load balancing modules.

What You’ll Build

In this guide you’ll deploy:

                     Internet
                         │
                  Public IP Address
                         │
                +------------------+
                | Apache Load      |
                | Balancer         |
                | 192.168.1.10     |
                +--------+---------+
                         │
      -----------------------------------------
      │                  │                  │
+-------------+   +-------------+   +-------------+
| Apache Web  |   | Apache Web  |   | Apache Web  |
| Node 1      |   | Node 2      |   | Node 3      |
|192.168.1.21 |   |192.168.1.22 |   |192.168.1.23 |
+-------------+   +-------------+   +-------------+

The load balancer:

• Accepts all client traffic
• Terminates HTTPS (optional)
• Performs health checks
• Routes traffic
• Removes failed servers automatically

Backend nodes:

• Serve websites
• Remain private
• Never exposed directly to the Internet

Example Environment

Host	IP	Role
lb01	192.168.1.10	Apache Load Balancer
web01	192.168.1.21	Apache Web Server
web02	192.168.1.22	Apache Web Server
web03	192.168.1.23	Apache Web Server

Ubuntu 24.04 is used throughout this guide.

System Requirements

Load Balancer

• 2+ CPU cores
• 4 GB RAM
• SSD storage
• Public IP

Web Nodes

• 2+ CPU cores
• 2–4 GB RAM
• SSD
• Private network connectivity

---

Compare Ubuntu VPS Plans

---

How to Set Up a Load-Balanced Apache Cluster

To setup a load-balanced Apache cluster, follow the steps below:

1. Update All Servers

   On every server:

   sudo apt update
   sudo apt upgrade -y
   

2. Install Apache

   On every machine:

   sudo apt install apache2 -y
   

   Enable Apache:

   sudo systemctl enable apache2
   sudo systemctl start apache2
   

   Verify:

   systemctl status apache2
   

3. Configure Backend Servers

   Create a unique page on each backend.

   Node 1

   echo "<h1>Web Server 1</h1>" | sudo tee /var/www/html/index.html

   Node 2

   echo "<h1>Web Server 2</h1>" | sudo tee /var/www/html/index.html

   Node 3

   echo "<h1>Web Server 3</h1>" | sudo tee /var/www/html/index.html

4. Enable Required Apache Modules

   Only on the load balancer:

   sudo a2enmod proxy
   sudo a2enmod proxy_http
   sudo a2enmod proxy_balancer
   sudo a2enmod lbmethod_byrequests
   sudo a2enmod headers
   sudo a2enmod rewrite
   sudo a2enmod slotmem_shm
   sudo systemctl restart apache2
   

   Installed modules include:

   • mod_proxy
   • modproxyhttp
   • modproxybalancer
   • modlbmethodbyrequests
   • modslotmemshm

5. Create Load Balancer Virtual Host

   Create:

   /etc/apache2/sites-available/loadbalancer.conf
   

   Example:

   <VirtualHost *:80>
   
   ServerName www.example.com
   
   ProxyPreserveHost On
   
   <Proxy "balancer://mycluster">
   
   BalancerMember http://192.168.1.21
   
   BalancerMember http://192.168.1.22
   
   BalancerMember http://192.168.1.23
   
   ProxySet lbmethod=byrequests
   
   </Proxy>
   
   ProxyPass "/" "balancer://mycluster/"
   ProxyPassReverse "/" "balancer://mycluster/"
   
   </VirtualHost>
   

   Enable:

   sudo a2ensite loadbalancer.conf
   sudo systemctl reload apache2
   

6. Test

   Open:

   http://LoadBalancerIP
   

   Refresh repeatedly.

   You should see:

   Web Server 1
   

   then

   Web Server 2
   

   then

   Web Server 3
   

   depending on the balancing method.

Load Balancing Algorithms

Load-balanced Apache cluster supports several scheduling methods.

Round Robin (Default)

ProxySet lbmethod=byrequests

Requests are distributed evenly.

Least Connections

sudo a2enmod lbmethod_bybusyness

Then:

ProxySet lbmethod=bybusyness

Best for applications with long-running requests.

Weighted Distribution

BalancerMember http://192.168.1.21 loadfactor=5

BalancerMember http://192.168.1.22 loadfactor=2

BalancerMember http://192.168.1.23 loadfactor=1

Node 1 receives approximately 5 out of every 8 requests.

By Traffic

sudo a2enmod lbmethod_bytraffic

Balances based on bandwidth instead of request count.

Heartbeat Method

Ideal for geographically distributed clusters.

Sticky Sessions

Applications like WordPress admin, Magento, WHMCS, and some PHP frameworks require users to remain on the same backend server.

Enable:

ProxySet stickysession=ROUTEID

Backend example:

BalancerMember http://192.168.1.21 route=node1
BalancerMember http://192.168.1.22 route=node2
BalancerMember http://192.168.1.23 route=node3

Application cookie:

ROUTEID=node2

User remains on Node 2.

Health Checking

Apache can remove unhealthy nodes automatically.

Example:

BalancerMember http://192.168.1.21 retry=5

BalancerMember http://192.168.1.22 retry=5

BalancerMember http://192.168.1.23 retry=5

If a server fails:

• Requests stop
• Retry after five seconds
• Automatically rejoins cluster

Timeout Configuration

ProxyTimeout 30

Long-running PHP applications:

60-120 seconds

Enable Balancer Manager

Useful for monitoring.

<Location "/balancer-manager">

SetHandler balancer-manager

Require ip 192.168.1.0/24
</Location>

Access:

http://LoadBalancerIP/balancer-manager

View:

• Active servers
• Failed servers
• Current load
• Session routes

Restrict access to trusted IPs or protect it with authentication.

HTTPS Configuration

Install Certbot:

sudo apt install certbot python3-certbot-apache

Obtain certificate:

sudo certbot --apache

SSL terminates at the load balancer.

Backend servers may continue using HTTP over a trusted private network.

Forward Client IP

Without additional headers, backend servers only see the load balancer’s IP.

Enable:

RequestHeader set X-Forwarded-Proto "https"

RequestHeader set X-Forwarded-Port "443"

RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s

PHP:

echo $_SERVER['HTTP_X_FORWARDED_FOR'];

Applications can log the real visitor IP.

Logging

Separate logs:

ErrorLog ${APACHE_LOG_DIR}/cluster-error.log

CustomLog ${APACHE_LOG_DIR}/cluster-access.log combined

Firewall

Allow:

80
443

Only from Internet.

Backend servers should only accept traffic from the load balancer.

Example using UFW:

sudo ufw allow from 192.168.1.10 to any port 80 proto tcp
sudo ufw deny 80/tcp

Scaling the Cluster

Adding another node:

BalancerMember http://192.168.1.24

Reload:

sudo systemctl reload apache2

Done.

Shared Storage Considerations

For static websites, each node can have its own local copy of the files. Dynamic applications, however, require shared or synchronized content to keep all nodes consistent.

Popular options include:

• NFS
• GlusterFS
• CephFS
• DRBD
• Rsync (scheduled or event-driven)
• Object storage (Amazon S3, MinIO, etc.)

Database-backed applications should also use a centralized or replicated database service such as MariaDB Galera Cluster, MySQL InnoDB Cluster, or PostgreSQL with replication.

High Availability for the Load Balancer

The load balancer itself is a potential single point of failure. For production environments, deploy at least two load balancers.

Example:

           Virtual IP (VIP)
                 │
     --------------------------
     │                        │
+-----------+          +-----------+
| LB01      |          | LB02      |
| Apache     |          | Apache    |
| Keepalived |          | Keepalived|
+-----+------+          +-----+-----+
      │                       │
      -------------------------
                 │
      -------------------------
      │         │            │
   Web01     Web02       Web03

Use Keepalived with VRRP to maintain a floating virtual IP address. If the primary load balancer fails, the standby automatically assumes the VIP with minimal interruption. For even greater scalability, HAProxy or Envoy can also be deployed behind Keepalived, or DNS-based load balancing can distribute traffic across multiple load balancer pairs in different regions.

Monitoring

Recommended tools include:

• Prometheus + Grafana
• Zabbix
• Nagios
• Netdata
• Munin
• Apache mod_status
• Elastic Stack (ELK/OpenSearch) for centralized logging

Monitor:

• CPU utilization
• Memory usage
• Active connections
• Backend response times
• HTTP status codes
• SSL certificate expiration
• Apache worker utilization
• Network throughput

Performance Optimization

To maximize throughput and resilience:

• Enable HTTP/2 and TLS 1.3 on the load balancer.
• Enable mod_deflate or mod_brotli for compression.
• Use mod_cache or a CDN to reduce backend load for static assets.
• Configure KeepAlive On with appropriate KeepAliveTimeout and MaxKeepAliveRequests values.
• Tune the selected Multi-Processing Module (MPM), typically event for modern workloads.
• Offload static content (images, CSS, JavaScript, downloads) to object storage or a CDN where appropriate.
• Use connection pooling (ProxyPass options such as connectiontimeout, timeout, and keepalive) to reduce backend connection overhead.

Troubleshooting

Problem	Possible Cause	Solution
503 Service Unavailable	All backend servers unavailable	Verify Apache is running on each backend and that firewall rules allow the load balancer to connect.
Requests always hit the same server	Sticky sessions enabled or only one backend healthy	Check ProxySet stickysession configuration and backend health.
Clients see the load balancer IP	Missing forwarded headers	Configure X-Forwarded-For and ensure the application trusts proxy headers.
SSL certificate warnings	Certificate misconfiguration	Verify the certificate chain and ensure the correct virtual host is serving HTTPS.
Balancer Manager inaccessible	Access restrictions	Confirm Require directives or authentication settings permit your management IP.
Slow responses	Backend bottleneck or insufficient workers	Review Apache MPM settings, backend resource usage, and application performance.

Conclusion

You now know how to setup a load-balanced Apache cluster.

Apache’s built-in reverse proxy and load balancing capabilities provide a robust foundation for building scalable, fault-tolerant web infrastructure without requiring additional software. By combining multiple backend web servers with intelligent request distribution, sticky session support, health monitoring, and SSL termination, you can significantly improve application availability and performance.

For production deployments, consider enhancing this architecture with redundant load balancers using Keepalived, centralized session storage (such as Redis), shared or synchronized application files, replicated databases, comprehensive monitoring, and automated configuration management tools like Ansible or Terraform. Together, these components create a highly available Apache cluster capable of serving demanding enterprise workloads while remaining relatively simple to operate and expand.