XAMPP with virtual hosts configuration


The out-of-the-box XAMPP configuration demonstrates projects as subfolders in the default htdocs folder. There are a couple of improvements on this that I like to implement as the start of my workflow to make my life easier during development, while working towards deployment. These improvements revolve around the use of virtual hosts in XAMPP and are documented in this post.

Note: For now, this post assumes a XAMPP installation on Windows in the root of the C:/ harddisk.

The Apache distribution that XAMPP is based on supports virtual hosts as usual, but this is disabled by default. The global vhost config file include needs to be enabled to start with. Remove the # (hash sign) at the start of the line with the following code in C:/xampp/apache/conf/extra/httpd.conf:

 #Include conf/extra/httpd-vhosts.conf

Note: Remember to restart/reload Apache after every change to config files, as only then they are reloaded.

This includes Apache’s vhosts config file for further use. My main use-case is to create subdomains per project.

The vhosts config file helps with a couple of things of particular interest. It allows the localhost to resolve subdomains to specific folders on the local file system. This comes in handy especially when cross-device testing a project on the (local) network. This is a very similar configuration as on typical deployment servers. So at the same time, for instance, it supports the typical .htaccess configuration for WordPress. Furthermore, more advanced configurations using environment variables can be configured. These I will not cover in further detail in this post. Leave a comment if you would like more information on this.

Resolving web addresses to the XAMPP localhost

Vhosts help in routing incoming request on the local server, to a document on the local file system. Let’s focus on the first aspect of this feature: any virtual host we are going to be making up must eventually resolve back to the localhost’s IP address. There are actually several ways to make this happen for any address, each with it’s own pros and cons.

Using the hosts file

The most versatile way to explicitly route a (web) address to any IP address, is by including a reference in the hosts file (Windows: C:/windows/system32/drivers/etc/hosts). This file contains line by line records of IP addresses followed by one or more web addresses that are ‘short wired’ to this IP address. Like the following:    project1.dev    project2.dev project3.local

Note: is always going to be the localhost. Therefore, all above web addresses will resolve to the local server.

The main con with this approach, is that every project will require editing the hosts file for explicit ‘short wiring’ of the new subdomain to the localhost. The pro is that there’s hardly anything that can go wrong with this approach; most importantly, in contrast with the following approach, the hosts file setup does not require a internet connection.

Using a wildcard DNS service

Wildcard DNS services route a web address back to a local network IP address. Both nip.io and xip.io offer this service (I find nip.io to serve with better reliability in terms of uptime). As per their examples: resolves to
www. resolves to
mysite. resolves to
foo.bar. resolves to

The main con with this approach, is that it requires the online wildcard DNS service. Also, If you’re not using in the nip.io address, you will want to ensure you have a static IP address, or you will find yourself having to find out your new local IP address (uses ipconfig/ifconfig), and perhaps even replacing this address in your local WordPress installation database. Both these cons make this solution especially unattractive when working from a mobile workstation (on different networks, online and offline). A pro is that, on a desktop computer with a static local network and stable internet connection, you won’t have to set up the hosts file for every new project. The main pro though, is that anyone on the local network can use the nip.io link with your IP address to make requests to the Apache server running on your computer. This comes in especially handy when sharing your development with colleagues, or when testing on multiple devices.

Serving files to web address requests

With web address requests incoming towards the local Apache server, the vhosts configuration needs to be set up to route these requests to files on the local filesystem. This is done through a per project node in the httpd-vhosts.conf file. Of course, the exact configuration of this node depends on your prior technique of choice for resolving the addresses to the localhost.

For an address in the hosts file:

<VirtualHost *:80>
    DocumentRoot "C:\Projects\project1\httpdocs"
    ServerName project1.dev

And for a nip.io address:

<VirtualHost *:80>
    DocumentRoot "C:\Projects\project1\httpdocs"
    ServerName project1.*.nip.io

Further Apache settings

Finally, a couple of requirements will have to be satisfied in order to get the above fully operational:

Firstly, in C:\xampp\apache\conf\httpd.conf add:

<Directory />
   AllowOverride none
   Allow from all

to allow read access to the local web server.

Note: this introduces significant security leaks if your web server is exposed to the internet. Consider http://stackoverflow.com/a/10600896/794071.

Secondly, above all project specific nodes in the httpd-vhosts.conf add:

<VirtualHost *:80>
    DocumentRoot "C:/Projects"
    ServerName localhost
    ServerAlias localhost.*.nip.io

This ensures the localhost remains accessible, along with it’s typical subfolders in the XAMPP setup, like localhost/xampp and localhost/phpmyadmin.

All set!

Now you are ready to start developing in the documentroot of your choice, under the virtual domain name of your choice!

Further reading

To work around a missing internet connection, service downtime or changing IP with the nip.io project nodes setup, you can combine this approach with the hosts file approach as follows:

In the hosts file:    project1.your.old.ip.addresss.nip.io

Where your vhosts project node looks something like:

<VirtualHost *:80>
    DocumentRoot "C:\Projects\project1\httpdocs"
    ServerName project1.*.nip.io

This should short wire the nip.io address to the localhost again, without the need for the wildcard DNS service.

Leave a Reply

Jouw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>