The inability to access a website on port 80 after configuring DNS typically stems from firewall blocks, incorrect web server binding, or incomplete propagation. Verify that the VDS firewall allows inbound HTTP traffic and that your web service is actively listening on 0.0.0.0:80. Additionally, ensure the DNS record points to the correct public IP address of the VDS instance.
Verifying Firewall Rules and Inbound Traffic
The most common reason for port 80 inaccessibility is a restrictive firewall configuration. Both the operating system level and the cloud provider's network security group must permit incoming HTTP connections. If the firewall drops packets before they reach the web server, the connection will time out rather than refuse immediately.
On Linux-based VDS instances, check the status of ufw (Uncomplicated Firewall) or iptables. For ufw, ensure the rule for port 80 is enabled by running sudo ufw allow 80/tcp. If you are using firewalld, verify that the http service is allowed in the active zone with sudo firewall-cmd --permanent --add-service=http followed by sudo firewall-cmd --reload. On Windows Server environments, inspect the Windows Defender Firewall advanced settings to confirm an inbound rule exists for TCP port 80.
Beyond the OS firewall, cloud providers like AWS, DigitalOcean, Linode, or Vultr enforce network-level security groups. Log into your hosting dashboard and locate the networking or firewall section associated with your VDS. Ensure there is an inbound rule allowing TCP traffic on port 80 from source 0.0.0.0/0 (or your specific client IP range). Failure to configure this layer correctly results in connectivity issues regardless of the internal server setup.
Confirming Web Server Binding and Status
Even if the firewall is open, the web server software must be configured to listen on port 80 and bind to all available interfaces. A common misconfiguration occurs when a server listens only on 127.0.0.1 (localhost), making it inaccessible from external networks.
Use the command netstat -tuln | grep :80 or ss -tuln | grep :80 to check which addresses the web server is bound to. You should see entries indicating 0.0.0.0:80 or :::80. If the output shows only 127.0.0.1:80, you must modify your web server configuration file. For Nginx, check the server block in /etc/nginx/sites-available/default or similar paths to ensure the listen directive does not specify localhost exclusively. For Apache, verify the Listen directive in ports.conf or the virtual host configuration files.
Restart the web service after making changes to apply them. Use sudo systemctl restart nginx or sudo systemctl restart apache2 depending on your stack. Monitor the logs for errors during startup. If the service fails to start, the port remains closed, leading to access failures. Checking the service status with systemctl status nginx provides immediate feedback on whether the process is active and healthy.
DNS Propagation and Record Accuracy
After setting the DNS address, users may encounter access issues due to caching or incorrect record types. DNS changes do not propagate instantly; they rely on Time-to-Live (TTL) values set in the DNS records. During this propagation window, some users might still be directed to old or non-existent IPs.
Verify that your DNS A record points to the exact public IPv4 address of your VDS. Use tools like nslookup yourdomain.com or dig yourdomain.com from an external machine to see what IP address is being resolved. If the returned IP differs from your VDS IP, wait for full propagation or lower the TTL value in advance for future changes. Ensure there are no conflicting CNAME records that might redirect traffic unexpectedly.
Additionally, check if the domain registrar has locked the domain or if nameservers are pointing to the correct provider. Incorrect nameserver configurations can prevent DNS resolution entirely. Once the correct IP is resolved, test access via IP directly (http://your-vps-ip) to isolate whether the issue is DNS-related or server-side. If the IP works but the domain does not, the problem lies strictly within DNS configuration.
Related Resources
If you suspect deeper network connectivity issues beyond simple port blocking, understanding the underlying TCP mechanics can help diagnose timeouts. Refer to our guide on Understanding the 'listen()' Call and 3-Way Handshake in TCP Server Debugging for insights into connection states.
Frequently Asked Questions
Why can I access the site via IP but not domain name?
This indicates a DNS propagation delay or a misconfigured DNS record. The server is working correctly on port 80, but the domain name is resolving to an incorrect or outdated IP address. Clear your local DNS cache or wait for TTL expiration.
How do I check if port 80 is blocked by my ISP?
Most residential ISPs do not block port 80 for servers, but some may filter outbound traffic. Use a tool like telnet yourdomain.com 80 from a different network (e.g., mobile data) to see if the connection establishes. If it fails externally but works locally, the issue is likely your VDS firewall or server binding.
What if my web server is running but returns a 403 Forbidden error?
A 403 error means the port is accessible, but permissions prevent viewing the content. Check the ownership and permissions of your web root directory. Ensure the web server user (e.g., www-data or nginx) has read access to the files. Also, verify that a default index file (like index.html) exists in the document root.
Can SSL certificates affect port 80 access?
No, SSL certificates primarily affect port 443 (HTTPS). However, if you have configured HTTP-to-HTTPS redirects in your web server config, accessing port 80 will automatically forward to HTTPS. If the HTTPS certificate is invalid or expired, the browser may block the connection after the redirect, appearing as if port 80 is broken.
What should I do if the VDS firewall rules seem correct but access still fails?
Double-check the cloud provider's security group or network ACLs, as these operate independently of the OS firewall. Many users forget to update these rules after changing the OS firewall settings. Ensure both layers allow inbound TCP traffic on port 80 from the desired source IPs.