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

We have setup a loadbalancer to balance 2 servers. The config looks like this:

    maxconn 40960
    user haproxy
    group haproxy

    log     global
    option  dontlognull
    retries 3
    #option redispatch
    timeout client 10s
    timeout server 10s
    timeout connect 4s
    maxconn 40960

listen webpool lbIP:80
    mode http
    cookie SERVERID insert indirect
    balance roundrobin
    server slave1 slave1IP:80 cookie A check port 8981
    server slave2 slave2IP:80 cookie B check port 8982

The servers slave1 and slave2 needs digest authentication. When the client sends a request the first request is balanced to slave1. This returns a 401: Unauthorized. The second request is balanced to slave2 and will succeed, it returns a 200: OK. The problem is that the authentication always happens on slave1 and the the response always came from slave2. I want both requests(authentication and returning data) into one connection/slave.

Is it possible to configure this in HAproxy?

share|improve this question

If I understood you well, you can try using a different balancing algorithm balance source instead of roundrobin. Using this algorithm, all the requests from the same IP will go the same backend server (unless that server is down). This can distribute the load between your backend servers evenly depending on your clients IP addresses.

share|improve this answer
Yes, i tried that before. The problem is the requests came from 1 client/website. When i use "balance source" it will only use slave1. – John Jan 13 '12 at 14:07

Yes this can be done quite simply.

balance uri

uri This algorithm hashes either the left part of the URI (before the question mark) or the whole URI (if the "whole" parameter is present) and divides the hash value by the total weight of the running servers. The result designates which server will receive the request. This ensures that the same URI will always be directed to the same server as long as no server goes up or down. This is used with proxy caches and anti-virus proxies in order to maximize the cache hit rate. Note that this algorithm may only be used in an HTTP backend. This algorithm is static by default, which means that changing a server's weight on the fly will have no effect, but this can be changed using "hash-type".
This algorithm supports two optional parameters "len" and "depth", both followed by a positive integer number. These options may be helpful when it is needed to balance servers based on the beginning of the URI only. The "len" parameter indicates that the algorithm should only consider that many characters at the beginning of the URI to compute the hash. Note that having "len" set to 1 rarely makes sense since most URIs start with a leading "/".
The "depth" parameter indicates the maximum directory depth to be used to compute the hash. One level is counted for each slash in the request. If both parameters are specified, the evaluation stops when either is reached.

The uri is always the same so the challenge is sent to the same backend. Hopefully most of your uri's are unique (i.e. have a user id) so this doesn't compromise the balancing.

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.