Last modified: April 27, 2026
This article is written in: 🇺🇸
A reverse proxy is a server that receives incoming requests from external clients and forwards them to one or more internal servers. To the client, the reverse proxy looks like the application server. Behind the scenes, the proxy decides where the request should go.
Reverse proxies are common in modern backend architectures because they provide a single controlled entry point into a system. They can improve load balancing, security, caching, SSL/TLS handling, compression, observability, and routing.
Instead of exposing every backend server directly to the internet, teams place a reverse proxy in front of them. This hides internal server details and allows traffic to be managed centrally.
Reverse Proxy in Action
+----------------------+
| Internet |
+---------+------------+
|
Incoming Requests
v
+------+------+
| Reverse |
| Proxy |
+------+------+
|
Traffic routed to appropriate server
+------+--------+--------+------+
| | | | |
v v v v v
+--------------+ +--------------+ +--------------+
| Web Server 1 | | Web Server 2 | | Web Server 3 |
+--------------+ +--------------+ +--------------+Example request to the reverse proxy:
GET /dashboard HTTP/1.1
Host: app.example.comExample backend routing result:
{
"clientRequested": "app.example.com/dashboard",
"reverseProxyRoutedTo": "web-server-2:3000",
"status": "success"
}The client does not need to know that web-server-2 handled the request. It only communicates with app.example.com.
Forward proxies and reverse proxies both sit between two network participants, but they serve different sides of the connection.
A forward proxy acts on behalf of clients. It is often used by organizations to filter outbound traffic, cache external resources, or hide client identity from the internet.
A reverse proxy acts on behalf of servers. It receives inbound traffic from the internet and forwards it to internal application servers.
| Forward Proxy | Reverse Proxy |
| Sits between clients and the internet. | Sits between external users and internal servers. |
| Primarily used for client anonymity, outbound caching, or content filtering. | Primarily used for load balancing, security, caching, and inbound traffic control. |
| Often used to apply organizational policies or route outbound traffic. | Often used to protect internal servers, improve performance, and handle SSL offloading. |
Example forward proxy flow:
Employee Laptop → Corporate Proxy → Internet WebsiteExample reverse proxy flow:
Internet User → Reverse Proxy → Internal App ServerExample output:
{
"forwardProxyProtects": "client side",
"reverseProxyProtects": "server side"
}The key difference is who the proxy represents. A forward proxy represents the client. A reverse proxy represents the server infrastructure.
A reverse proxy receives client requests, applies routing or policy rules, forwards the request to a backend server, receives the backend response, and returns that response to the client.
The backend server usually sees the reverse proxy as the immediate network peer. The client usually sees only the reverse proxy.
Basic flow:
GET /index.html, to the reverse proxy’s public domain or IP address.Client -> Reverse Proxy -> Web Server -> Reverse Proxy -> ClientExample routing rule:
/api/* -> api-service:3000
/static/* -> static-server:8080
/admin/* -> admin-service:4000Example output:
{
"requestPath": "/api/users",
"selectedBackend": "api-service:3000",
"proxyAction": "forwarded"
}This allows one public domain to route different paths to different internal services.
Reverse proxies are useful because they sit at a strategic point in the request path. Since all inbound traffic passes through them, they can apply performance, security, and routing policies before requests reach backend servers.
Load balancing distributes incoming requests across multiple backend servers. This prevents one server from receiving all traffic while others sit idle.
A reverse proxy can choose a backend using strategies such as round-robin, least connections, random selection, weighted routing, or consistent hashing. It can also remove unhealthy servers from rotation.
Example backend pool:
Backend servers:
- web-1: healthy
- web-2: healthy
- web-3: unhealthyExample output:
{
"request": "/api/products",
"selectedBackend": "web-2",
"excludedBackends": ["web-3"],
"reason": "health check failed"
}This improves availability. If one backend fails, the reverse proxy can continue sending traffic to healthy instances.
Reverse proxies can improve performance by caching, compressing, and optimizing responses before they reach the client.
Caching stores frequently requested responses at the proxy. If many users request the same static file or public page, the proxy can serve it directly without contacting the backend.
Example cached response:
HTTP/1.1 200 OK
Content-Type: text/css
X-Cache: HIT
body {
font-family: Arial;
}Compression reduces payload size, lowering bandwidth usage and improving load time.
Example compression header:
Content-Encoding: brSSL/TLS termination lets the proxy handle HTTPS encryption and decryption. This centralizes certificate management and can reduce work on backend servers.
Example output:
{
"tlsTerminatedAt": "reverse-proxy",
"backendConnection": "http://api-service:3000",
"compression": "brotli",
"cache": "enabled"
}A reverse proxy can hide the internal network structure from external users. Attackers see only the proxy address, not the private IPs of backend servers.
It can also enforce security policies before traffic reaches application code. These policies may include IP blocking, rate limiting, request size limits, WAF rules, bot detection, header validation, and TLS enforcement.
Example blocked request:
{
"clientIp": "203.0.113.50",
"path": "/login",
"action": "blocked",
"reason": "too many failed requests"
}Reverse proxies also centralize logs. Since all requests pass through the proxy, teams can capture request IDs, latency, status codes, client IPs, user agents, and routing decisions in one place.
Example access log:
{
"requestId": "req-123",
"clientIp": "198.51.100.20",
"method": "GET",
"path": "/api/orders",
"status": 200,
"upstream": "orders-service:3000",
"durationMs": 42
}This observability helps teams debug errors, trace traffic, and monitor service health.
Reverse proxies often handle SSL/TLS termination. This means the client connects to the proxy over HTTPS, and the proxy forwards the request to the backend using HTTP or HTTPS.
Centralized TLS termination simplifies certificate renewal and configuration. Instead of installing certificates on every backend service, teams can manage them at the proxy layer.
Example HTTPS request:
GET /profile HTTP/1.1
Host: app.example.com
Protocol: HTTPSExample proxy behavior:
{
"clientToProxy": "HTTPS",
"proxyToBackend": "HTTP",
"certificateManagedAt": "reverse-proxy"
}In higher-security environments, the proxy-to-backend connection may also use HTTPS or mutual TLS.
Example stricter setup:
{
"clientToProxy": "HTTPS",
"proxyToBackend": "mTLS",
"backendAuthentication": "required"
}SSL offloading can improve operational simplicity, but teams must ensure internal network traffic is protected according to the sensitivity of the system.
Without extra headers, the backend usually sees the reverse proxy as the immediate client. This is useful for network isolation, but application code may still need the original client IP, public host, or original protocol.
Reverse proxies commonly add forwarding headers to preserve this metadata.
X-Forwarded-For carries the original client IP chain.X-Forwarded-Proto indicates whether the original request used HTTP or HTTPS.X-Forwarded-Host preserves the public hostname the client used.Forwarded is the standardized alternative to the X-Forwarded-* headers.Example proxied request:
GET /profile HTTP/1.1
Host: internal-app:3000
X-Forwarded-For: 198.51.100.20, 10.0.0.5
X-Forwarded-Proto: https
X-Forwarded-Host: app.example.comExample backend interpretation:
{
"originalClientIp": "198.51.100.20",
"originalProtocol": "https",
"originalHost": "app.example.com"
}Backends should trust these headers only when the request comes from known proxies or load balancers. If the backend accepts these headers from any client, attackers can spoof IP addresses or protocols.
Example spoofing risk:
X-Forwarded-For: 127.0.0.1Example safe policy:
{
"trustForwardedHeadersOnlyFrom": ["10.0.0.5", "10.0.0.6"],
"publicClientsCannotSetTrustedForwardedHeaders": true
}Nginx is commonly used as a reverse proxy. The following configuration listens on HTTPS, terminates TLS, forwards requests to an internal service, and preserves useful request metadata.
server {
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/ssl/certs/app.crt;
ssl_certificate_key /etc/ssl/private/app.key;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 60s;
}
}Example request:
GET /api/status HTTP/1.1
Host: app.example.comExample backend response:
{
"status": "ok",
"service": "node-api"
}Example proxy access log:
198.51.100.20 - GET /api/status 200 upstream=127.0.0.1:3000 time=12msThis setup terminates TLS at the proxy, forwards requests to an internal service, and preserves metadata that the backend may need for redirects, logging, and audit trails.
Running a reverse proxy in production requires careful attention to health checks, retries, timeouts, caching, long-lived connections, and high availability.
Reverse proxies often check whether backend servers are healthy. If a backend fails, the proxy stops sending traffic to it.
Example health check output:
{
"backend": "api-3",
"health": "unhealthy",
"action": "removed_from_rotation"
}Timeouts prevent requests from waiting forever. Retries can reduce user-facing failures, but they must be used carefully. Retrying unsafe operations such as non-idempotent POST requests can accidentally create duplicate orders, payments, or records.
Example retry policy:
{
"retryOn": ["connection_error", "timeout"],
"retryMethods": ["GET", "HEAD"],
"avoidRetryMethods": ["POST", "PATCH", "DELETE"]
}A reverse proxy can cache static or slowly changing responses. This reduces latency and protects backends during traffic spikes.
Example cache result:
{
"path": "/assets/app.js",
"cacheStatus": "HIT",
"originContacted": false
}WebSockets and streaming responses require explicit proxy configuration. Otherwise, the proxy may close long-lived connections too early.
Example WebSocket routing output:
{
"path": "/socket",
"upgrade": "websocket",
"connection": "upgraded",
"timeoutPolicy": "long-lived"
}Because the reverse proxy is a critical entry point, production systems should not rely on only one proxy instance. Teams often run multiple proxy instances behind DNS failover, anycast, cloud load balancers, or another high-availability layer.
Example HA output:
{
"reverseProxyInstances": 3,
"failover": "enabled",
"singlePointOfFailure": false
}Reverse proxies can be software-based, hardware-based, or cloud-based. The right option depends on scale, budget, operational model, performance needs, and team expertise.
Software reverse proxies are installed and configured on general-purpose servers or containers.
Examples include:
Characteristics:
Example output:
{
"type": "software_reverse_proxy",
"example": "Nginx",
"strength": "flexible and widely used"
}Hardware reverse proxies are dedicated appliances from vendors such as F5, Citrix, or Cisco. They are often used in enterprise data centers.
Characteristics:
Example output:
{
"type": "hardware_reverse_proxy",
"bestFor": "enterprise data centers with specialized performance or support requirements"
}Cloud-based reverse proxies are managed services that sit in front of applications. They often combine load balancing, TLS termination, CDN caching, DDoS protection, WAF features, and global routing.
Examples include:
Characteristics:
Example output:
{
"type": "cloud_reverse_proxy",
"features": ["global edge routing", "TLS termination", "DDoS protection", "caching"],
"maintenance": "managed by provider"
}Reverse proxies can improve security, but they also become highly sensitive infrastructure. If the proxy is misconfigured, unavailable, or compromised, the entire application may be affected.
Reverse proxies reduce direct exposure of backend servers. External clients connect to the proxy, while internal servers can remain on private networks.
Security benefits include:
Example WAF block:
{
"action": "blocked",
"reason": "SQL injection pattern detected",
"path": "/search",
"clientIp": "203.0.113.50"
}Reverse proxies also introduce risks.
X-Forwarded-* headers.Example cache misconfiguration risk:
{
"path": "/account",
"problem": "private user page cached publicly",
"impact": "one user may receive another user's data"
}Careful configuration, testing, and monitoring are required to prevent these issues.
Reverse proxies work best as part of a layered security system. They should be combined with firewalls, WAFs, intrusion prevention, identity-aware access controls, logging, and regular patching.
Examples:
Example layered security output:
{
"firewall": "enabled",
"waf": "enabled",
"reverseProxy": "nginx",
"tls": "enforced",
"logs": "centralized",
"patching": "scheduled"
}A reverse proxy is not a complete security solution by itself, but it is an important control point. When configured well, it improves performance, protects backend servers, and gives teams a powerful place to manage inbound traffic.