Check which server answers
Results
| # | Time | Status | Connected IP | Backend identity | Other headers and details |
|---|
What this tool shows
A load balancer spreads incoming requests across several servers, and from the outside you normally cannot tell which one answered. This checker sends 1 to 10 requests, one after another with a short pause, each on a brand new connection, so the balancer is free to choose a different backend each time. For every reply it shows the response time, the status code, the IP address we actually connected to, and the headers that usually identify a server: X-Served-By, X-Backend, X-Server, X-Node, X-Hostname, X-Upstream (highlighted), plus Via, Server, X-Cache, CF-Ray, X-Amz-Cf-Pop, X-Request-Id, Age and Date. You can add up to two header names of your own, and cookie names from Set-Cookie are listed with their values hidden.
The summary counts how many different IP addresses and how many different backend identities were seen. If only one identity appears, the tool says so and lists the usual reasons: sticky sessions, source-IP hashing, a single backend, or no identity header.
Make each server say who it is
The load balancer, not the tool, decides where a request goes, and most balancers do not tell the client. The dependable fix is to give every backend its own identity in the reply, then use this checker to confirm the spread. Use a different value on each server, and keep in mind that host names can reveal your internal layout, so you may want to remove the header after testing.
nginx: add a header on each backend server
Put this in the server block of every backend nginx, so each one reports its own host name. If a location block has its own add_header lines, repeat this line there, because add_header in a location replaces the ones inherited from the server block. A proxying nginx passes the backend's header through to the client by default.
add_header X-Served-By $hostname always;Apache: add a header on each backend server
Needs mod_headers (on Debian or Ubuntu: a2enmod headers). Use a different fixed value on each server, for example the server's name.
Header always set X-Served-By "web-02"HAProxy: add the chosen server's name on the balancer
In the backend section. %s is the server name from the server line that was chosen, and %b is the backend name. This exposes your internal names, so remove it after testing if you do not want them public.
backend web_servers
mode http
balance roundrobin
http-response set-header X-Backend %s
server web1 10.0.0.11:80 check
server web2 10.0.0.12:80 checknginx as the balancer: log which backend was used
$upstream_addr is the address of the backend that handled the request. Logging it is safer than sending it to visitors.
log_format lb '$remote_addr "$request" $status $upstream_addr';
access_log /var/log/nginx/lb.log lb;A /whoami page on each backend (nginx example)
Returns the host name as plain text. This checker shows the first 200 characters of a text/plain or JSON reply, so you can see the value for every request. Any application can do the same by returning its host name.
location = /whoami {
default_type text/plain;
return 200 "$hostname\n";
}Load balancer specifics
- AWS Application Load Balancer: it does not add a response header that names the target. Turn on access logs and read the
target:portfield for each request, or add a header on your instances as above. When stickiness is enabled the balancer sets a cookie namedAWSALB(duration-based) or one starting withAWSALBAPP-(application-based), and this tool lists cookie names in the details column. - CDNs and reverse proxies: the IP address and headers such as
CF-RayorX-Amz-Cf-Popdescribe the CDN edge, not your origin server. The origin has to send its own identity header and the CDN has to pass it through.
About sticky sessions
Sticky sessions (also called session affinity) keep one client on one backend. A balancer can do that with a cookie it sets, or by hashing the client IP address, for example ip_hash; in an nginx upstream block or balance source in HAProxy. This tool sends no cookies, so cookie-based stickiness will not pin it and you see the underlying distribution. Every request does come from the same IP address, so a balancer that hashes the client IP will always choose the same server. That is expected behaviour, not a fault in your setup.
Limits and permission
Only test sites you own or have permission to test. Each check allows 1 to 10 requests, 6 checks per 10 minutes per visitor, plain GET or HEAD requests, ports 80 and 443 only and at most 3 redirects. Private, internal and reserved addresses and this server are refused. The check runs from our server because browsers cannot read most cross-site response headers.
Frequently asked questions
How can I tell which server behind a load balancer answered my request?
A load balancer normally hides which backend handled a request, so the reliable way is to make each server say who it is. Add a response header such as X-Served-By with a different value on every server, or expose a small /whoami page that returns the host name. This checker then sends several requests on fresh connections and shows the header values, the status and the IP address it connected to for each one, so you can see whether the answers rotate between servers.
Why do I only see one server, or the same value every time?
There are four common reasons: the balancer uses sticky sessions, the balancer picks the backend from a hash of the client IP address (every request here comes from the same IP address, so nginx ip_hash or HAProxy balance source will send them all to one server), only one backend is healthy or configured, or your servers do not expose an identity header, so the replies look identical. Try more requests, add an identity header to each server, and check the balancer's own algorithm and logs.
Why does the check run on your server instead of in my browser?
Browsers block web pages from reading the response headers of another site unless that site allows it with CORS, so a page running in your browser cannot reliably read headers such as X-Served-By from your servers. The request is therefore made from the ITCOH server, which sends plain HTTP or HTTPS requests with a fixed User-Agent and returns only a short list of headers, the status, the timing and the IP address it connected to.
Which sites can I test, and what are the limits?
Only test sites you own or have permission to test. You can run 1 to 10 requests per check, up to 6 checks every 10 minutes, with a short pause between requests and a 5 second timeout for each. Only http:// and https:// addresses on the standard ports 80 and 443 are accepted, with no user name or password in the URL. Private, internal and reserved addresses, this server and itcoh.com itself are refused, and redirects are followed for at most 3 hops, with each hop checked again.
Does this show my real server if I use Cloudflare, CloudFront or another CDN?
Not by itself. If a CDN or reverse proxy sits in front of your servers, the IP address we connect to belongs to the CDN, and headers such as CF-Ray or X-Amz-Cf-Pop describe the CDN's edge location, not your origin server. To see the origin that answered, have each origin add its own identity header and make sure the CDN passes it through, or look at the origin or balancer logs.