DNS Propagation and VPS Website Issues: How to Troubleshoot

You've moved your site to a new VPS and updated the A record at your registrar, yet your browser keeps loading the old version. Or a colleague already sees the new site while you get a connection error. Situations like these almost always come down to DNS caching, commonly called "DNS propagation." Sometimes waiting really is the fix, but just as often the cause is on the server itself: a closed port, a web server misconfiguration, or a forgotten AAAA record.

In this article, we'll explain why DNS changes don't show up instantly, what actually determines how long "propagation" takes, and how to pinpoint the problem step by step: DNS, a local cache, or the VPS. You can run every command in this guide on your workstation and on any Linux server, such as a VPS in the Serverspace cloud.

Key Terms

• DNS (Domain Name System) is the system that maps domain names to IP addresses and other data.
• Authoritative DNS server is a server that hosts a domain's zone and gives the "official" answers about its records. These servers are listed in the domain's NS records.
• Recursive resolver is a server that finds the answer for a client by walking the DNS hierarchy and then caches the result. Examples include your ISP's resolvers, public services (Google Public DNS 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9), and the caching DNS on your home router.
• TTL (Time To Live) is the number of seconds a resolver may serve a record from cache without asking the authoritative server again.
• Delegation is the entry in the parent zone (.com, .net, .org) that says which NS servers are responsible for a domain. You manage it at your registrar.
• A and AAAA records hold a name's IPv4 and IPv6 address. A CNAME is an alias that points to another name.
• SOA is the zone's start-of-authority record: the zone serial number, server synchronization settings, and the negative caching time.
• Negative caching means a resolver caches the answer "this name or record doesn't exist."

How DNS "Propagation" Works

The term is misleading: when you change a record, nothing gets pushed anywhere. The new value appears on the authoritative servers right away, but thousands of resolvers keep serving their cached copy until its TTL expires. "Propagation" is really caches gradually expiring, not changes being delivered.

The Path of a DNS Query

1. The browser checks its own cache and then asks the operating system. The OS checks the hosts file and its own cache.
2. If there's no answer, the query goes to a recursive resolver: your ISP's, your router's, or a public one.
3. If the resolver doesn't have a cached answer, it asks the root servers for the TLD servers (.com, .org), asks those for the domain's NS servers, and then requests the record from the authoritative server.
4. The answer is cached at every level: in the resolver, in the OS, and in the browser.

This leads to the core troubleshooting principle: different users have different chains of caches, so one person sees the new IP address while another still gets the old one. Don't ask "does it work for me?" Ask what each link in the chain returns.

Why Changes Aren't Visible Right Away

Three mechanisms cause the delay.

• The TTL of the changed record. If your A record had a TTL of 86,400 seconds (one day), a resolver that looked it up a minute before your change will keep returning the old address for almost a full day. What matters is the old TTL: the resolver only learns the new value after its cached copy expires.
• The delegation TTL. Changing NS servers updates the parent zone, and NS records there are cached too. In the .com zone, their TTL is 172,800 seconds, or two days. On top of that, the registry needs time to publish the updated zone.
• Negative caching. If someone looked up www.example.com before you created that record, the resolver remembers the "no such record" answer. It keeps that answer for the smaller of two values: the TTL of the SOA record and the SOA's last field.

Resolvers aren't the only caches. Browsers, operating systems, routers, and some applications store answers themselves and sometimes hold them longer than the TTL allows.

How Long to Wait: Rough Estimates

Common Problem Scenarios

Moving a Site to a New VPS

This is the most common case. The same NS servers keep hosting the domain, and only the A record changes. Users whose cache still holds the old address land on the previous server. If it's already shut down, they get a connection error. If the site is still running there, you get a different problem: orders, comments, and sign-ups go into the old database.

Switching DNS Hosting

When you move your zone to another DNS provider and change the NS records at your registrar, some resolvers keep querying the old NS servers for a while. If the zone on the new host is incomplete, say you forgot the MX, TXT, or www records, your site and email start working only intermittently.

A New Domain or Subdomain

A new subdomain won't resolve if someone checked it before you created the record: the resolver cached the negative answer. With a new domain, a common cause is that it isn't active in DNS yet. In .com WHOIS output, a clientHold or serverHold status means the domain is not published in DNS at all.

An SSL Certificate Won't Issue

For the HTTP-01 challenge, Let's Encrypt connects to your domain at the address in DNS. If DNS still points to the old server or the domain has a wrong AAAA record, validation fails even though the site on the new VPS is ready.

DNS Is Correct, but the Site Won't Load

