Unit

Apache Default Virtual Host

Learn how Apache selects a default virtual host, configures HTTP and HTTPS fallbacks, orders site files, and validates hostname routing safely.

An Apache virtual host is a configuration container that defines how Apache serves a site or service on a particular address and port. With name-based virtual hosting, several domains can share one server IP address because Apache uses the requested hostname to choose the correct configuration.

A default virtual host is the first loaded virtual host for an address-and-port combination. Apache uses it when no configured ServerName or ServerAlias matches the requested hostname. It is sometimes called the fallback virtual host.

Why a default virtual host matters

A client may connect using the server's IP address, an unrecognized domain, a misspelled hostname, or a hostname that is not configured on this server. Apache still needs to select a virtual host for the connection. The default virtual host handles that unmatched request.

Common designs include:

  • A neutral placeholder page stating that the requested site is unavailable.
  • A controlled redirect to a canonical domain.
  • An explicit error response or denial.
  • A catch-all security page that reveals as little as possible.

Do not make a production application the fallback unless that behavior is deliberate. Otherwise, a request for an unknown hostname may accidentally expose the content of a real hosted site.

How Apache chooses a virtual host

Apache first groups virtual hosts by the local connection address and port. A declaration such as <VirtualHost *:80> applies to HTTP connections received on port 80 on any local address. A declaration such as <VirtualHost *:443> applies to HTTPS connections on port 443. These are separate selection groups, so the default HTTP and default HTTPS virtual hosts can be different.

For ordinary HTTP/1.1 requests, the client sends a Host header, which identifies the requested hostname. Apache compares that hostname with the virtual hosts in the matching address-and-port group:

  • ServerName specifies the primary hostname for a virtual host.
  • ServerAlias specifies additional hostnames or supported patterns.
  • If a hostname matches, Apache selects that virtual host.
  • If no hostname matches, Apache selects the first loaded virtual host in that address-and-port group.

There is no special DefaultVirtualHost directive that chooses the fallback for name-based hosting. The effective configuration load order determines it. This makes deliberate file naming and verification important.

Selection sequence

Apache Virtual Host Selection Sequence

Connection address and port: Apache identifies the listener group, such as *:80 or *:443.

TLS/SNI for HTTPS: During the TLS handshake, Apache may use SNI to identify the intended hostname and choose a certificate before HTTP exists.

HTTP Host header: After the connection is established, Apache reads the requested hostname from the HTTP request.

ServerName and ServerAlias comparison: Apache compares the hostname with the declarations in the matching virtual-host group.

Fallback: If no hostname matches, Apache uses the first loaded virtual host for that address and port.

Defining the default HTTP virtual host

The following example creates a minimal fallback for port 80. The hostname default.invalid is intentionally non-public; replace it only if you have a reason to give the fallback a real hostname.

<VirtualHost *:80>
    ServerName default.invalid
    DocumentRoot /var/www/default

    <Directory /var/www/default>
        Require all granted
    </Directory>

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

DocumentRoot is the filesystem directory from which Apache serves content. The Directory block grants access to that directory using Apache 2.4 authorization syntax. The separate error and access logs make fallback traffic easy to identify.

Create only minimal content in this directory. For example, a short static response can explain that the hostname is not configured. Do not enable directory listing, place secrets there, or use a path that contains another site's application files.

Two named sites and a fallback

A safe arrangement puts the fallback first and then defines the real sites. The exact filenames depend on the operating system, but the effective order must be confirmed rather than assumed.

<VirtualHost *:80>
    ServerName default.invalid
    DocumentRoot /var/www/default
    <Directory /var/www/default>
        Require all granted
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/default-error.log
    CustomLog ${APACHE_LOG_DIR}/default-access.log combined
</VirtualHost>

<VirtualHost *:80>
    ServerName example.test
    ServerAlias www.example.test
    DocumentRoot /var/www/example
    <Directory /var/www/example>
        Require all granted
    </Directory>
