VMware ESXi and vSphere Cluster Management

Apache sites-enabled Directory: Enabling and Disabling Virtual Hosts

Learn how Apache uses sites-available and sites-enabled on Debian and Ubuntu, including a2ensite, a2dissite, configuration testing, reloads, and virtual-host verification.

On Debian- and Ubuntu-based systems, Apache HTTP Server commonly separates stored virtual-host configurations from the configurations it currently loads. The two important directories are /etc/apache2/sites-available and /etc/apache2/sites-enabled.

This layout lets you keep configuration files on the server without necessarily making Apache load them. A site becomes active after its configuration is enabled and Apache successfully reloads or restarts.

What is /etc/apache2/sites-enabled?

/etc/apache2/sites-enabled is an Apache configuration inclusion directory used by Debian-family Apache packages. It contains the site configurations that Apache should load.

A site configuration normally defines one or more virtual hosts. A virtual host is an Apache configuration block that specifies how requests for a hostname, IP address, or port should be handled. It can define settings such as:

• The hostname handled by the site with ServerName or ServerAlias.
• The website's document root.
• Access and directory rules.
• Access and error log locations.
• TLS settings for HTTPS sites.

In a standard Debian or Ubuntu installation, the main Apache configuration includes matching files from the enabled-sites directory. When Apache loads its configuration, it reads the enabled virtual-host definitions.

sites-available versus sites-enabled

A symbolic link is a filesystem reference that points to another file. For example, a link named newWebsite.conf in sites-enabled can point to the source file with the same name in sites-available.

This separation is useful because an administrator can preserve a configuration while preventing Apache from loading it. Disabling a site normally removes its enabled link; it does not delete the source configuration from sites-available.

How Apache loads enabled sites

1. A site configuration is stored in /etc/apache2/sites-available.
2. The configuration is enabled, normally with a2ensite.
3. The helper creates or manages a symbolic link in /etc/apache2/sites-enabled.
4. Apache checks and reads the enabled configuration during a reload or restart.
5. If the configuration is valid, the new virtual host can handle matching requests.

External accessibility requires more than an enabled Apache file. DNS must point the hostname to the correct server, the network and firewall must allow the relevant port, the document root must exist and be readable, and any application or proxy setup must work correctly.

Example virtual-host configuration

The following is a minimal name-based virtual host for HTTP. Name-based virtual hosting means that Apache selects a site using the HTTP Host header, allowing multiple hostnames to share an IP address and port.

<VirtualHost *:80>
    ServerName example.test
    DocumentRoot /var/www/example

    ErrorLog ${APACHE_LOG_DIR}/example-error.log
    CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

Save a configuration like this as /etc/apache2/sites-available/newWebsite.conf. The file is only a stored configuration until it is enabled.

Enable a site with a2ensite

a2ensite is the Debian-family helper utility for enabling an Apache site configuration. Pass it the configuration filename from sites-available:

sudo a2ensite newWebsite.conf

The command creates or manages the corresponding symbolic link in /etc/apache2/sites-enabled. It does not replace the need to validate and reload Apache.

sudo apache2ctl configtest
sudo systemctl reload apache2

A safe workflow is:

1. Create or edit the file in sites-available.
2. Run sudo a2ensite newWebsite.conf.
3. Run sudo apache2ctl configtest.
4. Reload Apache only after the syntax test succeeds.
5. Verify the hostname, response, document root, and logs.

Disable a site with a2dissite

a2dissite disables an enabled site. It normally removes the symbolic link from sites-enabled while preserving the original configuration file in sites-available.

sudo a2dissite newWebsite.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

After disabling, confirm both results:

• The link for newWebsite.conf is no longer in sites-enabled.
• The original newWebsite.conf file remains in sites-available.

Site management commands

Inspecting symbolic links

Use a long directory listing to inspect enabled sites:

ls -l /etc/apache2/sites-enabled/

A typical symbolic-link listing has an arrow showing the target:

newWebsite.conf -> ../sites-available/newWebsite.conf

The exact display can vary, but the important detail is that the enabled entry points back to the source file. Edit the source file in sites-available; do not treat the link as an independent copy.

