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

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

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

Yes. Two domains can use one VPS and one public IP. Point each domain’s DNS records to that address, then configure separate NGINX server blocks or Apache name-based virtual hosts so the web server selects the correct site from the requested hostname. Finally, issue certificates for every hostname, redirect HTTP to HTTPS, reload the service, and test both domains independently.

How the arrangement works

A domain-to-VPS setup has two independent layers:

1. DNS translates a hostname such as domain-a.example into the VPS IPv4 or IPv6 address. DNS does not decide which files or application should answer.
2. The web server receives the request and examines its hostname. NGINX uses server_name; Apache uses ServerName and optional ServerAlias. The matching configuration selects a document root or an application upstream.

That separation explains why adding a DNS record alone can still show the wrong website: the request reaches the VPS, but no matching virtual host has been configured.

#	Preview	Product	Price
1		DNS & BIND Cookbook	$17.30	Buy on Amazon
2		Linux Dns Server Administration (Craig Hunt Linux Library)	$8.19	Buy on Amazon
3		WINDOWS SERVER 2022 ADMINISTRATION: A Practical Step-by-Step Guide to Active Directory, DNS, DHCP,...	$14.99	Buy on Amazon
4		DNS: Run Your Own Internal DNS with BIND 9 (The Frugal Admin)	$19.99	Buy on Amazon
5		ZPARIK 6 Pack Guest Checks Books, Server Note Pads, Pink	$6.99	Buy on Amazon

What you need before changing anything

• The VPS public IPv4 address.
• The VPS public IPv6 address, only if IPv6 is enabled, routed to the server, and allowed through the VPS firewall.
• Administrative access to the VPS.
• Access to the DNS zone for both domains.
• Either NGINX or Apache installed and serving HTTP.
• Separate directories, containers, or application processes for the two sites.
• Firewall rules that permit inbound TCP ports 80 and 443. Keep your administrative port protected separately.

Decide whether each hostname serves static files or proxies to an application. A static site normally uses a root or Apache DocumentRoot. An application site uses NGINX or Apache as a reverse proxy to a process listening on a local port or socket.

Step 1: Point both domains in DNS

At the DNS provider for each domain, create an apex A record containing the VPS IPv4 address. The apex is usually shown as @ in a DNS control panel. If the VPS has correctly configured IPv6, add an AAAA record containing its IPv6 address as well.

#1 Best Overall

Sale

DNS & BIND Cookbook

$17.30

Buy on Amazon

Do not add an AAAA record merely because the VPS provider displays an IPv6 address. If the operating system, route, or firewall is incomplete, some visitors will choose IPv6 and fail while IPv4 visitors work.

Verify the records from a terminal with commands such as:

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

Each returned address should be the intended VPS address. Check the www names separately. DNS changes can remain cached according to the zone’s TTL, so test from more than one network if a newly created record is not visible everywhere yet.

Step 2: Create separate site roots or application targets

Keep the content for each domain separate. A simple static layout is:

/var/www/domain-a
/var/www/domain-b

Place a distinct test page in each directory while configuring:

sudo mkdir -p /var/www/domain-a /var/www/domain-b
printf 'Domain An' | sudo tee /var/www/domain-a/index.html
printf 'Domain Bn' | sudo tee /var/www/domain-b/index.html

Use ownership and permissions appropriate for the service account and your deployment process. Do not make an entire filesystem tree writable by the web server just to get a test working.

For applications, substitute separate local listeners, for example port 3001 for domain A and port 3002 for domain B. The ports are internal implementation details; visitors still use standard HTTP and HTTPS ports.

Step 3: Configure NGINX server blocks

HTTP blocks for two static sites

Create one server block per site. Include the apex and every alias that should serve the same content in that block’s server_name list.

Rank #2

Linux Dns Server Administration (Craig Hunt Linux Library)

• Linux
• Linux DNS

$8.19

Buy on Amazon

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;
    }
}

NGINX compares the request hostname with server_name and chooses the matching block. The two blocks can listen on the same IP and port because the hostname, not a unique port, separates them.

NGINX blocks for proxied applications

Replace the static root and try_files directives with a proxy target when a local application serves the site:

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

    location / {
        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;
        proxy_pass http://127.0.0.1:3001;
    }
}

Give domain B its own block and point proxy_pass at its own process, such as http://127.0.0.1:3002. Confirm that each application is actually listening on the address and port used in the configuration.

Enable, validate and reload NGINX

On systems that use an enabled-sites directory, place or link the files into the directory loaded by NGINX. Then validate the complete configuration before reloading:

sudo nginx -t
sudo systemctl reload nginx

If validation reports an error, correct it before reloading. A failed reload leaves the previous working configuration in place, but it does not activate your new blocks.

Step 4: Configure Apache name-based virtual hosts

