If you ask ten engineers the difference between a Load Balancer, a Reverse Proxy, and an API Gateway, you’ll get ten different answers.

Some say they are the same thing. Others say they live at different OSI layers.

Technically, they all do “Request Forwarding,” but their intent is completely different.

This is the Mastery Guide to the “Traffic Trio”. We’ll start with a clean mental model, then dive into the headers, the error codes (502 vs 504), and the actual Nginx configurations you need to build them.

Part 1: Foundations (The Mental Model)

The One Diagram to Remember

Think of these three as layers of a funnel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

OUTSIDE WORLD (The Internet)
      │
      ▼
TRAFFIC DISTRIBUTION (Layer 4/7)
   Load Balancer
      │
      ▼
SECURITY & OPTIMIZATION (Layer 7)
   Reverse Proxy
      │
      ▼
ORCHESTRATION & LOGIC (Layer 7)
   API Gateway
      │
      ▼
INTERNAL SERVICES (Your Apps)

The Grand Hotel Analogy

Imagine a massive, luxury hotel.

• Load Balancer = The Traffic Cop (Outside) The cop stands at the driveway. There are three different entrances to the hotel. He just points cars to the entrance that is least crowded. He doesn’t care who you are; he just wants the driveway clear.

  • Goal: Availability. Stop one server from crashing.

• Reverse Proxy = The Receptionist (At the Door) Once you walk in, the receptionist checks your ID (SSL Termination), takes your coat (Compression), and gives you a map (Caching). They protect the “inner” staff from dealing with basic questions.

  • Goal: Efficiency & Anonymity. Hide the backend servers.

• API Gateway = The Concierge (The Expert) The concierge is the smartest person there. If you say, “I want a steak dinner, a massage, and a taxi,” they personally call the Chef, the Masseur, and the Valet for you. They orchestrate your needs and answer you with a single confirmation.

  • Goal: Complexity Management. Handle Auth, Rate Limiting, and Routing.

Part 2: The Investigation (Debug Like a Pro)

When you introduce a middleman (proxy), you break the direct connection between Client and Server. This creates a debugging nightmare if you don’t know your Headers.

1. The Lost IP Address (X-Forwarded-For)

When a user connects to your App through a Load Balancer, your App sees the Load Balancer’s IP as the source, not the User’s.

• Problem: You ban an abusive IP, but you accidentally ban your own Load Balancer (taking down the whole site).
• Fix: Look at the X-Forwarded-For header.

1

X-Forwarded-For: <Client IP>, <Proxy 1 IP>, <Proxy 2 IP>

• The Golden Rule: The first IP in the list is the real user. The last IP is the proxy closest to you.

2. The Trace (X-Request-ID)

In a microservices world, one request might jump through 5 different services. If it fails, how do you find it in the logs?

You must tag every request with a unique ID at the exact moment it enters your system (at the Gateway).

1

X-Request-ID: 123e4567-e89b-12d3-a456-426614174000

Usage:

1. Gateway generates UUID.
2. Service A logs it and passes it to Service B.
3. Service B fails.
4. You grep your generic log aggregator (Splunk/Datadog) for that UUID and see the entire story.

Part 3: The Diagnosis (Error Codes Decoded)

When the “Hotel” is on fire, the error code tells you exactly where the fire is.

502 Bad Gateway vs. 504 Gateway Timeout

These are the two most common errors, and people always confuse them.

Pro Tip: If you see a 502, check if your process is running (ps aux). If you see a 504, check your database locks or slow queries.

Part 4: The Resolution (Nginx Cookbook)

Can one tool do all three? Yes. Nginx is the Swiss Army Knife. But the config determines the role.

Scenario 1: The Load Balancer

Simple Round-Robin distribution.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

upstream backend_servers {
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.3;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

Scenario 2: The Reverse Proxy

Adding SSL Termination and headers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

server {
    listen 443 ssl;
    server_name api.mysite.com;

    # SSL Config (The "Receptionist" checking ID)
    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/key.pem;

    location / {
        # Passing the true identity (The "Lost IP" fix)
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_set_header Host            $host;
        
        proxy_pass http://localhost:8000;
    }
}

Scenario 3: The API Gateway

Adding Rate Limiting and specialized routing.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Define Rate Limit: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    listen 443 ssl;
    
    # 1. Auth Service
    location /auth {
        proxy_pass http://auth-service:3000;
    }

    # 2. Payment Service (Protected)
    location /payments {
        # Enforce Rate Limit
        limit_req zone=api_limit burst=5;
        
        # Verify Token (Nginx Plus or Lua script usually needed here for full JWT)
        auth_request /auth/verify; 
        
        proxy_pass http://payment-service:4000;
    }
}

Final Mental Model

1
2
3
4
5
6
7

Distribute Traffic -> Load Balancer (Availability)
Hide & Protect     -> Reverse Proxy (Security)
Routing & Logic    -> API Gateway (Orchestration)

502 = App is Dead
504 = App is Slow
X-Forwarded-For = The Real User IP

Don’t just implement tools. Understand the intent of the traffic flow, and you’ll know exactly which tool (and config) to pull from your belt.