In Apache httpd 2.4, how does the server decide which <VirtualHost> block handles an incoming request, and what happens when the request's Host header matches no ServerName or ServerAlias?

## The problem virtual hosts solve One Apache process, one IP address, and many websites. Apache has to decide, per request, which site's document root, logs, TLS settings and proxy rules apply. That decision is the virtual host lookup, and it runs before almost anything else in request handling. ## Stage one: address and port Apache only listens on the addresses and ports named by `Listen`. A `<VirtualHost 10.0.0.5:8443>` block on a server that never says `Listen 8443` is dead configuration — no socket, no traffic, no error that points at the vhost. This is one of the most common "my config is right but nothing happens" causes. Given a connection, Apache collects the vhosts whose address specification matches, preferring the most specific one. A block written `<VirtualHost 10.0.0.5:80>` beats `<VirtualHost *:80>` for a connection that landed on 10.0.0.5. Only the surviving set goes to stage two. ## Stage two: the Host header Within that set, Apache compares the request's `Host` header (or the `:authority` pseudo-header on HTTP/2) against each vhost's `ServerName`, then its `ServerAlias` entries. `ServerAlias` accepts wildcards: ```apacheconf <VirtualHost *:80> ServerName www.example.com ServerAlias example.com *.example.com DocumentRoot /srv/www/example </VirtualHost> ``` Matching is first-match, in configuration order, and configuration order means the order files are pulled in by `Include`/`IncludeOptional` — usually alphabetical by filename. A vhost carrying a broad `ServerAlias *.example.com` placed early will shadow a later vhost whose `ServerName` is exactly `api.example.com`. Nothing warns you; requests simply land on the wrong site. ## The default vhost, and why it surprises people If no name matches, Apache uses the **first** vhost defined for that address:port. There is no 404-by-hostname behaviour and no "unknown host" error. Practical consequences: - Someone else's domain pointed at your IP gets served by your first vhost. - A typo'd `ServerName` silently demotes that site to unreachable-by-name, while its content shows up for every unmatched host. - Scanners hitting the bare IP see whatever the first vhost exposes. The fix is to make the default explicit rather than accidental: define a first-listed catch-all vhost that returns 404 or a static holding page, and give it a filename that sorts first (`000-default.conf` is the Debian convention for exactly this reason). ## ServerName also affects generated URLs `ServerName` is not only a matching key. When Apache builds a self-referential URL — the redirect it issues when a directory request lacks its trailing slash, for instance — `UseCanonicalName` decides whether it uses the configured `ServerName` (`On`) or the hostname the client supplied (`Off`, the common default in shipped configs). Setting `ServerName` to an internal hostname while `UseCanonicalName On` is in force produces redirects to a name clients cannot resolve. ## TLS makes ordering matter earlier For an HTTPS vhost the certificate must be chosen during the TLS handshake, before any `Host` header exists, so Apache uses the SNI name the client sent. If the client sends no SNI, or sends a name no vhost claims, the handshake is completed with the **first** HTTPS vhost's certificate — after which the request's `Host` header may point somewhere else entirely. `SSLStrictSNIVHostCheck` controls whether such a mismatch is rejected instead of served. ## Diagnosing it `apachectl -S` (equivalently `httpd -S` or `apache2ctl -S`) dumps the resolved virtual-host map: every address:port, every vhost under it with the file and line number it came from, and an explicit `default server` marker. Reading that output takes seconds and settles most "why is this domain serving the wrong site" arguments immediately. Pair it with `apachectl configtest` before any reload. ## Rules worth memorising 1. Address:port narrows; `Host`/SNI selects; first match wins. 2. No match falls back to the first vhost for that address:port — never an error. 3. `NameVirtualHost` is a no-op in 2.4; delete it rather than tuning it. 4. A vhost on a port with no `Listen` receives nothing.