Apache implements the same shared-IP design with name-based virtual hosts. Each virtual host has its own ServerName, optional aliases, document root and logs.

HTTP virtual hosts for static sites

<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>

On distributions that provide an a2ensite helper, enable each site file with that tool; otherwise ensure the files are included by Apache’s active configuration. The exact file location varies by operating system.

Apache as a reverse proxy

For an application rather than static files, enable the proxy modules required by your Apache installation and use a separate target for each host:

Rank #3

WINDOWS SERVER 2022 ADMINISTRATION: A Practical Step-by-Step Guide to Active Directory, DNS, DHCP, File Server, and IIS with Screenshots

$14.99

Buy on Amazon

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

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3001/
    ProxyPassReverse / http://127.0.0.1:3001/

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

Create an equivalent virtual host for domain B with its own upstream. Keep application processes bound to local interfaces unless they deliberately need to be publicly reachable.

Validate and reload Apache

sudo apachectl configtest
sudo systemctl reload apache2

Some systems use the service name httpd instead of apache2. Use the name provided by your operating system. Apache’s virtual-host configuration does not create DNS records; DNS must still point both domains to the VPS.

Step 5: Add HTTPS for every hostname

HTTPS certificate selection also depends on the hostname. Obtain certificates that cover each name you will answer, including www if it remains enabled. Server Name Indication (SNI) allows multiple HTTPS sites to share one IP, provided the TLS configuration contains the correct certificate and private key for each name.

NGINX HTTPS layout

After your ACME client has issued certificates, create a 443 block for each site. Replace the certificate paths with the paths produced by your certificate client:

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

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

    root /var/www/domain-a;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

    root /var/www/domain-b;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

For proxied applications, keep the same 443 and certificate directives but use each application’s proxy_pass settings. Ensure the upstream receives the original host when the application uses host-based routing.

Apache HTTPS virtual hosts

Each Apache SSL virtual host needs its own names and certificate files. A typical structure is:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName domain-a.example
    ServerAlias www.domain-a.example
    DocumentRoot /var/www/domain-a

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain-a.example/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain-a.example/privkey.pem

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

Make a second SSL virtual host for domain B and use its certificate paths. Confirm that the SSL module is enabled and run apachectl configtest before reloading.

Step 6: Redirect HTTP to HTTPS

Once certificates work on port 443, make port 80 redirect each hostname rather than serving a second copy of the site.

Rank #4

DNS: Run Your Own Internal DNS with BIND 9 (The Frugal Admin)

$19.99

Buy on Amazon

NGINX redirect blocks

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;
}

Keep the 443 blocks separate so each hostname continues to receive its intended certificate and content. If you use a canonical hostname, such as redirecting www to the apex, create an explicit redirect and ensure the certificate covers the source hostname.

Apache redirect virtual hosts

<VirtualHost *:80>
    ServerName domain-a.example
    ServerAlias www.domain-a.example
    Redirect permanent / https://domain-a.example/
</VirtualHost>

<VirtualHost *:80>
    ServerName domain-b.example
    ServerAlias www.domain-b.example
    Redirect permanent / https://domain-b.example/
</VirtualHost>

Use a redirect that matches your chosen canonical host. If preserving arbitrary paths and query strings is important, verify the behavior of the redirect directive and your Apache version before applying it broadly.

Step 7: Test both names, protocols and certificates

Test each hostname independently. The response body should identify the intended site, and the certificate should contain the hostname requested.

curl -I http://domain-a.example
curl -I https://domain-a.example
curl -I http://domain-b.example
curl -I https://domain-b.example

Expected results after the redirect is enabled are an HTTP 301 response and a successful HTTPS response for each domain. Also test the www names if they are configured.

When DNS is still changing, you can test the origin directly while supplying the hostname:

curl -I --resolve domain-a.example:443:203.0.113.10 https://domain-a.example
curl -I --resolve domain-b.example:443:203.0.113.10 https://domain-b.example

Replace 203.0.113.10 with the VPS IPv4 address. This sends the request to the specified address while retaining the hostname used for virtual-host and SNI selection. It is useful for separating a DNS problem from a web-server problem.

NGINX server blocks versus Apache virtual hosts

Neither choice is inherently required for sharing one VPS. Use the server you already operate confidently, and apply the same discipline: one clearly named configuration per site, independent logs, explicit certificates and a syntax check before every reload.

Troubleshooting: when the wrong site appears

1. Confirm DNS before editing the web server

Run dig or nslookup for the apex and www names. If one hostname resolves to an old server, a proxy service or a different address, changes to the VPS configuration cannot affect that request.

Best Value

ZPARIK 6 Pack Guest Checks Books, Server Note Pads, Pink

