Forward and reverse proxies is an important concept that a lot of technical people don't know about but it's really important and if not taken into account will bite them. I'll explain them in as few words as possible for the layman:
- A forward proxy is used when you want to access resources in the internet. Usually companies don't allow unrestricted access to the internet from their internal network. Thus the users would need to use a (forward proxy) to access the internet. What happens is that when you want to access an internet resource (i.e www.google.com) you will ask a specific server which you have configured in your client (i.e brower) for it. So instead of http://www.google.com your browser will access http://proxy.company.com/?url=www.google.com and the proxy will fetch the results and return them to you.
- A reverse proxy on the other hand is used when you have a web server but do not want to expose it to the internet (for various reasons). What happens is that you use another web server which you configure to "proxy" requests that fulfill some specific criteria to the other web server. The criteria may be requests that have a specific host or a specific port or even a particular path. A characteristic example of reverse proxy is the well-known 3-tier architecture (web server / app server / database server). The web server is used to serve all requests but it "proxies" (forwards) some of the requests to the app server. Or you can offload your SSL security to a particular web server that stores your private key and acts as a reverse proxy for your internal web servers. Or you have an app server that can't serve static files (i.e gunicorn) and you need to put an nginx in front to be used as a reverse proxy to serve these files and pass the other requests to the app server. Or you can use an akamai reverse proxy to protect your server.
Notice that while there's only one forward proxy, there could be a (large) chain of reverse proxies when accessing a server. I.e when a user accesses www.example.com the request may pass through: akamai -> nginx (ssl) -> varnish (cache) -> app server.
Forward proxies work the same way in terms of chaining. There's only one user-visible proxy but there might be chain of forward proxies if that's how your org decided to structure things. It's not too unreasonable for $department proxy to run its own filtering logic and then pass the request upstream to $corporate proxy.
TBH we only ever had two levels but cache_peer worked fine for us. I can’t really remember running into many headaches with it. We were more concerned with auditing and caching than actively blocking which might be the pain point. We didn’t try to pass along user identities or define groups at the root level.
When you hand your friend a letter and ask them to mail it from their mailbox, that friend acts as a forward proxy. The post office doesn't know from whom the letter originates, only that the friend sent it.
When you go to the post office and hand the clerk your letter, that clerk acts as a reverse proxy. You don't know what happens to the letter from that point on.
Common cases:
Say your friend provides this service for your entire town, then they're acting as a privacy VPN (since now the post office can only say a particular letter is from the town).
Say you want to send a letter to that celebrity but the celebrity's security team will toss any envelope not on the approved list. So you ask your friend, who is on that list, to put your letter in their envelope so it'll get through. Now your friend is acting as an access VPN.
I think the comment is clearer than the linked content as a basic explanation. The linked content covers "the difference" with two bullet points, and uses the term "origin server" which isn't super-intuitive.
One can only be bombarded with Medium popups and other modern web annoyances for so long… I typically gain more from the comments than the articles themselves, but YMMV.
I like the consistency of HN's style, instead of being pushed to a random website that may have all kinds of pop ups and distractions. I wish there was like a "HN Reader Mode" that would convert the content of the website to look like a HN comment for me.
OP started their comment with: "Forward and reverse proxies is an important concept that a lot of technical people don't know about but it's really important... I'll explain them in as few words as possible..."
It's far simpler than this. If you get the basics of http, the only thing you need to know is what is the 'proxy' a proxy (stand-in) for? the client (forward) or server (reverse).
If people used the names client proxy and server proxy it would be much clearer. Calling one forward and one reverse means you have to know the order of popularity of usage which is dumb thing to settle on.
This is a common mnemonic, but it also has a common flaw, which is easily reached by application of a modicum of overthought: Both proxies always act as both servers and clients; just to different sides, one in the direction of requests (forward), another against (reverse).
At least that's where I end up every time I have to remind myself which is which.
I find the "reverse" naming so confusing. To me it makes it sound like the http request goes backwards or something like that which makes no sense. What you suggest should be the way to word it.
As far as I can tell, the article is just choosing to use that term.
There’s an origin concept in HTTP/browser security (see link), but the “origin” here appears to be different.
It seems potentially confusing, so maybe they could simply use the term “server” instead of “origin server”. That fits in well with “client” and “proxy”.
- A forward proxy is used when you want to access resources in the internet. Usually companies don't allow unrestricted access to the internet from their internal network. Thus the users would need to use a (forward proxy) to access the internet. What happens is that when you want to access an internet resource (i.e www.google.com) you will ask a specific server which you have configured in your client (i.e brower) for it. So instead of http://www.google.com your browser will access http://proxy.company.com/?url=www.google.com and the proxy will fetch the results and return them to you.
- A reverse proxy on the other hand is used when you have a web server but do not want to expose it to the internet (for various reasons). What happens is that you use another web server which you configure to "proxy" requests that fulfill some specific criteria to the other web server. The criteria may be requests that have a specific host or a specific port or even a particular path. A characteristic example of reverse proxy is the well-known 3-tier architecture (web server / app server / database server). The web server is used to serve all requests but it "proxies" (forwards) some of the requests to the app server. Or you can offload your SSL security to a particular web server that stores your private key and acts as a reverse proxy for your internal web servers. Or you have an app server that can't serve static files (i.e gunicorn) and you need to put an nginx in front to be used as a reverse proxy to serve these files and pass the other requests to the app server. Or you can use an akamai reverse proxy to protect your server.
Notice that while there's only one forward proxy, there could be a (large) chain of reverse proxies when accessing a server. I.e when a user accesses www.example.com the request may pass through: akamai -> nginx (ssl) -> varnish (cache) -> app server.