Forward Proxy vs Reverse Proxy: Key Differences, Diagrams and Comparison Table

Networking guide · Last reviewed 1 October 2026 · 18 min read

Forward proxy vs reverse proxy comes down to one question: whose side is the proxy on? A forward proxy works for the client. You configure your browser, script or network to send requests to it, and it fetches websites on your behalf, so the site sees the proxy’s IP address instead of yours; a rotating residential proxy is a commercial example. A reverse proxy works for the server. It sits in front of a website, receives every visitor’s request as if it were the site, and passes it to the real servers behind it. This guide compares the two side by side, shows the request flow for each, explains the Forwarded and X-Forwarded-For headers and TLS termination, covers the software and services behind both, and shows how reverse proxies help absorb DDoS traffic.

What is a forward proxy?

A forward proxy is a server that makes requests on behalf of its clients. When people just say “proxy”, this is usually what they mean. The HTTP specification, RFC 9110, defines a proxy as a message-forwarding agent chosen by the client, usually through local configuration. That word “chosen” is the heart of it: the client knows the proxy exists and sends its traffic there on purpose.

The Apache HTTP Server documentation puts it plainly. An ordinary forward proxy sits between the client and the origin server; to get content, the client sends the request to the proxy and names the origin server as the target, and the proxy fetches the content and returns it. The client has to be specially configured to use it, in the browser’s proxy settings, the operating system, an environment variable such as HTTPS_PROXY, or directly in code.

Because the proxy opens the connection to the website, the website sees the proxy’s IP address, not the client’s. That one property explains most forward proxy use cases:

• Access control and filtering. Companies and schools route staff or student traffic through a forward proxy that allows, blocks and logs sites. Apache’s docs give “Internet access to internal clients that are otherwise restricted by a firewall” as the typical use.
• Caching. A shared proxy can keep copies of popular content and serve them to many users, saving bandwidth. Squid, an open-source forward proxy, describes itself as a caching proxy that reduces bandwidth and improves response times.
• Privacy and location. A proxy in another city or country lets you see a website the way local users see it, which is what ad verification, price monitoring and SEO rank checks depend on.
• Data collection at scale. Scrapers and monitoring tools spread requests over many IP addresses through a rotating proxy network, so no single address sends everything.

  YOUR SIDE                     |   THE INTERNET
                                |
  browser / script  (your IP)   |
        |                       |
        |  "get example.com"    |
        v                       |
  forward proxy  (you chose it) |
        |                       |
        +-----------------------+-->  example.com
                                |     sees the proxy's IP,
                                |     not yours

On the wire, a client talking to a forward proxy sends a slightly different request from one it would send to a website directly. RFC 9112 says that for a plain HTTP request to a proxy the client sends the full URL, in what it calls absolute-form, so the proxy knows where to go. For HTTPS the client first sends a CONNECT request naming only the host and port, and the proxy opens a tunnel. You can see both forms in Figure 2.

# plain HTTP: the full URL goes to the proxy (absolute-form)
GET http://example.com/prices HTTP/1.1
Host: example.com
Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# HTTPS: ask the proxy for a tunnel first (authority-form)
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

The Proxy-Authorization header carries the client’s credentials for the proxy. RFC 9110 notes that it applies only to the next proxy that asked for authentication, and that proxy consumes it, so it is not passed on to the website.

What is a reverse proxy?

A reverse proxy faces the other way. It sits in front of one or more web servers, and every visitor’s request reaches it first. RFC 9110 calls it a gateway, “a.k.a. reverse proxy”: an intermediary that acts as the origin server for the client but forwards the requests inbound to other servers. The Apache documentation says a reverse proxy “appears to the client just like an ordinary web server”, with no special configuration needed on the client.

That is the practical difference you notice first. Nobody sets a reverse proxy in their browser. The website’s DNS record points at the reverse proxy, so visitors reach it simply by typing the address. The proxy then decides which backend server gets each request, passes it on and returns the answer as if it had produced it itself. The backend servers’ own addresses can stay private.

The RFC lists what gateways are typically for, and the list still holds: improving performance through “accelerator” caching, and partitioning or load balancing HTTP services across several machines. Add the jobs modern reverse proxies took on later and you get the usual set:

• Load balancing. Spread requests over several application servers and stop sending traffic to one that fails a health check.
• TLS termination. Hold the site’s certificate, decrypt HTTPS at the edge and pass plain or re-encrypted traffic to the backends.
• Caching and compression. Serve repeat content without touching the application.
• One address for many services. Route /api to one service and /shop to another, which Apache describes as bringing several servers into the same URL space.
• Protection. Hide the origin’s IP, rate-limit abusive clients and absorb attack traffic before it reaches the application.

