What Is a Reverse Proxy?

When you visit a website, you think you're talking to their server. You're probably not. You're talking to a reverse proxy—a server whose entire job is to pretend to be the real thing while actually forwarding your request somewhere else.

The client thinks it's talking to the real server. It isn't. That's the whole point.

The Deception That Enables Everything

A regular proxy (sometimes called a "forward proxy") acts on behalf of clients—like a VPN that fetches web pages for you so websites see the proxy's IP instead of yours. The proxy serves you.

A reverse proxy flips this relationship. It acts on behalf of servers. The "reverse" isn't about direction—it's about who the proxy serves. A forward proxy hides clients from servers. A reverse proxy hides servers from clients.

This deception enables everything that follows: load balancing, caching, security, SSL termination. All of these work because the client doesn't know—and doesn't need to know—what's happening behind the curtain.

What Happens When You Make a Request

Your browser sends a request to what it believes is the web server. The request arrives at the reverse proxy instead.

The reverse proxy examines your request—the URL path, headers, maybe the content—and decides which backend server should handle it. It forwards your request there, possibly modifying headers or adding authentication information.

The backend server processes the request and sends a response back to the reverse proxy. The proxy might cache that response, compress it, modify headers, or just pass it through. Then it sends the response to you, appearing as if it came directly from the origin server.

You never see the backend servers. You know only the reverse proxy's address. The actual application servers could move, multiply, or change entirely—you'd never know.

Why This Architecture Exists

Modern web applications aren't single servers. They're clusters of application servers, database servers, caching layers, and microservices. Someone needs to manage how clients connect to this complexity.

That someone is the reverse proxy. It provides:

A single entry point regardless of how many servers run behind it. Clients connect to one address. What happens after that is your business, not theirs.

Load distribution across multiple servers. Three application servers? The reverse proxy sends each request to whichever has capacity. One server fails? The proxy routes around it automatically.

Infrastructure flexibility. You can add servers, remove servers, move servers—clients never know. Their requests still go to the same address.

A security boundary. Backend servers don't need public IP addresses. Only the reverse proxy faces the Internet. This dramatically reduces attack surface.

Performance optimization. The proxy can cache responses, compress content, and terminate SSL—offloading work that would otherwise burden every backend server.

Load Balancing

With multiple backend servers, someone must decide which one handles each request. The reverse proxy makes this choice using various algorithms:

Round-robin sends requests to servers in rotation: first to server A, next to B, then C, back to A.

Least connections sends each request to whichever server currently has the fewest active connections.

Weighted distribution sends more requests to more powerful servers. If server A has twice the capacity of server B, it gets twice the traffic.

Consistent hashing ensures requests from the same client (or for the same resource) go to the same server. This matters when servers maintain state.

The result is horizontal scalability—need more capacity? Add more servers. The reverse proxy distributes load across them.

SSL Termination

HTTPS encryption is computationally expensive. Every encrypted connection requires cryptographic operations.

With SSL termination, the reverse proxy handles all HTTPS negotiation. Clients connect securely to the proxy. The proxy then communicates with backend servers over plain HTTP (or HTTPS if your security requirements demand internal encryption too).

This centralizes certificate management—one place to install and renew certificates instead of every backend server. It lets you use specialized hardware or software optimized for cryptographic operations. And it frees backend servers to focus on application logic instead of encryption.

Caching

When hundreds of users request the same resource, why generate it hundreds of times?

A reverse proxy can cache responses. The first request hits the backend server. Subsequent requests for the same resource get the cached response directly from the proxy—the backend server never sees them.

For static content—images, CSS, JavaScript—aggressive caching means backend servers only serve each file once. For dynamic content that tolerates some staleness, even short cache durations dramatically reduce backend load.

The proxy respects Cache-Control headers from backend servers, so your application controls what gets cached and for how long. When content changes, cache invalidation removes the stale response.

Security Functions

The reverse proxy is a bouncer. Every request goes through it, so it's the natural place to enforce security.

Backend protection: Your application servers don't need public IP addresses. They exist on a private network, accessible only through the proxy. Attackers can't reach what they can't address.

Request filtering: The proxy can inspect requests for SQL injection attempts, cross-site scripting, or other malicious patterns. Block them before they reach your application.

Rate limiting: Limit how many requests a client can make per second or minute. This prevents brute force attacks, resource exhaustion, and basic denial-of-service attempts.

Information hiding: Strip server version headers, sanitize error messages, remove any response data that reveals your backend architecture. Don't help attackers understand your system.

Centralized authentication: Authenticate users at the proxy before requests reach backend servers. Every service behind the proxy gets consistent authentication without implementing it themselves.

Health Checks and Failover

A load balancer is useless if it sends requests to dead servers. Reverse proxies monitor backend health.

Active health checks periodically probe each backend server—maybe a TCP connection attempt, maybe an HTTP request to a health endpoint. Servers that don't respond correctly get marked unhealthy.

Passive health checks monitor actual traffic. If a server starts returning errors or timing out, the proxy notices and stops sending it traffic.

When a backend server fails, the proxy routes around it automatically. Requests continue succeeding because they go to healthy servers. When the failed server recovers, it returns to the rotation. No manual intervention required.

Popular Solutions

Nginx dominates the reverse proxy landscape. Fast, efficient with concurrent connections, straightforward to configure. Most modern web applications use it.

HAProxy specializes in load balancing. Sophisticated algorithms, detailed health checking, excellent under high load. Choose it when distribution logic is your primary concern.

Traefik integrates with container orchestration. It automatically discovers services in Docker or Kubernetes and configures routing. Popular in microservices deployments.

Envoy powers service mesh architectures. High performance, advanced features like circuit breaking and detailed observability. The data plane proxy in many cloud-native systems.

Caddy offers automatic HTTPS with minimal configuration. Excellent for smaller deployments where simplicity matters most.

Reverse Proxy vs. Load Balancer

The terms overlap because most reverse proxies do load balancing and most load balancers do reverse proxying.

Conceptually: a load balancer focuses on distributing requests across servers. A reverse proxy focuses on being an intermediary that can modify requests and responses, cache content, handle SSL, and route based on URLs.

In practice, Nginx and HAProxy do both. The distinction matters when thinking about your system—are you primarily solving a distribution problem or an intermediary problem?—but the same software handles both.

Configuration Example

A basic Nginx reverse proxy configuration:

upstream backend_servers {
    server app1.internal:3000;
    server app2.internal:3000;
    server app3.internal:3000;
}

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;
    }

    location /static/ {
        proxy_pass http://backend_servers;
        proxy_cache my_cache;
        proxy_cache_valid 1h;
    }
}

Three backend servers. Load balanced automatically. Client IP forwarded in headers so backends know who's really asking. Static content cached for an hour.

In Microservices Architectures

When applications decompose into dozens of services, reverse proxies become even more critical.

API gateways are reverse proxies specialized for microservices. They route client requests to the right service, aggregate responses from multiple services, handle authentication, and implement rate limiting.

Service meshes deploy proxy sidecars alongside every service. Each service talks to its local proxy, which handles all network communication: service discovery, load balancing, encryption, retries, timeouts. The reverse proxy pattern applied to every service-to-service call.

The Invisible Infrastructure

Reverse proxies succeed by being invisible. When they work, you don't know they're there. Your request arrives, gets handled, and returns—the complexity of what happened in between stays hidden.

That invisibility is the point. The client doesn't need to know about your three application servers, your caching layer, your SSL certificates, or your health checks. The client just needs a response.

The reverse proxy makes that happen while giving you the flexibility to change everything behind it without changing anything the client sees.