Introduction

A production application can contain several web servers, API instances, administration services, media services, and internal application components.

Allowing clients to connect directly to every backend creates several problems:

• Clients need to know several internal addresses and ports
• Backend servers become directly exposed
• Every backend must manage public TLS certificates
• Routing rules become part of client configuration
• Backend replacement can affect public URLs
• Security and request limits can become inconsistent
• Traffic cannot be distributed centrally

A reverse proxy solves these problems by sitting between clients and backend servers.

Client
   |
   v
Reverse Proxy
   |
   +-- Web Server
   +-- API Server
   +-- Administration Server
   +-- Media Service

The client communicates with the reverse proxy rather than connecting directly to the selected backend.

Prerequisites

What Is a Proxy?

A proxy is an intermediary that communicates with one system on behalf of another.

Direct communication:

Client
   |
   v
Server


Communication through a proxy:

Client
   |
   v
Proxy
   |
   v
Server

The proxy receives traffic, applies its configured behaviour, communicates with the destination, and relays the result.

Forward Proxy vs Reverse Proxy

Basic Reverse-proxy Flow

1. The client resolves the public hostname.

2. The client connects to the reverse proxy.

3. For HTTPS, the configured TLS handshake occurs.

4. The proxy reads the information required for routing.

5. The proxy selects a healthy backend.

6. The proxy forwards the request.

7. The backend processes the request.

8. The backend returns a response to the proxy.

9. The proxy returns the response to the client.

The client can continue using one stable public hostname even when internal backend addresses, ports, instance counts, or deployments change.

Example Architecture

                         Internet
                            |
                            v
                  +-------------------+
                  |  Reverse Proxy    |
                  |  Public endpoint  |
                  +-------------------+
                     |       |       |
          +----------+       |       +----------+
          |                  |                  |
          v                  v                  v

   +-------------+     +-------------+    +-------------+
   | Web Service |     | API Service |    | Admin       |
   | /           |     | /api        |    | /admin      |
   +-------------+     +-------------+    +-------------+

Internal services can use private addresses that are not advertised directly to public clients.

Main Responsibilities

A reverse proxy can provide:

• One public entry point
• Backend address abstraction
• Hostname-based routing
• Path-based routing
• Load balancing
• Backend health handling
• TLS termination
• Backend TLS connections
• Forwarding-header management
• Connection pooling and reuse
• Timeout enforcement
• Request-size limits
• Rate limiting where supported
• Response caching where supported
• Compression where supported
• Centralized access logging

Exact capabilities depend on the selected reverse proxy or managed application-delivery platform.

Host-based Routing

Host-based routing selects a backend according to the requested hostname.

www.example.com
    -> Website service


api.example.com
    -> API service


admin.example.com
    -> Administration service

Conceptual NGINX Configuration

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

    location / {
        proxy_pass http://api_backend;
    }
}

server {
    listen 443 ssl;
    server_name www.example.com;

    location / {
        proxy_pass http://web_backend;
    }
}

The proxy can expose several applications on the same public infrastructure while routing each hostname to a separate backend pool.

Path-based Routing

Path-based routing selects a backend according to the URL path.

www.example.com/
    -> Website service


www.example.com/api/
    -> API service


www.example.com/media/
    -> Media service


www.example.com/admin/
    -> Administration service

Conceptual Configuration

server {
    listen 443 ssl;
    server_name www.example.com;

    location /api/ {
        proxy_pass http://api_backend;
    }

    location /media/ {
        proxy_pass http://media_backend;
    }

    location /admin/ {
        proxy_pass http://admin_backend;
    }

    location / {
        proxy_pass http://web_backend;
    }
}

Reverse Proxy as a Load Balancer

A reverse proxy can distribute requests across several instances of the same service.

Client requests
      |
      v
Reverse Proxy
      |
      +-- API Instance 1
      +-- API Instance 2
      +-- API Instance 3

Upstream Pool Example

upstream api_backend {
    least_conn;

    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

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

    location / {
        proxy_pass http://api_backend;
    }
}

Backend selection can use round robin, weights, least connections, hash-based affinity, or another supported algorithm.

Reverse Proxy vs Load Balancer

The terms overlap. Evaluate the actual listener, protocol, routing, forwarding, TLS, health, retry, and policy features instead of relying only on the product label.

Backend Health Checks

A reverse proxy should avoid routing new requests to an instance that cannot serve them correctly.

Reverse Proxy
      |
      v
GET /health/ready
      |
      +-- Successful response:
      |      backend remains eligible
      |
      +-- Repeated failure:
             backend removed
             from active routing

Example Readiness Response

{
  "status": "ready"
}

Readiness is different from liveness. A process can be alive while still loading configuration, warming caches, or waiting for a required dependency.

TLS Termination

