Troubleshooting Home Server: Suddenly Unreachable Over Internet

Your home server is unreachable over the internet due to misconfigured DNS records, incorrect Nginx reverse proxy settings, or firewall blocks. Verify your public IP matches your router's WAN address, ensure A records point correctly, and check that Nginx listens on port 443 with valid SSL certificates for services like Nextcloud and Navidrome.

Verify Public IP and Connectivity

The first step in troubleshooting a suddenly unreachable home server is confirming that your external identity has not changed. Many home internet connections use dynamic IPs, meaning your public address can change without notice. If your DNS records still point to an old IP, traffic will fail to reach your device. Start by visiting a site like whatismyipaddress.com from a device outside your local network to determine your current public IP. Then, compare this value against the IP address displayed in your router’s status page under the WAN or Internet section. If these two addresses do not match exactly, you have identified the root cause immediately. If the IPs match, test basic connectivity using ping from an external machine. While some routers block ICMP ping requests for security, a successful response confirms that your ISP is routing traffic to your gateway. If the ping fails, check if your ISP has blocked inbound ports or implemented Carrier-Grade NAT (CGNAT), which prevents direct access entirely. In such cases, you may need to contact your provider or use a tunneling service like Tailscale as an alternative. For more details on handling strange networking issues with similar setups, see Strange Networking Issues with FreshRSS behind Nginx Reverse Proxy on Garnet.

Check DNS Configuration

Once connectivity is confirmed, inspect your Domain Name System (DNS) settings. Ensure that your domain’s A record points to your current public IPv4 address. If you are using IPv6, verify the AAAA record as well. Use tools like dig or online DNS checkers to confirm propagation. Sometimes, changes take up to 48 hours to propagate globally, but most modern providers update within minutes. Clear your local DNS cache if you suspect stale records are affecting your testing. Additionally, check if you are using a Dynamic DNS (DDNS) service; if so, verify that the client software running on your router or server is successfully updating the provider with your new IP address.

Inspect Nginx Reverse Proxy Settings

Assuming DNS and network paths are clear, the issue likely lies within your Nginx configuration. A common failure mode occurs when Nginx is configured to listen only on localhost (127.0.0.1) instead of all interfaces (0.0.0.0). Open your server block configuration file, typically located in /etc/nginx/sites-available/ or /etc/nginx/conf.d/. Look for the listen directive. It should read listen 443 ssl; or listen [::]:443 ssl ipv6only=on;. If it specifies server_name incorrectly or lacks the ssl_certificate and ssl_certificate_key paths, Nginx will reject connections or return errors. Test your configuration syntax before reloading by running sudo nginx -t. This command checks for syntax errors and reports missing files. If the test passes, reload the service using sudo systemctl reload nginx. Check the error logs at /var/log/nginx/error.log for specific messages indicating why connections are dropping. Common issues include expired SSL certificates or mismatched hostnames in the server_name directive. For insights on resolving archive access issues with Nextcloud, refer to Unable to Access Nextcloud Archive via Internet with Nginx Reverse Proxy.

Validate Firewall Rules

Even with correct Nginx configurations, your server’s firewall may block incoming traffic. On Linux systems, ufw (Uncomplicated Firewall) or iptables are common culprits. Ensure that port 80 (HTTP) and port 443 (HTTPS) are allowed. You can check UFW status with sudo ufw status. If inactive, enable it and allow the necessary ports: sudo ufw allow 80/tcp and sudo ufw allow 443/tcp. If you are using firewalld, ensure the https and http services are enabled in the public zone. Remember that your router itself also acts as a firewall; verify that port forwarding rules direct traffic from WAN ports 80 and 443 to your home server’s local IP address.

Test Service Specifics

Different applications may have unique requirements. For Nextcloud, ensure that the trusted_domains array in config.php includes your public domain name. If it does not, Nextcloud will redirect or deny access. For Navidrome, check that the base URL setting matches your reverse proxy path. Restart the application containers or services after making configuration changes. If you encounter specific errors related to other home automation platforms, reviewing setup guides for KVM environments might provide additional context on proxying multiple services, as seen in Setting Up Nginx Reverse Proxy for Home Assistant OS on KVM.

Frequently Asked Questions

Why does my server work locally but not remotely?

This usually indicates a firewall or port forwarding issue. Your local network bypasses the router’s external firewall rules, allowing direct access to internal IPs. Ensure your router forwards ports 80 and 443 to your server’s local IP and that no host-level firewall blocks these inbound connections.

How do I know if my ISP is blocking port 80?

Many residential ISPs block standard web ports to prevent users from hosting servers. Test by attempting to connect to port 80 from an external network using a tool like telnet or an online port checker. If it times out while port 443 works, your ISP likely blocks HTTP, forcing you to rely solely on HTTPS.

What causes "502 Bad Gateway" errors in Nginx?

A 502 error means Nginx cannot communicate with the backend service. Check if your application (e.g., Nextcloud or Navidrome) is running and listening on the expected socket or port. Verify that the proxy_pass directive in your Nginx config points to the correct upstream address and that there are no typos in the hostname or port number.

Can I use a different reverse proxy instead of Nginx?

Yes, alternatives like Traefik, Caddy, or Apache can handle reverse proxy duties. Caddy, for instance, automatically handles SSL certificate provisioning, which simplifies setup. However, switching requires reconfiguring all virtual hosts and ensuring your DNS records remain stable during the transition.

Why are my SSL certificates invalid or expired?

Certificates obtained via Let's Encrypt through Certbot expire every 90 days. If automatic renewal fails, your web server will present an invalid certificate, causing browsers to block access. Check the cron jobs or systemd timers responsible for running certbot renew and review the logs for errors preventing successful renewal.