Forward vs Reverse Proxy: What Each One Does
Forward and reverse proxies are often confused. This explains who each one acts for, how they sit in the request path, and which one you need for scraping.
- proxy-basics
- networking
Forward proxy and reverse proxy describe the same technology pointed in opposite directions. The difference is who the proxy represents. Get that clear and the rest of the terminology falls into place.
Forward proxy: acting for the client
A forward proxy sits between clients and the wider internet, and it acts on the client's behalf. You configure it in a browser, a script, or an environment variable, and every request you send is relayed through it.
The origin server sees the forward proxy's IP address rather than the client's. Common uses:
- Masking the client's IP and ASN for scraping and automation.
- Reaching content that is restricted to certain regions.
- Applying a shared egress policy or filter for a team.
- Centralising outbound traffic so it can be logged or rate limited per client.
This is the topology almost everyone means when they talk about proxies for data collection. If you are configuring a proxy in requests, curl or a browser profile, you are using a forward proxy. Our introduction to what a proxy server is walks through the full request path.
Reverse proxy: acting for the server
A reverse proxy sits in front of one or more origin servers and acts on their behalf. Clients connect to the reverse proxy believing it is the site, and the reverse proxy decides what to do with the request.
Typical jobs:
- Terminating TLS so the application servers do not have to.
- Load balancing across several application servers.
- Caching responses to reduce load on the origin.
- Buffering slow clients and absorbing traffic spikes.
- Filtering malicious requests and hiding the application servers' topology.
If you have used nginx or a cloud load balancer in front of an app, you have deployed a reverse proxy. You did not have to configure anything on the client side, because the client never knew it existed.
Why the distinction matters in practice
The confusion usually shows up in three places.
Configuration location. A forward proxy is configured on the client. A reverse proxy is configured on the server. If you are looking for where to put proxy credentials, you are dealing with a forward proxy.
Who benefits from anonymity. A forward proxy hides the client from the origin. A reverse proxy hides the origin's internals from the client. Neither hides both.
Rotation semantics. Forward proxies are the ones you rotate per request or per session, because you are controlling many client identities. Reverse proxies are usually stable endpoints, and any rotation happens behind them.
The layered reality
Real systems often use both at once. A scraper (client) sends requests through a forward proxy, which connects to a site that is itself sitting behind a reverse proxy or CDN. Two proxies, different jobs, in the same request path.
That layering is worth remembering when something fails. A 403 might be the origin's reverse proxy rejecting your forward proxy's IP. A 407 is your forward proxy asking for credentials. Read the status code and the connection stage together, and you can usually tell which hop is unhappy.
Which one do you need?
For scraping, geo testing, ad verification, multi-account management and anything else where you control the client: a forward proxy.
For serving your own application with TLS, load balancing or caching, and you own the backend: a reverse proxy.
Both are ordinary infrastructure. The useful question is not which is better, but which side of the connection you are trying to change. Once you have decided you need a forward proxy, the next choice is the IP type, and Residential vs Datacenter Proxies covers that trade-off in detail.