Forward Proxy vs Reverse Proxy ✨
#77: Break Into Proxy Servers (4 Minutes)
Get my system design playbook for FREE on newsletter signup:
This post outlines the differences between a forward proxy and a reverse proxy. You will find references at the bottom of this page if you want to go deeper.
Share this post & I'll send you some rewards for the referrals.
Imagine a family with a small kid on a tourist visit to Italy.
They visit a local restaurant for lunch.
The kid then tells her father that she needs 9 ice creams.
But the father orders only a single ice cream when the waiter arrives.
(The forward proxy works similarly.)
The kid is like the client, while the father is like the forward proxy.
The father filters the kid's request and speaks to the waiter in Italian on her behalf.
Likewise, the forward proxy filter requests, provides compatibility layers, and reduces unnecessary requests. This approach offers performance.
The waiter then passes their order to the kitchen expeditor.
And he informs the right chef to prepare the ice cream.
(The reverse proxy works similarly.)
Think of the waiter as the internet layer.
And the kitchen expeditor is like the reverse proxy, while the chef is like the server.
The waiter doesn’t have to enter the kitchen or talk directly to the chef.
Likewise, a reverse proxy protects the server by avoiding direct exposure to the internet.
Onward.
“How to Adopt Externalized Authorization: Step-By-Step Roadmap” Ebook by Cerbos - Sponsor
Hardcoded authorization logic doesn't scale. As your application, requirements, and users grow - it turns into a bottleneck, slowing you down, creating security gaps, and making compliance a mess.
If you’re thinking about moving from hardcoded permissions to externalized authorization, this 10-step playbook will guide you:
Step-by-step adoption strategy from planning to PoC rollout
Frameworks, policy examples, code samples + 80 pages of in-depth content
Lessons from teams who've made the transition
If you're dealing with authorization complexity, this might save you some trial and error.
Forward Proxy
The forward proxy sits between the client and the Internet.
Think of the forward proxy as a funnel; all traffic goes through it. Yet it checks whether a request is allowed.
Also it’s necessary to configure the client to use the forward proxy.
Here’s how it works:
The client sends a request to the forward proxy
The forward proxy passes the request to the Internet
The forward proxy receives the response from the server
The forward proxy then passes it to the client
Schools and corporate networks often install a forward proxy to control the sites people can visit. And one can set up a forward proxy using Nginx or Squid.
Here are some popular use cases of the forward proxy:
Caching: It stores frequently accessed sites to reduce network bandwidth and latency. This improves the user experience in a shared network.
Request filtering: It blocks access to specific sites based on predefined policies.
Anonymity: It masks the client’s IP address for privacy and makes it difficult to track user activity.
Put simply, a forward proxy acts as a gateway to the Internet.
But a forward proxy could add latency as it introduces an extra network hop. Also it increases administrative overhead as client setup is necessary. So use it only if necessary.
Ready for the best part?
Reverse Proxy
Both forward proxy and reverse proxy send client requests to the server.
But a forward proxy belongs to the client side, while a reverse proxy belongs to the server side. It means the difference between them is in the direction from which you look at them.
The reverse proxy sits between the Internet and the server.
Here’s how it works:
The client sends the request to the reverse proxy
It forwards the request to the server
The server responds to the reverse proxy
The reverse proxy then forwards it to the client
The client interacts with the reverse proxy as if it’s the origin server. And one can set up a reverse proxy using Nginx or HAProxy.
Here are some popular use cases of the reverse proxy:
TLS termination: It decrypts the incoming traffic. Thus freeing up server resources for performance.
Load balancing: It routes requests uniformly across servers for scale and reliability.
Security: It avoids direct server exposure to the internet. And reduces the risk of DDoS by hiding its IP address. Also it drops unnecessary incoming traffic.
Caching: It stores static content, such as images, to reduce server load and latency.
A/B testing: It allows for testing a newer app version with a subset of users by routing traffic only to specific servers.
Authentication & Authorization: It verifies the client ID and checks if the client is allowed to perform a specific action.
Put simply, the reverse proxy acts as a gateway from the Internet.
But a reverse proxy adds operational complexity. Besides it could become a single point of failure without redundancy. So use it based on your needs and scale.
Subscribe to get simplified case studies delivered straight to your inbox:
Want to advertise in this newsletter? 📰
If your company wants to reach a 160K+ tech audience, advertise with me.
Neo’s recommendation 🚀
Want instant code feedback and catch bugs quickly? CodeRabbit helps you by spotting bugs, providing one-click fix suggestions, and reviewing as you write code. Try CodeRabbit's VS Code extension for free.
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
TL;DR 🕰️
You can find a summary of this article here. Consider a repost if you find it helpful.
My rule of thumb is: forward proxy hides the client, reverse proxy hides the server.
Thanks for the clear breakdown, Neo.
Thanks, Neo! Awesome illustrations as well.