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

While creating a load balanced and reverse proxy based architecture, how would the two be placed?

Is this the correct architecture? First LB server, then proxy: - When client hits a URL, it is basically a load balancer, which has multiple reverse proxy servers sitting behind it. It calls a reverse proxy server, which in turn gathers data from multiple servers and afulfills the request

Is there a possibility of First proxy server then LB server?

Or am I totally missing the plot?

share|improve this question
up vote 2 down vote accepted

As Jesper mentioned, you need more details.

What is the role of the reverse proxy in this situation? Is the goal performance, high availability or both?

Some load balancers do URL filtering, so if the proxy is just routing traffic (not caching), then you may not need a proxy at all.

How much of the traffic can be cached? Where are your bottlenecks?

Lately, I've been using this stack with good results for a PHP based application:

HAProxy --> Varnish --> Nginx --> PHP-FPM --> MySQL/NFS server

What we found is about 70% of all requests can be served from the Varnish cache. We considered putting Varnish out front but a single Varnish server cannot handle the load. So we would need to load balance anyway.

This creates a single point of failure at the LB level, but our client is fine with it as we can spin up a new instance in about 5 minutes. They are willing to risk 5-10 minute outage rather than have a more complicated infrastructure with dual HA-Proxy servers.

Each usage case varies and only through testing can you find the best solution that fits the budget.

share|improve this answer
+1 As mentioned I do not have enough points to vote you up, thanks for the guys rock! – open_sourse May 3 '13 at 14:37

Here's what I generally do.

Have 2 varnish servers out front with a shared IP via keepalive in case one dies. as my reverse proxy.

Behind it (or on the same server) sit haproxy doing the load balancing.

Varnish also supports load balancing to backends but you don't get the nice stats or control as you do with haproxy. If you go with a hardware load balancer.. chances are that would be up front first since that might also be your firewall.

In the end.. it really depends on how you want to lay it out.

share|improve this answer
+1 I cannot vote you up since I dont have enough rep, but thanks for the tips! I will take a look at haproxy – open_sourse May 3 '13 at 14:36

It depends on your more detailed and specific needs, so it's not really possible to answer based on the info you have given. Both your suggestions are valid and good solutions in certain cases.

As always ... profile your live production load, and benchmark the appliances/the software you're working with for proxying and load balancing.

In general:

  • If you need SSL, then much will depend on whether the LB or proxy handles SSL best. Generally, you'd want to handle SSL on the edge of your network, i.e. on the first server(s).

  • If you need multiple proxy servers to handle the load, that would push towards LB --> proxie(s) --> LB --> App Servers (or using crude DNS Round Robin to coarsely distribute load to multiple proxies).

  • If you need consistent hashing in front of your proxies, then that would push towards LB --> proxie(s) --> LB --> App Servers and a load balancer which supports consistent hashing.

  • If a single proxy can handle your load, then proxy --> LB --> App Servers is simplest. Some proxies, like Varnish, even have a basic load balancer built in.

Willy Tarreau, author of the excellent HAProxy, has written a nice article about common front end load balancing / SSL offload / proxying architectures.

share|improve this answer
Thank you for the article! It was very good! +1 – open_sourse May 3 '13 at 14:39

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.