Forward Proxy vs Reverse Proxy: What Is the Difference

The short answer

Both are intermediaries between a client and a server. The difference is whose side they are on:

• A forward proxy works for the clients. The client knows about the proxy and deliberately sends traffic through it. The destination server sees the proxy, not the client.
• A reverse proxy works for the servers. The client usually does not know it exists: it connects to what looks like the website, and the proxy decides which backend actually answers.

A simple way to remember it: a forward proxy hides clients from servers, a reverse proxy hides servers from clients.

How a request flows

Forward proxy:

[Laptop] --> [Forward proxy] --> internet --> [example.com]
  configured      checks policy,           sees the proxy IP
  to use proxy    logs, caches

Reverse proxy:

[Browser] --> internet --> [Reverse proxy] --> [app server 1]
  thinks it talks          TLS, routing,  \-> [app server 2]
  to example.com           cache, limits   \-> [static files]

In the first case the proxy belongs to the organization of the user. In the second it belongs to the owner of the website.

Typical uses of a forward proxy

• Corporate filtering: blocking categories of sites, enforcing acceptable-use rules.
• Logging and auditing outbound traffic for security teams.
• Controlled egress: servers in a private network reach the internet only through one known address, which is easy to whitelist on partner side.
• Caching of frequently downloaded content, for example package mirrors in a build network.
• Access from another location, similar to what people use VPNs for. Note that a proxy usually handles only specific protocols or apps, while a VPN tunnels all traffic of the device.

A classic example is Squid. Many corporate security gateways and cloud "secure web gateway" products are forward proxies too.

Typical uses of a reverse proxy

• TLS termination: the proxy holds certificates and handles HTTPS, backends speak plain HTTP inside a private network.
• Load balancing across several application instances.
• Routing: /api goes to one service, / to the frontend, /static to a file store.
• Caching responses and serving static files quickly.
• Protection: rate limiting, request size limits, a WAF, hiding internal topology.
• Zero-downtime deploys: switching traffic between old and new versions.

Common examples: nginx, HAProxy, Traefik, Envoy, and CDNs such as Cloudflare, which act as a globally distributed reverse proxy in front of your origin.

A minimal nginx reverse proxy looks like this:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/example.crt;
    ssl_certificate_key /etc/ssl/example.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;
    }
}

Side-by-side comparison

Common mistakes

• Losing the real client IP. Behind a reverse proxy the app sees the proxy address. Pass X-Forwarded-For and configure the app to trust it only from the proxy.
• Trusting forwarded headers from anyone. If the backend is reachable directly, a client can forge X-Forwarded-For. Keep backends private.
• Wrong scheme in redirects. With TLS terminated at the proxy, the app may think the request is HTTP and generate http:// links. Forward X-Forwarded-Proto.
• Open forward proxy. A forward proxy without authentication on a public IP will quickly be abused by strangers.
• Caching private pages. A reverse proxy cache must respect cookies and Cache-Control, or one user may see another user's data.