The domain and the server live in two separate places that don't depend on each other: you can set up DNS before the server is anywhere near ready. This walks through the whole path, from finding the server's IP to a working HTTPS site behind a reverse proxy.

You bought the domain, the VPS is up, and the browser still only shows the site when you type in the bare IP, something like 203.0.113.10. To point a domain at a VPS, you actually configure two separate things people tend to conflate: the DNS record that tells the world which IP answers for your domain name, and the setting on the server itself that decides what to serve for that name. Here's the whole path in order: where to find the VPS's IP, how to add the record at your registrar, how to confirm it has actually propagated, and how to end up with real HTTPS instead of a browser warning about an untrusted connection.

Short version. At your domain's DNS panel, add an A record with the name @ pointing to your VPS's IPv4 address (find it in the WeaselCloud client area, under the "Hosting Information" tab), plus a matching one for www. Give it time to propagate - usually a few minutes to a couple of hours, checked with dig +short yourdomain. On the server, put a reverse proxy in front of your app. Caddy is the simplest option: it requests and renews the Let's Encrypt certificate on its own, no manual certbot runs and nothing to remember on a calendar.

How to point a domain at a VPS: two independent layers

When a browser opens example.com, two things happen that know nothing about each other. First the browser asks DNS (the Domain Name System, the lookup service that turns names into IP addresses) which IP answers for example.com. Once it has that answer, it sends the actual request to that IP, tagging it with a Host: example.com header - the name the server reads to decide which of the sites it might be running should handle this particular request.

The practical upshot: you can set the DNS record any time, even before the VPS has anything running on it. The domain will simply point at an IP where nobody is listening yet, so the browser shows a connection error rather than "domain doesn't exist." Once a reverse proxy or web server comes up on that IP, the same domain starts working without touching DNS again.

Step 1. Find the server's real IP address

Log into my.weasel.cloud, open your service, and check the "Hosting Information" tab - it lists the server's IPv4 address, the login (usually root), and the password in plain text. That IPv4 is the one that goes into the DNS record, not whatever address you might remember from the order confirmation email if it happened to change since. If you're not sure where that tab even is, the client area walkthrough covers the whole menu.

While you're connected, it's worth checking whether the server is actually listening on the port you'll need - this saves time later, at the HTTPS step:

ss -tlnp

Look for lines with :80 or :443. If there aren't any yet, that's expected on a fresh server - the reverse-proxy step below takes care of it.

Step 2. Add the A record at your registrar or DNS provider

This part happens outside WeaselCloud entirely, wherever your domain's DNS zone is managed - either your registrar's own panel, or a third-party DNS provider like Cloudflare if you've pointed the domain's nameservers (NS) there. The interfaces all look roughly the same; the example below uses Cloudflare.

Add a record with these values:

  • Type - A
  • Name - @ (the bare domain, example.com; some panels want this field left empty or filled with the full domain name instead of @)
  • The address-value field (usually labelled IPv4 address or Content, depending on the panel) - the IPv4 from Step 1
  • TTL (time to live - how long resolvers are allowed to cache the record) - Auto, or a short value like 300 seconds while you're still setting things up, so later edits take effect faster

Then add a second A record with the name www pointing at the same IP - otherwise the site opens at example.com but not at www.example.com. Instead of a second A record you can use a CNAME with the name www pointing at example.com, which means you only ever update the IP in one place; the bare domain (@) can't take a CNAME, only an A record.

Type

Name

Value

What it's for

A

@

server's IPv4

domain without www loads the site

A or CNAME

www

server's IPv4 (or example.com for CNAME)

domain with www loads the same site

The AAAA record (the same idea as A, but for an IPv6 address) deserves its own note: you need one only if your provider actually assigned the server a working IPv6 address you can enter. Not every VPS gets one by default - check that in your own control panel before hunting for an AAAA field in DNS. A regular site works fine with just the A record for IPv4: visitors without IPv6 use it directly, and visitors with IPv6 fall back to IPv4 when there's no AAAA record anyway - either way, the site loads.

Step 3. Wait for the record to propagate

A new record doesn't show up everywhere at once. DNS servers around the world cache the previous answer for however long its TTL said. Usually 5-30 minutes is enough, sometimes a couple of hours; switching a domain's nameservers entirely (as opposed to a single record) takes longer, up to a day.

Check from your own machine:

dig +short example.com

This returns the IP your network currently resolves for the domain. If dig isn't available (Windows without extra tools, for instance), nslookup example.com does the same job. Once your server's IP shows up in the answer, the record has reached at least your own resolver; to check it across many regions at once, a site like whatsmydns.net works well.

Step 4. Get HTTPS running with a reverse proxy

Your app or site usually listens on a local port, something like 127.0.0.1:3000, rather than on 80 and 443 directly. A reverse proxy is what actually faces the internet: it accepts the incoming connection, reads the Host header, and hands the request off to whichever internal service should answer it. The same piece of software usually also handles HTTPS: it obtains a certificate and terminates TLS on your behalf.

We'd point you at Caddy here rather than the more common nginx + certbot combo, and there's a concrete reason for that. Caddy's Let's Encrypt certificate is obtained and renewed automatically, with no separate command to run and no cron job to remember exists. Its config file is shorter, which mostly means there are fewer places to get it wrong. For a single site on a single VPS - which is exactly the situation most people land here with - that difference is noticeable in practice, not just on paper.

