Point a domain at your VPS and debug DNS

A website can be running correctly on a VPS while its domain still sends visitors somewhere else. This guide separates the naming problem from the application problem, so you can change one thing at a time and explain the result.

You need a domain you control, its DNS dashboard, a VPS address, and a working local application. Start with the VPS production learning path if those pieces are new. All addresses below are documentation examples: replace them with your own, not somebody else's server.

Draw the route before changing records

For this exercise the intended route is:

app.example.com
└── DNS address answer
    └── VPS TCP port 443
        └── Nginx virtual host
            └── 127.0.0.1:3000 application

DNS does not choose an application's port, issue its certificate or configure Nginx. A correct address with a wrong virtual host can still display the wrong website.

In your DNS provider's dashboard, record the current values before editing. Confirm that you are editing the provider actually named by the domain's delegation, rather than an unused dashboard at the registrar.

Choose the records deliberately

For a simple subdomain, the choices are:

Do not publish the sample addresses. Add an AAAA record only after the server, firewall and reverse proxy work over IPv6. A stale AAAA record can affect some visitors while your IPv4 test succeeds.

A CNAME is an alias, not an HTTP redirect: it does not change the address bar or redirect a path. It normally cannot coexist with other record data at the same name. Apex flattening offered by some providers is a provider feature, not a reason to assume an ordinary apex CNAME works. The distinction between names, aliases and caching is described in the DNS concepts specification.

Read the answer your machine receives

Run these on your laptop or an Ubuntu test machine. Ubuntu's dnsutils package supplies dig; check your existing installation first.

dig -v
dig app.example.com A +noall +answer
dig app.example.com AAAA +noall +answer
dig app.example.com CNAME +noall +answer
dig example.com NS +noall +answer

The answer includes the name, remaining TTL, class, type and value. An empty answer is not a complete diagnosis. Run dig app.example.com A without output filters and read the status: NXDOMAIN means the queried name does not exist in that answer; SERVFAIL is a resolution failure and can involve delegation or DNSSEC, not simply a missing A record.

Keep the full output privately with the time and resolver used. The BIND dig manual explains selecting record types and query servers.

Compare the authority with a resolver

Use the authoritative nameserver returned for your domain, not the placeholder below.

dig @ns1.example.net app.example.com A +noall +answer
dig app.example.com A +noall +answer

If the authority returns the new address while your usual resolver returns the old one, caching is a plausible explanation. Lowering TTL immediately before a change cannot shorten a previously cached answer's original lifetime. Plan a lower TTL ahead of a migration, then restore your normal value after stability is confirmed.

If the authority itself returns the old address, waiting is unlikely to fix editing the wrong zone. If answers vary between authoritative servers, check the provider's zone synchronisation. Preserve MX, TXT and verification records when making website changes; replacing an entire zone to fix one address can break email.

Test HTTPS without waiting for DNS

On your laptop, this makes one request to your own chosen address while retaining the hostname for HTTP and TLS:

curl --resolve app.example.com:443:192.0.2.10 \
  --connect-timeout 5 --max-time 15 \
  --fail --show-error --silent \
  https://app.example.com/health

Your server must already have a valid certificate for that hostname. Do not add --insecure to make a failed certificate check appear successful. A TLS error is useful evidence. A connection failure suggests a different layer; a 404 can mean the selected virtual host or path is wrong. Curl's address override documentation describes this hostname-preserving test.

Verify both address families and recover

Once DNS resolves correctly, test normally from outside the VPS:

curl -4 --connect-timeout 5 --max-time 15 --fail --show-error https://app.example.com/health
curl -6 --connect-timeout 5 --max-time 15 --fail --show-error https://app.example.com/health

The IPv6 test also requires an IPv6-capable client connection. Failure there alone does not identify whether the client, route or server is responsible. Compare with another authorised network and your server's listener inventory.

For rollback, restore the recorded old DNS values only if the old service is still safe and ready. Expect mixed traffic during caching; never allow two independent databases to accept conflicting writes accidentally. Check certificate monitoring and Nginx routing after a successful cutover.

The commands are reviewed examples, not evidence that your domain has been changed or your provider tested. Completion means the expected hostname, certificate, response and application data all agree.