iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
You can host many domains on one Apache server and one IP address by using name-based virtual hosting. DNS sends every domain to the server; Apache then examines the requested hostname and selects the matching <VirtualHost> block. Use one block for each independent website, and use ServerAlias when several names should serve the same site.
The title’s “one virtual host” wording is easy to misunderstand: the Apache instance can use one listening address, but several virtual-host blocks are normally required. The procedure below covers DNS, HTTP, HTTPS, configuration order, verification, and the common reasons Apache serves the wrong site.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match
How Apache maps several domains to one server
Name-based hosting separates sites by hostname rather than by having a different IP address for every site. A browser first resolves a domain through DNS, opens a connection to the resulting address, and sends an HTTP Host header such as example.com. Apache groups virtual hosts by local IP address and port, then compares that hostname with each block’s ServerName and ServerAlias.
For HTTPS, the TLS handshake also includes the hostname as SNI (Server Name Indication). Apache uses the SNI name to choose the SSL virtual host, while the certificate presented must cover the requested name. Certificate selection and renewal are separate tasks from Apache’s hostname-to-document-root mapping.
#1 Best Overall
Apache’s official 2.4 guidance describes name-based virtual hosting as usually simpler. It also specifies an important fallback rule: within an address-and-port group, the first virtual host in configuration order becomes the default when no ServerName or ServerAlias matches.
Decide whether names are separate sites or aliases
Before writing configuration, determine whether the domains represent independent content or different names for one site. That decision controls the number of document roots, certificates, redirects, logs, and access rules.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Layout | Virtual-host blocks | Document root | Typical use | Main caution |
|---|---|---|---|---|
| Independent domains | One block per domain | Separate directory for each site | Different applications, owners, or deployment schedules | Keep permissions, logs, and credentials isolated. |
| Alternate names for one site | One block with multiple ServerAlias entries |
One shared directory | www.example.com and example.com, or a rebranded domain during migration |
Choose one canonical name and redirect other names if search and cookie behavior require it. |
| Shared content by design | Separate blocks may point to one directory | One shared directory | Deliberately identical, host-aware content | Applications must correctly handle the hostname; accidental sharing can expose data. |
| HTTP and HTTPS | Usually an HTTP block and an HTTPS block per site | Often the same directory | Redirecting HTTP to HTTPS and serving encrypted traffic | Port 80 and port 443 are different address-and-port groups and need matching settings. |
Do not create multiple aliases when the names are actually separate sites. An alias routes all those names to the same block and therefore the same document root, rewrite rules, environment, and usually the same logs.
Prerequisites: DNS, addresses, and Apache listening ports
Point every name at the server
Apache configuration does not create DNS records. For each domain and alias, create the required A record for an IPv4 address, an AAAA record for an IPv6 address, or the equivalent record used by your DNS provider. The records must resolve to an address where this Apache instance is reachable.
Rank #2
- Used Book in Good Condition
Check DNS before debugging Apache. From a system with DNS tools, query each name and confirm that the answer is the intended public address. If an old address remains in a resolver cache, requests can reach a different server even when your Apache file is perfect. If you publish both A and AAAA records, make sure Apache and the firewall are configured for IPv6 as well as IPv4; otherwise some visitors may consistently reach the wrong service or fail to connect.
Make sure Apache accepts the ports
The server must listen on the ports used by the virtual hosts, normally 80 for HTTP and 443 for HTTPS. A firewall, cloud security group, reverse proxy, or load balancer must permit the corresponding traffic. A virtual-host block cannot receive a request on a port Apache is not listening to.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsCreate a document root for each independent site
Use a distinct directory when domains are independent. For example, you might place the files for example.com under /var/www/example.com/public_html and the files for example.net under /var/www/example.net/public_html. The exact base directory is your choice; consistency matters more than the name.
- Give the Apache service read and directory-traverse permission without making application secrets web-accessible.
- Keep upload directories and configuration files outside the public document root when the application allows it.
- Use separate deployment and backup paths so restoring one site does not overwrite another.
- Do not point unrelated sites at a common directory merely to avoid creating directories; that removes an important isolation boundary.
Write one HTTP virtual-host block per site
Each name-based block should contain an explicit ServerName and DocumentRoot. Add ServerAlias only for additional names that should serve that same site. A minimal two-site HTTP configuration is:
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com/public_html
ErrorLog /var/log/apache2/example.com-error.log
CustomLog /var/log/apache2/example.com-access.log combined
</VirtualHost>
<VirtualHost *:80>
ServerName example.net
ServerAlias www.example.net
DocumentRoot /var/www/example.net/public_html
ErrorLog /var/log/apache2/example.net-error.log
CustomLog /var/log/apache2/example.net-access.log combined
</VirtualHost>The *:80 notation means “any local address on port 80.” You can use a specific local address instead when the server has a deliberate multi-address design, but every block that should answer a given address and port must be grouped consistently.
The log paths in the example use a Debian-style directory. On systems that store Apache logs elsewhere, change the paths to an existing directory writable by the service. Separate logs make it possible to identify which site generated an error or request; a shared log is valid when centralized analysis is more important than per-site separation.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Optional directory access rules
Apache 2.4 installations commonly grant access with a <Directory> section. If your global configuration does not already grant access to the chosen root, add a narrowly scoped rule such as:
<Directory /var/www/example.com/public_html>
Require all granted
AllowOverride None
</Directory>Use AllowOverride only when the application genuinely needs .htaccess; permitting overrides can increase per-request work and lets files in the tree change Apache behavior. If you enable overrides, allow only the directive classes the application needs rather than enabling every class indiscriminately.
Install the configuration and validate Apache’s view
- Save the file in the active configuration tree. Debian and Ubuntu commonly keep site files under
/etc/apache2/sites-available/. RHEL- and Fedora-family systems commonly load virtual-host files from an includedconf.ddirectory. Use the layout already included by your distribution. - Enable the site files where required. On Debian or Ubuntu, enable each file with the distribution’s
a2ensitecommand. On systems that automatically includeconf.d, placing a correctly named file there is usually sufficient. Do not assume that a file in an arbitrary directory is loaded. - Run a syntax check before reloading. Use
apachectl configteston Unix-like systems. Fix every reported error before reloading; a failed reload can leave the previous configuration running, which makes testing misleading. - Inspect the parsed virtual-host map. Run
apachectl -S. On Windows, the equivalent diagnostic ishttpd.exe -S. The output shows address-and-port groups, the default host, configuration-file order, and theServerName/ServerAliasvalues Apache actually recognized. - Reload Apache gracefully. Use the service name supplied by your operating system, commonly
apache2on Debian/Ubuntu andhttpdon RHEL/Fedora. A reload applies configuration changes without unnecessarily dropping existing connections.
Do not rely on the filename alone to determine precedence. Apache uses the order of the parsed configuration, which may differ from the order you expect if files are included by several directives. The -S output is the authoritative check for what Apache loaded.
Add HTTPS for every public hostname
For encrypted traffic, create corresponding *:443 virtual hosts. Enable the SSL module and provide a certificate and private key appropriate for the names in that block. A certificate can cover several names through subject-alternative-name entries, or you can use separate certificates and blocks; the certificate strategy must match your operational and security requirements.
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com/public_html
SSLEngine on
SSLCertificateFile /path/to/example.com-fullchain.pem
SSLCertificateKeyFile /path/to/example.com-privkey.pem
ErrorLog /var/log/apache2/example.com-ssl-error.log
CustomLog /var/log/apache2/example.com-ssl-access.log combined
</VirtualHost>Replace the certificate paths with files managed by your certificate process; the paths above are illustrative, not downloadable files. Every HTTPS name that users enter must be covered by the certificate presented for that request. A valid HTTP mapping does not prove that HTTPS will select the same site, because HTTPS adds SNI and certificate matching.
Redirect HTTP without creating a loop
If a site should be HTTPS-only, keep a port-80 block whose sole purpose is to redirect to the canonical HTTPS hostname, and keep application content in the port-443 block. Make sure the HTTPS endpoint is reachable before enabling the redirect. When a reverse proxy terminates TLS before Apache, use the proxy’s documented forwarded-protocol settings carefully; otherwise an application may believe every request is HTTP and repeatedly redirect.
Best Value
- Used Book in Good Condition
Test each domain as a client would
- Confirm each domain’s DNS answers point to the intended server.
- Request each HTTP hostname and verify the expected status, title, or response body. You can test a specific address before DNS changes finish with a request that supplies the intended
Hostheader. - For HTTPS, test with the hostname in the URL and verify both the certificate name and the returned content. A command such as
curl --resolve example.com:443:203.0.113.10 https://example.com/directs that hostname to a chosen test address while preserving SNI; replace the example address with the server’s actual test address. - Test every alias, not only the primary name. An omitted alias falls through to another virtual host or to the default host.
- Review the per-site access and error logs while making a request. The entry confirms which Apache instance received it and often reveals permissions, rewrite, or application errors.
Why Apache shows the wrong site
| Symptom | Likely cause | What to check or change |
|---|---|---|
| A domain consistently shows the first site | No matching ServerName/ServerAlias, or the request arrived on an unexpected port |
Inspect the request hostname, the block’s spelling, and apachectl -S. Add the missing name to the correct block. |
| Only some users see the wrong site | DNS answers differ, stale caches exist, or IPv6 reaches another endpoint | Query A and AAAA records from affected networks and compare the destination addresses. |
| HTTP works but HTTPS shows another site or a certificate warning | Missing *:443 block, incorrect SNI match, or a certificate that omits the hostname |
Create or correct the 443 block, verify SNI behavior, and install a certificate covering every requested name. |
| Both domains display identical files unexpectedly | Both blocks use the same DocumentRoot, or the application ignores the hostname |
Assign separate roots for independent sites and inspect application host-routing settings. |
| Apache refuses to reload | Syntax error, duplicate or malformed directive, unreadable certificate, or invalid path | Run apachectl configtest, correct the first reported error, then test again before reloading. |
| The right block is selected but returns 403 | Filesystem permissions, missing directory traversal permission, or restrictive <Directory> rules |
Check each parent directory, the service account’s read access, and the effective access directives. |
| Changes appear to have no effect | The file is not included, the service was not reloaded, or a proxy/cache serves an old response | Confirm the file appears in apachectl -S, reload the correct service, and test the origin directly. |
Configuration choices that prevent future problems
Make the default host intentional
Because the first host in an address-and-port group is the fallback, put a deliberate default there. It can be a harmless landing page or a catch-all that rejects unknown hostnames. Do not let an unrelated production site become the accidental response for misspelled domains or hostile Host headers.
Keep aliases explicit
List every supported alternate name in ServerAlias, including the exact www form when it is intended to work. An alias is not a DNS record and a DNS record is not an Apache alias; both layers must be configured.
Separate logs and access policy when sites are independent
Per-site logs simplify incident response, traffic analysis, and retention decisions. Independent applications should also have separate filesystem permissions, deployment credentials, scheduled jobs, and backup scopes. Shared logs or directories are reasonable only when the sites are intentionally operated as one unit.
Plan certificate renewal
Record which hostnames each certificate covers, where its key is stored, and how renewal reloads Apache. Test renewal before expiration. Adding a new ServerAlias to HTTP does not automatically add that name to an existing certificate.
Account for application-level host handling
Apache can route a request to the correct directory while the application still generates links for the wrong hostname, accepts untrusted host headers, or shares sessions across domains. Configure each application’s canonical URL, allowed-host list, cookie scope, and redirect policy independently of Apache’s virtual-host mapping.
When one IP is not enough
Name-based hosting is appropriate for most modern HTTP and HTTPS deployments, but a separate IP can still be useful when a legacy protocol cannot provide a hostname, when strict network isolation is required, or when an external device routes traffic by address rather than by host. Those cases are exceptions; adding IP addresses does not remove the need for correct DNS, certificate coverage, or explicit Apache configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
A repeatable deployment checklist
- Every domain and alias has the intended A and/or AAAA record.
- The server, firewall, and any proxy accept the required ports.
- Each independent site has its own document root and access policy.
- Each block has an explicit
ServerNameandDocumentRoot. - Aliases are listed with
ServerAliasonly when they should serve the same site. - HTTP and HTTPS blocks are both present where encryption is required.
- Certificates cover every HTTPS hostname and private keys are protected.
apachectl configtestsucceeds.apachectl -Sshows the expected names, ports, order, and default host.- Requests to every name return the intended content, and logs show the expected site.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
