To park a domain on a LAMP server, point its DNS records at the server, then add an Apache name-based virtual host that recognizes the hostname. Apache’s virtual-host file and public DNS are separate: a correctly written vhost cannot make a domain resolve by itself. Once DNS, the document root, Apache configuration, and request tests all agree, multiple domains can share one IP while Apache sends each hostname to the intended site.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What “parked domain” means on a LAMP server
In this context, a parked domain is an additional hostname that should reach an Apache server already hosting a website. The extra hostname can serve the same content as an existing domain, or it can have its own directory and logs while using the same server and IP address. Apache’s name-based virtual hosting is designed for this arrangement: it examines the hostname in each HTTP request and selects the matching virtual host.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Parking is therefore a routing task with two independent layers:
- DNS tells clients which IP address to contact for each hostname.
- Apache decides which site configuration handles a request after it reaches that IP address.
Both layers must be correct. A DNS record pointing at the wrong address never reaches your intended server, while a valid DNS answer can still display the wrong site if Apache’s ServerName, ServerAlias, or virtual-host order is wrong.
#1 Best Overall
Choose the hosting layout before changing files
Decide whether the parked hostname should share content with another domain or receive an isolated site. This choice determines the document root, log files, deployment process, and how much damage a misconfiguration can cause.
| Layout | Document root | Logs | Best fit | Main trade-off |
|---|---|---|---|---|
| Shared content | The same root used by the primary domain | Can be shared, although separate access and error logs make hostname-specific diagnosis easier | A true alias or alternate spelling that should show identical pages | A change made for one hostname changes what every alias serves |
| Isolated domain | A separate directory such as /var/www/example.com/public_html |
One access log and one error log for that domain | Different content, independent deployments, or clearer ownership boundaries | More directories, configuration, and maintenance to manage |
The example below uses an isolated document root because it makes the routing boundary obvious. If the parked name should show an existing site, replace its DocumentRoot with the established site’s root and keep the hostname declarations explicit.
Prepare DNS for every hostname
Create DNS records before expecting a browser or command-line client to reach Apache. For each public hostname, add an address record that resolves to the server’s reachable address. The Apache documentation specifically cautions that creating a virtual-host configuration does not create DNS entries.
| Hostname | Record to consider | Purpose |
|---|---|---|
example.com |
A record for the server’s IPv4 address; AAAA if the server is intentionally reachable over IPv6 | Handles the bare domain |
www.example.com |
A and/or AAAA record for the same service, according to your DNS design | Handles the common www name |
| Any additional alias | A and/or AAAA record for that exact hostname | Allows Apache to receive and match the alias |
Do not add an AAAA record merely because the server has an IPv6 address somewhere in the network. An AAAA answer invites IPv6-capable clients to connect over IPv6; that path must lead to the same host, port, firewall policy, and Apache listener as the IPv4 path. If IPv6 is not ready, omit the AAAA record until it is.
DNS changes can take time to appear at different resolvers. During that period, one client may obtain a new address while another still has a cached answer. Test the actual answers from the network where the site will be used rather than assuming that a single resolver represents everyone.
For local-only testing, a hosts-file mapping can associate a name with the server’s address on one computer. That is useful for checking Apache before public DNS is ready, but it affects only the machine containing the entry; it does not publish the domain.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
- Used Book in Good Condition
Create the document root safely
Create a directory for the parked site, for example:
/var/www/example.com/public_htmlPlace the site’s entry page and application files beneath that directory. Set ownership and permissions according to the policy of your Linux distribution and the account model used by its web server. The web-service account must be able to read the files it serves, while write access should be limited to the directories and deployment processes that genuinely require it.
Keep the directory path consistent with the path in the Apache configuration. A typo or a directory that the Apache process cannot traverse can produce a permission error or an empty-looking site even when DNS and hostname matching are correct.
Write a name-based Apache virtual host
Distribution packages normally keep site definitions in an Apache sites directory. Create a file for the parked domain there, using the filename convention already used by your system. The following configuration is a complete HTTP example:
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com/public_html
<Directory /var/www/example.com/public_html>
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>Each directive has a distinct job:
<VirtualHost *:80>limits this definition to HTTP traffic received on port 80 on the server’s available addresses.ServerName example.comgives Apache the canonical hostname to match. Keep it explicit; leaving it out can allow an unintended server name to be inherited.ServerAlias www.example.comadds another hostname that should use this same virtual host. Add further aliases only when you have created DNS records for them and intend to serve them.DocumentRootidentifies the top-level directory from which Apache serves files.- The
Directoryblock grants access to that path and permits per-directory rules in.htaccessbecauseAllowOverride Allis set. If your application does not need.htaccess, a narrower override policy is preferable, but the example preserves the supplied Apache pattern. ErrorLogandCustomLoggive this host its own diagnostic and request records. Thecombinedformat includes the usual request details used when investigating routing.
Make sure the aliases are written exactly as clients will send them. A request for store.example.com does not match a configuration that lists only example.com and www.example.com.
Use the same content for a parked alias
If “parked” means that the additional domain is simply another name for an existing site, you do not need a second copy of the files. Point the parked virtual host at the existing site’s DocumentRoot, or add the parked hostname as a ServerAlias on the existing virtual host when that is the clearest operational design.
Keeping the additional name in an explicit declaration is safer than relying on a catch-all. It documents the supported hostnames and prevents an unrelated request from being silently treated as a valid alias. If you need hostname-specific redirects or application behavior later, a separate virtual-host definition and log set makes that split easier to operate.
Enable the site and reload Apache
Save the vhost file, then enable it using the mechanism supplied by your Linux distribution. On Debian-family systems, a typical sequence is:
Recommended Free Tools
sudo a2ensite example.com.conf
sudo systemctl reload apache2Use the actual filename you created. A reload asks Apache to read the new configuration while allowing existing workers to finish; do not assume that editing a file automatically activates it. If your distribution does not provide a2ensite, place the file in the distribution-managed virtual-host directory and use that system’s documented reload procedure.
A reload should be performed only after checking the syntax. If Apache rejects the configuration, correct the error before attempting to serve traffic; an invalid change can prevent the service from loading its configuration.
Inspect Apache’s parsed virtual-host map
Run:
sudo apachectl -SApache documents apachectl -S as a way to dump how it parsed the virtual-host configuration. Read the output rather than checking only whether the command exits: verify the address and port, the file Apache loaded, the ServerName, every expected alias, and the order in which hosts are listed.
This command is especially valuable when several files appear to describe the same domain. It reveals duplicate declarations, a vhost attached to an unexpected address, and a configuration file that was never enabled. The parsed view is more reliable than guessing from filenames.
Test DNS and HTTP routing in a controlled order
Test one layer at a time so a failure has a narrow cause. The following sequence covers the bare domain, its alias, and Apache’s behavior for an unknown name.
- Check the DNS answer for the bare domain. Query the A and, when applicable, AAAA records for
example.com. Confirm that the returned address is the server you configured, not an old host or an unrelated service. - Check every alias. Query
www.example.comand any other hostname listed inServerAlias. Each name must resolve independently; a working bare domain does not prove that its alias has a record. - Request the bare domain over HTTP. Use a client that sends the hostname, such as a browser or an HTTP command-line request. Confirm that the response comes from the intended document root and that the dedicated access log records the request.
- Request the
wwwname. It should select the same vhost when it is declared as an alias. Check its access-log entry separately so you know which hostname reached Apache. - Try an intentionally unknown hostname. Send a request for a name that is not listed. This shows which virtual host is acting as the fallback and helps you detect an unsafe default site.
- Compare the result with
apachectl -S. If the observed page conflicts with the parsed map, check that the request reached the expected IP and port before changing the vhost file.
For a local test before DNS is public, use a hosts-file entry on the test computer, then remove or update it when public DNS becomes authoritative. A hosts-file test proves only that this machine can reach Apache with that hostname; it says nothing about other clients.
How Apache selects the virtual host
When a request arrives, Apache first finds the best matching address and port. For name-based hosting, it then compares the requested hostname with the ServerName and ServerAlias values attached to virtual hosts for that address and port.
If no declared name matches, Apache uses the first listed virtual host for that address and port. That first entry is therefore the fallback for unknown or misspelled hostnames. Put the vhost you deliberately want as the default first, and do not depend on accidental file ordering. A request can reach the right IP and still show the wrong site solely because no hostname matched and another vhost was listed first.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The same logic applies independently to each address-and-port combination. An HTTP definition on port 80 is not a substitute for a correctly configured TLS virtual host on the port used by HTTPS.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot the common failure modes
The wrong site appears
- Check the hostname in the browser or HTTP request. A typo, an unexpected
wwwprefix, or a stale bookmark can select a different host. - Verify that the hostname resolves to the intended server address, including the IPv6 answer if an AAAA record exists.
- Review
ServerNameandServerAliasfor spelling, punctuation, and the exact names clients use. - Run
apachectl -Sand inspect which vhost is first for the address and port. An unmatched name will use that first entry. - Check the vhost’s access log. If no request is recorded there, the request may be reaching another server, another port, or a different virtual host.
The domain does not connect
- Confirm that A and/or AAAA records exist for the exact hostname.
- Compare DNS answers with the server’s current public addresses and allow for resolver caching after a change.
- Check firewall rules and upstream network policy for the port being tested.
- Confirm that Apache is listening on the requested port and address. A vhost declaration alone does not open a firewall or create a listener.
- Use the server’s error log and the client’s connection error together; a name-resolution failure is different from a refused or timed-out TCP connection.
The site works only on the server or one workstation
A hosts-file override or local DNS cache may be masking a public DNS problem. Test from a second network without the override, and inspect the authoritative records rather than relying on the local machine’s cached result.
Best Value
- Used Book in Good Condition
The configuration behaves unexpectedly
Start with apachectl -S. Confirm that the file is enabled, the vhost is attached to the expected address and port, and the aliases appear under the intended ServerName. Then inspect the access and error logs named in the vhost. This sequence avoids changing multiple settings before identifying which layer is actually failing.
Operational choices: isolation, routing, and maintenance
| Decision | Explicit per-domain setup | Shared or catch-all setup |
|---|---|---|
| Isolation | Separate root and logs make ownership, permissions, and incident review clearer. | One root reduces duplication but couples all names to the same files and behavior. |
| Routing | Named ServerName and ServerAlias values make supported hostnames auditable. |
Catch-all behavior can absorb typos and unknown names, making mistakes harder to notice. |
| Operations | Distribution-managed site files can be enabled, inspected, and reloaded independently. | Fewer files can be simpler for a tiny setup, but changes affect every alias together. |
| Security posture | Each domain can receive its own access policy and later its own TLS configuration. | Shared configuration makes a permissive rule or deployment error apply to every name. |
For a single additional name that must always serve identical content, a shared root is efficient. For domains with different owners, release schedules, logs, or permissions, separate roots and vhost files provide a cleaner boundary.
Complete the HTTPS configuration before production use
The example above handles HTTP on port 80 only. A production parked domain that users access over HTTPS needs a separate TLS virtual-host configuration on the HTTPS listener, together with certificates covering the names clients will request. Certificate procurement, renewal, and the choice of certificate service are operational decisions outside the HTTP setup described here.
Do not consider the domain finished merely because an HTTP request returns the right page. Test the HTTPS hostname independently after the TLS vhost and certificates are installed, and make sure every intended alias is covered. Keep the HTTP and HTTPS host mappings consistent so a request cannot switch to an unintended site during a redirect or secure connection.
A repeatable change and rollback checklist
- Write down the exact hostnames that should work and decide whether each uses shared or isolated content.
- Create or verify A and AAAA records that point those names to the correct server addresses.
- Create the document root, deploy a clearly identifiable test page, and apply the distribution’s ownership and permission policy.
- Save a vhost with an explicit
ServerName, all requiredServerAliasentries, the correctDocumentRoot, a matchingDirectoryblock, and named logs. - Enable the site using the distribution’s site-management command.
- Run
apachectl -Sand resolve any unexpected address, alias, duplicate, or ordering result. - Reload Apache only after the parsed configuration matches the intended design.
- Test DNS, the bare domain, each alias, and an unknown hostname; inspect the corresponding logs.
- If the change fails, disable the new site or restore the previous vhost file, reload Apache, and use the parsed map and logs to isolate the fault before trying again.
This process leaves a visible record of what the domain should resolve to, which Apache file owns it, and which fallback behavior applies when a hostname is not recognized.
Quick Recap
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.