Sometimes DNS updated long ago, yet the site is still unreachable. In that case, the cause is on the server: the web server isn't running, a firewall blocks the port, or the nginx configuration doesn't include the right name. That's why troubleshooting starts with one key question: is it DNS or the server?

Step-by-Step Troubleshooting

You'll need the dig and whois utilities. On Ubuntu and Debian, install them like this:

sudo apt update
sudo apt install -y dnsutils whois

On AlmaLinux, Rocky Linux, and other RHEL-compatible distributions, dig is part of the bind-utils package:

sudo dnf install -y bind-utils whois

On Windows, you can use nslookup or the PowerShell cmdlet Resolve-DnsName instead of dig.

In all examples, the site's domain is example.com, the new VPS address is 203.0.113.10, and the old server's address is 198.51.100.20. Replace them with your own values.

Step 1. Test the New Server, Bypassing DNS

First, let's make sure the VPS itself serves the site. To do that, we'll request it at an explicitly specified IP address. The --resolve option makes curl connect to the given address while keeping the correct Host header and, for HTTPS, the correct SNI name:

curl -I --resolve example.com:80:203.0.113.10 http://example.com/
curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Sample response from a working server:

HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
Content-Type: text/html

A 200, 301, or 302 status means the server is responding. If the new server doesn't have a certificate yet, curl will report a certificate error on the HTTPS request. To check reachability only, you can temporarily add the -k option, which skips certificate verification.

If curl returns Connection refused or hangs until it times out, the problem is on the VPS, and waiting for DNS won't help — skip to step 6. If the server responds correctly, the problem lies in DNS.

Testing in a Browser with the hosts File

To view the site on the new server in a browser, add a line to the hosts file: /etc/hosts on Linux and macOS or C:\Windows\System32\drivers\etc\hosts on Windows (run your editor as administrator):

203.0.113.10 example.com www.example.com

This line overrides DNS only on your computer. Be sure to remove it after testing; otherwise, you'll be looking at your own override instead of the real picture during further troubleshooting.

Step 2. Check the Domain's Delegation

Let's confirm that the correct NS servers are set at the registrar. Start with WHOIS:

whois example.com | grep -iE "name server|domain status"

The Name Server lines list the domain's NS servers, and Domain Status shows its state. Statuses such as clientTransferProhibited are normal. However, clientHold or serverHold means the domain has been removed from DNS, and no amount of waiting will fix it. Registrars often apply clientHold when a domain expires or when the registrant's email address hasn't been verified, so check your registrar account and inbox.

WHOIS shows the registrar's data, not what resolvers see. So next, we'll query the TLD servers directly. Get their list and send a non-recursive query to one of them:

dig NS com. +short
dig NS example.com @a.gtld-servers.net +norecurse

For a domain in another zone, such as .org, the first command becomes dig NS org. +short, and you send the second query to one of the servers from its output. In the response, look at the AUTHORITY SECTION: it lists the NS servers the domain is delegated to and the delegation TTL.

;; AUTHORITY SECTION:
example.com. 172800 IN NS ns1.dns-provider.example.
example.com. 172800 IN NS ns2.dns-provider.example.

If you still see the old NS servers here, the registrar or registry hasn't applied the change yet. Double-check your registrar settings and wait for the zone to be published.

A trace shows the entire chain from the root to the authoritative server:

dig +trace example.com A

dig walks from the root servers to the TLD servers and then to the domain's NS servers on its own, without using a resolver cache. The last block of output is the authoritative server's answer:

example.com. 300 IN A 203.0.113.10
;; Received 56 bytes from 192.0.2.53#53(ns1.dns-provider.example) in 18 ms

If the trace shows the new IP address, your DNS is configured correctly, and all that's left is for caches to expire. Steps 4 and 5 describe how to speed that up.

Step 3. Compare Answers from All Authoritative Servers

A domain usually has two or more NS servers, and they must all return the same data. If you run the zone on your own BIND servers and a secondary didn't receive the update, the NS servers answer differently and the site loads only some of the time. Compare the SOA serial numbers across all servers:

dig +nssearch example.com

SOA ns1.dns-provider.example. hostmaster.example.com. 2026092701 3600 900 1209600 300 from server 192.0.2.53 in 15 ms.
SOA ns1.dns-provider.example. hostmaster.example.com. 2026092701 3600 900 1209600 300 from server 192.0.2.54 in 21 ms.

The serial numbers must match. Next, query the record directly from each NS server:

dig example.com A @ns1.dns-provider.example +norecurse +short
dig example.com A @ns2.dns-provider.example +norecurse +short

