The title is pretty much it. Is there any particular behavior that is indicative of the presence of a load balancer on a certain site?

7 Answers 7


EDIT: This will be very difficult to do if not impossible (dislike for that word) since the whole point of having a LoadBalancer is to make the client's interaction with it transparent and basically invisible. That being said, here is my original post:

I administer a load balancer for a rather large site. The only indication that our visitors have that they are visiting any specific application server is that we actually put the specific name of the server at the bottom of their login page. This helps us troubleshoot issues that they have.

Other than that I can think of only one thing that would "key" you into the fact that we are running a load balancer if we didn't follow that policy. Here's how you could tell but it'll take some luck.

Say that the load balancer is set to forward all traffic to either one server or another. Or at least it forwards ssh traffic between one server to another. Even though you probably don't have log in cred to log into either box, both will provide you with a different key should you attempt to log in. So if you attempt to log in via ssh the first time you'll be asked if you want to accept the key. Then if you get lucky on the second or third request you'll be told that there is a different key (ie it's another box). On a *nix system you're often alerted that this might be due to a man in the middle attack.

So two things have to be in place:

  1. SSH on remote server
  2. LB of SSH

So if you get two keys in a relatively short period of time you can probably assume that the sys admin hasn't changed them but rather that you've just communicated with two separate machines behind a load balancer.

Note: there is one other item but it's a real shot in the dark. You could attempt to figure out what block of IP's that this server was grouped with. Then let's say that on one of these particular IP address is placed on the LB (in fact it is on one of these IPs).

The Load Balancer is placed at XXX.XXX.XXX.5 for instance. The LB will then be set up to capture all traffic for at least one additional IP address. It typically does not forward traffic for XXX.XXX.XXX.5 (the commercial hardware I have definitely doesn't do this). So you can count on there being and admin address.

If the LB is set up to allow admin from all external hosts you may be able to apend something like /admin to the ip addresses until you find the LB. This assumes that the LB uses that path for administration.

  • This of course only works if the load balancer forwards all packets using the same set of rules. The load balancers I come in contact with most often will only deal with 80 and 443, so you can't take advantage of SSH like that. Jan 28, 2010 at 5:23
  • @Catherine Macinnes - That's why I said that the load balancer would have to be set to forward ALL traffic or at least SSH traffic to the servers (and that you'd need some luck).
    – Patrick R
    Jan 28, 2010 at 13:01
  • @Patrick R What are the possible ways to fix this vulnerability? any pointers? Jun 6, 2018 at 5:33

There is no determinative way, but there are a grab bag of clues you can look for.
- nmap it. nmap can give some clues on the OS of whatever device you're talking to. If it says BSD and the url's end in .aspx you're onto something.
- cookies: lot of loadbalancers add (or can add) session cookies. Look for any strange ones and google them, if you land on the F5 support forums, viola.
- assorted other headers: lots of 'em add headers based on things like if an item was cached or not (and other reasons). Look for any interesting headers and google them.
- on the page or buried in an html comment its common for the developers to have added a "served by web7" to help them troubleshoot.
- request the same content rapidly from multiple different ip's and compare the ETag headers. Apache by default bases the etag off the filesystem inode, and a lot of admins never get around to tuning that, so if you see a different Etag for the same content you can guess its coming from different servers (only works with apache, only works if not tuned, only works if not a shared filesystem).

Truthfully I'd only expect all of that to give you a meaningful answer like 1 time in 4 though, overall you can't really know unless as Catherine said "something is wrong".


IP ID changes for every IP stack, thus IP host "behind" the load balancer. A tool like hping would give you just that: watch for IDs which do NOT belong to the same range, or - even if by some strange coincidence close enough - not increasing:

hping3 www.yoursite.com -S -p 80 (or whatever)

The above catches multiple hosts behind LB "under" the application layer.


So, I think the question was, can you figure out casually from website behavior if there is a load balacner, and I would venture that the answer is "not unless something is wrong" (like the servers are out of sync). It is however, at least theoretically possible to figure out if there is an extra "invisible" device between you and the server responding to the request. That device might be a proxy server, a port forwarder, a static NAT device, a load balancer, or possibly something else that I've missed. Basically anything that responds to a ping on the IP, but isn't ultimately serving an HTTP request. Essentially you figure out how many hops there are between you and the public IP of the site using something like traceroute. Then you do some packet inspection to determine the TTL of a packet arriving from the host. Since the possible starting values for TTL are limited and well defined (unless someone is doing some serious hacking on their network stack), you can determine whether or not there is an extra hop. Not sure if that helps you at all, but I at least think it is an interesting thought.

  • i doubt if ttl would reliably tell you the truth. reason for that is that connection is usually terminated at the lb and ttl values for ping and normal http request will be the same as it's the lb tcp stack thats sending the responses.
    – rytis
    Jan 28, 2010 at 5:36
  • pulegium is correct. the ttl is terminated at the load balancer. One item that Catherine said which is correct is that you'll have to count on that fact that "something is wrong". Hopefully no one with experience would forward ALL traffic to one of two server (like I mentioned below). But if they did, that's your possible route in (ie if they also have ssh). And if they did have something like that set up, it sure would be hard to count on ssh'ing into the correct box until you were in the private subnet.
    – Patrick R
    Jan 28, 2010 at 13:08
  • Why does this work differently for a lb then for a standard NAT router? Packets are not generated by the lb, they are generated by the server on the other side, and the lb shouldn't reset the ttl, therefore it will be one too low when it gets to you (just like it is for any computer sitting behind a NAT router). Feb 1, 2010 at 5:44

If the load balancer is doing cookie-based persistence then looking at the cookies might give you a clue.


Pay close attention to the HTTP headers.

wget --save-headers
can help you capture them.. (there are also firefox plugins that keep track of headers)

Hit the same page over and over again and look for things like alternating "Last-Modified or Expires" headers.

Many sites encode their backend severs in the headers too. That should stand out if it's there.

Good luck.


It may be worth trying to identify the differents IP stacks (if any) using the IP Identification Field. You may want the read more on how to do that on the Scapy Demo page (find the line with the 'IPID field' words).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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