How to Point Two Domains to One VPS (NGINX and Apache Setup)

Yes. Point each domain’s DNS to the VPS public IP, then configure the VPS web server to distinguish the hostnames. DNS gets both names to the machine; separate NGINX server blocks or Apache name-based virtual hosts decide which site or application answers. Finally, issue certificates for every hostname, redirect HTTP to HTTPS, reload the service, and test both domains.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

What happens when two domains share one VPS

A browser sends a request containing a hostname such as domain-a.example. DNS resolves that hostname to an IP address, so both domains can resolve to the same VPS. The web server then reads the hostname in the request and selects the matching configuration.

#	Preview	Product	Price
1		Managing Mission - Critical Domains and DNS: Demystifying nameservers, DNS, and domain names	$50.99	Buy on Amazon
2		Networking Is a Contact Sport: How Staying Connected and Serving Others Will Help You Grow Your...	$9.03	Buy on Amazon
3		AWS Certified Advanced Networking Official Study Guide: Specialty Exam	$6.67	Buy on Amazon
4		DNS Security: Defending the Domain Name System	$49.95	Buy on Amazon
5		Mastering Entra ID Domain Services: A Comprehensive Guide to Modern Identity Management	$14.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

These are separate jobs. DNS does not create websites or virtual hosts. Apache’s documentation explicitly notes that creating virtual-host configurations does not create DNS entries for those hostnames. Conversely, a DNS record pointing at your server does not create a document root, application process, certificate, or routing rule.

• DNS: maps each hostname to the VPS address.
• Web server: maps each hostname to a directory or application upstream.
• TLS: presents a certificate that covers the hostname requested by the browser.
• Application: serves the files or process assigned to that hostname.

NGINX calls its per-site configurations server blocks. Apache calls them name-based virtual hosts. Both let multiple websites share one public IPv4 address and, when configured, one IPv6 address.

#1 Best Overall

Managing Mission - Critical Domains and DNS: Demystifying nameservers, DNS, and domain names

$50.99

Buy on Amazon

Plan the two-site layout before editing anything

Write down the exact hostnames that should work. A common plan is an apex name and its www alias for each site:

The paths and ports above are examples, not requirements. Use a separate directory or upstream for each site. Do not point both configurations at one directory unless sharing the same content is intentional.

Collect the addresses and access details

• Record the VPS public IPv4 address.
• Record the VPS IPv6 address only if IPv6 is enabled on the VPS, allowed by its firewall, and configured by the operating system.
• Confirm that you can administer the VPS and reload NGINX or Apache.
• Identify which service owns ports 80 and 443. Only the intended web server should bind those ports.
• Decide whether each site is static, served directly by the web server, or proxied to a separate application process.

If a CDN or reverse proxy sits in front of the VPS, its DNS and certificate settings become an additional layer. The origin configuration still needs to recognize the hostnames, but tests from the public internet may show the proxy rather than the VPS directly.

Point both domains at the VPS in DNS

Create the apex records

At the DNS provider for each domain, create an A record for the apex name. Set the value to the VPS public IPv4 address. The host field may be displayed as @, an empty value, or the full domain, depending on the provider.

If IPv6 is genuinely configured end to end, add an AAAA record for each apex name with the VPS IPv6 address. Do not add an AAAA record merely because the VPS provider advertises IPv6: a broken IPv6 route or firewall rule can make some visitors fail while IPv4 users continue to work.

Add the www names

For each domain, choose one of these patterns according to the DNS provider’s rules:

Rank #2

Sale

Networking Is a Contact Sport: How Staying Connected and Serving Others Will Help You Grow Your Business, Expand Your Influence-or Even Land Your Next Job

• Used Book in Good Condition

$9.03

Buy on Amazon

• Create www A and, when appropriate, AAAA records pointing to the same addresses as the apex.
• Create a www CNAME pointing to the apex name. Follow the provider’s restrictions, since a CNAME normally cannot coexist with other records at the same name.

Repeat the process independently for Site B. DNS records do not need to use different IP addresses; both domains can legitimately contain the same VPS address.

Allow for DNS propagation and verify resolution

Resolvers cache records according to their TTL, so an old address can remain visible for a while after a change. Check each hostname with a DNS lookup tool or commands such as:

dig +short A domain-a.example
dig +short AAAA domain-a.example
dig +short A www.domain-a.example
dig +short A domain-b.example

Do the equivalent checks for Site B’s www name. The result should contain the intended VPS address. If one resolver still returns the former host, wait for its cache to expire rather than changing the web-server configuration to compensate.

Prepare separate content or application targets

Static files

Create the two document roots, deploy the appropriate files, and ensure the web-server account can read them:

sudo mkdir -p /var/www/domain-a
sudo mkdir -p /var/www/domain-b
sudo chown -R www-data:www-data /var/www/domain-a /var/www/domain-b

The account name can differ by distribution or service. Preserve the permissions model already used on your VPS; the important property is that Site A’s root and Site B’s root are distinct and readable.

Proxied applications

