Apache Virtual Hosts: Explain the Site That Answered

A domain points at the expected server, yet Apache displays another site's page. DNS chooses an address; it does not select the virtual host inside Apache. The web server first considers the destination address and port, then the hostname within the applicable group. HTTPS adds a TLS server-name step before the HTTP request.

Prepare the intended hostname, origin address, port and current virtual-host files. Confirm whether a proxy terminates TLS before Apache. Use non-sensitive test pages and keep host verification active. Avoid changing public DNS to diagnose a configuration-selection problem that can be reproduced directly against the intended origin.

1. Run apachectl -S or the distribution's supported equivalent. Record the address-and-port groups, first/default hosts and configuration locations. This view is more useful than reading a directory listing because include order and enabled-site links determine effective configuration. Check command output for warnings about missing names or configuration ambiguity.
2. Inspect ServerName, ServerAlias and <VirtualHost> arguments for the intended site. Apache selects the most specific address match before comparing names. A name in an unrelated address group does not become eligible simply because it looks correct. Review duplicate names and wildcard aliases that could make ownership unclear.
3. For HTTPS, test with the intended hostname in the connection as well as the request. A controlled curl --resolve site.example:443:192.0.2.10 https://site.example/ pattern preserves hostname and SNI while selecting a test origin address; substitute approved values for these placeholders. Do not replace certificate validation with an insecure flag as the acceptance test.
4. Compare the virtual host's access log and a harmless site-specific response marker. A shared error page or identical document root can make a correct virtual-host selection appear wrong. Verify the actual handler, proxy target or document root after identifying which host accepted the request.

In an illustrative multi-site server, a new domain is added to DNS but omitted from ServerAlias. Apache receives the request on a valid address and port, finds no matching name and uses that group's first virtual host. Moving random files in the document root cannot repair the missing hostname declaration. The configuration map exposes the selection immediately.

Add or correct the intended name in the proper virtual host and remove only demonstrated conflicting declarations. Define how unknown hostnames should be handled instead of relying on accidental file order. Preserve the prior files, run the supported syntax test and use a planned reload.

Verify the intended hostname, aliases, HTTP-to-HTTPS behavior and an unmatched-host test. Confirm the certificate identity for HTTPS and check the site-specific log. Existing unaffected sites should also pass a representative request because name-order changes can alter their fallback behavior.

Record hostname ownership, address groups, certificates, roots or upstreams and default-host policy. Include apachectl -S review and hostname-aware requests in deployment acceptance. Clouvenix Linux administration can help keep multi-site selection predictable.

Technical reference

Apache name-based hosting, matching details and virtual-host diagnostics.