These three terms get used interchangeably, and it does not help that a single Nginx config can be any of them. The confusion is understandable: from the outside they are identical. One address accepts requests and something else answers them.
The distinction is not in the front. It is in what is behind it.
flowchart LR
accTitle: Three entry-point patterns
accDescr: A client reaches a single entry point. A reverse proxy routes to one backend, a load balancer to copies of one backend, and an API gateway to different backends.
C[Client] --> E[Single entry point]
E -->|reverse proxy| B1[One backend]
E -->|load balancer| B2[M copies of one backend]
E -->|API gateway| B3[N different backends]That is the entire taxonomy. Everything else is detail.
Reverse proxy — one backend
One entry point, one service behind it. A reverse proxy intermediates before passing the request along, and it exists to do something to the request on the way through: terminate TLS, validate credentials, rewrite a header, transform the body, or serve a cached response. In theory there is one entry point and one backend.
The canonical use is exposing something that cannot be exposed directly. A machine on 192.168.0.12 is firewalled off from the internet; a machine on a public address accepts connections and forwards them inward. Clients only ever talk to the public one and generally have no idea the other exists.
By checking credentials in advance and transforming requests before they reach the service, a reverse proxy adds a layer of both security and flexibility. The value is interposition: you have a place to put behaviour that belongs in front of the service rather than inside it.
Load balancer — many copies of one backend
One entry point, M identical instances behind it. Now the job is distribution: spreading incoming traffic across the copies according to some decided strategy — round robin, least connections, or weighted if the machines differ in capacity. The idea is to run multiple instances of a service while presenting a single entry point that handles them all.
This is the horizontal scaling primitive. You add capacity by adding instances, and the balancer is what makes them look like one address to the outside world. It optimises resource utilisation, prevents any single instance becoming a bottleneck, and keeps things running smoothly under high traffic.
Two things usually come with it. Health checks, so an instance that stops responding is taken out of rotation rather than continuing to receive a third of your traffic. And session affinity, so a client that needs to keep hitting the same instance can — though needing that at all is usually a sign of state living somewhere it should not.
API gateway — many different backends
One entry point, N distinct services behind it. The gateway routes on the content of the request, because the backends are not interchangeable: /users goes to one service, /orders to another. The idea is to group multiple different services behind one public API, which streamlines development and gives clients a single coherent surface.
Once you are inspecting requests in order to route them, it becomes cheap to do other things at the same time, and gateways accumulate features accordingly — authentication, rate limiting, quotas, request and response transformation, API key management, and per-consumer policy. Gateways can also perform validations, ensuring the integrity of a request before it is passed along.
That is the real difference from a load balancer. A load balancer forwards; a gateway forwards and enforces. It is the natural home for policy that would otherwise be reimplemented, inconsistently, in every service.
What the software actually does
Consider Nginx. Acting as a reverse proxy, it can distribute incoming requests among multiple copies of the same backend — which makes it a load balancer. It can equally handle N different backends, which makes it suitable as an API gateway. So can Envoy, HAProxy, and Traefik.
The key factor is the intended purpose of the incoming traffic: whether you are distributing to multiple distinct services, scaling multiple instances of one service, or intermediating to validate and transform. The category is determined by the topology you deploy, not by the binary. Asking "is this a reverse proxy or a load balancer" is a question about your architecture, not your software choice.
A reverse proxy can additionally reduce load on the backend by caching objects. It is worth noting that load balancers and API gateways are generally non-caching services, whereas something like CloudFront acts as a reverse proxy with caching built in.
Comparing load balancers with API gateways directly, the gateway is far more extensible. A load balancer principally forwards requests. A gateway can inspect authenticated endpoints for tokens, manipulate requests before forwarding them — running them through a lambda processor, for instance — manage quotas, and integrate with identity providers.
Cloud products blur the lines further. AWS Application Load Balancer performs content-based routing, which is gateway behaviour. CloudFront is a CDN that is also a caching reverse proxy. API Gateway is a managed gateway that also balances. The labels are marketing; the topology is what you should reason about.
NOTE
Caching is worth separating out from all of this. It is a feature some implementations offer, not a property of any of the three categories — a reverse proxy may cache, a gateway may cache, a plain load balancer usually does not. Whether caching is available is a question about the specific product, not about which of these three shapes you have drawn.
A worked example
It helps to start simple and add complexity a step at a time.
Scenario 1 — reverse proxy. Two machines. Machine A sits on 192.168.0.12 and is not reachable from the internet because of firewall rules. Machine B has the public address 1.1.1.1. Internet users connect to Machine B, unaware that their requests are transparently forwarded on to Machine A. This is commonly called port forwarding, or reverse proxying.
Scenario 2 — load balancing. Now there are two machines doing the same work, on 192.168.0.12 and 192.168.0.13, both firewalled off from direct access. Instead of a simple forward, we distribute user requests evenly between them, improving performance and making better use of the hardware. The balancer can be configured to send more traffic to .13 if that machine can handle a heavier load, and rules can maintain session consistency so that a user routed to .13 keeps going to .13.
Scenario 3 — API gateway. We now want API call limits and authentication. Rather than implementing these on each machine individually, we consolidate them into the entry point, which effectively turns it into a gateway. It takes charge of access control, call limits, and throttling for .12, .13, and any servers added later. Centralising it this way keeps API management coherent and applies security measures consistently across the system.
Each step adds a capability the previous one lacked, and none of them requires replacing the software — usually just extending its configuration.
Conclusion
The three tend to arrive in this order as a system grows: one firewalled machine behind a public host, then a second identical instance with traffic spread between them, then authentication and rate limiting moving to the front because implementing them per-service means implementing them inconsistently.
Which is why the terms get muddled. They are not three different tools competing for the same job. They are three points on one line, and most systems walk along it as they grow.
Understanding which point you are at matters, because it tells you where a given piece of behaviour belongs. Whether you are consolidating services, balancing load across instances, or ensuring requests are validated before they reach anything important, the topology is what determines your options for performance, scalability, and security.