Run each application on its own local listener, for example 127.0.0.1:3001 and 127.0.0.1:3002. Bind application ports to loopback unless external access is required. The web server remains the public entry point and forwards requests based on the hostname.

Rank #3

AWS Certified Advanced Networking Official Study Guide: Specialty Exam

$6.67

Buy on Amazon

Configure two domains with NGINX

NGINX selects a server block by matching the request hostname against server_name. One block can list an apex name and its www alias; separate blocks keep the two sites independent.

Option A: serve separate static roots

Create one HTTP server block per site. The following example uses the two planned roots:

server {
    listen 80;
    listen [::]:80;
    server_name domain-a.example www.domain-a.example;

    root /var/www/domain-a;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name domain-b.example www.domain-b.example;

    root /var/www/domain-b;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

If IPv6 is not enabled, omit the bracketed IPv6 listener rather than leaving a listener that cannot bind. Save each site in the layout used by your distribution, enable the files if your package uses an enabled-sites directory, and test the complete configuration:

sudo nginx -t
sudo systemctl reload nginx

Option B: proxy each hostname to a different application

Replace the static root and try_files directives with a separate upstream destination:

server {
    listen 80;
    listen [::]:80;
    server_name domain-a.example www.domain-a.example;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name domain-b.example www.domain-b.example;

    location / {
        proxy_pass http://127.0.0.1:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The application ports are illustrative. Confirm that each process is listening before blaming NGINX for a gateway error.

Configure two domains with Apache

Apache’s name-based virtual hosting uses a separate virtual-host definition for each site. Give every vhost its own ServerName, optional aliases, document root or proxy target, and logs.

Rank #4

DNS Security: Defending the Domain Name System

$49.95

Buy on Amazon

Separate static document roots

<VirtualHost *:80>
    ServerName domain-a.example
    ServerAlias www.domain-a.example
    DocumentRoot /var/www/domain-a

    ErrorLog ${APACHE_LOG_DIR}/domain-a-error.log
    CustomLog ${APACHE_LOG_DIR}/domain-a-access.log combined

    <Directory /var/www/domain-a>
        Require all granted
        AllowOverride None
    </Directory>
</VirtualHost>

<VirtualHost *:80>
    ServerName domain-b.example
    ServerAlias www.domain-b.example
    DocumentRoot /var/www/domain-b

    ErrorLog ${APACHE_LOG_DIR}/domain-b-error.log
    CustomLog ${APACHE_LOG_DIR}/domain-b-access.log combined

    <Directory /var/www/domain-b>
        Require all granted
        AllowOverride None
    </Directory>
</VirtualHost>

Enable the site definitions using the mechanism provided by your Apache installation, then validate and reload:

sudo apachectl configtest
sudo systemctl reload apache2

The service name can be httpd on some systems. Use the service name actually installed on your VPS.

Proxy applications through Apache

When Apache is the public reverse proxy, assign each vhost a different backend port and configure the proxy modules required by your distribution. Keep the same separation principle: Site A forwards only to its application, and Site B forwards only to its application. Test module availability and syntax before reloading; a missing proxy module or malformed directive prevents the configuration from loading.

Add HTTPS certificates for every hostname

HTTPS is not automatically covered because both domains share an IP. A certificate must include every hostname that will answer securely, such as domain-a.example and www.domain-a.example. Obtain certificates from your chosen certificate authority and install the corresponding private keys securely on the VPS.

Server Name Indication (SNI) lets NGINX or Apache select the certificate and HTTPS virtual host using the requested hostname, so multiple HTTPS sites can share one IP. The certificate configuration still has to match the names in DNS and in the server configuration.

NGINX HTTPS blocks

A typical NGINX HTTPS block for a static site is:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name domain-a.example www.domain-a.example;

    root /var/www/domain-a;
    index index.html;

    ssl_certificate /etc/letsencrypt/live/domain-a.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain-a.example/privkey.pem;

    location / {
        try_files $uri $uri/ =404;
    }
}

Create a corresponding 443 block for Site B with its own names, root or upstream, and certificate paths. If one certificate contains both sites’ names, it can technically be referenced by both blocks, but separate certificates make ownership, renewal, and replacement easier to reason about.

Best Value

Mastering Entra ID Domain Services: A Comprehensive Guide to Modern Identity Management

$14.99

Buy on Amazon

Apache HTTPS virtual hosts

Apache uses the same name-based pattern on port 443. Each HTTPS vhost needs its ServerName, aliases, document root or proxy settings, and certificate directives appropriate to the Apache version and certificate authority. Keep the certificate and private-key files associated with the names declared in that vhost.

After installing certificates, run the relevant configuration test and reload. Check renewal automation separately; a certificate that works today but cannot renew will eventually cause an outage.

Redirect HTTP to HTTPS after HTTPS works

Do not enable a blanket redirect before the 443 blocks and certificates are functioning. First confirm that each HTTPS hostname serves the intended site. Then make the port-80 block for each site redirect to its own HTTPS hostname.

server {
    listen 80;
    listen [::]:80;
    server_name domain-a.example www.domain-a.example;
    return 301 https://$host$request_uri;
}

server {
    listen 80;
    listen [::]:80;
    server_name domain-b.example www.domain-b.example;
    return 301 https://$host$request_uri;
}

The equivalent Apache approach is a port-80 vhost that redirects while the 443 vhost serves content. Keep the redirect scoped to the intended names; an accidental default-host redirect can make an unrelated hostname appear to belong to one of the sites.

Validate both domains from the outside

Run the checks after DNS has reached the VPS and after every configuration reload:

1. Check DNS for the apex and www names. Confirm A records, and AAAA records only where IPv6 is deliberately enabled.
2. Request HTTP headers for Site A and Site B: curl -I http://domain-a.example and curl -I http://domain-b.example.
3. Request HTTPS headers: curl -I https://domain-a.example and curl -I https://domain-b.example.
4. Follow redirects when needed with curl -IL and confirm the final URL, status, and hostname.
5. Open each hostname in a browser and verify distinctive content, not merely a successful status code.
6. Inspect the presented certificate and confirm its subject or SAN entries include the exact hostname in the address bar.
7. Review the per-site access logs while making a request. A request for Site A should not appear only in Site B’s log.

For a temporary origin test when public DNS still points elsewhere, send the hostname explicitly to the VPS address with a tool that supports host resolution, or test after DNS propagation. Avoid interpreting a cached CDN response as proof that the origin configuration is correct.

Troubleshoot the wrong site, certificate, or response

The domain resolves to the wrong server

• Query the authoritative DNS provider and several recursive resolvers.
• Look for an old A or AAAA record at the apex, www, or another subdomain.
• Remove stale records only when you are certain they are no longer needed.
• Remember that cached DNS follows the record’s TTL; changing the VPS configuration cannot override a resolver returning the old address.

The correct IP shows the wrong website

• Check the exact hostname in NGINX server_name or Apache ServerName/ServerAlias.
• Confirm the intended configuration file is enabled and the service was reloaded after editing.
• Check for duplicate names in another server block or vhost.
• Inspect the default server or default vhost. An unmatched hostname is commonly served by that configuration.
• Verify that a proxy or CDN is not sending a different Host header or serving cached content.

HTTPS presents the wrong certificate

• Confirm the request reaches port 443 and that the 443 block or vhost declares the hostname.
• Check certificate coverage for both the apex and www name; a certificate for one does not automatically cover the other.
• Look for an earlier default 443 server that catches unmatched names.
• Validate the certificate and key paths, then run nginx -t or apachectl configtest before reloading.
• If a CDN terminates TLS, inspect its edge certificate as well as the origin certificate.

One site returns a gateway or connection error

• For a proxied site, verify that the application is running and listening on the configured local port.
• Check firewall rules for ports 80 and 443 and, where used, the local application ports.
• Read the web-server error log and the application log together; the first upstream error usually identifies the failing layer.
• Confirm that IPv6 listeners and firewall rules are consistent with the AAAA records. A partially configured IPv6 path can fail only for clients that prefer IPv6.

NGINX server blocks versus Apache virtual hosts

Neither choice changes the DNS requirement. Select the server you already operate confidently, or the one required by your application stack. The reliable pattern is the same: one explicit hostname mapping and one explicit content or upstream target per site.

Operational checklist for future changes

• Lower DNS TTL ahead of a planned migration if you need a shorter cache window, then restore a sensible TTL afterward.
• Make configuration changes one site at a time and retain the previous working file until validation succeeds.
• Run the syntax test before every reload. A failed test should stop the deployment rather than trigger a reload.
• Keep separate access and error logs so a hostname can be traced without filtering a combined stream.
• Back up private keys securely and limit their permissions.
• Monitor certificate expiration and renewal results, not only the current certificate date.
• Document whether www is an alias, a redirect, or an independently served hostname.
• When adding a third domain later, repeat the same DNS, content, server-block or vhost, certificate, redirect, and test sequence.

What success looks like

Both domains resolve to the VPS addresses you selected. Requests for Site A consistently reach its root or application, while Site B reaches its own target. Each HTTPS hostname presents a certificate containing that name, HTTP redirects to HTTPS, and the web server’s logs show the requests under the expected site. Once those conditions hold, the two domains are sharing infrastructure without sharing their routing, files, certificates, or application processes.

Quick Recap

Bestseller No. 1

Managing Mission - Critical Domains and DNS: Demystifying nameservers, DNS, and domain names

$50.99

SaleBestseller No. 2

Networking Is a Contact Sport: How Staying Connected and Serving Others Will Help You Grow Your Business, Expand Your Influence-or Even Land Your Next Job

Used Book in Good Condition

$9.03

Bestseller No. 3

AWS Certified Advanced Networking Official Study Guide: Specialty Exam

$6.67

Bestseller No. 4

DNS Security: Defending the Domain Name System

$49.95

Bestseller No. 5

Mastering Entra ID Domain Services: A Comprehensive Guide to Modern Identity Management

$14.99

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.