Apache virtual hosts let one server configuration route requests to different websites. Check 4 things when setting them up: the address and port, the requested hostname, the selected virtual host and the document root. DNS pointing at a server is necessary for normal access, but it does not by itself configure Apache to serve the intended site.
This guide concerns Apache HTTP Server 2.4 and name-based routing. Hosting panels and reverse proxies can generate or sit in front of that configuration, so establish the actual request path before editing. Do not apply a standalone tutorial directly to a shared production server without understanding its management layer and change process.
How does name-based virtual hosting work?
Apache’s name-based virtual-host guide explains using the requested hostname to distinguish sites sharing an address. Its configuration examples show common scenarios. The matching address and port are considered before the hostname selection within that group, so an unexpected result can have more than one cause.
| Configuration element | What it controls | Common misunderstanding |
|---|---|---|
| Listening address and port | Where the server accepts the relevant connection | A VirtualHost block alone opens a new listener |
| ServerName | The primary name for the site | DNS automatically supplies the whole configuration |
| ServerAlias | Additional intended names | Every name pointing to the IP is automatically equivalent |
| DocumentRoot | Files served by that site | The directory name determines hostname routing |
| Directory access | Permission to serve the intended content | A correct path guarantees public access |
| Logging | Evidence for requests and failures | A browser screenshot explains which host was selected |
Use explicit names in a multi-site configuration. Apache’s documentation describes how the first matching virtual host can handle a request when no configured name matches. A misspelled or missing name can therefore expose a default site’s content rather than produce the error a beginner expects.
Keep DNS and web routing distinct. DNS resolves a name towards an address; Apache uses the connection and request information to select a site. If either layer is wrong, the browser can show an unexpected result. Diagnose the layers separately instead of changing both at once.
What does a minimal configuration illustrate?
The following is a conceptual Apache 2.4 example for a controlled test environment. The path and names are placeholders, not instructions to overwrite an existing managed file.
<VirtualHost *:80>
ServerName example.test
ServerAlias www.example.test
DocumentRoot "/srv/example/public"
</VirtualHost>
The example identifies names and a document root. It does not create the directory, configure permissions, open firewall access, set DNS or provide HTTPS. Those are separate requirements that must be resolved for the actual environment.
Directory access rules may be inherited from elsewhere or need explicit configuration. Read the relevant existing configuration before adding a broad permission rule. A tutorial that works on an isolated server can unintentionally change access when copied into a shared installation.
If a control panel owns the configuration, use its supported site-management route. Manual edits to generated files can be overwritten or contradict the panel’s model. Identify the owner of each file and retain the original before an authorised change.
How do you verify the selected virtual host?
Apache’s httpd programme reference documents syntax testing and configuration information options. Use the distribution’s appropriate wrapper and configuration path. A syntax check establishes that configuration can be parsed; it does not prove DNS, content permissions or a complete customer journey.
Inspect the virtual-host mapping and compare it with the expected names. If a request reaches the default site, investigate name matching and the active configuration rather than assuming the document root’s files are missing. Check the configuration actually loaded by the running service.
Use a controlled request for each intended hostname. Inspect the response and the relevant logs. A request directly to an IP may select a default site and cannot substitute for testing the proper host. Keep the hostname, scheme and port with the evidence.
Use this original virtual-host diagnostic ledger:
| Layer | Question | Evidence |
|---|---|---|
| Name resolution | Does the intended name reach the expected address? | Resolution checked through an appropriate route |
| Connection | Is the intended service listening on the right port? | Listener and authorised network checks |
| Active configuration | Is the intended file actually loaded? | Configuration inspection |
| Host selection | Which matching block handles the request? | Virtual-host mapping and request evidence |
| Content | Does the selected root contain the intended page? | Safe file inspection and response |
| Access | Can Apache serve the relevant content? | Permissions and error-log evidence |
| HTTPS | Does the secure route select the correct site? | Separate hostname and certificate test |
| Application | Does the important workflow operate? | Representative page or form test |
The ledger is an original troubleshooting aid. It discourages a common mistake: treating every wrong-page response as the same fault. Diagnose the first unsupported link in the request path and preserve the evidence for that conclusion.
What changes when HTTPS is involved?
An HTTP example on port 80 does not configure TLS. The secure listener, certificate and hostname route need their own correct configuration. If a proxy or delivery service terminates TLS, establish how it forwards the request and which host information Apache receives.
Test HTTP and HTTPS deliberately. A redirect may send a correct initial request to an incorrectly configured destination. Inspect the full route and intended canonical hostname rather than checking only that the browser eventually displays a page.
On a shared server, keep changes scoped to the intended site. Preserve the configuration, test parsing and use the authorised reload or deployment process. Do not restart shared services casually to see whether an unexplained change works.
Document the final names, root, configuration owner and verification results. That record helps a later operator distinguish a deliberate alias from an accidental default. It also makes a rollback more understandable if a subsequent application change produces a different symptom.
Run configuration inspection before a controlled request
The Apache reference documents these read-only inspection forms; use the installed distribution’s equivalent executable and the actual configuration path:
httpd -t -f /path/to/test-httpd.conf
httpd -S -f /path/to/test-httpd.conf
The first checks syntax; the second shows parsed virtual-host settings. Neither starts a test listener or changes a running service. Verify that the configuration inspected is the one intended for the task. For an isolated HTTP test listener already running on loopback, a hostname-specific request can be:
curl --resolve example.test:80:127.0.0.1 http://example.test/
This sends the intended Host name without changing DNS. Inspect which site’s response arrives and compare it with the mapping. It does not validate public DNS, HTTPS or the live application. Do not apply these placeholders as a production configuration change.
See hosting for related operating responsibilities. To explain a routing problem, get started with the affected hostname, observed response and relevant non-sensitive configuration details.
Keep mail routing outside a website-host change unless it is explicitly part of the authorised task. A domain can use the same name for several services, and changing its web destination does not establish that its mail delivery should move. Record the exact DNS records and service boundaries involved.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.