Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 serveral backends (one is nginx+passenger) to combine via ESI. Since I don't want to go without gzip/deflate and SSL varnish can't do the job out of the box. So I thought about the following setup:

What do you think? overkill?

share|improve this question
I can't make heads or tails of that diagram. – cagenut Dec 18 '09 at 18:42

Do you need varnish at all?

1. nginx can cache results on disk or in memcached
2. nginx has SSI
3. nginx has fair load balancer or ey-balancer
4. Best practice says that HAProxy before nginx is good move.

Don't forget about KISS - more components your system has - less stable it becomes.

share|improve this answer
Moreover, Nginx SSI is much better and more featured than the Varnish ESI... – Thomas Decaux Aug 14 '12 at 10:11

Based on the diagram, I'm not sure exactly what what you're trying to do (what is ESI?). However, there's a small, fast load-balancing front-end server called "pound" and it will handle the SSL layer for you. It could sit alongside Varnish on the front end on port 443 (I assume you have Varnish on port 80?) and pass the SSL traffic directly to nginx (SSL can't be cached anyway, so no point in going through Varnish). Normal, unencrypted traffic would go to Varnish as expected.

share|improve this answer
+1 for pointing, that SSL encrypted traffic could be cached properly, because it is encrypted using different keys per connection. Varnish should be placed between nginx frontend server and reverse proxy, where SSL is terminated. But this architecture is more complicated. – sumar Dec 19 '09 at 1:11
Adding a forking proxy in front of Nginx would cut performance. Just configure Varnish to not answer requests on port 443 (it won't anyhow) and let Nginx handle SSL. – deleted Apr 1 '10 at 19:25

While I haven't personally used it, Nginx does have an ESI plugin:

share|improve this answer

If ESI is an absolute must I'd recommend the following set up

User -> Nginx (gzip+proxy+ssl termination) -> Varnish (ESI) -> Ngnix App Server.

That way you don't have to delegate your ssl, gzip requests to one back end server, and the ESI requests to another.

Have Varnish strip the Accept-Encoding headers from the incoming requests, that way your backends won't try to gzip (iff they're configured to do so), and Varnish can parse your backend response objects for ESI includes. Varnish will then present to your Nginx proxy fully formed content. That leaves the Nginx proxy to do compression and SSL delivery.

I've got a very similar setup running in production (without the SSL termination), and I've found it works quite gracefully.

share|improve this answer
Then your ESI pages won't be gzipped? – Joris Sep 17 '10 at 6:16
Yup they do, because Nginx still receives the Accept-Encoding header, it takes the response from the Varnish server (be they ESI's, static, dynamic) and gzips it. – flungabunga Oct 27 '10 at 0:53
Server       Requests per second
G-WAN Web server       142,000 
Lighttpd Web server     60,000
Nginx Web server        57,000
Varnish Cache server    28,000

Save yourself the hurdle (and the bloat) of another intermediate layer. Just using a better server seems to be more efficient.

share|improve this answer
That link is all about serving small static files, which is not really what the original post is about; caveat emptor, etc. – nickgrim May 31 '11 at 10:59

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.