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 been looking around different setups for a server cluster supporting SSL and I would like to benchmark my idea with you.


  • All servers in the cluster should be under the same full domain name. (http and https)
  • Routing to subsystems is done on URI matching in HA proxy.
  • All URIs have support for SSL support.


  • Centralizing routing rules

            |                  |
    Inet -->HA--+---https--->NGInx_SSL_1..N
                +---http---> Apache_1..M
                +---http---> NodeJS

Idea: Configure HA to route all SSL traffic (mode=tcp,algorithm=Source) to an NGInx cluster turning https traffic into http. Re-pass the http traffic from NGInx to the HA for normal load-balancing which performs load balancing based on HA config.

My question is simply: Is this the best way to to configure based on requirements above?

share|improve this question

The way I've always heard of it being deployed is that you would have multiple load balancers, all running nginx (or stunnel) to strip the SSL. These would then directly connect to the backend servers. Your approach of having a separate set of servers to decrypt the SSL seems like it would be quite complex.

Honestly, what are you hoping to get out of this setup? Is your traffic too much for one server? Are you hoping to get high-availablity (in which case you need multiple HAproxy servers, which adds to the confusion)?

share|improve this answer
also what we are doing. Use nginx as SSL offloader, forwarding traffic to HAPROXY (which also get http traffic straight) which then load balance internally. Allows you to keep your traffic secure up to your edge. NGINX also support SSI. Quite an interesting features if all browsers accepted it. – CloudWeavers Dec 13 '12 at 16:57

To me your setup seems a little bit strange and complicated. I also think it will be hard, if at all possible, to manage to get the original visitor's ip address into the final nginx logs.

A common alternative is to use stunnel in front of haproxy. Stunnel will decrypt the ssl and feed it to haproxy, which can in turn forward the stuff to the appropriate backend server. This solution also has some difficulty in forwarding the original ip address, but if you use the current 1.5 development version of haproxy and v. 4.45 or later of stunnel, you can use the PROXY protocol for that.

share|improve this answer

So there are two options.. use stunnel with the xforwardfor patch

This will allow you to set the header for the backend servers to read from

I would just sit nginx in front of it to handle the ssl termination and also setting the xforwardfor header back to the app. Put it on the same server as haproxy. Also you could just use ngninx for passing back based on routes also so there would be no need for even haproxy.

share|improve this answer

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.