Pointing your domain at your VPS
To point your domain at a VPS, you need an A record (and AAAA for IPv6) with the VPS's IP address. You can add this record to your existing DNS zone without changing nameservers, or move the whole zone to Hostworld's nameservers first. The guide covers both approaches and explains propagation delays.
To make your domain load the site on your Hostworld VPS, you need an A record (and an AAAA record too, if you use IPv6) pointing at the VPS's IP address. That's it, in most cases. You only need to touch your domain's nameservers if you want Hostworld to hold the whole DNS zone rather than just this one record.
This guide assumes the VPS itself is already up and serving the site when you visit its IP address directly. If you haven't reached that point yet, sort the server first: pointing a domain at a VPS that isn't serving anything just moves the "it doesn't work" problem from one screen to another.
Before you start
- You need the VPS's IP address. You'll find it in Virtualizor, on the List VPS screen, alongside the VPS ID and hostname.
- You need access to wherever the domain's DNS zone currently lives. That's either the registrar it's registered with, a separate DNS provider, or the WHMCS client area at portal.hostworld.uk if the domain is with us and DNS management is switched on for it.
- Decide, before you start, whether you actually want to move the whole zone to Hostworld's nameservers or just add one record. Most people only need the record. Moving nameservers is a bigger step with a longer, slower window while it takes effect, and it's easy to do it without needing to.
- If email for this domain is hosted somewhere separate from the website, note down the existing MX records before you touch anything. An A record change won't affect them, but a nameserver change will move the whole zone, MX records included, and if you don't recreate them on the new nameservers, mail stops working the moment the switch lands.
Step 1: Find your VPS's IP address
Log in to the Hostworld client area at portal.hostworld.uk and open Virtualizor. The List VPS screen shows, for each VPS you have: its ID, its hostname, and its IP address. That IP address is the value every DNS record in this guide points to. Write it down, or keep the tab open, you'll need it more than once.
Virtualizor also has a separate feature called VPS Domain Forwarding, which proxies a domain to a VPS through a shared source IP on the node. That's only relevant if your VPS doesn't have a public IP of its own, which isn't the normal setup. If your VPS has a public IP (almost all of them do), ignore Domain Forwarding entirely and use a standard A record instead. It's the simpler, more predictable route and it's what the rest of this guide covers.
Step 2: Choose your route
There are two legitimate ways to get a domain pointing at your VPS, and they are not the same thing:
- Add an A record, keep your existing nameservers. If the domain is registered elsewhere, or its DNS is already managed somewhere you're happy with, you don't need to change anything at the registrar. You just add or edit the A record in that existing zone so it points to the VPS's IP address. This is the quicker route and the one most people want.
- Change nameservers to Hostworld's, then add the A record. If you'd rather have Hostworld hold the whole DNS zone (useful if you want everything managed in one place, or if you're moving other services here too), you first change the domain's nameservers at the registrar to point at Hostworld, and only once that's done and the zone exists there do you add the A record. Changing nameservers on its own does nothing to load your site. It only moves where the records live; the A record still has to be created afterwards.
If you're not sure which you want: if the only reason you're here is "make the domain load my VPS", pick the A record route and leave the nameservers alone.
Step 3: Add or edit the A record (existing nameservers)
Go into the DNS management screen wherever the domain's zone currently lives. If that's another registrar or DNS provider, it'll be their DNS or Zone editor. If the domain is registered through Hostworld and DNS management is enabled for it, you'll find it in the domain's section of the WHMCS client area; if you don't see a DNS editor there, DNS management hasn't been enabled for that domain, or the registrar module doesn't support it, and you'll need to manage the record wherever the nameservers currently point instead.
Find or create the A record for the domain (and for www, if you use that separately) and set its value to the VPS's IP address from Step 1. If you use IPv6, add an AAAA record with the VPS's IPv6 address as well; without it, IPv6-capable visitors may fail to connect even though the A record is correct.
Be careful editing a live zone. Changing the wrong record, or editing the wrong domain's zone entirely, can take the site or the mailbox offline at the same time, and it's an easy mistake to make when a zone has more than a handful of rows.
Step 4 (only if you're moving the zone): Change nameservers to Hostworld's
If you decided in Step 2 that you want Hostworld to hold the zone, this is done at your domain's registrar (which may or may not be Hostworld). Set the nameservers to:
ns1.serverworld.ukns2.serverworld.ukns3.serverworld.ukns4.serverworld.uk
If the domain is registered through Hostworld, this is done from the domain's page in the WHMCS client area at portal.hostworld.uk. Look for the nameserver management option on that domain's management screen; the exact wording depends on the registrar module behind the domain, but it will let you enter or select nameservers for it.
Once the nameserver change has taken effect (see the propagation note below), the zone on Hostworld's nameservers becomes authoritative for the domain. At that point, go back and follow Step 3 to add the A record in that new zone. If email for the domain is hosted separately, add the matching MX records into the same zone before, or as close to the same time as possible after, the nameserver change lands, so there isn't a window where mail has nowhere to go.
Step 5: Understand propagation, and don't panic at the wait
The instruction you'll see everywhere to "wait 24 to 48 hours" isn't a fixed rule, it's a ceiling. What actually determines how long a change takes to be seen everywhere is the TTL (Time To Live) on the specific record you changed. A change at the authoritative nameserver is instant there. What takes time is every recursive resolver out at ISPs, mobile networks and offices that has cached the old answer and won't ask again until its cached copy expires.
A plain A record edit, on an existing zone, is usually the quicker of the two changes in this guide. A nameserver change is slower, because it also has to update at the TLD registry level, not just at the DNS zone, and that step is genuinely outside anyone's control; the registrar's nameserver TTL is typically the full 24 to 48 hours.
If you know in advance you're going to do this (rather than reading this guide mid-emergency), the useful trick is to lower the TTL on the records you're about to change a few days beforehand, down to somewhere around 300 to 600 seconds, and then wait at least as long as the old TTL before making the real change. That empties the caches out ahead of time, so the actual cutover is quick. It only works if you plan ahead; it's not something you can do retroactively once you've already made the change.
Either way, expect a window where some visitors reach the new site and some briefly still see the old one (or nothing, if there was no previous site). That's normal, it isn't data loss, and it resolves itself as caches expire.
A note if your site is actually on cPanel hosting, not a VPS
This guide is written for a VPS reached through Virtualizor. If your site is instead on Hostworld's cPanel-based shared, reseller or WordPress hosting, the process is different: you'd usually change the domain's nameservers to Hostworld's and let the account's existing A record handle the rest, rather than editing an A record by hand. If you do need to add or check a record on cPanel hosting yourself, that's done in cPanel's Zone Editor, with quick-add buttons for A, CNAME and MX records. Don't mix the two approaches: on a VPS, the A record is the whole job; on cPanel hosting, it's usually already sorted for you once the nameservers point here.
What next
For the click-by-click version of finding the IP address and adding the record in our panels, see finding your VPS's IP address in Virtualizor. If you're changing nameservers on a domain registered with Hostworld, the client-area steps are covered in changing nameservers in your Hostworld account.
Once the domain is loading the site correctly, the next thing worth setting up is email for the domain, and after that, a TLS certificate if you don't already have one. Have a look through our VPS guides for what to tackle next. If anything here doesn't behave as expected, particularly if a record won't save or the domain still isn't resolving after a sensible wait, open a support ticket and we'll look at the zone with you.
Common questions
Do I need to change my nameservers to point a domain at my VPS?
No. Changing nameservers moves where your whole DNS zone lives; it doesn't, by itself, point anything at your VPS. Most people just need to add an A record in the zone they already have, wherever it currently lives.
Where do I find my VPS's IP address?
In Virtualizor, on the List VPS screen in your Hostworld client area. It's shown as a column alongside the VPS ID and hostname, there isn't a separate lookup tool for it.
Why isn't the site loading yet after I added the record?
Almost always this is caching, not a wrong record. Check the record itself is saved correctly first. If it is, it's a matter of waiting out the TTL on that record, which is usually well under 24 hours for a plain A record and can be as much as 24 to 48 hours if you changed nameservers.
Do I need an AAAA record as well as an A record?
Only if the VPS has an IPv6 address and you want IPv6 visitors to reach it directly. If you're not using IPv6, an A record on its own is enough.
Will this affect my email?
An A record change on its own won't touch mail. A nameserver change moves the whole zone, MX records included, so if email for the domain is hosted separately from the website, make sure the MX records exist correctly in the new zone before, or immediately after, the nameserver change lands.