vADC Docs

Getting Started - Load-balancing to a website using Stingray Traffic Manager

by on ‎03-28-2013 04:53 AM (13,452 Views)

You've just downloaded and installed Stingray Traffic Manager, and you're wondering "where next?". This article talks through the process of load-balancing traffic to a public website, and explains the potential pitfalls and how to overcome them.

We'll look at how to set up a basic load balanced service using the Manage a New Service wizard, then consider four potential problems:

When you access the Web site through Stingray, it responds with a 404 Not Found or other error, or redirects you directly to the websiteYou need to correct the Host Header in the request your web browser has sent.  Use a simple Request Rule in Stingray to patch the request up correctly.
The web site stops working when you access it through StingrayStingray is running Ping health checks against the web servers, and these are failing because the public servers won't respond to pings.  Remove the health checks, or replace them with HTTP checks.
Links in the web content refer directly to the fully-qualified domain of the website, rather than to the website delivered through StingrayYou need to rewrite the web content to correct the fully-qualified links.  Use a response rule in Stingray to make this change.
HTTP Location redirects and cookies issued by the website refer to the fully-qualified domain of the website, rather than to the website delivered through StingrayYou need to use the connection management settings to transparently rewrite the Location and Set-Cookie headers as appropriate

Basic Load Balancing

Let's start with a simple example.  Select a target website, such as

Fire up the Manage a New Service wizard:


This will pop up a new window to step you through the process of creating a new service.

warning.pngWarning:  If you don't see the pop-up window, your web browser may be configured to prevent popups.  Check and fix this problem.

Step through the wizard.  Create a service named web site, listening on port 80:


Specify the servers ("nodes") that will host the website.  In this example, enter, port 80:



Note:  If you get an "ERROR: Cannot resolve" message, then most likely the Stingray device is not configured with a correct nameserver address, or it cannot route to the outside world.  You'll need to fix these problems before continuing:

  • You can use as the nameserver
  • Ensure that the networking is configured so that the Stingray device has external connectivity

Review your settings and commit the result:



Note:  If you get a 'Cannot Bind' error when you commit the changes, then another service on the Stingray device is listening on port 80.

  • If it's a pre-existing Stingray Virtual Server, you should stop this virtual server
  • It it's another service on the same host (for example, a webserver), you should stop this service

Alternatively, select another port (instead of port 80).

The wizard will create a virtual server object listening on port 80, and a pool object containing the nodes (or whatever you chose).  The Virtual Server will receive traffic and then pass it on to the pool for load balancing.

Try it out

Try it out.  Go to http://stingray-ip-address/ with your web browser.  If you are lucky, it will work first time, but most likely, you'll get an error message, or possibly a redirect to

Problem #1: The Host Header

Most webservers host many websites on the same IP address and port.  They determine which website a particular request is destined for by inspecting a parameter in the request called the 'Host Header'.

The 'Host Header' is constructed from the URL that you typed in your web browser (for example:  This will cause the webbrowser to include the following header in the request:


The web server will reject this request, returning either an error message, 404 Not Found, or a forceful redirect to the correct page.

You can use a TrafficScript Rule to change the host header in the request to a value that the web site will recognise.

How to create the TrafficScript Rule

Edit the 'web site' virtual server you created and navigate to the 'Rules' page.  In the 'Request Rules' section, click the 'Manage Rules in Catalog' link to create a new rule that is associated with that virtual server:

Screen Shot 2013-03-28 at 10.58.36.pngCreate a TrafficScript rule called ' host header':

Screen Shot 2013-03-28 at 11.01.51.png

with the following text ( 'http.setHeader( "Host", "" );' ):

Screen Shot 2013-03-28 at 11.02.35.png

and save your changes.

Now, Stingray will fix up the host header in every request and the site should render correctly.

Problem #2: Health Monitors

If your Stingray service works for a short time, then starts returning a "Service Unavailable" error message, you've most likely hit a health monitoring problem.

When Stingray creates a new pool, it assigns a 'ping' health monitor to the nodes.  Many public webservers, and websites that are delivered over a CDN, do not respond to 'ping' healthchecks, so this monitor will quickly fail and mark the nodes as unavailable.

Edit the 'web site pool' Pool object and locate the Health Monitoring section.  Remove the Ping health monitor:

Screen Shot 2013-03-28 at 11.13.09.png

This will clear the error.  You could replace the Ping health check with an HTTP health check (for example) if you wished.

Problem #3: Embedded Links

As you click round the website that is delivered through Stingray, you may find that you jump off the http://stingray-IP-address/ version of the site and start going directly to the URLs.

This may happen because the website content contains absolute, fully-qualified links:

<a href="">Headlines</a>

rather than unqualified links:

<a href="/headlines">Headlines</a>

(yes, this is a problem if you load-balance to for example).

You can fix those links up by rewriting the HTML responses from the webservers using a Response Rule in Stingray:

$contentType = http.getResponseHeader( "Content-Type" );

if( string.startsWith( $contentType, "text/html" ) ) {

   $body = http.getResponseBody();

   $body = string.replaceAll( $body, "", "/" );

   http.setResponseBody( $body );


Problem #4: Cookies and Location redirects

The origin webserver may issue cookies and Location redirects that reference the fully-qualified domain of the website, rather than the IP address of the Stingary device.  Your web browser will not submit those cookies, and it will jump to the origin website if it follows a Location redirect.

Stingray can automatically patch up these parts of the HTTP response, using the Cookie and Location Header settings in the Connection Management page of your Virtual Server's configuration:

Screen Shot 2013-05-17 at 11.10.50.png

Rewrite domains, paths and other cookie parameters when proxying a website using a different URL

Screen Shot 2013-05-17 at 11.11.02.png

Intelligently rewrite location redirects so that users are not hopped on to the origin server

Use these settings to address any inconsistencies and problems related to cookies or location redirects.


These three problems (host header, health monitors, embedded links) can occur when you load-balance public websites; they are a lot less likely to happen in production because there won't be a firewall blocking pings between Stingray and the local webservers, and the DNS for will resolve to a traffic IP address on the Stingray device so the host header and embedded links will be correct.

Watch out for situations where the web server sends HTTP redirects to another domain.  For example, when I tested by load balancing to, the website immediately tried to redirect me to (I was based in the UK).  You have no control over this behavior by a public website; I configured my Stingray to forward traffic to instead.

Now that you have a working load-balancing configuration, you can: