If a domain shows the wrong website or a Virtualmin default page, first establish which server and virtual host answered the request. The symptom can come from DNS, disabled hosting, an empty document root or a hostname mapping problem.
IN THIS ARTICLE
Gather the details you will need
Record the exact URL, displayed page and certificate. Check both the apex and www hostname, as well as IPv4 and IPv6 records. Preserve current domain configuration before changing address mappings or document roots.
01 Fix a Virtualmin domain that shows the wrong website
- Query the public A and AAAA records and compare them with the intended server addresses. Check a CDN or reverse proxy separately because it may be serving cached content or a different origin.
- Select the domain in Virtualmin and inspect whether its website feature is enabled and whether the virtual server is suspended or disabled. Resolve the authorized account-status cause rather than bypassing it.
- Review the configured document root and its index files. A default index page can remain ahead of the application expected entry file, but back it up before replacing it.
- Test the destination using the real hostname with controlled resolution, such as an authorized hosts-file override. Browsing an IP alone may legitimately select the default virtual host and show a different site.
- Inspect the web-server virtual-host mapping and domain logs. Confirm HTTP and HTTPS both select the right hostname and address combination.
- Correct the specific DNS, alias, document-root or enabled-state issue, then retest without cached browser content.
02 Example: test the intended destination without changing public DNS
From a trusted workstation with curl, substitute the actual hostname and destination address. The address below is a documentation placeholder:
curl --resolve example.com:443:192.0.2.10 -I https://example.com/This sends the HTTPS request to the specified address while retaining example.com for the requested host and certificate check. It does not change public DNS. Review the returned status and headers, then inspect the actual page through an approved preview or local resolution method because a header-only response does not prove the page content is correct.
A certificate error is useful evidence; do not add a verification bypass merely to hide it. Confirm the destination is prepared to serve that hostname. Repeat separately for each intended hostname and compare with a normal request that uses public DNS. This avoids drawing conclusions from browsing a bare IP, which can select a different virtual host.
Does a default page mean the server is offline?
No. It usually proves a web server answered. The next question is whether the requested hostname selected the intended active site and document root.
Confirm the expected result
Confirm the expected site appears under each intended hostname and that the TLS certificate matches. Check a dynamic page as well as a static file. Verify neighbouring domains still select their own content.
If the problem continues
Do not reorder or delete unrelated virtual hosts just to make an IP address display one website. Avoid enabling Apache UserDir as a generic preview workaround on shared hosting. If a recent migration caused the issue, compare the destination address and template settings with the recorded source design.