</VirtualHost>

<VirtualHost *:80>
    ServerName shop.example.test
    DocumentRoot /var/www/shop
    <Directory /var/www/shop>
        Require all granted
    </Directory>
</VirtualHost>

A request with Host: example.test selects the second block. A request with Host: shop.example.test selects the third block. An unknown hostname or an IP-address request selects the first block.

Default HTTPS virtual host

HTTPS adds a TLS step before the HTTP request. The TLS handshake establishes encryption and selects a certificate before Apache receives the HTTP Host header. Therefore, certificate selection and HTTP virtual-host selection are related but distinct operations.

SNI, or Server Name Indication, lets a client send the intended hostname during the TLS handshake. Apache can then select the certificate for that hostname. A client that does not send SNI, or sends an unknown name, receives the certificate from the first suitable virtual host in the port 443 group.

The first HTTPS virtual host must therefore have a certificate appropriate for non-SNI clients and unknown hostnames. It should also be a controlled fallback, not a production application.

<VirtualHost *:443>
    ServerName default.invalid
    DocumentRoot /var/www/default

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/default.crt
    SSLCertificateKeyFile /etc/ssl/private/default.key

    <Directory /var/www/default>
        Require all granted
    </Directory>

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

The certificate and private-key paths must exist and have secure permissions. The TLS module, commonly mod_ssl, must also be enabled. Each real HTTPS site needs its own correctly configured certificate, usually selected through SNI.

HTTP and HTTPS differences

HTTP and HTTPS Default Virtual Host Differences

Hostname availability: HTTP has the Host header during the request; HTTPS can provide the hostname earlier through SNI.

Certificate selection: Port 80 has no certificate. Port 443 must select one during the TLS handshake.

Role of SNI: SNI is not used for ordinary HTTP; it is important for selecting HTTPS certificates.

Fallback behavior: Each port has its own first-loaded fallback virtual host.

Testing approach: Use a Host header for HTTP and curl --resolve for HTTPS so the hostname and local destination can both be controlled.

Configuration ordering and site enablement

Apache reads its main configuration and then processes files referenced by include directives. Virtual-host definitions may be in the main file, included directories, or distribution-specific site files. The order in which those files are read affects which virtual host becomes the default.

Debian and Ubuntu conventions

Debian-family systems commonly store site definitions in /etc/apache2/sites-available/. Enabled sites are represented in /etc/apache2/sites-enabled/, usually as symbolic links. Site tools commonly enable or disable those links, after which Apache is reloaded.

Give the fallback an intentionally early filename, such as 000-default-catchall.conf, if the local include arrangement uses lexical ordering. A name alone is not proof of precedence; verify the result with Apache's diagnostics.

apachectl configtest
systemctl reload apache2

RHEL-family conventions

RHEL-family systems commonly include configuration files ending in .conf from /etc/httpd/conf.d/. There is often no separate sites-available and sites-enabled structure by default. A fallback file with an early lexical name, such as 00-default-catchall.conf, can be used when the include order is lexical.

apachectl configtest
systemctl reload httpd

Other installations

Custom builds may use a different main configuration path and include layout. Inspect the active Apache configuration rather than copying a distribution assumption. The key rule is that all relevant virtual hosts must be included, and the intended fallback must be first within each address-and-port group.

Common Apache configuration locations

Common Apache Configuration Locations

Debian and Ubuntu: Available site location: /etc/apache2/sites-available/. Enabled site location: /etc/apache2/sites-enabled/. Typical workflow: create a site, enable it, run apachectl configtest, then reload apache2.

RHEL-family systems: Available site location: commonly /etc/httpd/conf.d/. Enabled or include location: files ending in .conf under that directory. Typical workflow: add or edit a configuration, run apachectl configtest, then reload httpd.

Custom Apache installations: Available site location and include location depend on the build. Typical workflow: inspect the main configuration and includes, validate the effective configuration, then gracefully reload the service.

