Comment by spapas82 | Hacker News Reader

Comment by spapas82 | Hacker News Reader

Parent Full thread

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.

In practice, setting up forward proxy chaining with squid is extremely difficult. What product do you do it with?

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.

By way of metaphor:

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.

Minor nitpick.

You might also have many reverse proxy depending on network topography, security posture, and segmentation.

Great write up for the uninitiated! ::has fever dreams in BlueCoat::

Why did you felt you had to explain what is already in the link ?

The application examples are not in the linked text and I have found them interesting and useful for my understanding.

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.

Many HN readers only read HN comments, not the articles themselves. Sad but true.

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..."

Reply on news.ycombinator.com