Skip to content

Virtual Hosting

Overview

Virtual hosting allows a single web server to serve multiple websites, each with its own domain name, from the same IP address and machine. This is possible because HTTP/1.1 includes a Host header that tells the server which site the client is requesting.

There are two types: name-based virtual hosting (multiple domains share one IP, distinguished by the Host header) and IP-based virtual hosting (each domain gets its own IP). Name-based hosting is far more common and efficient. Virtual hosts can have independent configurations, log files, document roots, and security settings.

How It Works

Name-Based Virtual Hosting

When a browser sends an HTTP request, it includes a Host header specifying which domain the client is requesting. The web server reads this header and selects the matching virtual host configuration.

This allows a single server with one IP address to serve multiple websites:

Client requests www.example.com  →  Server reads Host: www.example.com  →  Serves /var/www/www
Client requests blog.example.com →  Server reads Host: blog.example.com →  Serves /var/www/blog
Client requests mail.example.com →  Server reads Host: mail.example.com →  Serves /var/www/mail

Apache Virtual Host Configuration

Each virtual host is defined in a <VirtualHost> block, typically in a separate .conf file under /etc/httpd/conf.d/:

<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /var/www/html/www
    ErrorLog /var/log/httpd/www-error.log
    CustomLog /var/log/httpd/www-access.log combined
</VirtualHost>

<VirtualHost *:80>
    ServerName blog.example.com
    DocumentRoot /var/www/html/blog
    ErrorLog /var/log/httpd/blog-error.log
    CustomLog /var/log/httpd/blog-access.log combined
</VirtualHost>

Each virtual host can have its own:

  • DocumentRoot — the directory containing the website's files
  • Log files — separate error and access logs per site
  • Security settings — different authentication, TLS, or WAF rules
  • Proxy rules — different backends for reverse proxy configurations

DNS Requirements

Virtual hosting requires DNS records pointing all domain names to the server's IP address. Typically this means:

  • An A record for each hostname (e.g., www, blog, mail) pointing to the server IP
  • Or a CNAME record aliasing subdomains to the main hostname

Without DNS, clients cannot resolve the hostname, and the Host header won't match any virtual host.

IP-Based Virtual Hosting

The older approach assigns a separate IP address to each website. The server selects the virtual host based on which IP received the request. This is rarely used today because:

  • IPv4 addresses are scarce and expensive
  • Name-based hosting handles the same use case without extra IPs
  • TLS/SNI (Server Name Indication) eliminated the last reason for IP-based hosting

HTTPS Virtual Hosting

For HTTPS, virtual hosts listen on port 443 and include TLS directives:

<VirtualHost *:443>
    ServerName www.example.com
    DocumentRoot /var/www/html/www
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/www.crt
    SSLCertificateKeyFile /etc/pki/tls/private/www.key
    SSLCACertificateFile /etc/pki/tls/certs/cacert.crt
</VirtualHost>

With SNI (supported by all modern browsers), multiple HTTPS sites can share a single IP. A wildcard certificate (*.example.com) can secure all subdomains with a single certificate.

Key Terminology

VirtualHost
An Apache configuration block that defines how to serve a specific website based on the requested hostname and/or IP.
ServerName
The hostname that a virtual host responds to. Must match the Host header in the client's request.
DocumentRoot
The filesystem directory containing the website's files.
SNI (Server Name Indication)
A TLS extension that allows the client to specify the hostname during the TLS handshake, enabling multiple HTTPS sites on one IP.
Default Virtual Host
The first virtual host defined (or the one matching _default_) serves requests that don't match any ServerName. This is important for catching misconfigured or unexpected requests.

Why It Matters

As a system administrator, you will:

  • Host multiple websites on a single server to maximize resource efficiency
  • Configure separate log files per site for easier debugging and analysis
  • Apply different security policies per site (authentication, WAF rules, TLS settings)
  • Combine virtual hosting with reverse proxy to route traffic to different backend applications

Common Pitfalls

  1. Missing DNS records — the virtual host won't be reachable if the hostname doesn't resolve to the server's IP.
  2. Incorrect ServerName — typos or mismatches between DNS and ServerName cause requests to fall through to the default virtual host.
  3. Forgetting the Host header — testing with curl by IP address won't trigger the correct virtual host unless you add -H 'Host: www.example.com'.
  4. Not restarting Apache — configuration changes require systemctl restart httpd (or reload for graceful changes).
  5. Permission issues — Apache needs read access to the DocumentRoot directory. SELinux context must be httpd_sys_content_t.
  6. Port 443 without mod_ssl — HTTPS virtual hosts require the mod_ssl package to be installed.

Further Reading