How to Point a Domain to Your Web Server

You have a domain from a registrar and a server from a hosting or cloud provider, and you want the two connected so that typing your domain opens your site. To point a domain to a server you need to get three things right: the DNS records, the web server's configuration, and the network path in between. Skipping any one of them produces the familiar "it works by IP but not by name" problem. This walk-through covers all three for a typical VPS or dedicated server.

Before you start: gather three facts

1. The server's public IP address. It is shown in your hosting dashboard. On the server itself, curl -4 ifconfig.me prints the public IPv4 address. Make sure it is a static or reserved IP; many cloud providers change the address of a stopped instance unless you reserve it.
2. Whether the server has IPv6 and, if so, its public IPv6 address.
3. Where your domain's DNS is managed. This may be the registrar, a separate DNS provider or a CDN. A WHOIS lookup shows the domain's current name servers, which tells you which control panel you need to log in to.

Step 1: Create the DNS records to point the domain to the server

In the DNS control panel for the domain, create or edit these records (replace the example addresses with yours):

A few points that save time:

• The @ symbol means the bare domain. Some panels want you to leave the name blank instead.
• For www, a CNAME pointing to your bare domain works just as well as a second A record, and means you only update one record if the IP ever changes.
• Delete conflicting records. New domains often come with a registrar parking A record, or a www CNAME pointing to a parking page. If two A records exist for the same name, visitors will be sent to each at random.
• Leave MX and TXT records alone unless you are also moving email.

If the domain is about to move from an existing live server, lower the TTL on these records a day in advance so the switch takes effect quickly.

Step 2: Tell the web server about the domain

DNS only gets the visitor's browser to your server's IP address. The browser then sends a Host header containing the domain name, and the web server uses it to decide which site to serve. If no site is configured for that name, you will see a default page or the wrong site.

For Nginx, a minimal server block looks like this:

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

Test and reload with sudo nginx -t && sudo systemctl reload nginx.

For Apache, the equivalent virtual host is:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/public
</VirtualHost>

Enable it and reload, for example with sudo a2ensite example.com.conf && sudo systemctl reload apache2 on Debian or Ubuntu. If you use a control panel such as cPanel or Plesk, adding the domain in the panel creates this configuration for you.

Step 3: Open the firewall

Web traffic needs TCP port 80 for HTTP and 443 for HTTPS. On cloud platforms there are often two firewalls: the provider's security group or network firewall, and the operating system's own (such as ufw or firewalld). Allow both ports in each. From outside the server, the port checker confirms whether 80 and 443 are actually reachable.

Step 4: Wait for DNS, then test properly

New records usually appear within minutes; changes to existing records depend on the old TTL. Check from several locations with the DNS propagation checker rather than relying on your own browser, which may have cached an old answer.

You can also test the web server before DNS has spread, by telling curl which IP to use for the name:

curl -I --resolve example.com:80:203.0.113.25 http://example.com/

A 200 OK or a redirect means the server is configured correctly and you are only waiting for DNS.

Step 5: Add HTTPS

Once the domain resolves to your server, you can get a free certificate from Let's Encrypt. On many Linux servers Certbot does the work and edits the Nginx or Apache configuration for you:

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

Certificate issuance validates that the domain points at your server, which is why it has to come after DNS. Afterwards, redirect HTTP to HTTPS and pick one canonical version of the domain (with or without www), redirecting the other to it.

Troubleshooting

• Domain shows the registrar's parking page: an old A record is still in place, or you edited DNS at a provider the domain is not using.
• Connection times out: firewall or security group is blocking port 80/443, or the IP is wrong.
• Wrong website or default page: the server block or virtual host does not list that name.
• Works for some people, not others: propagation still in progress, or a broken AAAA record affecting IPv6 users.
• Certificate warning: the certificate does not cover the name being visited, often www.

Key takeaways

• Create A records (and AAAA only if IPv6 works) for both the bare domain and www, and remove conflicting parking records.
• Configure the web server to answer for the domain name, and open ports 80 and 443.
• Test with curl --resolve and a multi-location propagation check, not just your browser.
• Add HTTPS once DNS resolves, and redirect to one canonical host name.