Virtual Hosts In Depth: Name-Based, IP-Based & SNI

Web Servers Fundamentals Chapter 4 showed one <VirtualHost> block matched by ServerName/ServerAlias, on a single IP, over plain HTTP. That example quietly skipped three real questions: what happens when a server has more than one IP address, how HTTPS makes this whole mechanism dramatically harder, and what actually happens when a request's Host header doesn't match anything at all.

Name-Based Virtual Hosting (What Fundamentals Already Showed)

Every distinct <VirtualHost> sharing the same IP:port is matched purely by the Host header, exactly as Chapter 4 showed. One historical footnote worth knowing if working from an older tutorial: pre-2.4 Apache required an explicit NameVirtualHost *:80 line to turn this matching on at all. Apache 2.4 removed that requirement — any IP:port combination shared by more than one <VirtualHost> automatically becomes name-based. A leftover NameVirtualHost line from an old config isn't fatal on 2.4 — Apache logs a deprecation warning at startup and ignores it — but it's dead weight worth removing.

IP-Based Virtual Hosting

IP-based hosting is a genuinely different mechanism, not just a variant of the same one: it distinguishes requests by which IP address they arrived on, not by the Host header at all — this requires the server to actually have multiple IP addresses bound to it (multiple NICs, or IP aliases on one interface). It's rare in modern deployments for the exact reason covered next: the historical problem that made IP-based hosting genuinely necessary for HTTPS has since been solved.

The Historical Problem: HTTPS Broke Name-Based Hosting

A TLS handshake — negotiating encryption and presenting a certificate — happens before any HTTP request, including the Host header, is ever sent; it has to, since the request itself needs to be encrypted using whatever the handshake just negotiated. That created a real chicken-and-egg problem for HTTPS name-based hosting: with several <VirtualHost> blocks sharing one IP, each potentially needing a different TLS certificate, Apache had no way to know which certificate to present during the handshake, since the only thing that would have told it which site was intended — the Host header — hadn't arrived yet. For years, the only real fix was IP-based hosting: one dedicated IP address per HTTPS domain, so the IP itself told Apache which certificate to present.

SNI: How Modern HTTPS Solves This

Server Name Indication (SNI) is a TLS extension that adds the target hostname into the very first message of the handshake — the ClientHello — in plain text, before encryption is even established. That's enough information for Apache to pick the correct <VirtualHost>, and therefore the correct certificate, before the rest of the handshake proceeds — solving the historical problem directly, and making genuinely name-based HTTPS hosting on a single IP the normal case today. Client support is effectively universal now (only truly ancient or specialized embedded clients lack it), which is exactly what makes Chapter 6's per-<VirtualHost> mod_ssl configuration possible in the first place.

The Default/Catch-All VirtualHost

When a request's Host header matches none of the ServerName/ServerAlias entries for the matching IP:port, Apache doesn't return an error — it silently serves whichever <VirtualHost> was defined first for that IP:port, in the order the config files were parsed (commonly alphabetical, for a typical sites-enabled/ setup). This is one of the most common real-world Apache surprises: automated scanners and bots routinely probe a server by raw IP address rather than any real domain name, and whatever site happens to load first in the config silently answers every one of those requests.

Hands-On Exercises