Forward and Reverse Proxies Explained | Hacker News Reader

Forward and Reverse Proxies Explained

haskellforall.com

113 pointstodsacerdoti21 comments

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.

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::

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.

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

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

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.

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.

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.

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.

This doesn't have to be hard to remember. Don't let the proxy being a server complicates the view.

What does the proxy look like 'to the internet', a client or a web server?

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.

It's interesting that 20-30 years ago when someone mentioned setting up a proxy, they meant forward proxy. Now the default is the reverse one.

Crystal clear!

Out of curiosity, why do they call destination server an "origin"?

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

https://datatracker.ietf.org/doc/html/rfc6454

Reply on news.ycombinator.com