The helper utilities are the preferred administration method. The underlying concept can also be represented manually with a symbolic-link command:

sudo ln -s /etc/apache2/sites-available/newWebsite.conf /etc/apache2/sites-enabled/newWebsite.conf

Manual linking requires more care, so use a2ensite and a2dissite for normal site management.

Configuration lifecycle

Activating a site

1. Create or edit the virtual-host file in sites-available.
2. Enable it with a2ensite.
3. Inspect sites-enabled to confirm the link exists.
4. Run sudo apache2ctl configtest.
5. Reload Apache.
6. Test the intended hostname and inspect apache2ctl -S.

Deactivating a site

1. Run a2dissite for the site.
2. Confirm its link is absent from sites-enabled.
3. Confirm the source remains in sites-available if it should be retained.
4. Run a configuration syntax test.
5. Reload Apache.
6. Verify that the hostname is no longer served by that virtual host.

If you edit a source file that is already enabled, the linked configuration changes as well because the link points to that source. Apache will use the edited content only after a successful reload or restart.

Reload versus restart

A configuration reload tells Apache to reread its configuration while keeping the service running. It is generally the appropriate operation after a validated virtual-host change.

A restart stops and starts the service. It may be needed in situations that require a full service restart, but it causes a more noticeable interruption. Always run a syntax test before either operation:

sudo apache2ctl configtest
sudo systemctl reload apache2

Default virtual hosts and ordering

A default virtual host handles a request when Apache cannot find a more specific name match for the relevant address and port. This matters especially with name-based virtual hosting.

For a given address and port, Apache considers the configured virtual hosts and their ordering. The first applicable virtual host commonly becomes the default for requests that do not match another configured hostname. Therefore, an unexpected site may appear when:

• The intended configuration is not enabled.
• The request's Host header does not match ServerName or ServerAlias.
• A distribution-provided default site remains enabled.
• The enabled configuration order differs from the expected order.

Do not assume that the site you intended to be the default is actually first or selected. Inspect Apache's parsed view:

sudo apache2ctl -S

When replacing the package default site, enable the custom virtual host first, check the mappings, and disable the distribution default only if unmatched requests should no longer reach it. Test both the intended hostname and an unmatched hostname or direct address request.

Common virtual-host states

Troubleshooting

The file exists, but Apache does not serve the site

• Inspect /etc/apache2/sites-enabled and confirm the expected link exists.
• Run sudo apache2ctl -S to see whether Apache parsed the virtual host.
• Check that the requested hostname matches ServerName or ServerAlias.
• Verify DNS resolution and the hostname actually sent by the browser or client.
• Run sudo apache2ctl configtest and reload Apache after a successful test.

Apache fails to reload

A failed reload commonly indicates a syntax error, an invalid directive, a missing module, a malformed path, or a port or virtual-host conflict.

1. Run sudo apache2ctl configtest.
2. Read the reported file and line number.
3. Review service status and Apache error logs.
4. Correct the configuration before attempting another reload.

The default Apache page appears

• Confirm that the intended site is enabled.
• Run sudo apache2ctl -S and inspect the default and named mappings.
• Check whether the distribution default site is still enabled.
• Verify that the request hostname matches the configured name.
• Check DNS and test with the correct HTTP Host header.

Disabling a site did not change the response

• Confirm that the link was removed from sites-enabled.
• Reload Apache after a successful syntax test.
• Check whether another enabled virtual host matches the same hostname.
• Use apache2ctl -S to inspect the active mappings.
• Consider browser or proxy caching, DNS caching, or a load balancer serving the response.
• Test with an explicit Host header and inspect the response source.

Safe administration checklist

• Keep source configurations in sites-available.
• Use a2ensite and a2dissite rather than deleting configuration files to change activation state.
• Inspect symbolic links with ls -l.
• Run apache2ctl configtest before applying changes.
• Prefer a reload after a valid configuration change.
• Use apache2ctl -S to verify Apache's actual virtual-host mapping.
• Check DNS, firewall rules, ports, document-root permissions, and application behavior separately from Apache site activation.
• Confirm the replacement behavior before disabling a default or only active virtual host.

For the directory itself, see Apache sites-enabled Directory.