You bought a domain, you have a VPS, and the browser still says "site can't be reached." The missing piece is almost always two DNS records and a web server that actually answers on the right address. Here's the whole path, from registrar to a working HTTPS padlock.
Before you start: does your plan accept web traffic?
Visitors connect to ports 80 and 443 on your server. That requires a plan with its own public IP. NAT plans forward only your personal SSH port, so they can't host a site on a domain — our dedicated IP vs NAT article explains the difference. A small site runs fine on Nano-IP.
1. Find your server's addresses
Your IPv4 and IPv6 addresses are on the server page in the dashboard. We'll use documentation addresses in the examples:
- IPv4:
203.0.113.10 - IPv6:
2001:db8::10
2. Create the DNS records
Log in wherever your domain's DNS lives (usually the registrar) and add:
| Type | Name | Value | TTL |
|---|---|---|---|
| A | @ | 203.0.113.10 | 300 |
| AAAA | @ | 2001:db8::10 | 300 |
| CNAME | www | example.com. | 300 |
@ means the bare domain. A short TTL like 300 seconds makes mistakes cheap to fix; you can raise it to 3600 once everything works.
If you don't want IPv6 yet, skip the AAAA record for now — see the warning in step 5.
3. Check that DNS answers
Don't trust the registrar's "saved" message. Ask DNS directly:
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com
dig +short example.com A @1.1.1.1
The last line asks a public resolver, which is closer to what your visitors see. If you get your IP back, DNS is done.
4. Make the server answer
Install nginx and open the ports:
apt update && apt install -y nginx
ufw allow 80/tcp
ufw allow 443/tcp
Open http://example.com — you should see the nginx welcome page. Now add HTTPS with a free certificate:
apt install -y certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com
Certbot edits the nginx config, sets up the redirect to HTTPS and renews the certificate automatically. For a real app behind nginx, follow our reverse proxy with HTTPS guide.
5. The IPv6 trap
This one catches a lot of people. You add an AAAA record, but nginx listens only on IPv4. Visitors on IPv6 (many mobile networks) try the IPv6 address first and fail. Make sure your server block has both:
listen 80;
listen [::]:80;
The default Ubuntu nginx config already includes [::], but custom configs often drop it. Test from a machine with IPv6:
curl -6 -I https://example.com
Common problems
- Old IP still shows up: your local resolver cached it. Wait out the TTL or query
@1.1.1.1as above. - Certbot fails with a timeout: port 80 is blocked or DNS doesn't point here yet. Check
ufw statusanddigagain. - Works without www, fails with www: the certificate or the server block doesn't include
www. Rerun certbot with both names.
About reverse DNS
A and AAAA records go from name to IP. Reverse DNS (PTR) goes the other way, and it's set in your dashboard rather than at the registrar. You only need it for mail or when a service checks it — our PTR guide covers it.
If you're putting a site online for the first time, the website use-case page walks through sizing, and the network docs list which addresses each plan gets.
Comments
No comments yet. Be the first.