Virtual Hosts, Server Blocks & Sites

Web Servers Fundamentals

Chapter 4 · Virtual Hosts, Server Blocks & Sites

Every chapter so far has quietly assumed one server serves one website. In practice, a single physical (or virtual) server very often needs to serve several completely different sites at once — this chapter covers the mechanism each of the three servers uses to do that, under three different names for the same underlying idea.

The Problem: One Server, Many Websites

A server typically has one IP address, listening on port 80/443 — but DNS can point any number of different domain names at that same IP. When a request arrives, every browser sends a Host header naming which domain it actually wants, and the web server uses that header to decide which site's content to serve. DNS only gets the request to the right server; splitting it apart by domain from there on is the web server's own job.

Apache's VirtualHost Blocks

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example
</VirtualHost>

Apache defines a separate <VirtualHost> block per site, each naming its own ServerName (and optional ServerAlias entries for additional domains that should match the same block) and its own DocumentRoot. When a request arrives, Apache matches the incoming Host header against each block's ServerName/ServerAlias to decide which one handles it.

Nginx's Server Blocks

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example;
}

Nginx's server {} block is functionally the same idea as Apache's <VirtualHost>, just under different terminology: a listen directive for the port, a server_name directive matched against the Host header, and a root for that site's own files. The underlying concept is identical to Apache's — a per-site config block, matched by domain name — even though Nginx's own syntax looks nothing like Apache's directive style.

IIS's Sites

In IIS Manager, each site is configured with one or more bindings — a combination of IP address, port, and host name — and every site is tied to a specific Application Pool (Chapter 2). IIS matches an incoming request's Host header against each site's bindings the same way Apache and Nginx match against ServerName/server_name, just configured through the GUI (or the equivalent XML) rather than a text block.

	Apache	Nginx	IIS
Term used	Virtual Host	Server Block	Site
Matching mechanism	`ServerName`/`ServerAlias` vs. Host header	`server_name` vs. Host header	Bindings (IP/port/hostname) vs. Host header
Config location	A `<VirtualHost>` block, often its own file under `sites-available`	A `server {}` block, often its own file under `sites-enabled`	IIS Manager GUI / `applicationHost.config`
Tied to a process/pool	Shares the same Apache process pool	Shares the same Nginx worker processes	Each Site is tied to its own Application Pool

Connecting this to earlier chapters

Setting Up a Web Server on Debian's own real Apache configuration set up exactly one <VirtualHost> block for one domain — the same mechanism this chapter describes, just not yet exercised with a second site alongside it. This also sets up Chapter 7 directly: each of these per-site blocks commonly needs its own TLS certificate, since HTTPS/TLS Fundamentals' own certificate material is typically issued per domain, not per server.

DNS doesn't split the traffic — the web server does

It's a common point of confusion to assume that pointing two different domains at the same server's IP address somehow automatically "just works," with DNS itself routing each domain to different content. DNS only resolves a domain name to an IP address — it has no idea what's running on that server or how many sites it hosts. The actual split, based on the Host header included in every request, happens entirely inside the web server itself, via whichever mechanism this chapter just covered.

Hands-On Exercises

Exercise 1

Write an Apache VirtualHost block that serves site-a.example from /var/www/site-a and a separate one that serves site-b.example from /var/www/site-b, both on port 80.

📄 View solution

Exercise 2

A user points two different domains at the same server's IP address via DNS, then is confused when both domains show identical content instead of two different sites. Using this chapter's own warning box, explain what's actually missing.

📄 View solution

Exercise 3

Explain, in your own words, why an IIS Site being tied to its own Application Pool is a meaningfully different guarantee than an Apache VirtualHost or Nginx server block sharing the same pool of worker processes as every other site on that server.

📄 View solution

Chapter 4 Quick Reference

The same idea, three names: Apache's VirtualHost, Nginx's server block, IIS's Site
All three match an incoming request's Host header against a configured name/binding to decide which site handles it
DNS only resolves a name to an IP — the web server itself performs the actual per-domain split
IIS Sites are each tied to their own Application Pool (Chapter 2); Apache/Nginx sites on the same server typically share the same process pool