IP-based Virtual Hosting on OpenLiteSpeed

How Can We Help?
< Back
You are here:

IP-Based Virtual Hosting on OpenLiteSpeed

In all versions of LiteSpeed Web Server, including OpenLiteSpeed, there is very little difference between IP- and name-based virtual hosting. IP-based virtual hosting is the same as name-based virtual hosting, except that each virtual host has its own IP address. IP-based virtual hosting does, however, bring with it certain special advantages and disadvantages. We will begin by discussing these. Afterwards we will guide you through setting up an IP-based vhost, though, actually, setting up an IP-based vhost is exactly the same as setting up a name-based vhost.

Advantages and Disadvantages


  • Allows you to access a vhost directly through its IP.
  • Allows you to bind a specific site to a particular worker process in the Binding listener setting. In order to be bound to a specific processor, a listener must have a unique IP-port combination. Thus, by giving a site a unique IP, you can bind it to a specific processor. (Of course, if you have more than one site associated with an IP, you can still have that IP served by a particular listener and thus bound to a particular process.)


  • IP-based virtual hosting can require extra setup for certain features like using OpenLiteSpeed as a reverse proxy. (An OpenLiteSpeed web server external application proxies traffic to one IP. If your sites are spread out on many IPs, you will need an external application for each IP.)
  • You have to have more IPs than for name-based hosting.


Set DNS Properly

Forward the domain names of your web sites to the IP addresses used by your web server. This is commonly done by adding an “A” name entry to the DNS zone file for the website. This is not part of your OpenLiteSpeed configurations.

Set up the Virtual Hosts in the WebAdmin Console

Create a Virtual Host for Each Website

First, make the virtual host’s directories. I will name my virtual host “Example3” (because I’ve used Example and Example2 for other guides). In the command line, I go to my LSWS directory and make the following directories:

cd /usr/local/lsws
mkdir Example3
mkdir Example3/{conf,html,logs}

I then make conf directory owned by lsadm:lsadm (the WebAdmin console user) so that only the WebAdmin console will be able to manipulate configurations. (You should not allow other users permission to manipulate your configuration.):

chown lsadm:lsadm Example3/conf

Then I go to the WebAdmin console > Virtual Hosts > Add to add the virtual hosts to OpenLiteSpeed:

You have to enter the virtual host’s name, the virtual host root file, and the virtual host configuration file. You also need to choose whether to enable scripts on this site and whether users can access content outside of this virtual host root from the site (Restrained).


I don’t have a virtual host configuration file yet, because I’m starting from scratch, so I tell OpenLiteSpeed to make one for me:


Then I save, go back into the virtual host’s configurations, and specify my document root:

Create and Assign Listeners

Go to the WebAdmin console > Listeners.

You can have one listener to listen on all local IP addresses, or you can create multiple listeners with each listener only listening to a specific IP address. Many users will find it simpler to have one listener that is then mapped to different domains (even if you have different IPs for each vhost), but having multiple listeners can be useful if, for example, you wish to set aside certain server processors for certain sites (see the listener binding section of LSWS’s documentation) or conduct special functions on separate ports.

I don’t need anything special, so I just go to the Default listener (that listens to all IPs on port 80):

And add a new mapping:

And input the domain for my virtual host: (In the Domains setting, “your.domain” will match to both “www.your.domain” and “your.domain”. The leading “www.” in a domain name is ignored.)

Graceful Restart

And you’re done. 🙂

Note: OpenLiteSpeed supports Server Name Indication (SNI), allowing users to set SSL certificates at the virtual host level. This means that virtual hosts (websites) with different SSL certificates can operate on the the same IP address and port number. Different listeners (and IP-based hosting) are not necessary for secure sites to have unique certificates.