If one server returns the old address, the zone isn't synchronized. When you edit a BIND zone by hand, remember to increment the SOA serial; otherwise, secondary servers won't pull the changes. If your zone is hosted by a DNS provider, contact their support.

The last number in the SOA output (300 in the example) is used to calculate the negative caching time. That's roughly how long resolvers will remember that a record doesn't exist if it was queried before being created.

Step 4. Compare Answers from Recursive Resolvers

Now let's see what users see. Query the record from several public resolvers and from your default resolver:

for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
echo "$r: $(dig +short example.com A @$r)"
done
dig +short example.com A

Sample output when not every cache has updated yet (the last line is your default resolver's answer):

8.8.8.8: 203.0.113.10
1.1.1.1: 203.0.113.10
9.9.9.9: 198.51.100.20
198.51.100.20

To find out how much longer to wait, look at the TTL in the resolver's answer. It shows how many seconds the record has left in that resolver's cache:

dig example.com A @9.9.9.9 +noall +answer

example.com. 5412 IN A 198.51.100.20

In this example, the resolver will keep returning the old address for about an hour and a half (5,412 seconds). Repeat the query in a few minutes: the TTL should be counting down. Large public resolvers run on many servers, each with its own cache, so repeated queries may return different answers.

Google Public DNS and Cloudflare let you flush the cache for a specific name through a web form on their sites. That won't speed things up at ISPs, but it helps everyone who uses those resolvers. To check from different countries and networks, use an online DNS propagation checker: these tools query dozens of resolvers worldwide and show a summary.

On Windows, run the equivalent checks with nslookup example.com 8.8.8.8 or, in PowerShell, Resolve-DnsName example.com -Server 1.1.1.1.

Step 5. Clear Local Caches

If public resolvers already return the new address but you still get the old site, the cache on your device is to blame. First, check the hosts file for a leftover line with your domain from earlier tests. Then clear the operating system's cache.

Linux with systemd-resolved

sudo resolvectl flush-caches

This command clears the cache of the local systemd-resolved resolver. Older systemd versions use systemd-resolve --flush-caches instead.

Windows

ipconfig /flushdns

macOS

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Browser

Chrome keeps its own DNS cache: open chrome://net-internals/#dns and click Clear host cache. In Firefox, go to about:networking#dns and click Clear DNS Cache. Keep in mind that with Secure DNS (DNS over HTTPS) turned on, the browser queries the resolver selected in its settings instead of the system resolver, so its answer may differ from what dig shows.

Your home router has its own cache too. If, after all these steps, your computer still gets the old address while your phone on cellular data gets the new one, restart the router or temporarily set a public DNS server on your computer.

Step 6. Check the Web Server on the VPS

If the server didn't respond in step 1, connect to the VPS over SSH and work through the checks below.

Is the Web Server Running, and Which Ports Is It Listening On?

sudo systemctl status nginx
sudo ss -tlnp | grep -E ':(80|443) '

The output should include lines for ports 80 and 443:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=7))

If those lines are missing, the web server isn't running or isn't configured for these ports. Check the configuration syntax and restart the service:

sudo nginx -t
sudo systemctl restart nginx

nginx -t only validates the configuration and doesn't affect the running server; the restart applies it. Look for the cause of any errors in the log:

sudo tail -n 50 /var/log/nginx/error.log

For Apache, the commands are similar: sudo apachectl configtest and sudo systemctl status apache2 (on RHEL-compatible systems, the service is called httpd).

Is a Firewall Blocking the Ports?

On Ubuntu, check the ufw status:

sudo ufw status

If ufw is active and there are no rules for ports 80 and 443, open them. The Nginx Full profile allows incoming HTTP and HTTPS connections:

sudo ufw allow 'Nginx Full'

AlmaLinux and Rocky Linux use firewalld. The commands below add permanent rules for HTTP and HTTPS and apply them:

sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

If you've set up a network firewall in your cloud control panel, check its rules as well: ports 80 and 443 must be allowed there too.

Does the Site Name Match the Configuration?

If you see the nginx welcome page or another site hosted on the same server, nginx didn't find a server block with the right name and served the default site instead. Let's see which names the configuration contains:

sudo nginx -T 2>/dev/null | grep server_name

The site's server block should list both names, with and without www:

server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html;
}

After editing, validate the configuration and apply it without dropping active connections:

sudo nginx -t && sudo systemctl reload nginx

Step 7. Check IPv6 and the AAAA Record

A common hidden cause is a leftover AAAA record that points to the old server or to an address that isn't configured on the new VPS. Clients with IPv6 prefer it, so the site works for some users and fails for others.

