How to Point a Domain to a VPS: A Step-by-Step DNS and Server Setup Guide

Overview

Here is the short version: to point a domain to a VPS, you need the server’s public IP address, access to your DNS provider, and a web server on the VPS that knows which domain it should answer for. In most cases, the DNS change itself is simple. The real work is making sure the server is ready before traffic arrives.

At a minimum, the process looks like this:

1. Confirm the VPS has a stable public IPv4 address, and IPv6 if you plan to use it.
2. Make sure your application or website is running on the server.
3. Configure your web server or reverse proxy to respond to the domain name.
4. Create or update the domain’s DNS records, usually an A record for the root domain and either an A record or CNAME for www or another subdomain.
5. Wait for DNS propagation, then test from the browser and command line.
6. Install SSL after the domain resolves correctly.

If you only remember one principle, make it this: prepare the VPS first, then change DNS. That order reduces stress and makes troubleshooting clearer.

It also helps to separate the moving parts:

• Registrar: where the domain is registered.
• DNS host: where the DNS zone is managed. This may be the registrar, Cloudflare, or another provider.
• VPS: the server that will receive web traffic.
• Web server or proxy: Nginx, Apache, Caddy, Traefik, or a hosting panel that maps domains to apps.

Those are often handled in different dashboards. A common source of delay is editing DNS at the registrar when the actual nameservers point somewhere else.

Checklist by scenario

This section is meant to be practical. Pick the scenario closest to your case and work through it top to bottom.

Scenario 1: New domain to a new VPS

Use this when the domain is not serving production traffic yet and you are connecting it to a fresh server.

1. Collect the essentials.
   • Domain name
   • VPS public IP
   • SSH access to the server
   • DNS provider login
2. Prepare the VPS.
   • Update the system packages.
   • Create a non-root user if you do not already have one.
   • Set up a firewall and allow ports 80 and 443.
   • Deploy the app or site files.
   • Configure your web server to listen for the domain and optionally www.
3. Create the DNS records.
   • Add an A record for @ pointing to the VPS IPv4 address.
   • Add an A record for www pointing to the same IP, or create a CNAME from www to the root domain.
   • If you use IPv6, add corresponding AAAA records.
4. Verify DNS resolution.
   • Use dig, nslookup, or an online DNS checker.
   • Make sure the records return the expected IP.
5. Test the site.
   • Open the domain in a browser.
   • Confirm the correct app responds.
   • Review server logs if the request fails.
6. Install SSL.
   • After DNS resolves, issue a certificate using your preferred method.
   • Set up HTTP to HTTPS redirects.

If you are building on Ubuntu, it helps to keep your deployment process documented. Related setup patterns are covered in How to Deploy a Node.js App on Ubuntu VPS With Nginx, PM2, and SSL and How to Deploy Docker Compose on a VPS: Production Checklist for Small Projects.

Scenario 2: Move an existing domain from one host to a new VPS

This is where order matters most. The objective is to avoid sending live traffic to an unprepared server.

1. Audit the current DNS zone before touching anything.
   • Export the zone if your provider allows it.
   • Take note of A, AAAA, CNAME, MX, TXT, SPF, DKIM, and DMARC records.
   • Do not assume only the website matters; email-related records must survive the change.
2. Lower TTL in advance if practical.
   • Do this before the migration window, not during it.
   • This can make later changes take effect faster, depending on existing cache behavior.
3. Prepare and test the new VPS first.
   • Restore files and databases.
   • Confirm the app works locally on the server.
   • Set the web server’s server_name or virtual host to the production domain.
4. Update only the web records.
   • Change the root A record to the new VPS IP.
   • Change the www record if needed.
   • Leave MX, SPF, DKIM, and DMARC untouched unless you are also migrating email.
5. Monitor both environments during propagation.
   • Some users may reach the old server while others reach the new one.
   • Avoid content changes during the cutover window unless you have a sync plan.
6. Retire the old server only after validation.
   • Check web traffic, SSL, cron jobs, and uploads.
   • Keep the old server available long enough to catch stragglers if the project allows it.

If email is tied to the same domain, review How to Set Up Email for a New Domain: Google Workspace, Microsoft 365, and Zoho Compared and SPF, DKIM, and DMARC Setup Guide for Small Business Domains before making DNS changes.

Scenario 3: Point a subdomain to a VPS

Subdomains are often simpler and safer than moving the root domain. This is common for staging sites, app frontends, APIs, dashboards, or self-hosted tools.

1. Decide what the subdomain should be.
   • Examples: app.example.com, api.example.com, status.example.com
2. Create the DNS record.
   • Add an A record for the subdomain pointing to the VPS IP.
   • Or use a CNAME if the subdomain should alias another hostname.
3. Configure the app or reverse proxy.
   • Make sure the VPS routes the subdomain to the correct service.
   • In multi-app setups, verify you are not sending the subdomain to the default site by mistake.
4. Issue SSL for the subdomain.
5. Test application-specific behavior.
   • Callbacks, cookies, CORS, webhook targets, and environment variables often depend on the final hostname.

This pattern is common when hosting tools like Nextcloud, n8n, or Plausible on their own subdomains. For deeper deployment checklists, see How to Host a Nextcloud Server, How to Self-Host n8n, and How to Host Plausible Analytics Yourself.

Scenario 4: Use Cloudflare or another DNS proxy layer

When a DNS provider offers proxying or CDN features, be clear on whether you want plain DNS resolution or proxied traffic.

