CLOUD
Infrastructure

Load Balancing: How to Set It Up for Your Server

CLOUD|January 15, 2026|3 min read|582 views
Load Balancing: How to Set It Up for Your Server

Nginx as reverse proxy + upstream servers. Load balancing ensures stable performance even during peaks. We cover the complete setup.

What is Load Balancing?

Load balancing distributes incoming requests across multiple servers instead of a single one. The goal: no single server bears all the pressure, and if one server goes down, the service continues from the remaining servers.

When do you need load balancing?

  • Your site handles more than 1,000 concurrent visitors
  • You need high availability without downtime
  • Your application consumes heavy resources beyond a single server's capacity
  • You want to perform maintenance without service interruption

Basic Architecture

 ┌──────────────┐
 │ Client │
 └──────┬───────┘
 │
 ┌──────▼───────┐
 │ Load Balancer │
 │ (nginx) │
 └──────┬───────┘
 │
 ┌────────────┼────────────┐
 │ │ │
 ┌──────▼──┐ ┌──────▼──┐ ┌──────▼──┐
 │ Web 1 │ │ Web 2 │ │ Web 3 │
 │10.0.1.10│ │10.0.1.11│ │10.0.1.12│
 └─────────┘ └─────────┘ └─────────┘

Setting Up Load Balancing with nginx

Install nginx on the Load Balancer Server

sudo apt update
sudo apt install nginx -y

Basic Configuration (Round Robin)

# File: /etc/nginx/conf.d/load-balancer.conf

upstream backend_servers {
 server 10.0.1.10:80;
 server 10.0.1.11:80;
 server 10.0.1.12:80;
}

server {
 listen 80;
 server_name example.com;

 location / {
 proxy_pass http://backend_servers;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

Distribution Algorithms

# 1. Round Robin (default) — equal distribution
upstream backend {
 server 10.0.1.10;
 server 10.0.1.11;
 server 10.0.1.12;
}

# 2. Least Connections — sends to the server with fewest active connections
upstream backend {
 least_conn;
 server 10.0.1.10;
 server 10.0.1.11;
 server 10.0.1.12;
}

# 3. IP Hash — same client always goes to the same server
upstream backend {
 ip_hash;
 server 10.0.1.10;
 server 10.0.1.11;
 server 10.0.1.12;
}

# 4. Weighted — distribution based on server capacity
upstream backend {
 server 10.0.1.10 weight=5; # receives 5 requests
 server 10.0.1.11 weight=3; # receives 3 requests
 server 10.0.1.12 weight=2; # receives 2 requests
}

Health Checks

upstream backend_servers {
 server 10.0.1.10:80 max_fails=3 fail_timeout=30s;
 server 10.0.1.11:80 max_fails=3 fail_timeout=30s;
 server 10.0.1.12:80 max_fails=3 fail_timeout=30s;
}

# Backup server — activates only when all primary servers are down
upstream backend_servers {
 server 10.0.1.10:80;
 server 10.0.1.11:80;
 server 10.0.1.12:80;
 server 10.0.1.99:80 backup;
}

Session Persistence

A common problem: the user logs in on Server A, the next request goes to Server B, and the session is lost.

Solution 1: IP Hash

upstream backend {
 ip_hash;
 server 10.0.1.10;
 server 10.0.1.11;
}

Solution 2: Centralized Sessions (Redis)

# Install Redis on a dedicated server
sudo apt install redis-server -y

# In Laravel application — .env file
SESSION_DRIVER=redis
REDIS_HOST=10.0.1.50
REDIS_PORT=6379

This solution is superior — sessions are stored in one location accessible to all servers.

Adding SSL

server {
 listen 443 ssl;
 server_name example.com;

 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;

 location / {
 proxy_pass http://backend_servers;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 }
}

server {
 listen 80;
 server_name example.com;
 return 301 https://$host$request_uri;
}

Monitoring and Verification

# Verify configuration
sudo nginx -t

# Monitor connections
sudo nginx -T | grep upstream

# nginx status
curl -s http://localhost/nginx_status

Practical Implementation with CLOUD

With CLOUD (cloud.net.sa) servers, you can build a load-balanced architecture quickly. Order 3 VPS instances in Riyadh — one as a load balancer and two as application servers. Latency between servers within the same data center is under 1ms.

Start with two servers and add more as you grow. CLOUD allows upgrades at any time without reconfiguring the entire architecture.


Get Started

Ready to build your infrastructure? Configure your cloud server to your exact specs, or view hosting plans.

Share