TopicLadder
Troubleshooting

Site Not Loading After a DNS Change

Use this repair path when a new domain, VPS, Nginx route, or HTTPS setup does not load after DNS was changed.

Use the VPS project path Open command checklist

Symptom table

Start with the visible symptom, then run the smallest command that can separate DNS, HTTP, HTTPS, Nginx, and file-path problems.

Symptom Likely cause Command Next fix
Domain still shows a parked page DNS points at the registrar or an old host. dig +short example.com A Compare the returned IP to the VPS IP before editing anything else.
www works but the root domain does not One hostname has a record and the other does not. dig +short www.example.com A && dig +short example.com A Add or correct the missing host only after you know which one fails.
HTTP works but HTTPS fails Certificate, TLS, redirect, or port 443 configuration is not ready. curl -I https://example.com Check certificate coverage and Nginx TLS config before reissuing certificates.
The Nginx default page appears The request is reaching Nginx but not the intended server block or root. grep -RInE 'server_name|root|listen' /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null Find the matching server block and verify its root path.
Browser shows 403 forbidden The server found the path but cannot read or serve it. namei -l /srv/www/example.com/current/index.html Inspect parent-directory execute bits and file owner before changing permissions.
Browser shows 404 after deploy The route, root folder, symlink, or generated file path does not match. find /srv/www/example.com/current -maxdepth 2 -type f | sort | head -50 Prove the file exists in the live release before changing Nginx.
Reload says failed Nginx config has a syntax or include error. sudo nginx -t Fix the reported file and line before running reload again.
Certificate renewal or issue failed DNS, HTTP challenge route, firewall, or certificate name does not line up. sudo certbot certificates Confirm the existing certificate names and domains before requesting another one.

Read the layers in order

DNS answers the question: which machine should receive this request? If the A record still points somewhere else, browser testing and Nginx edits will not prove much.

HTTP answers the question: can the domain reach a web server on port 80? If HTTP fails, certificate troubleshooting is usually premature.

HTTPS answers the question: does the certificate and TLS route match the hostname? A site can be reachable over HTTP while HTTPS still fails.

Nginx routing answers the question: did the right server block choose the right release folder? This is where default pages, wrong roots, and stale symlinks usually show up.

Common false reads

  • A browser cache can show an old redirect or old certificate warning after the server was fixed.
  • A registrar dashboard can say a record was saved before your current resolver returns the new answer.
  • A valid certificate can still be the wrong certificate for the hostname you typed.
  • An Nginx reload can succeed while the server block still points at an old release folder.
  • A 403 can mean path permissions, missing index file, or an Nginx rule; do not jump straight to broad permission changes.

Commands to use first

dig +short example.com A

Proves which IP the domain currently resolves to.

curl -I http://example.com

Checks plain HTTP reachability and redirects.

curl -I https://example.com

Checks HTTPS response and certificate-related failures.

sudo nginx -t

Validates Nginx config before reload.

systemctl status nginx --no-pager

Shows whether Nginx is running and recent unit messages.

grep -RInE 'server_name|root|listen' /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null

Finds likely server-block routing mistakes.

certbot certificates

Lists certificate names, covered domains, and expiry dates.

namei -l /srv/www/example.com/current/index.html

Walks path permissions when Nginx reaches the file but cannot serve it.

Decision path

  1. If dig +short example.com A does not show the intended VPS IP, stay in DNS. Check the exact hostname, record type, and provider dashboard.
  2. If DNS is correct but curl -I http://example.com cannot connect, check firewall, Nginx status, and whether the server listens on port 80.
  3. If HTTP works but HTTPS fails, inspect certificate coverage with certbot certificates and test the TLS route before requesting another certificate.
  4. If the default page appears, inspect server_name, listen, and root directives. The request is reaching Nginx, but not the intended site.
  5. If a 404 appears, prove the generated file exists in the current release folder before changing routing.
  6. If a 403 appears, use namei -l and stat to inspect path permissions before editing ownership or modes.

Safety notes

  • Do not keep changing DNS records until you have recorded the current answer.
  • Do not reload Nginx until sudo nginx -t passes.
  • Do not request certificates repeatedly before DNS and HTTP reachability are proven.
  • Do not use broad permission changes to fix 403 errors; inspect the path first.

Project note format

Record the domain, expected IP, actual DNS answer, HTTP status, HTTPS status, config test result, current release path, and next action. That gives you a useful handoff if the issue takes more than one session.

A good note also records where the command was run. DNS checks can run from your laptop, but Nginx config checks must run on the server. Mixing those contexts is one of the fastest ways to chase the wrong problem.

When to stop changing things

Stop editing if two different checks disagree and you cannot explain why. For example, if DNS appears correct locally but outside checks still show the old IP, write down both results and wait or test from another resolver before changing records again.

Stop reloading services if sudo nginx -t reports a config error. Fix the reported file and line first. Stop requesting certificates if the domain still points at the wrong machine or port 80 is unreachable.

Escalate carefully when the domain is used for email, production work, paid customers, or other people’s projects. DNS changes can affect more than the website.

Related pages and downloads

Buy me a coffee for more maker ladders

TopicLadder is free to read. Support helps turn rough project paths into useful notes, cards, videos, and practice tasks.

Support this project

Last reviewed: July 5, 2026. TopicLadder pages are curated for practical learning and may be updated as examples improve.