When a user hits the load balancer and the load balancer determines which web server to forward to, what happens next? Does the load balancer forward the request and all its data to the webserver, receive the webserver's response and return that back to the user?

Or is it more like a redirect where the load balancer literally just returns the selected server's ip address back to the browser and the browser has to open a new connection with the given server?

My instinct says it wouldn't be the latter because that would imply all web server IP addresses would be public and I thought for security reasons it's best to only expose load balancer addresses to the public. But then again I'm not exactly sure because if you enable SSL termination at the load balancer, wouldn't SSL need to be re-established again with the redirected server?


3 Answers 3


The end-IP is not published. The process actually works in a way the client (a user hitting the balancer) believes they are communicating with the balancer, while talking to an actual node.

In a very simple explanation, most transactions work like this:

  1. A user makes request to the load balancer.
  2. The balancer decides which node is the most suitable (based on the strategy you're using for balancing) and choses (changes) the destination IP.
  3. (This is where the magic happens.) The node receives a request, accepts the connection and responds back to the balancer.
  4. The balancer changes the response IP back to a virtual one, the one of the balancer and forwards the response to the user.
  5. Voilà, the user receives response with the IP of the initial request, even though it was actually processed somewhere else.

Keep in mind the packet rewriting (the change of the IP address in the step 4) is very important. Without it the client, receiving a packet from an IP it does not trust, would simply discard the response.


Lad balancer is work on layer 4 OSI. It decapsulate packet until port number and then directing packet with one of 3 mode.

Load balancer can work on 3 mode : 1. Direct routing In this mode your realserver is use IP public. The balancer receive the packet and decapsulate until layer 4. If in load balance rule match, it will be redirect packet (without modifying) to one of realserver. Realserver have an alias address same with loadbalance address, so when realserver receive packet with an xxx.xxx.xxx.xxx destination it define that packet right to he's address(alias). And then real server reply request to client direct (not through loadbalance).

2. NAT In this mode packet redirect to realserver with modifying destination address. Destination address will replaced with realserver address (NAT). In this mode your realserver not need IP public, it can use your local network. And then packet will be delivery no new destination address. When realserver receive packet it will be reply to client request address trough gateway (loadbalance). In this mode your loadbalance use as router & as gateway of your realserver.

3. Tunnel In this mode packet will be tunnelled with new src-dst address (like vpn) to delivery packet to realserver. when packet received in realserver, realserver will be reply via tunneled pipe to loadbalance. And then loadbalance delivery reply ti real request source address.

For HTTPS/SSL, loadbalance not process it, load balance process until layer 4 OSI. Layer 5 above will be process in realserver. So TCP 3 way hanshake, SSL/HTTPS it procesed in realserver. Loadbalance only director of the packet.

I hope my little explanation will be help something.

  • It appears you're talking about lvs here, but it's not necessarily the way http(s) load balancing works. Take a look at haproxy for example. This app does load balancing in userland and throws in nice backend routing functionality as well.
    – Friek
    Mar 17, 2016 at 21:18
  • In my datacenter i use lvs to load balance my https app service, and it work and running well.
    – dek.tiram
    Mar 18, 2016 at 2:57
  • Excuse my ignorance, but what is "lvs"? Is it a competitor to haproxy?
    – smaili
    Mar 18, 2016 at 5:27
  • Haproxy also use lvs. I use piranha which also use lvs for core process.
    – dek.tiram
    Mar 18, 2016 at 5:42
  • haproxy is a standalone application and doesn't require lvs at all (it's not even aware of the existence of lvs). You could use lvs to balance a cluster of haproxy nodes, if the load on haproxy gets too heavy though.
    – Friek
    Mar 18, 2016 at 6:12

A load balancer can either be a router or a reverse proxy:

LVS is the industry standard Layer 4 (routing based) load balancing module for the Linux Kernel. It is used in various commercial load balancers including Barracuda, Loadbalancer.org and Kemp Technologies. Barracuda and Loadbalancer.org also use HAProxy for Layer 7 load balancing (reverse proxy based).

Ps. I forgot this doesn't show where I'm from which is obviously Loadbalancer.org

  • 1
    when posting links to external resources one is expected to disclose affiliation, see How to not be a spammer
    – gnat
    Jun 26, 2017 at 7:43

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