Troubleshooting Self-Hosted Domain Not Responding on Local Network

Accessing a self-hosted domain on your local network usually fails because of split-horizon DNS or incorrect router port forwarding. The most common fix is configuring your internal DNS to resolve the public domain to your server's private IP address, ensuring NGINX serves the correct site via the server_name directive.

Understanding Split-Horizon DNS

When you access your website from outside your home, your router performs Network Address Translation (NAT) and forwards traffic from port 80 or 443 to your internal server IP. However, when you are inside the network, your computer tries to resolve the domain name using the public DNS servers provided by your ISP. These servers return the public IP address of your router. Your computer then sends the request back to the router, which must loop it back to your internal server. This process, known as NAT hairpinning or NAT reflection, is not supported by all consumer routers. If your router does not support this feature, the connection will time out or fail completely. To bypass this limitation, you need to implement split-horizon DNS. This technique involves providing different DNS responses based on where the query originates. For devices on your local network, the domain should resolve to the private IP address of your server (e.g., 192.168.1.x). For devices on the internet, it should resolve to the public IP address. The simplest way to achieve this is by modifying the /etc/hosts file on your client machines or, more effectively, by configuring your local DNS server to override the record for your specific domain. If you are running a local DNS resolver like Pi-hole, AdGuard Home, or BIND, you can add a static host entry that maps your domain to the server's local IP. This ensures that any device on your LAN queries the local DNS and receives the direct path to the server, eliminating the need for NAT hairpinning entirely. This approach is generally more reliable and faster than relying on router-based reflection.

Verifying Router Port Forwarding

Even with correct DNS resolution, your router must be configured to forward incoming HTTP and HTTPS traffic to your web server. Log into your router’s administrative interface and locate the Port Forwarding or Virtual Server section. You need to create rules that map external port 80 to your server’s internal IP on port 80, and external port 443 to internal port 443. Ensure that the protocol is set to TCP for both rules. It is crucial to verify that no other service on your network is conflicting with these ports. For instance, if another device is running a web server on port 80, the router may forward traffic to the wrong machine. Additionally, some ISPs block incoming ports 80 and 443 for residential customers to prevent hosting public websites. If you cannot open these ports, you may need to use alternative ports (like 8080) and update your NGINX configuration accordingly, though this requires accessing the site via http://example.com:8080. For a deeper understanding of securing services exposed to networks, see Improving NFS Server Security on a Local Network. While the focus here is web traffic, the principles of restricting access and verifying permissions apply similarly to other services you might expose locally.

Configuring NGINX for Local Domains

Once traffic reaches your server, NGINX must know how to handle requests for your specific domain. Check your server block configuration in /etc/nginx/sites-available/ or /etc/nginx/conf.d/. The server_name directive must exactly match the domain you are trying to access. If you are testing with example.com, ensure the configuration includes server_name example.com;. A common error occurs when NGINX serves the default page instead of your custom site. This happens if the server_name does not match any defined block, causing NGINX to fall back to the first available server block. Use the command nginx -t to test your configuration syntax before reloading. After making changes, reload NGINX with systemctl reload nginx. If you are encountering 404 errors or path issues within NGINX, refer to NGINX X-Accel-Redirect 404 Error: Path Config Seems Correct for troubleshooting steps related to file paths and redirects that often accompany domain configuration problems.

Testing Connectivity Locally

Before assuming complex network issues, perform basic connectivity tests. From a device on the same network, open a terminal and ping the server’s local IP address to verify layer 3 connectivity. Then, use curl -v http://your-domain to see the full HTTP transaction. If curl returns the correct HTML content, your NGINX configuration is working correctly, and the issue was likely DNS-related. Check your browser’s developer tools under the Network tab to see if the request is being sent to the correct IP. If the request goes to the public IP and times out, your split-horizon DNS is not working. If it goes to the local IP but shows an error, check NGINX logs at /var/log/nginx/error.log for specific failure reasons.

Firewall and Service Restrictions

Ensure that your server’s firewall allows inbound connections on ports 80 and 443. On Ubuntu systems using UFW, run sudo ufw allow 80/tcp and sudo ufw allow 443/tcp. On CentOS or RHEL systems using firewalld, ensure the http and https services are enabled. A misconfigured firewall is a frequent cause of "connection refused" errors even when NGINX is running properly.

Frequently Asked Questions

Why does my domain work externally but not internally?

This is typically caused by a lack of NAT hairpinning support on your router or missing split-horizon DNS entries. Your router forwards external traffic correctly, but internal clients resolving the public IP face a loop that the router cannot close. Fix this by pointing your local DNS to the server’s private IP address.

How do I check if my router supports NAT reflection?

Consult your router’s manual or admin interface for settings labeled "NAT Loopback," "Hairpin NAT," or "Local Access." If these options are absent, you must rely on local DNS overrides rather than router-level solutions.

What if my ISP blocks port 80?

Many residential ISPs block standard web ports to prevent unauthorized hosting. In this case, configure NGINX to listen on an alternative port like 8080 and update your local DNS or hosts file to reflect the new port in the URL structure.

How can I debug NGINX serving the wrong site?

Verify that your server_name directives are unique and correctly spelled. Use nginx -T to dump the full effective configuration and check which server block handles the specific domain. Ensure there are no typos in the configuration files before reloading.

Is it safe to expose my self-hosted domain locally?

Yes, exposing services locally is standard practice, but ensure you use strong passwords and keep your software updated. If you plan to expose it to the internet later, consider using a reverse proxy with SSL termination and rate limiting to enhance security.