A reverse proxy is a server that sits in front of one or more web servers and forwards client requests to them. Visitors connecting to a website never speak directly to the application server. The reverse proxy intercepts the request, decides where to send it, and returns the response as if it came from itself. Most users don't know a reverse proxy exists, which is exactly the point.
Forward proxy vs reverse proxy: what's the difference?
The naming is easy to mix up. A proxy server in the traditional sense sits on the client's side: it sends requests on behalf of a user, masking the user's identity from the destination server. A reverse proxy sits on the server's side, masking the identity of the backend servers from the user. Same concept, opposite direction.
Think of it this way. A forward proxy protects the client. A reverse proxy protects the server.
What a reverse proxy actually does
A reverse proxy performs several distinct jobs depending on how it's configured.
Load balancing. If a website runs on 4 application servers, a reverse proxy distributes incoming requests across all 4. One user's request goes to server A, the next to server B, and so on. No single server gets crushed. This is how large-scale platforms handle millions of simultaneous connections without collapsing.
SSL termination. Encrypting and decrypting HTTPS traffic is computationally expensive. A reverse proxy can handle all the SSL handshakes, then forward unencrypted traffic to backend servers over a private internal network. The backend servers don't carry the encryption load at all.
Caching. A reverse proxy can store copies of frequently served responses and return them directly without touching the application server. A product page viewed 10,000 times per hour doesn't need to query the database 10,000 times. The proxy serves the cached version and the backend barely notices. This overlaps with how a CDN works, though a CDN distributes those cached copies across dozens of global locations rather than one central proxy.
Security filtering. Because all traffic passes through it first, a reverse proxy is a natural place to block suspicious requests. It can reject traffic from known malicious IP addresses, rate-limit aggressive bots, and strip headers that reveal information about the backend infrastructure.
Compression. A reverse proxy can compress responses before sending them to clients, reducing bandwidth and speeding up load times without any changes to the application code behind it.
How the request flow works, step by step
Here's what happens when you load a webpage protected by a reverse proxy:
- Your browser sends an HTTP or HTTPS request to the website's domain (e.g. example.com.au).
- DNS resolves that domain to the IP address of the reverse proxy, not the application server.
- The reverse proxy receives the request and checks its rules: is this IP blocked? Is this response already cached? Which backend server should handle this?
- The proxy forwards the request to the selected backend server over the internal network.
- The backend processes the request and returns a response to the proxy.
- The proxy forwards that response to your browser.
The whole exchange typically takes under 20 milliseconds. You see a webpage. You never see any of this.
Common reverse proxy software
Nginx is the most widely deployed reverse proxy in the world. It's lightweight, handles high concurrency well, and doubles as a web server. Apache HTTP Server can also act as a reverse proxy using its mod_proxy module, though Nginx has largely displaced it in this role for high-traffic deployments. HAProxy is a specialist load balancer used at enormous scale, and Traefik has grown popular in containerised environments because it integrates directly with Docker and Kubernetes.
Why the hidden server matters for security
One underappreciated benefit of a reverse proxy is that the backend servers have no publicly visible IP addresses. An attacker trying to flood an application with traffic has to go through the proxy first. The application server is effectively invisible to the open internet. This doesn't stop every attack, but it raises the cost of targeting your infrastructure significantly.
A firewall controls what traffic reaches your network at all. A reverse proxy controls which of that traffic reaches your application. They're complementary tools doing different jobs. Understanding how a firewall protects your network gives context for why a reverse proxy adds a second layer of defence on top of it.
When you'd actually use one
A personal blog on shared hosting doesn't need a reverse proxy. A platform serving 50,000 concurrent users does. So does any service that runs multiple backend applications under one domain (a public API at api.example.com.au, a user dashboard at app.example.com.au, and a static marketing site at example.com.au, all served through one proxy that routes requests by path or subdomain).
Reverse proxies are also standard practice in microservices architectures, where dozens of small applications handle different functions and a proxy stitches them together behind a single address. Without the proxy, clients would need to know the address of every individual service. With it, they just hit one endpoint and the proxy handles the routing internally.
Reverse proxy vs API gateway
An API gateway is a more specialised kind of reverse proxy built specifically for managing API traffic. It adds features like authentication, rate limiting per API key, request transformation, and developer analytics on top of basic proxying. Many teams start with a general-purpose reverse proxy like Nginx and later add a dedicated API gateway as their API surface grows. The distinction matters when you're designing a system, not when you're just using one.
The reverse proxy is one of those infrastructure components that most Australians interact with dozens of times a day without knowing it exists. Every major bank, streaming service, and e-commerce platform in the country relies on one. It's unglamorous, largely invisible, and close to essential.