You have used a reverse proxy today without knowing it. The page you are reading comes through one: its response headers include Server: cloudflare and a CF-RAY request ID, which Cloudflare’s docs describe as an identifier encoding the data centre that handled the request.

  THE INTERNET                  |   THE SITE'S NETWORK
                                |
  visitor  (203.0.113.7)        |
     |                          |
     |  GET www.example.com     |
     v                          |
  reverse proxy                 |
  (www.example.com resolves     |
   here; it terminates TLS)     |
     |                          |
     +--------------------------+-->  app server 1  10.0.0.11
     |                          |
     +--------------------------+-->  app server 2  10.0.0.12
                                |     private addresses,
                                |     never exposed

Forward proxy vs reverse proxy: comparison table

Both are proxies in the literal sense: they receive a request, make a request of their own and relay the answer. What changes is who deploys them, who knows about them and what they protect. The table sums up forward proxy vs reverse proxy on the points that matter in practice.

How a request flows through each

The clearest way to see forward proxy vs reverse proxy in action is to follow one HTTPS request through each. Start with a forward proxy. Your client connects to the proxy and sends CONNECT example.com:443 with your proxy credentials. The proxy checks them, opens a TCP connection to example.com from its own IP address and replies 200. From then on RFC 9110 says the proxy restricts itself to blind forwarding of data in both directions. Your client and the website negotiate TLS through the tunnel, and the website sees a connection from the proxy’s IP.

Now the same visitor reaching a site behind a reverse proxy. DNS for www.example.com returns the reverse proxy’s address. The browser opens a TLS connection to it, and the proxy presents the site’s certificate, decrypts the request, applies its rules (cache, rate limit, routing) and forwards the request to a backend over the private network, adding headers that record the visitor’s real IP. The backend answers the proxy, and the proxy answers the browser.

In real traffic these chains often line up. A scraper sending requests through a residential proxy, to a site served through a CDN, passes through both kinds of proxy in one trip:

client (your IP)
   |  CONNECT www.example.com:443
   v
FORWARD PROXY  (yours: residential IP 198.51.100.24)
   |  opens TCP to www.example.com, then relays TLS blindly
   v