Installing Caddy

sudo apt update

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

sudo apt update

sudo apt install -y caddy

  • The first four lines add Caddy's official package repository and its signing key - without them apt won't find the package at all, since Ubuntu's default repositories either don't carry Caddy or carry an old version of it.

Right after installation, Caddy comes up as a systemd service with an empty default config - expected, since we haven't told it about a site yet.

Setting up the Caddyfile

Open Caddy's main config file:

sudo nano /etc/caddy/Caddyfile

Clear out the default content and put your own domain in instead:

example.com, www.example.com {

reverse_proxy 127.0.0.1:3000

}

reverse_proxy 127.0.0.1:3000 should point at whatever address and port your app is actually listening on (the same one you saw in the ss -tlnp output back in Step 1). Apply the config:

sudo systemctl reload caddy

As soon as the config reloads, Caddy walks every host name in the file, and for any of them that doesn't already have a valid certificate, it kicks off an ACME request on its own (ACME being the protocol Let's Encrypt runs its automated certificate issuance on) - usually over port 80, falling back to port 443 if 80 isn't reachable. That happens right after reload, not the moment some random visitor first shows up, which is exactly why Steps 2 and 3 matter: without a propagated DNS record and open ports 80/443, the issuance simply fails, and Caddy keeps retrying while logging the error.

Check the result:

curl -I https://example.com

What success looks like: something like HTTP/2 200 (or whatever status code your app actually returns) and response headers with no certificate warnings. If curl instead complains about the certificate or can't connect at all, see "Common problems" below.

If you need nginx instead of Caddy

Sometimes nginx is already there for an unrelated reason - the app might have originally been set up following a guide that used it. In that case the certificate is a separate step, handled by certbot: sudo apt install -y nginx certbot python3-certbot-nginx, then in the site's config file set server_name example.com www.example.com; and proxy_pass http://127.0.0.1:3000;, enable the site, and issue the certificate with one command:

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

Certbot finds the matching server block by domain name on its own, adds the HTTPS section to it, and sets up automatic renewal through a system timer - unlike Caddy, though, you have to run this command yourself once; the automation only kicks in after that first successful issuance.

Common problems: narrowing it down

A domain that's pointed but not loading almost always comes down to one of three causes, and they're easy to tell apart by symptom.

Symptom

Cause

How to check

Browser can't find the server at all, something like DNS_PROBE_FINISHED_NXDOMAIN

DNS record hasn't propagated yet, or wasn't created

dig +short example.com - empty, or the old IP

Domain resolves to the right IP, but the browser reports a connection refused

nothing on the server is listening on that port

ss -tlnp on the server - no line for :80/:443

Same symptom, but the service answers locally (curl 127.0.0.1:PORT works)

the firewall is blocking incoming 80/443

sudo ufw status - 80/443 aren't in the allowed list

That third case gets a full walkthrough in the ufw firewall guide, including why a program can be listening on a port just fine while the firewall still keeps it closed to the outside world unless it's explicitly allowed.

FAQ

How do I find my VPS IP address in WeaselCloud?

Log into my.weasel.cloud, open your service, and check the "Hosting Information" tab - it lists the server's IPv4 address, login, and password. Use that address in your DNS record, not whatever's in the original order confirmation email if it's since changed.

How do I add an A record for my domain?

In your domain's DNS panel (registrar or third-party DNS provider), create an A record with the name @ pointing at your server's IPv4 address, plus a matching one for www. TTL can stay at default, or be lowered temporarily while you're making changes so edits take effect faster.

How long does DNS propagation take?

Usually a few minutes to a couple of hours for a single record. Switching a domain's nameservers entirely is slower, up to a day. Check the current state with dig +short example.com or a service like whatsmydns.net.

Do I need an IPv6 address for a normal website?

No, it's not required: a single A record with IPv4 is enough for the site to load for every visitor. An AAAA record is only worth adding if your server genuinely has its own IPv6 address - check your provider's panel for that, since not every VPS gets one automatically.

How do I get free HTTPS on a VPS?

Through a Let's Encrypt certificate, which is free and automated in most setups. The simplest route is a Caddy reverse proxy, which obtains and renews the certificate on its own with no separate commands. The alternative is nginx with the certbot plugin, which issues a certificate in one command and sets up renewal through a system timer.

Domain is pointed but the site won't load - what do I check?

In order: dig +short example.com should return the right IP, ss -tlnp on the server should show something on ports 80/443, and sudo ufw status should confirm those ports are allowed through the firewall. One of these three is almost always the cause.

Takeaways

  • DNS (which IP answers for a name) and the server (what gets served for that name) are independent settings; you can set up DNS before the server is anywhere near ready.
  • Your VPS's IPv4 address in WeaselCloud lives in the client area, under "Hosting Information" on the service page.
  • At your registrar or DNS provider, add an A record for @ and one for www, both pointing at that IP; add AAAA only if the server genuinely has an IPv6 address.
  • Propagation usually takes a few minutes to a couple of hours, checked with dig +short yourdomain.
  • The easiest route to HTTPS is Caddy - the Let's Encrypt certificate is issued and renewed automatically. nginx with certbot is the alternative, where issuing the certificate is a separate manual command.
  • If the site won't load: check DNS propagation first, then whether the server is listening on the port, then whether the firewall is blocking it.

What's next