• Standard size: 6 pink server note pads, Each Book Comes with 50 bound order slips - that's 300 ticket sheets total! Check Pads Size 6.75 x 3.5 inch.
• Convenient Work: These guest check books for servers have a tear-free dotted line that is easy to rip off. You can give as a customer copy or keep for record keeping. We've provided extra rows on the back for additional note taking.Perfect For Restaurants, Lounges, Hotels, Cafes, And Waiters To Use.
• Record Important Information: These server note pads can record important information.Each ticket has a unique serial number printed at the top, dates, order details, number of guests, order amount, table numbers etc. They are lightweight, small and can fit most aprons. They can be used on-demand and can help decrease errors in orders, while improving work efficiency.
• High Quality: Sturdy, Not Drop Powder, It's Thick, You Can Write On The Back And Front Easily.Their whole page printing has clear handwriting and a reasonable layout. On the customer retention part of each guest check, "THANK YOU" on the back to make customers feel appreciated.
• Contact Us: We're confident that the quality of the server note pads will go beyond your expectation. If you experience an issue, feel free to contact us, we'll appreciate it to learn from your experience, and we'll make it better

$6.99

Buy on Amazon

2. Check the exact hostname in the configuration

Make sure the requested name appears in NGINX server_name or Apache ServerName/ServerAlias. A typo, missing www alias or an unexpected trailing name can send traffic to the default host.

3. Verify that the file is enabled and loaded

Inspect the active NGINX or Apache configuration, not only an unused file in a sites-available directory. Run the syntax test, then reload the service. Review service status and error logs if the reload fails.

4. Inspect the default virtual host

If an unknown hostname reaches the VPS, the default server or first virtual host may answer. This is normal fallback behavior, but it can hide a missing hostname entry. Configure every intended alias explicitly and use a deliberate default response if you do not want unknown names to expose a site.

5. Check for a proxy or CDN

A reverse proxy or CDN can terminate TLS and cache content before the request reaches the VPS. Confirm which address the DNS record returns and test the origin directly with curl --resolve when appropriate.

Troubleshooting: HTTPS shows the wrong certificate

First verify that the requested hostname is included in a certificate. Then inspect the 443 configuration for that hostname, including the certificate and private-key paths. A correct HTTP block does not fix a mismatched HTTPS block.

SNI must be supported and correctly configured for multiple HTTPS names on one address. Test each name separately with a browser or TLS inspection tool, and check that the 443 block or SSL virtual host has not been omitted, disabled or shadowed by a default configuration.

Troubleshooting: one domain works over IPv4 but not IPv6

Compare the A and AAAA results. If AAAA returns an address that cannot route to the VPS, remove or correct that AAAA record until IPv6 is fully configured. On NGINX, include IPv6 listeners such as listen [::]:80; and listen [::]:443 ssl; only when the host is actually prepared to accept those connections. Apache also needs the operating system and firewall to accept IPv6 traffic.

Operational checklist

• Both apex A records point to the same VPS IPv4 address.
• AAAA records exist only for functioning IPv6 paths.
• Every www name has an intentional A, AAAA or CNAME record.
• Each domain has its own document root or application upstream.
• Every hostname is listed in the correct NGINX or Apache host definition.
• Port 80 and port 443 are allowed through the VPS firewall.
• Certificates cover every hostname that accepts HTTPS.
• HTTP redirects to the intended HTTPS canonical name.
• nginx -t or apachectl configtest succeeds before reload.
• HTTP, HTTPS, apex and www requests have all been tested.
• Access and error logs are separate enough to identify which site failed.
• Certificate renewal is automated and its renewal path has been tested.

Can you add more than two domains later?

Yes. The same pattern scales by adding another DNS record pointing to the VPS and another NGINX server block or Apache virtual host. Resource limits still matter: CPU, memory, storage, database capacity, worker processes and network bandwidth are shared by every site on the VPS. Hostname routing itself does not require a separate public IP for each domain.

Final answer

Point both domains at the VPS in DNS, define one hostname-specific web-server configuration per site, and issue certificates for all names you serve. NGINX uses separate server blocks; Apache uses separate name-based VirtualHost entries. Validate the configuration, reload the service, redirect HTTP to HTTPS, and test each hostname so DNS, routing and certificate selection are verified independently.

Quick Recap

SaleBestseller No. 1

DNS & BIND Cookbook

$17.30

Bestseller No. 2

Linux Dns Server Administration (Craig Hunt Linux Library)

Linux; Linux DNS

$8.19

Bestseller No. 3

WINDOWS SERVER 2022 ADMINISTRATION: A Practical Step-by-Step Guide to Active Directory, DNS, DHCP, File Server, and IIS with Screenshots

$14.99

Bestseller No. 4

DNS: Run Your Own Internal DNS with BIND 9 (The Frugal Admin)

$19.99

Bestseller No. 5

ZPARIK 6 Pack Guest Checks Books, Server Note Pads, Pink

$6.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.