Front-Door Infrastructure
USERPROXYAPP

Reverse Proxy

Forward traffic, hide origins, terminate TLS, and spread load before requests hit the app servers.

Shared Front Door Stack

Same entrance, different jobs

These are roles, not always separate products. One vendor can collapse two or three of these into one box, which is why the diagrams can look similar.

WAF / Firewall

Is this malicious enough to block?

Security filtering, bot rules, attack scoring, challenge or block.

This Page

Reverse Proxy

Where should I forward this?

Forwarding, TLS termination, load balancing, buffering, hiding origins.

API Gateway

Is this API request allowed?

Auth, quotas, validation, transforms, versioning, aggregation.

Backend

What does the business logic do?

Domain rules, database writes, long jobs, transactions.

Cloudflare can combine CDN + WAF + edge proxyNGINX can do reverse proxy + load balancingKong adds API policy on top of a proxy-style front door
Without Reverse Proxy

Direct Client to Server

Client
Server 1
Server 2
Server 3
With Reverse Proxy

Smart Load Balancing

Client
Reverse Proxy
Server 1
Server 2
Server 3
Forwarding Path

What the Proxy Actually Owns

This is the forwarding path. WAF decisions can happen before it, and API gateway policy can happen around or behind it.

Client
Reverse Proxy
Origin App
Proxy Responsibilities

What the Reverse Proxy Handles

These are traffic-handling jobs. Security filtering belongs more to WAF, and API consumer policy belongs more to an API gateway.

Load Balancing

Hover to activate

SSL Termination

Hover to activate

Hides Backend

Hover to activate

Caching

Hover to activate

Implementation

What this looks like in real config

server {
  listen 443 ssl http2;
  server_name app.example.com;

  location / {
    proxy_pass http://app_cluster;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}