Proxy Servers: Forward vs Reverse Proxy

A proxy is a middleman for network traffic. Which side it stands in front of -- the clients or the servers -- changes everything about what it does.

Build a load-balanced web stack in the lab

Free interactive lab. No signup. Runs in your browser.

Quick Summary

The Assistant and the Receptionist Analogy

Picture two very different middlemen. The first is a personal assistant who makes phone calls on your behalf. When the assistant calls a restaurant to book a table, the restaurant talks to the assistant -- it never even learns who you are. That is a forward proxy: it acts for the client, and the outside world only ever sees the assistant.

The second is a company receptionist who answers the main phone line for hundreds of employees. Callers dial one number and the receptionist quietly routes them to whoever can help -- callers never reach the employees' desks directly. That is a reverse proxy: it acts for the servers, and callers only ever see the receptionist.

A proxy server is simply an intermediary that sits between clients and servers and relays requests and responses. The single most important question to ask about any proxy is: which side is it standing in front of? Stand it in front of the clients and you get a forward proxy. Stand it in front of the servers and you get a reverse proxy. That one detail flips who gets hidden and what the proxy is good for.

Forward vs Reverse at a Glance

The same box in the middle, two opposite jobs. On the left it represents the clients; on the right it represents the servers:

FORWARD PROXY (fronts clients) Client A Client B Client C ForwardProxy Internet /Server Server sees only the proxy's IP REVERSE PROXY (fronts servers) Clients /Internet ReverseProxy Backend 1 Backend 2 Backend 3 Client never sees the backend IPs Same middleman — the side it fronts decides who is hidden

Try It Yourself: Forward vs Reverse Proxy Toggle

