Skip to content
Stéphane Robert
Français
Account: not signed in, sync available My learning
Select theme
Français
Lire en français

Reverse proxy: definition, role and which tool to choose

By updated

Improve this page

What would you like to report?

The issue opens pre-filled with this page title and URL.

What you will learn

This lesson lays down the vocabulary the following guides rely on: it defines the reverse proxy, tells it apart from the classic proxy and from the load balancer, then links each need to a tool. The three objectives below match the guide's success criteria.

  • Define a reverse proxy and its role as a single entry point.
  • Tell apart reverse proxy, proxy and load balancer.
  • Choose the tool that fits your context.

What is a reverse proxy?

A reverse proxy is an intermediate server placed in front of your application servers: it receives the clients' requests, forwards them to the right backend, then returns the response. The client never talks directly to your servers, it only knows the proxy. Each of these servers placed behind it is called a backend. The proxy is the gatekeeper of your infrastructure: it centralizes TLS (the encryption of HTTPS connections), routing (choosing the backend from the address requested), load balancing (sharing requests among several backends) and security.

This guide gives the full definition, tells the reverse proxy apart from the classic proxy and from the load balancer, then helps you choose the tool (HAProxy, Traefik, Nginx, Caddy, Apache, or a tunneled reverse proxy, which publishes a service without opening a port) according to your context. Audience: beginners and intermediates who administer a web infrastructure.

The 3 immediate benefits:

  1. Your servers are hidden: users only know the proxy's address, never that of the backends.
  2. A single configuration point: TLS certificates, security rules and logs are centralized in the same place.
  3. High availability: if a server goes down, the proxy automatically redirects to the others.

Reverse proxy or proxy: do not confuse them

The word proxy alone generally means a forward proxy, which acts on behalf of the clients: it goes out of the network toward the Internet (web filtering, browsing cache, anonymization). The reverse proxy does the opposite, it acts on behalf of the servers and receives incoming traffic.

Proxy (forward)Reverse proxy
Acts forthe clients (outbound)the servers (inbound)
Hideswho accesses the Internetwhich servers answer
Use casesfiltering, browsing cacheTLS, routing, load balancing, WAF

A WAF (Web Application Firewall) is a filter that inspects HTTP requests to block malicious ones. Some reverse proxies include one.

Remember the simple rule: a forward proxy protects and hides the users, a reverse proxy protects and hides the servers.

The path of a request

When a user types https://app.example.com in their browser, the reverse proxy orchestrates the whole journey before the request reaches your application.

Path of a request: the browser sends an HTTPS request to the reverse proxy, which terminates TLS, applies its rules (Host, Path, Headers) then chooses a backend by load balancing and health check; it forwards in HTTP to the backend, whose response returns to the browser in HTTPS.BackendReverse proxyBrowser① TerminatesTLS (decryptsHTTPS)② Applies therules (Host,Path,Headers)③ Picks abackend (loadbalancing +health check)HTTPS requestHTTP forwardresponseHTTPS response
The reverse proxy can be HAProxy, Nginx or Traefik; the backend is your application. Source · SVG
Esc to close, + and − to zoom, scroll to move around. 100 %

Step by step:

  1. The client calls https://app.example.com.
  2. The reverse proxy terminates TLS (decrypts the HTTPS connection).
  3. It chooses a backend according to its rules (load balancing + health checks).
  4. It forwards the request to the selected backend.
  5. The backend processes and returns the response.
  6. The proxy returns the response to the client.

Concrete example: routing by path

Imagine a site with three components. The reverse proxy reads the URL and sends each request to the right server:

RequestWhere it goesWhy
GET /api/usersAPI backend (Node.js)Business logic
GET /Frontend (React/Vue)User interface
GET /static/logo.pngFile server or cachePerformance

Without a reverse proxy, you would need three different domains or to pile everything onto a single server.

The 5 key functions

A reverse proxy is a gatekeeper that performs five actions, whatever the tool chosen:

  1. Terminates HTTPS: it decrypts TLS connections. Your backends can run in plain HTTP, which is easier to manage.

  2. Routes requests: according to the path (/api), the domain (api.example.com) or a header, it sends to the right backend.

  3. Balances the load: it distributes requests among several servers (round-robin: each server in turn, or the one with the fewest connections, etc.).

  4. Checks health: it regularly tests each backend. A server that stops answering is removed automatically.

  5. Protects access: rate limiting (a limit on the number of requests per client), IP blocking, header validation. It is your first line of defense.

Reverse proxy or load balancer: what is the difference?

These two terms are often confused. A reverse proxy is an HTTP(S) entry point that does TLS, routing and security. A load balancer spreads traffic across several servers, at the transport (L4) or application (L7) level (the "L4 versus L7" box below details the difference).

ConceptWhat it doesExamples
Reverse proxyHTTP(S) entry point: TLS, routing, headers, securityNginx, Traefik, Apache
Load balancerSpreads traffic across servers (L4 or L7)HAProxy, AWS ALB, F5

In practice, most tools do both. HAProxy is an excellent load balancer that also acts as a reverse proxy. Nginx is a web server, a reverse proxy and a load balancer. Traefik combines everything in a cloud-native context.

