Reverse Proxying & Load Balancing Fundamentals

Web Servers Fundamentals

Chapter 6 · Reverse Proxying & Load Balancing Fundamentals

Chapter 1 described dynamic content as something a web server "hands off" to a separate application process. This chapter covers the actual mechanism behind that handoff — reverse proxying — kept deliberately foundational here, since Nginx In Depth is where this specific territory gets its own full treatment.

What a Reverse Proxy Actually Does

A reverse proxy is a server that sits in front of one or more backend servers, receives client requests on their behalf, forwards each request to a backend, and relays the backend's response back to the client — who never directly talks to the backend at all, and typically has no idea it exists. This is the opposite direction from a forward proxy, which represents a client (hiding the client from whatever server it's talking to) rather than representing a backend server to the outside world.

Apache as a Reverse Proxy

ProxyPass /app http://127.0.0.1:5000/
ProxyPassReverse /app http://127.0.0.1:5000/

Apache's mod_proxy module (with mod_proxy_http for HTTP backends) enables the ProxyPass/ProxyPassReverse directive pair: ProxyPass forwards matching requests to the backend, and ProxyPassReverse rewrites any redirect the backend sends back so it still points at the proxy's own address rather than leaking the backend's internal one.

Nginx as a Reverse Proxy

location /app/ {
    proxy_pass http://127.0.0.1:5000/;
}

Nginx's own proxy_pass directive is genuinely one of Nginx's single most common real-world uses — serving as the front door to a Node.js, Python, or Java application process is a large part of why Nginx shows up so often in modern deployments. This is exactly the territory Nginx In Depth exists to cover thoroughly.

IIS as a Reverse Proxy

IIS does not include reverse-proxy capability by default — it requires installing a separate module, Application Request Routing (ARR), alongside the URL Rewrite module it depends on. Once installed, ARR can forward requests to one or more backend servers, similar in spirit to Apache's or Nginx's own directives, but as an add-on rather than a built-in core capability — a genuine architectural difference worth noting, not just a naming difference.

Load Balancing Basics

Once more than one backend instance exists, a reverse proxy can also load balance — distributing requests across several backend instances rather than sending every request to just one. Round robin (cycling through each backend in turn) is the simplest algorithm and the default for all three: Apache's mod_proxy_balancer, Nginx's upstream {} block naming multiple backend addresses, and IIS ARR's own server-farm feature, which groups multiple backend servers together behind one routing rule.

	Apache	Nginx	IIS
Reverse proxy mechanism	`mod_proxy` + `ProxyPass`	`proxy_pass`	Application Request Routing (ARR)
Built in or add-on	Module, commonly enabled	Built in, core use case	Separate module install required
Load balancing	`mod_proxy_balancer`	`upstream {}` block	ARR server farms
Default algorithm	Round robin	Round robin	Round robin (weighted options available)

Where this shows up beyond a single server

Kubernetes' own Ingress controllers are very commonly built on top of exactly this mechanism — an Nginx (or similar) reverse proxy configured to route incoming cluster traffic to the right backend Pod, the same proxy_pass-style forwarding this chapter just introduced, just automated and driven by Kubernetes' own configuration instead of a hand-edited config file.

A reverse proxy isn't only for load balancing multiple servers

It's easy to assume reverse proxying only matters once there are several backend instances to distribute traffic across. In practice, a reverse proxy in front of a single backend is extremely common too — often purely to gain TLS termination (Chapter 7), response caching, or protocol translation (e.g. exposing a plain-HTTP Node.js app to the outside world over HTTPS, with the proxy handling the encryption layer the backend never has to know about). Load balancing is one reason to reverse-proxy, not the only one.

Hands-On Exercises

Exercise 1

Write the Nginx configuration (a location block) that reverse-proxies requests under /api/ to a backend application running on 127.0.0.1:3000.

📄 View solution

Exercise 2

A team runs a single Node.js application with no plans to run multiple instances of it. A teammate asks why they'd bother putting Nginx in front of it as a reverse proxy if there's nothing to load balance. Give an accurate answer using this chapter's own material.

📄 View solution

Exercise 3

Explain why IIS needing a separate module (ARR) for reverse proxying, while Apache and Nginx both support it as part of their normal module ecosystem or core functionality, is a genuine architectural difference rather than just a difference in terminology.

📄 View solution

Chapter 6 Quick Reference

A reverse proxy forwards client requests to a backend and relays the response back — the client never talks to the backend directly
Apache: ProxyPass/ProxyPassReverse. Nginx: proxy_pass — its own single most common real-world use case. IIS: Application Request Routing (ARR), a separate module install
Load balancing (round robin, by default on all three) distributes requests across multiple backend instances once more than one exists
Reverse proxying is just as often used for a single backend — TLS termination, caching, protocol translation — not only for load balancing several
This chapter is deliberately foundational — Nginx In Depth covers this territory in full