1. Add the A or AAAA record as usual.
2. Decide whether proxying should be enabled.
   • For first-pass troubleshooting, plain DNS-only mode is often simpler.
   • Once the origin responds correctly, you can enable proxy features if they suit your setup.
3. Check origin firewall rules.
   • If you later restrict origin access, be careful not to block legitimate traffic from your chosen front layer.
4. Review SSL mode and redirect behavior.
   • Mismatch between proxy SSL settings and origin certificates can create redirect loops or certificate warnings.

If you want a broader DNS explanation, keep DNS Propagation Explained: How Long Changes Take and How to Check Status handy during rollout.

What to double-check

These are the items that cause the most second-guessing during a domain-to-server change. A two-minute review here can save a long debugging session.

1. Are you editing the right DNS provider?

Check the domain’s nameservers. If the nameservers point to a third-party DNS host, edits made at the registrar may have no effect.

2. Does the root domain use an A record, not a CNAME, where required?

Many DNS setups use an A record for the apex domain and either an A record or CNAME for www. Some providers offer flattening or alias features at the root, but if you are unsure, the safe default for a VPS is an A record to the server’s IP.

3. Is the server listening for your exact hostname?

On Nginx or Apache, a domain can resolve correctly and still show the wrong site if the server block or virtual host configuration is incomplete. Confirm the domain and any aliases are explicitly included.

4. Are ports 80 and 443 open?

If DNS looks correct but the browser times out, the issue may be the server firewall, cloud firewall, or service binding rather than DNS.

5. Is SSL being issued after DNS resolves?

Many certificate tools validate over the public internet. If the domain does not yet point to the VPS, certificate issuance may fail or validate the wrong host.

6. Did you preserve email records?

This is one of the biggest mistakes during a web migration. Changing the website A record does not require replacing MX or TXT records. Audit the full zone before editing anything.

7. Are IPv6 records accurate?

If you publish an AAAA record, the server should actually be reachable over IPv6. A broken IPv6 path can create intermittent issues for some users. If you are not ready to support it, do not publish it yet.

8. Did you test from outside your local machine?

Browser cache, local DNS cache, and hosts file overrides can mislead you. Use command-line lookups and an external network to verify what the public sees.

9. Is the app itself healthy?

Sometimes DNS works and the server answers, but the application is down, returning 502/503 errors, or pointing to an old database. Pair DNS checks with basic VPS monitoring. A good companion resource is VPS Monitoring Checklist: What to Track for Uptime, CPU, Memory, Disk, and SSL.

10. Is the VPS sized appropriately?

A domain can point perfectly to a server that is too small for the workload. If you are launching a new app, review capacity before traffic arrives. See Ubuntu Server Sizing Guide for Web Apps for a planning framework.

Common mistakes

Most domain-to-VPS problems are not exotic. They are usually one of a handful of repeatable mistakes.

• Changing nameservers when you only meant to change a record.
  Nameserver changes move the entire DNS zone to another provider. If all you need is to connect a domain to a server, editing the A record is usually enough.
• Overwriting the whole DNS zone during a migration.
  This can break mail, verification records, and third-party services. Export or document the zone first.
• Pointing DNS before the server is ready.
  This is the fastest route to visible downtime. Prepare the app, web server, firewall, and SSL workflow first.
• Assuming propagation is instant everywhere.
  Some resolvers update quickly; others may take longer due to caching. Plan for overlap during host changes.
• Forgetting the www version.
  If the root domain works but www does not, or vice versa, it is often just a missing record or redirect.
• Confusing DNS with application routing.
  If multiple apps share one VPS, the domain may reach the server correctly but land on the wrong container or vhost.
• Leaving old hardcoded URLs in the app.
  CMS settings, environment variables, callback URLs, and asset links may still reference the old host.
• Skipping rollback planning.
  For production sites, know how to revert the record or direct traffic back if the new server fails validation.

A simple rule helps here: if the symptom is “domain does not resolve,” start with DNS. If the symptom is “domain resolves but site is wrong or broken,” start with the web server, reverse proxy, or app.

When to revisit

This setup is worth revisiting any time the underlying inputs change. Keep a short checklist in your runbook and review it before these moments:

• Before a server migration: confirm zone records, TTL strategy, rollback plan, and server readiness.
• Before a launch: verify the production hostname, SSL, redirects, and external monitoring.
• When changing DNS providers: ensure all records are copied, not just web records.
• When adding a new subdomain: check whether it needs its own app routing, SSL, and firewall rules.
• When enabling a proxy or CDN layer: test origin access, SSL mode, and redirect logic.
• When email is added to the domain: review MX and TXT records so website changes do not disrupt mail flow.
• When the VPS IP changes: update all relevant A and AAAA records and recheck any firewall or allowlist rules.

For a practical final pass, use this quick launch checklist:

1. Confirm the VPS public IP.
2. Confirm the app works on the server.
3. Confirm Nginx, Apache, or your proxy is configured for the domain.
4. Open ports 80 and 443.
5. Create or update the A record for the root domain.
6. Create or update the www record if needed.
7. Leave email records untouched unless you are intentionally changing mail services.
8. Verify propagation with external tools and command-line lookups.
9. Install SSL and force HTTPS only after resolution works.
10. Monitor uptime, logs, and certificates for the first day after the change.

If you treat domain pointing as a checklist rather than a one-off task, it becomes much easier to repeat during launches, rebuilds, and provider changes. The DNS record is only one line item. The reliable outcome comes from validating the registrar, DNS host, server, app routing, and post-change monitoring together.