Families of tools

These tools do not belong to the same category. Understanding their family avoids believing they all do the same thing:

FamilyToolsSpecialty
L4/L7 load balancerHAProxyLoad balancing, high availability, advanced checks
Cloud-native edge proxyTraefikService discovery, dynamic config, containers
Web server + reverse proxyNginx (in French), Apache (in French), Caddy (in French)Serve static content + proxy to backends
Tunneled / zero-trust reverse proxyPangolin, cloudflared, ngrokPublish a service without opening a port (all three); identity verified at the edge (the visitor authenticates before reaching the service) with Pangolin and cloudflared only
WAF / filtering reverse proxyBunkerWeb (in French)Application firewall built into the proxy
Data-plane / service meshEnvoyL7 proxy at scale (via Istio)

The WAF was defined above. The service mesh is a layer of proxies that links the services of a cluster together: the box below places it in relation to the Ingress.

The tunneled reverse proxy, a rising family

A more recent family of tools publishes a service without opening any inbound port on your firewall. A connector, installed in the private network, opens an outbound tunnel to a public entry point. An outbound connection crosses firewalls without any particular rule, and the visitors' traffic then comes back down through this tunnel. It is ideal for a homelab behind a router or a network without a public IP.

The private network's connector opens an outbound tunnel to the public entry point; an HTTPS request from a visitor arrives at the entry point, comes back down through the tunnel to the connector, which calls the internal service; the response goes back up the same path.InternalserviceConnectorPublic entrypointVisitorno inbound port onthe private network① opens the tunnel(outboundconnection)② HTTPS request③ the request comesdown the tunnel④ call to the localservice⑤ response⑥ the response goesup the tunnel⑦ HTTPS response
The tunnel is opened from the inside toward the outside; all the visitors' traffic reuses it. Source · SVG
Esc to close, + and − to zoom, scroll to move around. 100 %

Three tools illustrate this family, and they differ mainly by who operates the public entry point and by the intended duration of use:

  • Pangolin is the self-hosted and sovereign option: you operate the entry point yourself.
  • cloudflared is the managed option: Cloudflare operates the entry point.
  • ngrok is for a temporary exposure for development (a demonstration, a webhook to receive), not for a lasting publication.

These tools are double-edged: the same mechanism also serves attackers, and has to be watched. Each lesson of the module devoted to this family details the legitimate use and the detection of abuse.

Choosing in 5 questions

Answer in order: as soon as you have a "yes", you have your tool. The constraint that eliminates the most options, no open port, comes first:

QuestionIf yes →
1. Expose a service without opening a port (homelab)?Pangolin or cloudflared; ngrok for a temporary trial
2. Kubernetes or Docker with auto discovery?Traefik, dynamic config through labels/annotations
3. Critical L4/L7 load balancing + advanced health checks?HAProxy, built for that, very stable
4. Serve web content + cache + classic reverse proxy?Nginx (in French), the standard, built-in cache
5. Automatic HTTPS + minimalist configuration?Caddy (in French), native Let's Encrypt

Visual decision tree

Follow the tree from top to bottom and stop at the first branch that describes your situation: it gives the suitable tool. The most constraining cases, such as no public IP or Kubernetes, are placed first because they eliminate the most options.

Are you exposing a service without a public IP / without opening a port?
├── Yes → Pangolin (self-hosted) or cloudflared (managed)
└── No → next question
    │
    └── Does your infrastructure use Kubernetes?
        ├── Yes → Traefik (IngressRoute) or Nginx Ingress
        └── No → next question
            │
            └── Docker with frequent deployments?
                ├── Yes → Traefik (automatic discovery)
                └── No → next question
                    │
                    └── Advanced L4/L7 load balancing?
                        ├── Yes → HAProxy (health checks, runtime API)
                        └── No → Nginx (web + cache) or Caddy (automatic HTTPS)

Technical comparison

This table compares the operating models, not raw performance (sufficient for most workloads). The "TLS / ACME" row shows whether the tool obtains and renews its certificates by itself thanks to ACME, the protocol for automatically obtaining certificates used by Let's Encrypt:

CriterionHAProxyTraefikNginxApacheCaddy
ModelLB + L4/L7 proxyCloud-native edge proxyWeb server + proxyWeb serverModern web server
ConfigurationFile + runtime APIDynamic (providers)FileFileCaddyfile
Service discoveryNoDocker, K8s, ConsulNoNoNo
TLS / ACMETo be integratedBuilt inTo be integratedTo be integratedBuilt in
Web cacheNot the goalLimited (plugins)StrongDecentLimited
L4 (TCP/UDP)ExcellentGoodGoodLimitedLimited
When to choose itCritical APIs, LBContainers, K8sWeb + cacheLegacy, modulesSimplicity

Two comparisons come up almost every time and boil down to this. Traefik versus Nginx: Traefik is better suited as soon as there are containers (discovery and dynamic config), Nginx remains preferable for serving web content and handling a high-performance cache. HAProxy versus Nginx: HAProxy is the most specialized load balancer (fine health checks, runtime API), Nginx is more versatile (web + proxy + cache).