REVERSE PROXY / CDN edge  (the site's: holds the certificate)
   |  decrypts, checks rules, adds X-Forwarded-For: 198.51.100.24
   v
origin app server  (private)
   -> logs the visitor as 198.51.100.24, never sees your IP

The site’s operator sees the forward proxy’s IP as the visitor, because that is who connected to their reverse proxy. You, on the other side, never see the origin server’s address, only the reverse proxy’s. Each proxy hides its own side.

Companies do the same thing on purpose inside one network. Staff browse through an outbound forward proxy that enforces the acceptable-use policy, while the company’s public apps sit behind an inbound reverse proxy. The two are managed by different teams and solve different problems, even if the same product runs both.

Forwarded and X-Forwarded-For headers

A reverse proxy creates a problem for the servers behind it: every request now arrives from the proxy’s address. HAProxy’s manual says it directly: since HAProxy works in reverse-proxy mode, the servers see its IP address as their client address. Logs, analytics, geolocation and rate limits all need the visitor’s real address, so the proxy writes it into a header.

The common header is X-Forwarded-For. MDN describes it as a de facto standard, not part of any current specification. Each proxy appends the address it received the connection from, so the list reads left to right from the original client to the most recent proxy. Companion headers record the original protocol (X-Forwarded-Proto) and hostname (X-Forwarded-Host).

RFC 7239 standardised the same information in a single Forwarded header with four parameters: for (the client or previous proxy), by (the proxy’s interface that received the request), host (the original Host header) and proto (http or https). IPv6 addresses must be quoted and bracketed. Figure 5 shows the headers a backend might receive after one reverse proxy.

# de facto headers: most software sends these
X-Forwarded-For: 203.0.113.7
X-Forwarded-Proto: https
X-Forwarded-Host: www.example.com

# the standard header (RFC 7239)
Forwarded: for=203.0.113.7;proto=https;host=www.example.com;by=203.0.113.43
Forwarded: for="[2001:db8:cafe::17]:4711"

# after two proxies, each appends the address it received
X-Forwarded-For: 203.0.113.7, 198.51.100.17
Forwarded: for=203.0.113.7, for=198.51.100.17

# plus the Via header, which RFC 9110 requires proxies to add
Via: 1.1 edge-proxy

Here is the security catch, and every source agrees on it. RFC 7239 warns that the Forwarded header cannot be relied upon to be correct, because any node on the way, including the client, can modify it. MDN goes further: if your server can be reached directly from the internet, no part of the X-Forwarded-For list is trustworthy for security decisions. A client can send a fake header, and a careless proxy will append the real address after it.

The fix is to trust only addresses added by proxies you control, reading the list from the right. Each reverse proxy has a setting for it. Nginx’s realip module takes a list of trusted proxy addresses in set_real_ip_from and, with real_ip_recursive on, replaces the client address with the last untrusted address in the header. Caddy ignores incoming X-Forwarded-* values unless the sender is listed in trusted_proxies. Traefik trusts them only from the IPs in forwardedHeaders.trustedIPs. Envoy uses xff_num_trusted_hops to decide how many addresses from the right it believes.

What about forward proxies? On an HTTPS request through a CONNECT tunnel, a forward proxy can’t add headers at all, because it only relays encrypted bytes. On plain HTTP a corporate proxy may add Via or X-Forwarded-For. A proxy whose job is to hide the client, such as an anonymous proxy, leaves the client address out.

HTTPS: tunnels vs TLS termination

Encryption is where forward and reverse proxies differ most, and where they are most often misunderstood.

Forward proxy: a tunnel it can’t see into

For an https:// address, a client asks its forward proxy for a CONNECT tunnel. RFC 9110 describes tunnels as an end-to-end virtual connection, through one or more proxies, that can then be secured with TLS. The TLS session runs between your client and the website, so the proxy sees the destination host and port, the timing and the amount of data, but not the pages, form fields or cookies.

The exception is TLS inspection, which some corporate proxies use to scan traffic. Squid’s SslBump feature, for example, decrypts CONNECT traffic by becoming a man in the middle, which only works when client devices trust a certificate authority the proxy controls. Squid’s own documentation warns that decrypting HTTPS without users’ consent or knowledge may violate ethical norms and may be illegal in some jurisdictions. Without a certificate authority your device trusts, a proxy can’t decrypt the tunnel without browsers showing a certificate warning, so a proxy network you simply log in to with a username and password relays HTTPS as a plain tunnel.

Reverse proxy: it holds the certificate

A reverse proxy is the endpoint of the visitor’s TLS connection. It holds the site’s certificate and private key, decrypts each request, and can then route on the path, cache the response or block it. This is TLS termination. Behind it, the proxy either forwards plain HTTP over a private network or opens a new TLS connection to the backend (nginx’s proxy_ssl_verify and related directives cover that second leg). When one proxy serves many sites on one IP address, the TLS Server Name Indication extension (RFC 6066) tells it which certificate to present; nginx’s docs note that TLS 1.3 makes SNI mandatory to implement.

upstream app_servers {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     /etc/nginx/certs/www.example.com.crt;
    ssl_certificate_key /etc/nginx/certs/www.example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass        http://app_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;
        proxy_set_header  X-Forwarded-Proto $scheme;
    }
}

Nginx balances the two upstream servers with weighted round-robin by default. The $proxy_add_x_forwarded_for variable is the incoming X-Forwarded-For header with the client address appended, or just the client address if there was no header. Caddy gets the same result with less configuration: its automatic HTTPS obtains and renews certificates from Let’s Encrypt or ZeroSSL, and a site block containing reverse_proxy 10.0.0.11:8080 10.0.0.12:8080 is a complete TLS-terminating load balancer.

Who provides forward proxies

There are two ways to get a forward proxy, and which one fits depends on whose IP address you need the website to see.

Run your own. Squid is the classic self-hosted forward proxy: a caching proxy for HTTP, HTTPS and FTP with extensive access controls, released under the GNU GPL. Apache httpd can act as one with mod_proxy and ProxyRequests On, and its docs stress that you must restrict who can use it before switching it on, because an open forward proxy lets anyone reach arbitrary sites while hiding their origin. A self-hosted proxy is right for filtering, caching and controlling a team’s outbound traffic. Its exit IP is your own server’s, usually a single datacenter address.

Use a proxy network. When the point is to appear from many places, or from real household and mobile connections, you use a commercial forward proxy service. ProxyEmpire’s rotating residential proxies are an example: you point your client at one gateway, authenticate with a username and password, and each request or session exits from a residential IP in the country, city or ISP you choose. Mobile proxies do the same with 4G/5G carrier IPs, and datacenter proxies trade that realism for speed and price. Our guide to residential, mobile and datacenter proxies covers the trade-offs.

