Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've seen people recommend combining all of these in a flow, but they seem to have lots of overlapping features so I'd like to dig in to why you might want to pass through 3 different programs before hitting your actual web server.


  • ssl: yes
  • compress: yes
  • cache: yes
  • backend pool: yes


  • ssl: no (stunnel?)
  • compress: ?
  • cache: yes (primary feature)
  • backend pool: yes


  • ssl: no (stunnel)
  • compress: ?
  • cache: no
  • backend pool: yes (primary feature)

Is the intent of chaining all of these in front of your main web servers just to gain some of their primary feature benefits?

It seems quite fragile to have so many daemons stream together doing similar things.

What is your deployment and ordering preference and why?

share|improve this question
Varnish now has SSL support: see… – MiniQuark Mar 16 '13 at 21:23
you ment to say HAProxy? – Luis Lobo Borobia Aug 1 '13 at 3:00
Nginx seems to have everything, so I'd say just use nginx. – Seun Osewa Jul 5 '14 at 8:19
up vote 42 down vote accepted

Simply put..

HaProxy is the best opensource loadbalancer on the market.
Varnish is the best opensource static file cacher on the market.
Nginx is the best opensource webserver on the market.

(of course this is my and many other peoples opinion)

But generally.. not all queries go through the entire stack..

Everything goes through haproxy and nginx/multiple nginx's.
The only difference is you "bolt" on varnish for static requests..

  • any request is loadbalanced for redundancy and throughput ( good, thats scalable redundancy )
  • any request for static files is first hitting the varnish cache ( good, thats fast )
  • any dynamic request goes direct to the backend ( great, varnish doesnt get used)

Overall, this model fits a scalable and growing architecture ( take haproxy out, if you dont have multiple servers )

Hope this helps :D

Note: I actually also introduce Pound for SSL queries aswell :D
You can have a server dedicated to decrypting SSL requests, and passing out standard requests to the backend stack :D (It makes the whole stack run quicker and simpler )

share|improve this answer
Very interesting, especially the part about the decryption server. +1 – Gerry Sep 17 '11 at 5:21
Awesome answer. I'm wondering what sits in front of everything? Is it HAProxy or Nginx? – John Mar 12 '12 at 23:48
@John: [Client -> HAProxy -> Varnish -> Nginx -> Static Content] or [Client -> HAProxy -> Nginx (optional) -> Application Server (dynamic content)] – MiniQuark Mar 16 '13 at 21:25
Why would you cache static and serve dynamic? Nginx is lightning fast for serving up static files. I prefer to use a stack like [HAProxy -> Nginx] for static and [HAProxy -> Nginx -> Varnish -> Apache] to implement a cache on the dynamic. Terminating SSL at the load balancer as you stated with dedicated terminating nodes. – Steve Buzonas Dec 11 '13 at 18:26

It's true that the 3 tools share common features. Most setups are fine with any combination of 2 among the 3. It depends what their main purpose is. It's common to accept to sacrifice some caching if you know your application server is fast on statics (eg: nginx). It's common to sacrifice some load balancing features if you're going to install tens or hundreds of servers and don't care about getting the most out of them nor about troubleshooting issues. It's common to sacrifice some web server features if you're intending to run a distributed application with many components everywhere. Still, some people build interesting farms with all of them.

You should keep in mind that you're talking about 3 solid products. Generally you won't need to load balance them. If you need front SSL, then nginx first as a reverse-proxy is fine. If you don't need that, then varnish on the front is fine. Then you can put haproxy to load balance your apps. Sometimes, you'll like to also switch to different server farms on the haproxy itself, depending on file types or paths.

Sometimes you'll have to protect against heavy DDoS attacks, and haproxy in front will be more suited than the other ones.

In general, you should not worry about what compromise to do between your choices. You should choose how to assemble them to get the best flexibility for your needs now and to come. Even if you stack several of them multiple times it may sometimes be right depending on your needs.

Hoping this helps!

share|improve this answer
+1 for HAProxy -- the author responds to questions on Server Fault. Thanks. – Joel K Nov 21 '10 at 5:33
Arenstar: Did you write one of these tools? Willy Tarreau is the principle developer of HAProxy. – Joel K Nov 21 '10 at 20:24
Thanks for this Willy. You answered my question to Arenstar above. – John Mar 13 '12 at 0:10
Note that current development code for HAProxy now includes SSL. – Joel K Oct 30 '12 at 5:39

All other answers are pre-2010, hence adding an updated comparison.


  • A full web server, other features can also be used. Eg: HTTP Compression
  • SSL Support
  • Very light weight as Nginx was designed to be light from the start.
  • Near Varnish caching performance
  • Close to HAProxy load balancing performance


  • best for complex caching scenarios and incorporating with the applications.
  • best static file cacher
  • No SSL Support
  • Memory and CPU eater


  • best loadbalancer, for cutting edge load balancing features, comparable to hardware loadbalancers
  • SSL is supported since 1.5.0
  • Simpler, being just a tcp proxy without an http implementation, which makes it faster and less bug prone.

So the best method seems to be implementing all of them in an appropriate order.

However, for general purpose, Nginx is best as you get above-average performance for all: Caching, Reverse proxying, Load balancing, with very little overhead on resource utilization. And then you have SSL and full web server features.

share|improve this answer

Varnish has support for load balancing:

Nginx has support for load balancing:

I would simply configure this with varnish + stunnel. If I needed nginx for some other reason, I would just use nginx + varnish. You can have nginx accept SSL connections and proxy them to varnish, then have varnish talk to nginx via http.

Some people may throw nginx (or Apache) into the mix because these are somewhat more general purpose tools than Varnish. For example, if you want to transform content (e.g., using XDV, apache filters, etc) at the proxy layer you would need one of these, because Varnish can't do that by itself. Some people may just be more familiar with the configuration of these tools, so it's easier to use Varnish as a simple cache and do the load balancing at another layer because they're already familiar with Apache/nginx/haproxy as a load balancer.

share|improve this answer
Right -- "backend pool" was meant to point out that all three of these have load balancing features. From my initial investigation it seems that HAProxy has the most tunable load balancing options. – Joel K Nov 19 '10 at 18:00
That sounds reasonable, since it's been purpose-built as a load balancing tool. On the other hand, Varnish's load balancing features are pretty good, and removing one process from this mix gets your a simpler configuration with less latency. – larsks Nov 19 '10 at 18:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.