ThisCalculator

Everyday

Nginx Accept Your Domain: Setup Guide

Updated · Standard formula, shown below

Nginx Accept Your Domain: Setup Guide

This guide shows you how to configure Nginx to respond to your own domain name instead of just the server’s IP address. You’ll edit a server block, point the domain’s DNS records to your server, and reload Nginx. By the end, visiting your domain in a browser will serve your site over HTTP (and optionally HTTPS).

What You’ll Need

  • A server running Nginx (Ubuntu, Debian, CentOS, or similar) with sudo/root access.
  • A registered domain name (e.g., example.com).
  • Access to your DNS provider’s control panel (where you manage the domain’s records).
  • Your server’s public IP address.
  • Port 80 (HTTP) open in your firewall. For HTTPS, port 443 must also be open.

Step-by-Step

  1. Find your server’s IP address. Run curl ifconfig.me or hostname -I on the server. Note the public IPv4 address.
  2. Create a DNS A record. Log in to your DNS provider and add an A record: Host = @ (for the bare domain) or www (for the www subdomain), Value = your server’s IP. Add both if you want both to work. Wait for DNS to propagate (can take minutes to hours).
  3. Locate your Nginx configuration directory. On most systems it’s /etc/nginx/sites-available/ and /etc/nginx/sites-enabled/. On CentOS/RHEL, it’s often /etc/nginx/conf.d/.
  4. Create a new server block file. For example, sudo nano /etc/nginx/sites-available/example.com. (If your Nginx uses conf.d, create /etc/nginx/conf.d/example.com.conf.)
  5. Write a basic server block. Paste the following, replacing example.com and www.example.com with your actual domain, and /var/www/example.com with the path to your site’s files:
    server {
        listen 80;
        server_name example.com www.example.com;
    
        root /var/www/example.com;
        index index.html index.htm;
    
        location / {
            try_files $uri $uri/ =404;
        }
    }
        

    Save and exit.

  6. Enable the site (if using sites-available). Create a symbolic link: sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/. If you used conf.d, skip this step.
  7. Test the configuration. Run sudo nginx -t. If it says “syntax is ok” and “test is successful”, proceed. If there are errors, fix them (see Troubleshooting).
  8. Reload Nginx. Run sudo systemctl reload nginx (or sudo service nginx reload on older systems). This applies the new configuration without downtime.
  9. Verify in a browser. Visit http://example.com (and http://www.example.com). You should see your site’s content. If you see the default Nginx page, your server block might not be the one being used—check the server_name and that the default site isn’t overriding it.
  10. Set up HTTPS (recommended). Use Certbot to get a free SSL certificate: sudo apt install certbot python3-certbot-nginx (Debian/Ubuntu) or sudo dnf install certbot python3-certbot-nginx (CentOS). Then run sudo certbot --nginx -d example.com -d www.example.com. Follow the prompts. Certbot will automatically modify your server block and set up auto-renewal.

Common Mistakes

  • Wrong DNS record: Pointing the domain to the server’s private IP (like 192.168.x.x) instead of the public IP.
  • Missing www record: Only adding an A record for @ but not for www, and then the www subdomain doesn’t work.
  • Server name mismatch: Using server_name example.com; but the user types www.example.com—Nginx will serve the default site instead.
  • Not reloading Nginx: Editing the config but forgetting to run sudo nginx -t and sudo systemctl reload nginx.
  • Default site conflict: The default server block (often default in sites-enabled) catches all requests that don’t match any server_name. If your domain isn’t matching, the default site will show. Make sure your server block is correctly enabled and has the right server_name.
  • Firewall blocking port 80: Even if Nginx is listening, the OS firewall (ufw, firewalld) may block external requests.

Tips

  • Use a single server block for both www and non-www. List both in server_name as shown. If you want to redirect one to the other, add a separate server block with a return 301.
  • Test DNS with dig or nslookup. Run dig example.com from your local machine to see if the A record resolves to your server’s IP.
  • Keep your configs organized. Name files after the domain (e.g., example.com) and comment inside the file.
  • Use a staging environment. If possible, test on a subdomain like test.example.com before making changes to the main site.
  • Set up HTTPS early. Browsers now mark HTTP sites as “Not Secure”. Certbot makes it easy.

Troubleshooting

  • Nginx -t shows an error: Read the error message. Common issues: missing semicolon, duplicate server block, or invalid path. Fix the line indicated and re-test.
  • Domain shows default Nginx page: This means Nginx is running but not matching your server block. Check that the server_name matches exactly (including www). Also ensure your site is enabled (symlink exists) and the default site is not more specific. You can temporarily disable the default site with sudo rm /etc/nginx/sites-enabled/default (then reload).
  • Domain shows “This site can’t be reached”: DNS may not have propagated yet. Wait a few hours. Check that the A record points to the correct IP. Also check your firewall: sudo ufw status (Ubuntu) or sudo firewall-cmd --list-all (CentOS). Ensure port 80 is allowed.
  • HTTPS not working after Certbot: Make sure port 443 is open in the firewall. Also check that the certificate was issued successfully: sudo certbot certificates. If the domain isn’t resolving to the server, Certbot will fail.
  • Changes not taking effect: Always run sudo nginx -t first, then sudo systemctl reload nginx. If you changed DNS, remember that TTL (time to live) can delay propagation.
  • Permission denied when accessing files: Ensure the web root directory is readable by the Nginx user (usually www-data on Debian/Ubuntu, nginx on CentOS). Set permissions like sudo chown -R www-data:www-data /var/www/example.com.

Frequently Asked Questions

Do I need a static IP address?

Yes, for a public website you need a static public IP. If your IP changes, the DNS record will point to the wrong place. Some dynamic DNS services can help, but for a server, static is best.

Can I use a subdomain like blog.example.com?

Yes. Create an A record with blog as the host, and add blog.example.com to the server_name in a server block (or a separate one).

What if I don’t have a domain yet?

You can test with a free domain from services like DuckDNS, or edit your local hosts file (/etc/hosts on Linux/Mac, C:\Windows\System32\drivers\etc\hosts on Windows) to map a fake domain to your server’s IP for testing.

How do I redirect www to non-www (or vice versa)?

Add a separate server block for the one you want to redirect, with a return 301 http://example.com$request_uri;. For example, to redirect www to non-www:

server {
    listen 80;
    server_name www.example.com;
    return 301 http://example.com$request_uri;
}

Why does my site show the IP address instead of the domain?

That happens if you visit the IP directly. Nginx uses the Host header to choose the server block. If you type the IP, there’s no domain, so it falls back to the default block. Always use the domain in the browser.

Can I use Nginx with a domain that has no DNS A record?

No. Nginx doesn’t resolve the domain itself; the browser does. Without a valid A record pointing to your server, the domain won’t connect. You can test locally with the hosts file, but for public access, DNS is required.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.