People say "proxy" and mean two opposite machines. One is the thing you buy to hide your own address while you scrape or browse. The other is the thing standing guard in front of the website you are trying to reach, the Cloudflare or nginx layer that decides whether to let you in. Both are proxies. They point in opposite directions, they protect opposite parties, and confusing them is why a lot of proxy conversations talk straight past each other.
We run a proxy network, so untangling this is worth a few minutes: the exact definition of each, the one question that tells them apart instantly, and the reason a single request routinely passes through both without them ever fighting.
The definitions, from the HTTP spec
The cleanest source here is the protocol itself. RFC 9110, which defines HTTP semantics, names the two intermediaries precisely.
A proxy (the forward kind, the default meaning of the word) is "a message-forwarding agent that is chosen by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface." The load-bearing phrase is chosen by the client. You configure your software to use it. It works for you.
A gateway, the spec continues, "(a.k.a. 'reverse proxy') is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers." The load-bearing phrase here is acts as an origin server. To the outside world it looks like the website. Behind it sit the real servers it is shielding. It works for the destination.
MDN puts the same split in one sentence: "forward proxies can hide the identities of clients whereas reverse proxies can hide the identities of servers." That is the whole distinction, and everything else is a consequence of it.
The one question that tells them apart
Who chose to put the proxy there?
If you put it in your path, by configuring your browser, your scraper, or your operating system to route through it, it is a forward proxy. It exists to represent you: to change the IP a site sees, to reach the internet from inside a restricted network, to filter or cache on the way out. The website has no idea it exists and did not ask for it.
If the site owner put it in front of their servers, so that every visitor hits it whether they like it or not, it is a reverse proxy. It exists to represent the servers: to spread load across them, to cache their responses, to terminate TLS, to inspect and filter incoming traffic before it reaches anything real. You did not choose it and you cannot route around it, because it is the front door.
Same relay technology, opposite ownership, opposite beneficiary.
How one request hits both
Here is the picture that makes it click. These two are not alternatives you pick between, they are two ends of the same journey, and a real request often meets one of each.
Your scraper routes out through a forward proxy that swaps your real IP for a residential one. That request crosses the internet and arrives not at the website's server but at its reverse proxy, a CDN or web application firewall like Cloudflare, which inspects it, checks its reputation and fingerprint, and only then forwards it inbound to the origin if it passes. Your forward proxy is doing its job (the site sees a home IP, not yours) at the exact moment the site's reverse proxy is doing its job (the origin never talks to the internet directly). They do not conflict because they are solving opposite problems.
This is also the missing context in most "why did my proxy get blocked" questions. The block did not come from your forward proxy, it came from the target's reverse proxy, the anti-bot layer, which we take apart in how websites detect proxies. Understanding that the wall you are hitting is a reverse proxy reframes the whole problem: you are not fighting the website's application, you are getting past its gatekeeper first.
What each side is actually for
Forward proxies exist to serve the client. The uses line up with why anyone buys proxies:
- Changing the IP a destination sees, which is the entire job of a residential or datacenter proxy.
- Reaching the outside internet from inside a corporate or restricted network, often with filtering and logging on the way out.
- Caching common responses for a group of users to save bandwidth.
Reverse proxies exist to serve the destination. MDN lists the classic jobs: load balancing to "distribute the load to several web servers," caching static content to "offload the web servers," and compression to "speed up load time." Add to that TLS termination and, increasingly, bot management. Cloudflare, Akamai, nginx, and HAProxy in reverse mode are all this category. A reverse proxy is infrastructure you deploy for a service you host, not something you route your outbound traffic through.
The header footnote, because it trips people up
Because proxies sit in the middle, HTTP has headers that describe them, and they behave differently for each type. X-Forwarded-For records "the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer," which is how a reverse proxy passes the real visitor IP inbound to the origin that would otherwise only see the proxy. Via is "added by proxies, both forward and reverse," and describes the proxy itself rather than the client.
That first header is also where a forward proxy can betray you. A transparent forward proxy inserts your real IP into X-Forwarded-For, an elite one adds nothing, which is the entire basis of the transparent, anonymous, and elite grades you see on proxy lists. A SOCKS5 forward proxy sidesteps the issue by operating below the HTTP layer where those headers live, which we cover in what is a SOCKS5 proxy. None of this applies to reverse proxies, which are on the other end doing the opposite job.
RFC 9110 rounds out the set with a third intermediary, the tunnel, "a blind relay between two connections without changing the messages," which is how an HTTP proxy carries HTTPS it cannot read. Useful to know the term, but for the forward-versus-reverse distinction, tunnel is a mechanism, not a side.
The takeaway
Forward and reverse proxies are the same idea aimed in opposite directions: one stands in front of clients to represent them, the other stands in front of servers to represent them. When you buy a proxy to change what a website sees, you are buying a forward proxy, and ours are built to be convincing forward proxies, real residential and ISP IPs that read as genuine users to whatever reverse proxy is guarding the far end. Know which one you are dealing with in any given sentence, and half the confusion in this field disappears.
Sources and further reading
- RFC 9110: HTTP Semantics. Section 3.7 defines the three intermediaries: proxy (chosen by the client), gateway (a.k.a. reverse proxy, acting as an origin server while forwarding inbound), and tunnel (a blind relay).
- MDN, "Proxy servers and tunneling". Forward proxies hide clients, reverse proxies hide servers, the reverse-proxy jobs of load balancing, caching, and compression, and how the
X-Forwarded-ForandViaheaders work.