A reverse proxy can terminate the public TLS connection.

Client
    |
    | HTTPS
    v
Reverse Proxy
    |
    | HTTP or new HTTPS connection
    v
Backend

Central TLS termination can provide:

• Central certificate management
• One location for public TLS policy
• Reduced certificate configuration on individual backends
• Application-aware request inspection
• Centralized protocol negotiation

Backend traffic should be re-encrypted when required by the trust boundary and security policy.

Connection Abstraction

The client-side and backend-side connections are independent.

Client-side connection:

Client
  -> Reverse Proxy


Backend-side connection:

Reverse Proxy
  -> Application Server

This allows the proxy to use different connection lifetimes and, where supported, different HTTP versions on each side.

The proxy can reuse backend connections instead of establishing a new backend connection for every client request.

Forwarding Headers

The backend connection originates from the proxy. The proxy can therefore add approved headers describing the original request.

X-Forwarded-For: original-client-address
X-Forwarded-Proto: https
X-Forwarded-Host: www.example.com
X-Request-ID: request-correlation-id

Applications commonly use this information for URL generation, logging, redirects, auditing, and tracing.

Trusted Proxy Boundary

Public clients can attempt to send forged forwarding headers.

Application trusts every
X-Forwarded-For value
received from any client.

Application accepts trusted
forwarding information only when
the connection came through an
approved reverse proxy.

The proxy should replace, sanitize, or append forwarding information according to a documented trust model.

URL Rewriting

A reverse proxy can expose one external URL structure while forwarding a different internal path.

Public request:

/api/courses/42


Internal request:

/v1/internal/course-service/courses/42

Rewriting decouples public URLs from internal service locations, but complex rules can create broken redirects, unexpected paths, and difficult troubleshooting.

Redirect vs Rewrite

Reverse-proxy Caching

A reverse proxy can cache selected responses and serve later requests without contacting the application backend.

Client request
      |
      v
Reverse-proxy cache
      |
      +-- Cache hit:
      |      return response
      |
      +-- Cache miss:
             request backend
             store eligible response
             return response

Caching can reduce:

• Backend request volume
• Database query volume
• Response time for repeatable content
• Network traffic to origin services

Cache keys and rules must account for hostname, path, query parameters, authorization, content negotiation, tenant scope, and other response-varying inputs.

Private-content Caching

A shared cache must not return one user's or tenant's private response to another caller.

Cache key:

/api/profile


Problem:

All users share one cache entry.

Do not shared-cache private content,
or include every approved isolation
dimension required by the response.

Cache-stampede Protection

When a popular cached response expires, many simultaneous requests can reach the backend.

Popular cache entry expires
      |
      v
1,000 simultaneous cache misses
      |
      v
1,000 backend requests
      |
      v
Backend overload

Request coalescing, controlled stale serving, background refresh, and expiration jitter can reduce this risk when supported and appropriate.

Compression

A reverse proxy can compress eligible responses before sending them to clients.

Backend response
      |
      v
Reverse proxy
      |
      v
Check client encoding support
      |
      v
Compress eligible content
      |
      v
Return response

Avoid recompressing already compressed media such as common image, video, and archive formats. Compression consumes CPU and should be measured.

Rate Limiting

A reverse proxy can apply request limits before traffic reaches backend services.

Incoming request
      |
      v
Determine trusted limit key
      |
      v
Check quota or request rate
      |
      +-- Allowed:
      |      forward request
      |
      +-- Exceeded:
             reject or delay
             according to policy

Limits can be scoped by trusted tenant, authenticated caller, endpoint, client network identity, or another approved dimension.

Rate limiting protects capacity but does not replace backend authorization or business-level quota enforcement.

Timeout Configuration

A reverse proxy needs explicit timeout policies.

Proxy timeouts should fit inside the complete request deadline and align with client and backend behaviour.

Proxy Retries

A reverse proxy can retry selected requests after certain backend failures.

Request sent to Backend A
      |
      v
Backend connection fails
      |
      v
Proxy checks retry policy
      |
      +-- Retry is safe:
      |      send to Backend B
      |
      +-- Retry is unsafe:
             return failure

The proxy cannot always know whether a failed backend already performed the requested action.

POST /api/enrollments HTTP/1.1
Idempotency-Key: unique-operation-key

Automatic retries must consider operation idempotency, retry count, consumed request body, failure stage, and total deadline.

Uploads and Request Buffering

A reverse proxy can buffer or stream request bodies depending on its configuration.

Buffered Request

Client uploads body
      |
      v
Proxy buffers body
      |
      v
Proxy forwards body
to backend

Streamed Request

Client sends body
      |
      v
Proxy forwards body progressively
      |
      v
Backend processes stream

Review:

