Nginx reverse proxy or squid forward proxy (transparent)

I don't think that there is a way to explicitly invalidate cached items, but here is an example of how to do the rest. Update: As mentioned by Piotr in another answer, there is a cache purge module that you can use. You can also force a refresh of a cached item using nginx's proxy_cache_bypass - see Cherian's answer for more information.

In this configuration, items that aren't cached will be retrieved from example.net and stored. The cached versions will be served up to future clients until they are no longer valid (60 minutes).

Your Cache-Control and Expires HTTP headers will be honored, so if you want to explicitly set an expiration date, you can do that by setting the correct headers in whatever you are proxying to.

There are lots of parameters that you can tune - see the nginx Proxy module documentation for more information about all of this including details on the meaning of the different settings/parameters: http://nginx.org/r/proxy_cache_path

http {
  proxy_cache_path  /var/www/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
  proxy_temp_path /var/www/cache/tmp; 


  server {
    location / {
      proxy_pass http://example.net;
      proxy_cache my-cache;
      proxy_cache_valid  200 302  60m;
      proxy_cache_valid  404      1m;
    }
  }
}

Six long years and nobody has ventured a response. Well, I've got a bit of hindsight to complement experience so I'll proffer one.

Q1. Maybe. If you don't mind adding the complexity of cluster to your app, and you're careful to avoid anything that might throw in the master process, then cluster works great. Otherwise, you certainly want something to handle supervising your node process and restarting it when your app crashes. Your OS might provide alternatives such as daemon or systemd.

Q2. No. At best, on a good day with the wind at its back, node-http-proxy is almost as good as nginx or haproxy. Excluding SSL where both haproxy and nginx are much better. It'd be awfully hard to build a case for it being more suitable.

Q3. Yes, or haproxy. Until you have the need to introduce varnish. When you get to that point, you won't have to wonder if you should be using varnish. (Or you'll use a CDN).

Q4. Your call. Haproxy is my default tool of choice for TLS termination and proxying. I don't hate myself enough to put something as critical as a load balancer on someone else's server where I can't run tcpdump or other troubleshooting tools.

1. Yes. If you known nginx well, then use it to handle the HTTPS termination and proxying the requests to your app servers. If you aren't heavily into nginx already, consider haproxy instead. With a name like haproxy, you'd expect it to be really really good at HA and proxying and it doesn't disappoint.

2. haproxy / nginx. Always. Better certificate management, listing at cipherli.st, etc. There's also less impact to your app to upgrade the proxy when openssl vulnerabilities are released.

3. haproxy. (nginx supports proxying websockets now, so this question is past it's expiration date).

4. Multiple sites and BGP. Introducing tools like keepalived or other peer-to-peer TCP failover mechanisms to your stack is just as likely to be the cause of an outage as to prevent one. The use of such tools is typically rare so the human with site knowledge of it is out of practice when the necessity arises. Keep the stack simpler and depend on the skills of your network team. They are well practiced at routing around problems.