Flip the switch and watch the diagram redraw. Notice who gets hidden, which direction the traffic flows, and how the use cases change.

    The flip is the whole point: in forward mode the proxy speaks for the clients, so the server cannot see who is really behind it. In reverse mode the proxy speaks for the servers, so the client cannot see which backend actually handled the request.

    Proxies, Piece by Piece

    1

    The Forward Proxy: Fronting Clients

    A forward proxy sits in front of clients and acts on their behalf toward the internet. Because all client traffic exits through it, the destination server sees the proxy's IP, not the individual client's. A classic example is a corporate web proxy: it gives the IT team a single chokepoint for content filtering, caching, access control, monitoring, and client anonymity.

    2

    The Reverse Proxy: Fronting Servers

    A reverse proxy sits in front of servers and acts on their behalf toward clients. Clients believe they are talking to the real server, but they actually hit the proxy, which then forwards the request to a backend. This single entry point is where load balancing across multiple backends, caching, compression, and TLS/SSL termination happen -- and the client never learns the backend's real IP.

    3

    Reverse Proxy vs Load Balancer

    These two overlap so much that people often blur them. A reverse proxy is a general fronting server that frequently also load-balances; a pure load balancer's specific job is spreading traffic across servers. A load balancer can work at Layer 4 (raw TCP/UDP) or Layer 7 (HTTP, where it can route by URL or cookie). In practice, tools like Nginx and HAProxy act as both at once.

    4

    Real-World Tools & the CDN Connection

    The reverse proxies you will meet most often are Nginx, HAProxy, Envoy, and Cloudflare. A CDN is essentially a globally distributed reverse-proxy cache: it places copies of a reverse proxy in many cities so users hit a nearby one, getting cached content fast while the origin servers stay shielded. Same pattern, spread across the planet.

    Proxies in the Real World

    Here are three everyday places these two kinds of proxy show up:

    🏢

    Corporate Web Proxy (Forward)

    Many offices route all employee web traffic through a forward proxy. It blocks risky sites, caches popular downloads to save bandwidth, logs activity for compliance, and makes every employee appear to use a single company IP. The websites they visit never see the individual machines behind it.

    ⚖

    Nginx in Front of an App (Reverse)

    A web app running on three identical backend servers usually puts Nginx in front. Nginx terminates HTTPS (handling the TLS certificate once), then spreads incoming requests evenly across the three backends. If one backend dies, Nginx simply stops sending it traffic -- users never notice.

    🌎

    Cloudflare / CDN (Reverse, Global)

    When you visit a popular site behind Cloudflare, you hit a reverse proxy in a data center near you, not the origin server. It serves cached pages quickly, compresses responses, and absorbs DDoS attacks and malicious requests with a WAF before they ever reach the real backend.

    Common Mistakes & Misconceptions

    Proxies get muddled with other tools all the time. Watch out for these:

    ⚠

    "A Proxy Is the Same as a VPN"

    They are not interchangeable. A VPN encrypts all of your device's traffic in a tunnel at the operating-system level, so every app is routed through it. A proxy usually handles only specific application traffic (most often HTTP/HTTPS) and does not necessarily encrypt everything. Use a VPN for whole-device privacy; use a proxy to relay or shield particular web traffic.

    ⚠

    Confusing Forward and Reverse

    The labels trip people up constantly. Remember the one rule: a forward proxy fronts the clients (it hides who is asking), while a reverse proxy fronts the servers (it hides who is answering). If you mix these up, you will reason about which IP is exposed exactly backwards.

    ⚠

    "A Reverse Proxy and a Load Balancer Are Totally Different"

    People sometimes treat them as unrelated, but they overlap heavily. A reverse proxy very commonly performs load balancing as one of its jobs, and a load balancer is essentially a specialized reverse proxy. Do not assume you need two separate boxes -- one tool like HAProxy or Nginx usually does both.

    Why TLS Termination Matters

    One of the most valuable reverse-proxy tricks is TLS termination. Instead of every backend server handling its own HTTPS handshakes and certificates, the reverse proxy decrypts incoming TLS at the edge. It holds the certificate, performs the handshake once, and then forwards the now-plain request to a backend, often over a fast internal network.

    This centralizes certificate management (renew it in one place, not on ten servers) and offloads the CPU-intensive encryption work from your application servers, letting them focus on actual logic. It is also where compression, caching, and request inspection naturally live -- which is exactly why the reverse proxy has become a standard fixture in front of nearly every production web service.

    The bottom line: a proxy is a middleman, and the side it stands in front of defines its personality. Front the clients and you get a forward proxy that hides and controls who is asking. Front the servers and you get a reverse proxy that hides, balances, secures, and accelerates who is answering. Keep that one distinction straight and the rest falls into place.

    Frequently asked questions about proxy servers

    What is a proxy server?

    A proxy server is an intermediary that sits between clients and servers and relays requests and responses on behalf of one side. Instead of a client talking directly to a server, the traffic passes through the proxy, which can filter, cache, log, balance, or secure it. The two main types are forward proxies, which act for clients, and reverse proxies, which act for servers.

    What is the difference between a forward proxy and a reverse proxy?

    A forward proxy sits in front of clients and represents them toward the internet, so the destination server sees only the proxy's IP, not the real client. It is used for content filtering, caching, access control, monitoring, and anonymity. A reverse proxy sits in front of servers and represents them toward clients, so the client thinks it is talking to the real server but actually hits the proxy. It is used for load balancing, caching, TLS termination, compression, and security shielding.

    What is the difference between a reverse proxy and a load balancer?

    They overlap heavily. A reverse proxy is a server that fronts backends and can do many things, including distributing requests, while a load balancer's specific job is spreading traffic across multiple servers. A reverse proxy often load-balances, and a load balancer can operate at Layer 4 (TCP/UDP) or Layer 7 (HTTP). In practice tools like Nginx and HAProxy act as both.

    Is a proxy the same as a VPN?

    No. A VPN encrypts all of a device's traffic in a tunnel at the operating-system level, so every application is routed through it. A proxy usually handles specific application traffic, most often HTTP or HTTPS, and does not necessarily encrypt everything. A proxy is great for relaying or shielding web traffic, while a VPN is about whole-device encrypted networking.

    What is TLS termination on a reverse proxy?

    TLS termination means the reverse proxy decrypts incoming HTTPS at the edge so the backend servers do not each have to handle the TLS handshake. The proxy holds the certificate, decrypts the request, and forwards it to the backend, often over a faster internal connection. This centralizes certificate management and offloads encryption work from the application servers.

    Build the reverse-proxy pattern

    You just learned how forward and reverse proxies relay traffic. Now put a load balancer in front of web servers, trace a client's request through it, and see which address each side thinks it is talking to. The lab works at Layer 4, so forward proxies and HTTP-level features stay in the diagrams above.

    Launch the web stack lab →