• Maximum request size
• Header limits
• Upload duration
• Temporary storage
• Proxy memory usage
• Backend streaming capability
• Client cancellation
• Direct multipart upload to object storage

WebSockets and Streaming

Long-lived connections require proxy support and appropriate timeout and draining policies.

Client
    |
    | Long-lived connection
    v
Reverse Proxy
    |
    v
Backend Instance A

Monitor:

• Concurrent connections
• Connection duration
• Messages and bytes per connection
• Idle timeouts
• Backend connection limits
• Reconnection behaviour
• Deployment and scale-in drain time

Session Affinity

A reverse proxy can route related requests to the same backend using an affinity mechanism.

User A
    -> Backend 1
    -> Backend 1
    -> Backend 1


User B
    -> Backend 2
    -> Backend 2
    -> Backend 2

Affinity can help legacy applications with local session state, but it can cause uneven load and does not preserve session data after backend failure.

Externalized session state is generally more compatible with elastic horizontal scaling.

Connection Draining

Backends should be drained before deployment, maintenance, or scale-in.

Backend selected for removal
      |
      v
Mark backend not ready
      |
      v
Stop new requests
      |
      v
Finish permitted in-flight work
      |
      v
Close remaining connections
according to policy
      |
      v
Terminate backend

Uploads, streams, WebSockets, and long-running operations can require longer or application-specific draining.

Security Benefits

A reverse proxy can:

• Hide private backend addresses from public clients
• Centralize public TLS policy
• Restrict accepted request methods and sizes
• Integrate with a web application firewall where supported
• Apply request-rate controls
• Normalize selected headers
• Centralize access logs
• Reduce direct public exposure of application servers

A reverse proxy does not make an insecure backend secure automatically. Backend services must continue validating input, authenticating callers, enforcing authorization, and protecting data.

Common Security Risks

• Trusting forged forwarding headers
• Exposing an unintended administration route
• Using an open forward-proxy configuration
• Allowing unrestricted request sizes
• Publishing internal error details
• Keeping weak or expired TLS configuration
• Forwarding unvalidated identity headers
• Allowing direct backend access that bypasses the proxy
• Misconfiguring caching for private content
• Logging credentials or sensitive request bodies

Preventing Proxy Bypass

Public clients
      |
      v
Approved reverse proxy
      |
      v
Private application network


Network rule:

Application backends accept traffic
only from approved internal sources.

If backends remain publicly reachable, an attacker might bypass TLS policy, request limits, routing restrictions, header controls, or security inspection applied at the proxy.

Reverse-proxy Chain

A request can pass through several intermediaries.

Client
   |
   v
CDN or edge proxy
   |
   v
Public load balancer
   |
   v
Ingress or reverse proxy
   |
   v
Application service

Every hop must have a documented trust boundary, timeout budget, forwarding policy, logging responsibility, and failure behaviour.

End-to-end Deadline

Client deadline
      |
      +-- DNS and connection setup
      +-- TLS handshake
      +-- Edge processing
      +-- Reverse-proxy processing
      +-- Backend connection
      +-- Application processing
      +-- Database or dependency calls
      +-- Response transfer

A proxy timeout should not exceed the useful lifetime of the client request. Layered retries and long independent timeouts can consume resources after the caller has already stopped waiting.

Kubernetes Ingress

In Kubernetes, an Ingress controller commonly performs reverse-proxy and L7 routing responsibilities.

Internet
   |
   v
External Load Balancer
   |
   v
Ingress Controller
   |
   +-- /api -> api-service
   |
   +-- /web -> web-service
              |
              v
             Pods

Conceptual Ingress Configuration

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: learning-platform
spec:
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 3000

Exact TLS, timeout, rewrite, annotation, and health behaviour depends on the selected Ingress controller and platform.

Managed Reverse Proxies

Cloud application load balancers, application gateways, API gateways, and managed ingress services can provide reverse-proxy capabilities.

Evaluate:

• Supported protocols
• Hostname and path routing
• TLS certificate integration
• Backend health checks
• Request and response limits
• Connection and idle timeouts
• WebSocket and streaming support
• Autoscaling and capacity limits
• Logging and metrics
• Web application firewall integration
• Regional and multi-region availability
• Cost

PHP Trusted-proxy Example

<?php

declare(strict_types=1);

function getRequestScheme(
    array $server,
    array $trustedProxyAddresses
): string {
    $remoteAddress =
        (string)($server['REMOTE_ADDR'] ?? '');

    $isTrustedProxy =
        in_array(
            $remoteAddress,
            $trustedProxyAddresses,
            true
        );

    if ($isTrustedProxy) {
        $forwardedScheme =
            strtolower(
                trim(
                    (string)(
                        $server['HTTP_X_FORWARDED_PROTO']
                        ?? ''
                    )
                )
            );

        if (in_array(
            $forwardedScheme,
            ['http', 'https'],
            true
        )) {
            return $forwardedScheme;
        }
    }

    $httpsValue =
        strtolower(
            (string)($server['HTTPS'] ?? '')
        );

    return $httpsValue !== '' &&
        $httpsValue !== 'off'
            ? 'https'
            : 'http';
}