Using a commercial forward proxy looks the same as any other. In curl, -x sets the proxy, credentials can sit inside the proxy URL, and curl’s manual says HTTPS_PROXY in the environment has the same effect as the option:

# one request through a ProxyEmpire residential gateway
curl -x http://USERNAME:PASSWORD@v2.proxyempire.io:5000 https://example.com/

# or set it once for every tool that reads the variable
export HTTPS_PROXY=http://USERNAME:PASSWORD@v2.proxyempire.io:5000
curl https://example.com/

Things worth checking in any forward proxy you pay for: the IP types and locations on offer, how targeting works, whether you can keep one IP for a session or rotate on every request (see sticky vs rotating proxies), the supported protocols (HTTP, HTTPS and SOCKS5), how you authenticate and whether a real person answers when something breaks. Avoid free open proxies for anything that matters: whoever runs one sees your destinations and any unencrypted traffic.

Reverse proxy software and CDNs

Reverse proxies are mostly open-source software you run yourself, or a CDN that runs them for you at its edge. The projects below are the ones most often deployed. They are listed in no particular order, and each is described from its own documentation, not ranked; any of them can do the basic job of terminating TLS and forwarding to backends.

Their documentation also shows where each one starts from. Nginx, Apache and Caddy are web servers first, so they can serve files and proxy in the same process. HAProxy presents itself as a load balancer for TCP and HTTP. Traefik’s providers and Envoy’s dynamic configuration APIs are built for platforms where backends appear and disappear and the proxy has to follow, such as Docker and Kubernetes. Caddy’s automatic HTTPS removes certificate work entirely.

CDNs are reverse proxies too

A content delivery network is a reverse proxy spread over many locations. Cloudflare’s documentation defines a reverse proxy as servers that sit in front of web servers and either forward requests to them or handle requests on their behalf, and explains the mechanics: when a DNS record is set to proxied, DNS answers with a Cloudflare anycast IP instead of the origin’s IP, so HTTP and HTTPS traffic passes through Cloudflare’s network on its way to the origin. Other CDNs work on the same principle. The CDN caches static content near visitors, terminates TLS and passes the rest to the origin, adding headers such as CF-Connecting-IP and X-Forwarded-For so the origin still knows who the visitor was.

Reverse proxies and DDoS mitigation

CISA defines a distributed denial-of-service (DDoS) attack as one where multiple machines work together to make a service unavailable to its legitimate users. Reverse proxies are the main defensive layer against it, for four reasons.

• They absorb volume. A CDN’s reverse proxies run on a large, distributed network. With anycast, attack traffic is spread across many locations instead of landing on one server. Cloudflare’s docs say its DDoS protection works at layers 3, 4 and 7 and automatically detects and mitigates attacks.
• They hide the origin. If DNS only ever returns the proxy’s address, attackers have no direct target. The origin should then accept connections only from the proxy’s published IP ranges; otherwise anyone who finds the real IP can go around the proxy.
• They filter at the edge. Because a reverse proxy terminates TLS, it can inspect requests and drop malformed ones, block known-bad patterns and challenge suspicious clients before the application does any work.
• They serve from cache. Requests for cached pages never reach the origin, so a flood of them costs the application nothing.

Rate limiting is the tool you control directly. It caps how many requests one client can make in a period, which blunts application-layer floods and brute-force login attempts. Nginx’s limit_req module uses a leaky bucket per key, usually the client IP; HAProxy tracks request rates per source in a stick table; Traefik’s RateLimit middleware uses a token bucket with average, period and burst; Envoy’s local rate limit filter returns 429 by default. Figure 8 shows the first two.

# nginx: 10 requests/second per client IP, bursts of 20, answer 429
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location /login/ {
        limit_req        zone=perip burst=20 nodelay;
        limit_req_status 429;
        proxy_pass       http://app_servers;
    }
}

# HAProxy: deny clients above 100 requests per 10 seconds
frontend www
    mode http
    bind :443 ssl crt /etc/haproxy/certs/site.pem
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
    default_backend app_servers

Two details matter. Nginx returns 503 for rejected requests unless you set limit_req_status, and 429 Too Many Requests is the clearer answer. And if the proxy sits behind a CDN, the key has to be the real client IP recovered from trusted forwarded headers, as in the headers section above; otherwise every visitor shares the CDN’s address and one limit.