Validate and test virtual-host selection

Check syntax before reloading

Always test the configuration before asking Apache to reload it:

apachectl configtest

A successful syntax test does not prove that the intended virtual host is first, that DNS is correct, or that the certificate is appropriate. It only confirms that Apache can parse the configuration and perform basic checks.

Inspect effective virtual hosts

apachectl -S

This diagnostic output lists virtual hosts, address-and-port groups, hostname mappings, and the default or first-loaded virtual host. Use it to verify the result of include order and site enablement.

Test HTTP without DNS

curl -i -H 'Host: unknown.example.test' http://127.0.0.1/

This connects to the local server while supplying an unknown HTTP hostname. Test known names as well by changing the Host value:

curl -i -H 'Host: example.test' http://127.0.0.1/

Test HTTPS with local address resolution

curl -i --resolve example.test:443:127.0.0.1 https://example.test/

--resolve makes curl connect to the specified address while retaining example.test as the TLS SNI name and HTTP hostname. This isolates Apache configuration from public DNS. To test an unknown HTTPS name, replace the hostname in both places. Certificate verification may fail for test certificates; do not hide certificate errors in production troubleshooting.

Use logs as evidence

Check the separate access and error logs configured for the fallback. A request appearing in the fallback log confirms that the fallback processed it. Logs can also reveal malformed requests, unexpected hostnames, redirects, permission failures, and traffic reaching the wrong listener.

Security and operational guidance

  • Serve a minimal static response, explicit denial, or controlled redirect for unknown hostnames.
  • Do not use a real application's DocumentRoot as the fallback.
  • Keep directory listing disabled unless it is explicitly required.
  • Grant directory access only to the intended content directory.
  • Verify ownership and permissions so Apache can read public files without exposing private files.
  • Use separate fallback access and error logs to detect unsolicited or misrouted traffic.
  • Configure a suitable certificate on the first port 443 virtual host.
  • After changes, run the syntax test, inspect apachectl -S, perform controlled curl tests, and then reload.

Troubleshooting

The wrong site appears for an IP address or unknown hostname

The unintended site may be the first loaded virtual host for that address and port. The fallback may also be loaded later, or the request may be reaching another listener, IP address, or port.

  1. Run apachectl -S.
  2. Inspect enabled-site filenames and included configuration order.
  3. Test with curl -i -H 'Host: unknown.example.test' http://127.0.0.1/.
  4. Check the access log belonging to the intended fallback.
  5. Move the intentional catch-all first in the relevant group, validate, and reload.

HTTPS presents the fallback certificate

The client may not send SNI, the SNI name may not match a configured HTTPS virtual host, or the intended virtual host may have an invalid TLS configuration. Test with a client that sends the intended hostname, inspect apachectl -S, and verify certificate, key, and TLS module settings. The first TLS virtual host must have a suitable fallback certificate.

Apache refuses to reload

Run apachectl configtest and read the reported error. Common causes include a syntax error, an invalid document or certificate path, a missing TLS module, incorrect directory authorization directives, or file-permission problems. Correct the reported issue, validate again, and only then reload.

A hostname selects the wrong virtual host

Compare the hostname sent by curl with every ServerName and ServerAlias. Also verify DNS, reverse-proxy behavior, site enablement, and the effective configuration. Use curl --resolve to separate DNS problems from Apache routing problems.

Exam-relevant notes

  • The default name-based virtual host is normally the first loaded virtual host in its address-and-port group.
  • *:80 and *:443 are different groups with independent defaults.
  • ServerName is the primary name; ServerAlias adds other matching names.
  • For HTTPS, certificate selection occurs during TLS before the HTTP Host header is processed.
  • SNI allows the client to provide the intended hostname during the TLS handshake.
  • Use apachectl configtest for syntax and apachectl -S to inspect effective virtual-host precedence.

For related Apache configuration concepts, see Apache2 Conf File, and for Linux file permissions see Modify File Permissions.