Production frameworks usually provide trusted-proxy configuration. Prefer the framework's tested mechanism and configure the exact trusted network boundary rather than implementing ad hoc header handling.

Access Logging

A reverse proxy can record a consistent entry for incoming requests.

{
  "requestId": "request-correlation-id",
  "host": "www.example.com",
  "method": "GET",
  "path": "/api/courses/42",
  "status": 200,
  "backend": "api-instance-2",
  "requestDurationMs": 48,
  "backendDurationMs": 41
}

Avoid logging access tokens, passwords, session cookies, private query values, or complete sensitive request bodies.

Proxy Performance

Measure:

• Requests per second
• New connections per second
• Concurrent connections
• Bytes processed
• TLS handshake rate
• Proxy processing time
• Backend response time
• Cache hit rate
• Retry rate
• Timeout rate
• Request and response size
• CPU, memory, network, and temporary-storage utilization

The reverse proxy has finite capacity and should be load-tested with realistic TLS, routing rules, connection reuse, uploads, and long-lived connections.

High Availability

A reverse proxy must not become an unprotected single failure point.

Clients
   |
   v
One Reverse Proxy
   |
   v
Many healthy backends

Clients
   |
   v
Highly available entry point
   |
   +-- Reverse Proxy 1
   +-- Reverse Proxy 2
   +-- Reverse Proxy 3
              |
              v
        Backend services

Configuration distribution, certificate availability, health checking, and capacity should remain reliable across the reverse-proxy tier.

Configuration Deployment

Prepare new configuration
      |
      v
Validate syntax and references
      |
      v
Test routing and TLS
      |
      v
Deploy gradually
      |
      v
Observe errors and latency
      |
      +-- Healthy:
      |      complete rollout
      |
      +-- Unhealthy:
             roll back safely

A malformed proxy configuration can affect every application behind the shared entry point.

Observability

Useful reverse-proxy metrics include:

• Frontend request and connection rate
• Healthy backend count
• Requests by hostname and route
• Traffic distribution by backend
• Proxy and backend latency
• Response-status distribution
• TLS handshake failures
• Backend connection errors
• Timeouts and retries
• Active and idle connections
• Rejected requests
• Request-body size
• Cache hits, misses, and evictions
• Connection-draining duration
• CPU, memory, network, and temporary-storage usage

Alert Conditions

Alert when:

• The healthy backend count falls below the required minimum
• Proxy or backend latency exceeds its objective
• HTTP error responses increase
• Backend connection failures increase
• TLS handshakes fail
• A certificate approaches its operational renewal boundary
• Proxy CPU, memory, connection, or network capacity is exhausted
• Retry or timeout volume grows
• One route or tenant dominates traffic unexpectedly
• Configuration deployment fails
• Connection draining exceeds its limit

Troubleshooting Workflow

1. Confirm that DNS resolves to the expected public entry point.
2. Confirm the listener address, port, and protocol.
3. Test the TLS handshake and certificate chain.
4. Capture the requested hostname, method, and path.
5. Identify which routing rule matched.
6. Confirm that the expected backend pool contains healthy instances.
7. Check proxy-to-backend connectivity.
8. Check header forwarding and trusted-proxy configuration.
9. Check URL rewriting and trailing-slash behaviour.
10. Check connection and response timeouts.
11. Check request-body and header-size limits.
12. Check retry behaviour.
13. Compare proxy and backend logs using a request ID.
14. Inspect distributed traces when available.

Common Reverse-proxy Mistakes

Recommended Test Cases

Reverse-proxy Best Practices

Practice Exercise

Design a reverse-proxy layer for your online learning platform.

Requirements

1. Expose one HTTPS public endpoint.
2. Route /api/* to API instances.
3. Route /articles/* and course pages to web instances.
4. Route /admin/* to a protected administration service.
5. Distribute API requests among several instances.
6. Create separate liveness and readiness endpoints.
7. Terminate TLS at the proxy.
8. Define whether backend traffic is re-encrypted.
9. Configure trusted forwarding-header behaviour.
10. Define request, response, and idle timeouts.
11. Define upload-size and streaming rules.
12. Support WebSocket notifications.
13. Add safe caching for public static content.
14. Protect private responses from shared caching.
15. Define safe retry behaviour.
16. Add connection draining.
17. Test one failed backend and one failed proxy instance.

Reverse-proxy Design Template

Frequently Asked Questions