Detailed use cases

Classic website (WordPress, CMS, PHP)

Need: serve content with a cache, manage Let's Encrypt, simple configuration. Solutions: Nginx (in French) (standard, built-in cache) or Caddy (in French) (automatic HTTPS, ideal for getting started).

REST API or critical application

Need: high availability, precise health checks, minimal latency, persistent sessions. Solution: HAProxy, built for that and having been the subject of a security audit commissioned by ANSSI.

Microservices with Docker

Need: automatic discovery of containers, configuration by labels, frequent deployments. Solution: Traefik, with its Docker configuration by labels.

Kubernetes

Need: Ingress Controller, native integration, namespace management. Solution: Traefik as Ingress Controller (Gateway API, IngressRoute) or Nginx Ingress.

Homelab or service without a public IP

Need: publish an application from a network behind a router, without opening a port. Solution: Pangolin self-hosted, or cloudflared managed; ngrok is enough for a temporary trial.

Pitfalls to avoid

1. Single Point of Failure. Your reverse proxy becomes critical. Plan a second proxy in failover (a standby proxy that takes over, for example with keepalived and the VRRP protocol, which switches a virtual IP address) or a cloud load balancer in front of your proxies.

2. Forgotten X-Forwarded headers. Your backends see the proxy's IP, not the client's. Configure X-Forwarded-For (real IP) and X-Forwarded-Proto (http/https scheme).

3. Badly tuned timeouts. A timeout that is too short causes 504 errors, one that is too long keeps connections open for nothing. As a starting point (a heuristic, not an absolute rule), the proxy's timeout must exceed the backend's maximum normal processing time, otherwise the proxy gives up before the response. Measure your slowest requests before setting the value.

4. Insufficient buffers. Large uploads fail if the buffers are too small. Watch for 413 and 502 errors.

5. Unvalidated Host header. Without an allowlist, an attacker can manipulate the Host header. Always validate the allowed hosts.

Understanding 502 and 504 errors

These two codes almost always come from the reverse proxy, not from the client. A 502 Bad Gateway means the backend returned an invalid response or closed the connection: crashed backend, wrong port, TLS badly negotiated. A 504 Gateway Timeout means the backend did not answer in time: processing too long or proxy timeout too short. The reflex: check that the backend answers directly, then adjust the timeouts and the buffers.

Typical architecture

Here is a classic production architecture combining a cloud load balancer, HAProxy in active/passive and Traefik for the Kubernetes part:

Production reverse proxy architecture: Internet reaches a cloud load balancer (AWS ALB, GCP LB, Cloudflare), which sends traffic to the primary HAProxy, with failover to the standby HAProxy, and to the Kubernetes cluster's Traefik; HAProxy serves Web 1, Web 2 and API 1, Traefik serves Pod 1 and Pod 2.failoverInternetCloud load balancer(AWS ALB, GCP LB, Cloudflare)HAProxy reverse proxyprimaryHAProxy reverse proxystandbyTraefik reverse proxyK8sWeb 1Web 2API 1Pod 1Pod 2
Source · SVG
Esc to close, + and − to zoom, scroll to move around. 100 %

Go further with Traefik

Traefik is particularly suited to containers thanks to automatic discovery and its dynamic configuration. To use it, start with its configuration model, then discover publishing with Docker, TLS and ACME certificates and composing middlewares. Installation and the Kubernetes integration are separate tutorials, outside the main path of this course.

Practice

The "forgotten X-Forwarded headers" pitfall and the "terminates HTTPS" function become concrete when a second proxy is placed in front of the first. The lab has you follow a request through two chained reverse proxies to the application: you determine which link terminates TLS and which relays in clear, then you preserve the origin and identity of a legitimate client. The validation checks the TLS roles and the ports against the real traffic, rejects a spoof of X-Forwarded-For or of identity without privilege, and observes that the bypass is closed from the client.

Key points

  1. A reverse proxy is the single entry point of your infrastructure: TLS, routing and security centralized.

  2. Proxy and reverse proxy are opposites: the first acts for the clients, the second for the servers.

  3. It does 5 things: terminates TLS, routes, balances, checks health, protects.

  4. Choose according to your ecosystem: Traefik for containers, HAProxy for advanced balancing, Nginx for web and cache, Caddy for simplicity, Pangolin or cloudflared to publish without opening a port (ngrok for a temporary trial).

  5. Plan the high availability of the proxy itself: it becomes your new single point of failure.

Knowledge check

Check that the essentials of this guide are mastered. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

8 questions
8 min
70% to pass

How it works

  • The timer starts when you click Start
  • Multiple choice, true/false and short answer questions
  • You can move between questions
  • Detailed results are shown at the end

FAQ: frequently asked questions

The FAQ answers the questions that come up most often about the definition of a reverse proxy, how it differs from a load balancer, how the tools compare, automatic HTTPS, and publishing a service without opening a port.

Is this project useful to you?

The guides, courses, quizzes and labs stay free. If you use them regularly, you can contribute to their upkeep and development.

Become a supporting member (new tab) One-time support (new tab) Learn more

Follow the project on LinkedIn