Apache HTTPD / Request identity and configuration foundations / Lesson 3

Virtual hosts, Host names, and default selection

Separate listener binding, address matching, name matching, DNS, and TLS identity.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain first-match fallback within the relevant address set.
Review why changing DNS or a hosts file does not configure a virtual host.

Address and name selection are separate stages

Name-based virtual hosting lets several sites share a suitable address and port while selecting configuration using the reported hostname under documented matching behavior. Apache first determines the relevant address set, then applies name matching within it. Parcel and documentation can share a listener yet use different roots and policies. A DNS record helps a client find an address; it does not create an Apache VirtualHost. Conversely, a configured ServerName does not publish DNS or open a listening socket.

The first relevant virtual host matters

If no name matches within the selected address set, the first configured virtual host for that set can supply default behavior. Ordering therefore has operational meaning. Do not let an unknown hostname accidentally expose an unrelated sensitive site or assume a wildcard name is a permission boundary. Host input comes from the client and is not authenticated identity by itself. TLS adds certificate and SNI selection considerations before the ordinary HTTP request; those are developed in the TLS lesson rather than collapsed into one host-header rule.

Read two illustrative site definitions

The fragment below declares two synthetic names and Unix-style roots on an illustrative port. It does not include Listen, modules, access sections, files, or a complete security policy and is never loaded. No port is opened and no directory is created. The reserved example.invalid hostnames are teaching inputs. A real review must verify the actual address set, include order, effective ServerName and aliases, access rules, and protocol path. Successful text parsing alone would not prove that clients reach the intended site.

apache A non-runnable virtual-host fragment

<VirtualHost *:8080>
    ServerName parcel.example.invalid
    DocumentRoot "/lab/parcel/public"
</VirtualHost>
<VirtualHost *:8080>
    ServerName docs.example.invalid
    DocumentRoot "/lab/docs/public"
</VirtualHost>

The first definition illustrates fallback within this declared matching set, subject to the real server’s full configuration. The fragment does not enable a listener, authorize filesystem access, or establish TLS.

Model only exact names in one declared address set

The complete local program below selects a root from a list of exact lowercase names and otherwise returns the first entry. It does not implement Apache wildcard, address precedence, aliases, trailing-dot, port parsing, HTTP protocol, or TLS behavior. Its scope is deliberately narrow so a fallback decision is visible without network operations. Do not use it as a production hostname validator. Actual diagnostics must retain the request’s effective host and selected virtual-host evidence from an authorized observation path.

python A limited exact-name fallback model

sites = [("parcel.example.invalid", "parcel-root"), ("docs.example.invalid", "docs-root")]
def selected(host):
    return next((root for name, root in sites if host == name), sites[0][1])
print(selected("docs.example.invalid"))
print(selected("unknown.example.invalid"))

Expected output

docs-root
parcel-root

Only declared strings are compared. No DNS, socket, HTTP request, Apache matcher, or TLS handshake is used.

Prove the selected site before changing content

When the wrong page appears, compare the intended URL, resolved destination under the owner’s evidence, protocol, host, address set, include order, and site-specific logs. A direct IP request can legitimately select a default different from a named request. A preceding reverse proxy may rewrite Host or route to another backend. Changing DocumentRoot repeatedly cannot repair an unproven routing path. Keep the default behavior intentional and review unknown-host cases alongside normal named cases before any separately authorized configuration change.

Common errors and fixes

Adding a DNS record is expected to create the site configuration.

Why it happens: Name resolution was confused with server virtual-host selection.
How to fix it: Review DNS and Apache configuration as separate prerequisites.
Prevent it next time: Document the full client-to-listener-to-site path.

An unknown hostname serves the first site unexpectedly.

Why it happens: Default selection and include ordering were not reviewed.
How to fix it: Identify the relevant address set and intended fallback policy.
Prevent it next time: Include unknown-host cases in site-routing review.

A direct IP check is treated as equivalent to the intended named HTTPS request.

Why it happens: Hostname, TLS identity, and request path differ.
How to fix it: Compare equivalent scheme, destination, name, and protocol conditions.
Prevent it next time: State what each routing observation actually tests.

Check your understanding

1. In the local model, why does unknown.example.invalid select parcel-root?

Show worked solution

No exact name matches, so the model returns the first entry in its declared list. This illustrates one fallback idea only. Real Apache selection requires the full address and name-matching rules and effective configuration.

2. A reverse proxy sends the backend a different Host value. Can Apache choose another virtual host while DNS remains correct?