That's not how virtual hosts work, I'm afraid ;) Virtual hosts are used to host multiple independent sites on the same web server.
/var/www/. Therefore, in the Apache config the
DocumentRoot would be set to that directory,
If you now pointed your browser to
http://www.my-site.tld/welcome.html, it'd display the file
/var/www/welcome.html. To structure your site, you could use subfolders. So, for example, if you pointed your browser to
http://www.my-site.tld/holidays/summer2001.html, it'd display the file
So far so good. But what if you wanted to host more than one website on the same machine, on the same host? Multiple websites under different addresses, that are (if you look at them "from the outside") competely independent from each other, not just different subdirs inside the same website? That's where virtual hosts come into play.
In a virtual host configuration you can set many directives not globally for the whole webserver, but per website. Say, you're hosting two websites on the same webserver, "www.my-site.tld" and "www.my-other-site.tld". For that, you can use two virtual host configurations, for example
CustomLog /var/log/apache2/my-site.access.log "combined"
CustomLog /var/log/apache2/my-other-site.access.log "combined"
You see, the
DocumentRoot is defined differently in each virtual host, same for the
ServerName, same for the
ServerAlias and so forth.
I hope I could illustrate the idea of virtual hosts, and why virtual hosts and subdirectories inside the same host are two different things. To make it even more complicated, you can have subdirs inside a virtual host ;) Say, the address
http://www.my-other-website.tld/tournaments/finals2015.html with the above config would point to
Some other things you might come across, but that I can't go into in detail here:
If you're using addresses, domain names and such, you need to make sure that everybody knows where to find them. Just setting
ServerName my-cool-site.com doesn't let "the internet" now where to direct requests for
my-cool-site.com to ;) For that you'd typically use DNS by buying (in fact, it's mostly more renting, because you need to renew it every so often) the domain name and setting up a dns entry to the effect "if anybody's looking for
my-cool-site.com, send them to server such and such".
When you use an ip address instead of a domain name, for example
http://127.0.0.1/webstuff/how-dns-works.html, it doesn't change the principles shown above. In fact, if your server has assigned multiple ips to it, you can differentiate them in your virtualhosts.
<VirtualHost *:80>' means "apply this to requests for any ip, on port 80". If your server has192.168.2.101
assigned to it, you can differentiate between those ips in your virtual hosts.would only apply for requests directed to192.168.2.101
, not for requests directed to192.168.2.102`.
If you want to call your webserver from the same machine it's running on and don't want to use an ip directly, you can typically just say "Show me the webpage on the same host I'm on now, on the local host". For that, typically the special hostname
localhost is configured. So you could type something like `http://localhost/thats-a-long-answer.html' into your browser's address field.
Typically you have a common "parent directory" where all your virtual hosts
DocumentRoots are under. For example, you could have all your virtual hosts as subdirs of
/var/www/. It's not strictly necessary do use that structure, but it has proven to help you keep track of things, in contrast to storing your websites all over the place ;)
To include a directory from outside a virtual host's
DocumentRoot, you can use an
Alias. Say, you add to the virtual host config of "www.my-site.tld" a directive like
Alias /sports /home/john/some-sports
In that case,
http://www.my-site.tld/sports/soccer.html would point to
But such cases are prone for permission problems. The files in
/home/john/some-sports are typically owned by the user
john, so the user your webserver software (Apache) is running as may not have access to them.
All that might be a bit much do digest all at once, but those are some of the basic concepts you need to understand to successfully run a webserver. It's not as complicated as it might seem on the first glance.