dig +short example.com AAAA
curl -4 -I http://example.com/
curl -6 -I http://example.com/

The curl -6 command only works if the computer you're testing from has IPv6. If curl -4 responds but curl -6 doesn't, check whether the VPS has a global IPv6 address and whether the web server listens on IPv6 (the listen [::]:80; directive):

ip -6 addr show scope global

If you don't use IPv6 on the server, delete the AAAA record from the zone. If you do, update it with the new VPS's current address.

Step 8. Rule Out DNSSEC Errors

If your domain is signed with DNSSEC and you switched DNS providers, an old DS record may still be set at your registrar. Validating resolvers then reject answers from the new NS servers and return SERVFAIL, even though the authoritative servers answer correctly. Compare the responses with and without signature validation:

dig example.com A @8.8.8.8
dig example.com A @8.8.8.8 +cd

The +cd flag tells the resolver not to validate signatures. If the response header shows SERVFAIL without it but NOERROR and the correct address with it, the problem is DNSSEC:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41792

Check the DS record in the parent zone:

dig DS example.com +short

If a DS record exists but your new DNS provider doesn't sign the zone, remove the DS record at your registrar. If it does sign the zone, replace the DS record with the value your new provider gives you. DS changes also reach resolvers with a delay, so when switching providers, it's safer to disable DNSSEC in advance and re-enable it after the move.

Step 9. Issue the SSL Certificate After DNS Updates

Request a Let's Encrypt certificate on the new server only after DNS points to it. Confirm that the HTTP-01 challenge directory is reachable from outside. A 404 from the new server is fine here — what matters is that the new server is the one answering:

curl -I http://example.com/.well-known/acme-challenge/test

Then do a test run. It uses the Let's Encrypt staging server, doesn't count against production rate limits, and doesn't save a certificate:

sudo certbot certonly --nginx --dry-run -d example.com -d www.example.com

If the test run succeeds, get the certificate. The nginx plugin adds it to the site's configuration automatically:

sudo certbot --nginx -d example.com -d www.example.com

If validation fails, read the error message carefully: it usually includes the IP address the certificate authority connected to. The old address means DNS hasn't updated yet, and a timeout on the correct address means port 80 is closed. Also check your CAA records: if you have any, they must authorize letsencrypt.org.

dig +short example.com CAA

0 issue "letsencrypt.org"

How to Move to a New VPS Without Downtime

You can prevent most of these problems by planning the DNS change ahead of time. Here's the sequence:

1. Lower the TTL in advance. At least one old-TTL period before the move (one day if the TTL was 86,400 seconds), reduce the TTL of your A and AAAA records to 300 seconds. By the time you switch, every cache will have the short value.
2. Prepare the new server. Deploy the site on the new VPS and test it with curl --resolve or the hosts file, as in step 1. To have HTTPS during testing, copy the current certificate from the old server, then issue a new one after the DNS switch.
3. Sync your data. Before switching, stop writes on the old site (for example, enable maintenance mode) or set up database replication so new orders and comments aren't lost.
4. Update the A and AAAA records to the new server's addresses and verify the result with the commands from steps 2–4.
5. Don't shut down the old server right away. Keep it running for at least a couple of days. To send users with stale caches to the current site, set up the old server to proxy requests to the new one:
   location / {
proxy_pass https://203.0.113.10;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_ssl_server_name on;
proxy_ssl_name $host;
}
   The proxy_ssl_server_name and proxy_ssl_name directives pass the correct SNI name to the new server so it picks the right certificate, and the X-Forwarded-For header preserves the visitor's real IP address.
6. Restore the normal TTL. Once requests to the old server stop (you'll see this in its access log), shut it down and raise the TTL back, for example to 3,600 seconds.

It helps to create the new server ahead of time and run it alongside the old one for a while: that way, the DNS switch becomes the last and safest step of the move.

Cheat Sheet: Symptom, Cause, Check

Conclusion

"DNS propagation" is caches expiring, and how long it takes depends on TTLs: the old record's TTL when you change an address, the delegation TTL when you change NS servers, and the SOA values when you add new names. That's why you lower the TTL before a migration and keep the old server running for a while after the switch.

If your site won't load after a move, don't just wait. First test the new server directly with curl --resolve, then work through the chain from the registrar and authoritative servers to public resolvers and your local cache. Within minutes, this shows where the problem is: in DNS, on your computer, or on the VPS itself. You can rehearse the migration and troubleshooting on a test VPS in the Serverspace cloud before switching your production domain.