Rate limiting and a single reverse proxy won’t stop a large volumetric attack on their own; that takes the capacity of a distributed network, usually a CDN or a dedicated DDoS protection service, working with your hosting provider. CISA’s guidance lists enrolling in a protection service that detects abnormal traffic and redirects it away from your network, having a response plan, and contacting your ISP when an attack starts. A forward proxy plays no part in defending a site: it protects clients, not servers.

When you need which

Deciding between a forward proxy vs reverse proxy is rarely hard once you ask the direction question. The quickest test: if you want to change how you reach other people’s websites, you need a forward proxy. If you want to change how people reach your website, you need a reverse proxy. The enterprise use cases break down like this.

Most organisations end up with both, run by different people. The network team owns the outbound proxy, the platform team owns the load balancer, and the marketing or data team rents a proxy network for research. None of them replaces the others.

Where ProxyEmpire fits

To be clear about categories: ProxyEmpire is a forward proxy provider. It doesn’t host websites, terminate your TLS or protect your servers from attack traffic; for that you want a reverse proxy or a CDN from the section above. What it gives you is the outbound side: 30M+ residential IPs and 4M+ mobile IPs, reached through the gateway v2.proxyempire.io on port 5000 with username and password authentication, over HTTP, HTTPS or SOCKS5. Rotating residential and mobile proxies can be targeted by country, region, city, ZIP, ISP (carrier for mobile), ASN and OS fingerprint at no extra charge, with rotating or sticky sessions. There are also rotating mobile proxies, static residential and datacenter options, 99.9% uptime shown on the public status page and 24/7 support from real people. Residential starts at $3.50/GB and falls to $1.50/GB, unused bandwidth rolls over, and you can test it with a $1.97 trial.

Forward proxy vs reverse proxy FAQ

References

1. IETF — RFC 9110, “HTTP Semantics”: intermediaries, Via, CONNECT, Proxy-Authorization. rfc-editor.org/rfc/rfc9110
2. IETF — RFC 9112, “HTTP/1.1”: absolute-form and authority-form request targets. rfc-editor.org/rfc/rfc9112
3. IETF — RFC 7239, “Forwarded HTTP Extension”. rfc-editor.org/rfc/rfc7239
4. MDN Web Docs — X-Forwarded-For. developer.mozilla.org/…/X-Forwarded-For
5. Apache HTTP Server — mod_proxy, forward proxies and reverse proxies. httpd.apache.org/docs/2.4/mod/mod_proxy
6. nginx — ngx_http_proxy_module. nginx.org/en/docs/http/ngx_http_proxy_module
7. nginx — ngx_http_upstream_module. nginx.org/en/docs/http/ngx_http_upstream_module
8. nginx — Configuring HTTPS servers. nginx.org/en/docs/http/configuring_https_servers
9. nginx — ngx_http_realip_module. nginx.org/en/docs/http/ngx_http_realip_module
10. nginx — ngx_http_limit_req_module. nginx.org/en/docs/http/ngx_http_limit_req_module
11. HAProxy — Configuration Manual (option forwardfor, option forwarded, stick tables, bind ssl). docs.haproxy.org/2.8/configuration
12. Caddy — reverse_proxy directive. caddyserver.com/docs/caddyfile/directives/reverse_proxy
13. Caddy — Automatic HTTPS. caddyserver.com/docs/automatic-https
14. Traefik — Providers overview. doc.traefik.io/…/providers/overview
15. Traefik — EntryPoints (forwarded headers, PROXY protocol). doc.traefik.io/…/entrypoints
16. Traefik — RateLimit middleware. doc.traefik.io/…/middlewares/ratelimit
17. Envoy — What is Envoy. envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
18. Envoy — HTTP header manipulation (x-forwarded-for, xff_num_trusted_hops). envoyproxy.io/…/http_conn_man/headers
19. Envoy — Local rate limit filter. envoyproxy.io/…/local_rate_limit_filter
20. Squid — project home and SslBump. squid-cache.org · wiki.squid-cache.org/Features/SslBump
21. curl — manual page, –proxy and proxy environment variables. curl.se/docs/manpage
22. Cloudflare — How Cloudflare works. developers.cloudflare.com/…/how-cloudflare-works
23. Cloudflare — About DDoS protection. developers.cloudflare.com/ddos-protection/about
24. Cloudflare — HTTP headers (CF-Connecting-IP, X-Forwarded-For, CF-Ray). developers.cloudflare.com/…/http-headers
25. CISA — Understanding Denial-of-Service Attacks. cisa.gov/…/understanding-denial-service-attacks