Recommended Free Tools
You can host multiple websites on one server—and usually on one IP address—by pointing each domain to the server, then configuring Apache or NGINX to route requests by hostname. In Apache, create a <VirtualHost> for each site; in NGINX, create a server block for each. Give every hostname a content root or application destination, choose what happens to unknown hostnames, and configure HTTPS certificates for the names you serve.
How multiple websites share one server
When a browser visits example.com, DNS resolves that hostname to an IP address. The browser connects to the server and includes the requested hostname in its HTTP request. Apache or NGINX uses that name, along with the destination address and port, to select the site configuration that should handle the request. Apache describes this as name-based virtual hosting and notes that multiple names can share an IP address: Apache name-based virtual host support.
The selected configuration can serve files from a site-specific directory or forward requests to an application. Separate hostnames do not require separate physical servers, but each site’s DNS and web-server configuration must agree.
What you need before configuring sites
- A server running Apache HTTP Server or NGINX, with permission to edit its configuration and reload the service.
- One or more domain names, plus control of the DNS records for each hostname you want to serve.
- Network and host firewalls that allow the web ports you intend to use. Public websites commonly use HTTP on port 80 and HTTPS on port 443.
- A content directory for each static site, or an application/upstream destination if the web server will proxy requests.
- A plan for HTTPS certificates and for requests that arrive with an unknown or missing hostname.
Plan the routing before you edit files
- Choose hostnames. Decide whether each site should answer at the bare domain, a
wwwname, or both. Record every name that should reach the same site. - Prepare separate roots or destinations. For example, use
/var/www/example.comand/var/www/example.netfor static content. Ensure the web-server process can read the files; application proxying requires the appropriate upstream configuration instead. - Point DNS to the server. Create the appropriate records for every public hostname. An
Arecord maps a name to an IPv4 address; anAAAArecord maps it to IPv6. Only publish an address the server can actually receive traffic on. - Add one named server configuration per site. Configure the listener and hostname names, then associate each with its own root or application target.
- Validate and reload. Use the syntax-check and service-reload workflow supported by your installed server and operating system. File locations, include conventions, service names, permissions, and commands vary by distribution; do not assume a particular enablement layout.
- Test hostname routing and the fallback. Visit each configured hostname and test an unconfigured name as well. Verify that neither a typo nor an unknown host silently exposes the wrong site’s content.
- Configure TLS. Obtain certificates covering each public hostname, attach them to the corresponding HTTPS configuration, and test both the intended site and certificate selection.
Configure multiple sites in Apache
Apache uses a <VirtualHost> block for each site. Specify an explicit ServerName and DocumentRoot; use ServerAlias for additional names that should serve the same site. Apache’s examples explain these directives and the relationship between DNS and virtual-host configuration: Apache virtual-host examples.
#1 Best Overall
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com
</VirtualHost>
<VirtualHost *:80>
ServerName example.net
DocumentRoot /var/www/example.net
</VirtualHost>This is an illustrative HTTP routing shape, not a complete deployment or tested configuration. Adapt paths, ports, permissions, logging, TLS directives, and configuration inclusion or enablement conventions to your distribution and site. The directories must contain the intended content and be readable by Apache.
Apache first narrows the candidates by destination IP address and port, then compares ServerName and ServerAlias among candidates for that address-and-port group. If no name matches, the first listed virtual host for the matching group is the fallback. Omitting ServerName can lead to unexpected matching, so define it explicitly for every named site. See Apache’s virtual-host matching details.
Check Apache’s parsed virtual hosts
Run apachectl -S in the environment where Apache is configured. It displays Apache’s parsed virtual-host mapping, including names and address/port groupings, and can expose an unexpected first/default host or a missing name. The executable name or invocation may differ in some installations; consult the package’s service documentation if that command is unavailable. See Apache virtual-host documentation.
Configure multiple sites in NGINX
NGINX defines virtual servers with server directives inside the http context. Each block normally specifies a listen port and one or more server_name values. A root points to files for a static site; an application deployment can instead use its appropriate proxy directives.
Rank #2
- Used Book in Good Condition
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html;
}
server {
listen 80;
server_name example.net;
root /var/www/example.net;
index index.html;
}This example shows the routing pattern only; it is not a complete deployment or tested configuration. Adapt roots, indexes, access rules, logging, upstream proxy directives, TLS settings, and distribution-specific file inclusion to the application. NGINX’s web-server documentation describes server blocks and name-based selection.
For a name that does not match a configured server, NGINX uses the default server for the destination port. That is the first configured server for the port unless a server is explicitly marked with default_server. Set this deliberately, especially if a request for an unknown hostname should not display one of your sites.
How NGINX matches names
NGINX checks exact names first, then wildcard names, then regular expressions; regular-expression names are considered sequentially. Prefer exact names where practical. If NGINX reports a server-name hash construction error during startup, its documentation describes server_names_hash_max_size and server_names_hash_bucket_size as tuning options. Change these only in response to a relevant configuration error, rather than adding them preemptively. Details are in the NGINX server names guide.
Apache and NGINX: the routing differences
| Decision | Apache HTTP Server | NGINX |
|---|---|---|
| Per-site configuration unit | <VirtualHost> block |
server block in the http context |
| Hostname directives | ServerName, optionally ServerAlias |
server_name |
| Listener | Address and port in the virtual-host declaration; the server must listen on that port | listen directive |
| Name matching | First select candidates by address and port, then compare configured names | Exact names, then wildcards, then regular expressions |
| Unknown-name fallback | First listed virtual host for the matching address/port group | First server for the port unless one declares default_server |
| Useful configuration check | apachectl -S displays the parsed virtual-host mapping |
Inspect the loaded configuration’s listen, server_name, and default-server settings |
These mechanisms support the same basic goal—routing several hostnames on one server. The documented behavior above does not establish that either server is categorically faster or easier for every deployment; choose based on the software and configuration you operate.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
DNS, public reachability, and HTTPS
A virtual host or server block does not create public DNS records. Configure DNS separately for every hostname, and check both IPv4 and IPv6 records if the server is meant to accept traffic over both. The server’s firewall and any upstream network firewall must allow the intended ports. A hostname that resolves to a different machine will not reach the configuration you just added.
HTTPS adds hostname selection during the TLS handshake. Apache and NGINX can use Server Name Indication (SNI) to choose the name-specific TLS configuration and certificate. Ensure each site’s certificate covers all hostnames configured for it, including aliases such as www.example.com; configuring an HTTP site name alone does not make its certificate valid. See Apache’s matching documentation and the NGINX server names guide.
Choose a certificate validation method
- HTTP-01: The certificate authority requests a challenge file over HTTP. Let’s Encrypt’s HTTP-01 validation can use only port 80, so that port and the challenge path must be reachable and routed correctly from outside. See Let’s Encrypt challenge types.
- DNS-01: Prove control by creating a TXT record under
_acme-challenge. This method supports wildcard certificates and does not require an inbound connection to the web server. If automating DNS updates, protect DNS API credentials carefully. - Certbot web-server methods: Certbot’s Apache, NGINX, and webroot instructions generally expect an existing HTTP site reachable on port 80; DNS validation avoids that inbound-connection requirement. Follow the instructions for the authenticator and environment you actually use: Certbot instructions.
Let’s Encrypt recommends that general-purpose web servers offer HTTP on port 80 and HTTPS on port 443; HTTP can redirect visitors to HTTPS, and port 80 supports HTTP-01 validation. This is the certificate authority’s operational recommendation, not a guarantee that every hosting environment permits those ports. See Let’s Encrypt’s port 80 guidance.
Troubleshoot a request reaching the wrong site
Both domains show the same site’s files
- Check that each DNS name resolves to the intended server address, including any published IPv6 address.
- Confirm that the requested hostname exactly matches a configured
ServerName/ServerAliasor NGINXserver_name. - Verify that both site blocks are included and loaded, and that each points to the intended root or upstream.
- Check the requested port and listener. A correct hostname block for port 80 will not route a connection arriving on a differently configured port.
An unknown hostname displays a real site’s content
Inspect the fallback for the matching address and port. Apache uses the first matching virtual host when no name matches; NGINX uses the port’s default server, which is the first configured one unless default_server is explicit. Configure a deliberate fallback so unmatched requests do not unintentionally reveal a site’s content.
Apache seems to ignore a hostname
Use apachectl -S and compare the parsed hostnames and address/port groups with the request. Look for a missing alias, an omitted or mistaken ServerName, or a virtual host that is not loaded.
HTTPS shows the wrong certificate
Check that the connection uses the expected hostname (SNI), that the corresponding TLS virtual host/server is configured, and that its certificate covers the name being requested. A certificate for the bare domain does not necessarily cover a separate www hostname.
Certificate validation fails
- For HTTP-01, verify external reachability on port 80 and that the challenge URL reaches the expected site rather than a fallback or another application.
- For DNS-01, verify the TXT record name and value under
_acme-challenge, then allow for DNS propagation before retrying. - Check that the validation method and Certbot instructions match the web server and environment in use.
NGINX does not start after adding many names
If the error specifically reports server-name hash construction, review exact names and wildcard patterns, then consider the documented hash-size directives. Do not treat hash tuning as a fix for unrelated configuration errors.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
If you are building a site inventory or need screenshots while checking deployments, ScreenshotNeo can return a screenshot with one GET request. It removes supported cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, timeouts, and failed loads are not billed, and cache hits cost nothing. Its MCP server provides screenshot and page-info tools for AI agents.
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 problemsExample using cURL; replace the target URL and API key. See the ScreenshotNeo API documentation for request details.
Best Value
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpThe Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Sign up for ScreenshotNeo free.
Frequently Asked Questions
Can two domains use the same IP address but show different sites?
Yes. Point both names to the server, then configure separate hostname-based virtual hosts or server blocks.
Do I need a separate IP address for every website?
Not for ordinary name-based hosting. Multiple hostnames can share an address; the server routes by the requested name.
How many websites can one server host?
There is no universal site-count limit established here. Practical capacity depends on the workloads, traffic, and resources available.
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.
