VPS Website Not Loading: How to Check DNS, Open Ports, Firewall and Network Connectivity
Launching a site on a VPS is a straightforward and well-documented task. What is much harder is figuring out why it suddenly stopped opening. The browser shows an error, colleagues say the page is unavailable, and everything in the server control panel looks normal. It is an alarming situation — especially if this is a production service or an online store.
The cause is almost always hiding in one of four places: DNS resolves the domain to the wrong IP, the firewall has blocked the required port, the server is unreachable over the network, or the web server has crashed and stopped handling requests. Browser error messages can be misleading: ERR_CONNECTION_REFUSED and ERR_CONNECTION_TIMED_OUT look similar, but they mean completely different things. You need to work layer by layer — from basic network reachability to DNS and the web server configuration.
In this article, we will walk through each diagnostic layer step by step: how to check the network connection to the VPS, confirm that ports are reachable, verify the domain’s DNS records, and find the problem in the web server itself. All examples are real Linux commands that you can run right away.
How the chain works: where exactly things can break
When a user enters a website address in the browser, several things happen behind the scenes in sequence. The browser contacts a DNS server — asking which IP address corresponds to the domain name. After receiving the answer, it opens a TCP connection to the server on the required port. Only then does it send an HTTP request and wait for a page in response. If anything breaks at any of these steps, the site will not load.
Browser error messages provide a clue, but not always an exact one. ERR_NAME_NOT_RESOLVED points specifically to DNS — the domain does not resolve to an IP. ERR_CONNECTION_REFUSED means the server is reachable but refused the connection: the port is closed or the web server is stopped. ERR_CONNECTION_TIMED_OUT indicates a network problem or a hard firewall block — the connection is not established at all. 502 Bad Gateway means nginx is working, but the application behind it is not.
The easiest way to diagnose is from the bottom up: first check whether the server responds over the network, then whether the required ports are open, then whether DNS is configured correctly, and only after that check the web server itself. This order saves time: if the server is not reachable over the network at all, there is no point searching for nginx configuration errors.
Step 1. Check the network connection to the VPS
Ping: is the server alive?
ping is the simplest way to verify that the server is physically reachable. The command sends ICMP packets to the server’s IP address and waits for a reply.
ping 203.0.113.45If replies come back, the server is online and reachable at the IP level. If you get a timeout or “Destination Host Unreachable,” then either the server is down or ICMP is blocked by a firewall. The second case is fairly common: many administrators intentionally disable ping. So no reply to ping does not necessarily mean the server is dead — you need to keep checking.
traceroute: look at the path to the server
traceroute (on Windows — tracert) shows the full packet route — which intermediate hops they pass through and where they stop. This is useful when ping does not respond and you need to understand where the problem appears.
traceroute 203.0.113.45Pay attention to the last lines. If the route breaks before reaching the server, the issue is somewhere in the provider’s network or the backbone. If packets reach the last hop but there is no reply, ICMP is blocked on the server itself. In practice, that is normal if the site still opens.
curl: check the HTTP response directly
The curl utility lets you check the server’s HTTP response without the browser’s cache and extensions. The -I flag requests only the headers, so the response comes back quickly without downloading the full page.
curl -I http://203.0.113.45If the server returns 200 OK, 301 Moved Permanently, or even 403 Forbidden, the web server is alive and responding. If curl hangs without a reply, port 80 is closed or the web server is not running. A 502 Bad Gateway response means nginx is running, but the application behind it is not.
Check the network interface from inside the server
If you have SSH access or access through the hosting provider’s web console, check the network interfaces from inside the server. After a reboot, the interface sometimes does not come up or receives the wrong IP.
ip addr showThe output should show an active interface — usually eth0, ens3, or something similar — in UP state with the correct public IP address. If the interface exists but has no address or is in DOWN state, you need to bring it up manually or fix the network settings. Make sure the IP matches what is shown in the hosting control panel.
Step 2. Check ports and the firewall
Why a closed port = an unavailable site
The web server accepts connections on specific ports: HTTP runs on 80, HTTPS on 443. Even if the server is physically reachable and nginx is running, the firewall can block incoming connections to those ports. The browser will not be able to connect, even though the server is alive. To the user, it looks like the server is turned off.
Check ports from the outside
The most reliable way is to check the port from another machine, not from the server itself. nmap is convenient for this. If you do not have the tool, online services such as portchecker.co or portscan.online will also work — they test the port from an independent external IP.
nmap -p 80,443 203.0.113.45The result will show one of three statuses. open — the port is open and listening. closed — the port is unavailable, no process is listening. filtered — the port is blocked by a firewall. The difference between closed and filtered matters: in the first case, the problem is in the web server; in the second, it is in the firewall.
Check open ports from inside the server
On the server, the ss command helps you see what is listening and which process owns it. The -tlnp flags show TCP listening ports with process names.
ss -tlnpIn the Local Address column, look for lines with ports 80 and 443. If there are none, the web server is not running or is listening on another port. Pay attention to the address itself: 127.0.0.1:80 means the server listens only locally and does not accept external connections. For a public site, it should be 0.0.0.0:80 or :::80.
Open the required ports in the firewall
If the port is listening but shows filtered from the outside, the firewall is blocking it. On Ubuntu and Debian, UFW is most commonly used; on CentOS and Rocky Linux, firewalld or iptables is often used directly.
Check and allow ports in UFW:
ufw status verbose
ufw allow 80/tcp
ufw allow 443/tcp
ufw reloadFor firewalld on CentOS and Rocky Linux:
firewall-cmd --list-all
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reloadKeep in mind that cloud providers often add an extra firewall layer at the infrastructure level — on top of the system firewall. If you rent a VPS on Serverspace, check the security group settings in the control panel: those rules work independently from UFW on the server itself. Both layers must allow the required ports.
Step 3. Check DNS
What DNS is and when it is actually to blame
DNS (Domain Name System) is a global system that translates domain names into IP addresses. When the browser requests example.com, it first asks DNS: “What IP belongs to this domain?” After receiving the answer, it connects to the server at that address. If DNS returns the wrong IP or does not reply at all, the site will not open even if the server works perfectly.
DNS problems usually show up in two scenarios. First: the site opens by direct IP, but not by domain name. Second: it works for some users, but not for others. This happens because of DNS propagation — a new term for an old phenomenon: after an A record changes, the new data gradually spreads across DNS servers around the world and can be cached anywhere from a few minutes to 48 hours.
Check DNS with nslookup
nslookup is the easiest tool for checking DNS records. It works on Windows, macOS, and Linux without installation.
nslookup example.comThe command returns the IP addresses the domain points to. Compare the returned IP with the real public IP of your VPS. If they match, DNS is configured correctly. If they do not, the A record points to another address or the changes have not propagated yet.
You can also specify which DNS server to query. This helps determine whether public resolvers see the correct records:
nslookup example.com 8.8.8.8Here 8.8.8.8 is Google’s public DNS. If it returns the correct IP while your local DNS still shows the old one, the problem is caching on your side. You can also check using 1.1.1.1 (Cloudflare): if both public servers return the correct IP, the zone has propagated normally.
dig: a detailed DNS record check
On Linux and macOS, dig is available — a more informative tool. It shows the full DNS response, including the record’s time to live (TTL) and the zone’s authoritative servers.
dig example.com A +shortThe answer should contain an A record with your server’s IP. The TTL (Time to Live) value affects how quickly changes propagate: with a TTL of 300 seconds, updates become visible in 5–10 minutes; with a TTL of 86400, the cache may hold it for a day. If you plan to change the IP, lower the TTL in advance, a few hours before the change.
What to check in the domain settings
If DNS returns the wrong IP, open your registrar’s or DNS provider’s control panel and check the A record. It should contain your VPS’s public IP. Do not confuse an A record with AAAA — the latter is for IPv6. If you use a www subdomain, check it separately: the A record for www.example.com may point to a different address. Sometimes the cause is simply an expired domain name — this is easy to check with whois:
whois example.com | grep -i expirStep 4. Check the web server
Make sure the service is running
If the network works, the ports are open, DNS points to the correct IP — but the site still does not open — the problem is in the web server itself. nginx or Apache may have crashed after a package update, due to a syntax error in the config, or because it ran out of memory.
Check nginx status:
systemctl status nginxCheck Apache:
systemctl status apache2If the service is stopped (status inactive or failed), try starting it and immediately check the latest log entries:
systemctl start nginx && journalctl -u nginx -n 50 --no-pagerCheck the configuration for errors
A common reason for a web server crash is a syntax error in the configuration file. Before starting it, it is worth validating the config: both nginx and Apache have built-in commands for this.
For nginx:
nginx -tFor Apache:
apachectl configtestIf there are errors in the config, the commands will point to the problematic file and the exact line. That makes troubleshooting much faster, especially when there are many config files spread across several directories.
Read the error logs
The web server logs are the main source of information during troubleshooting. nginx writes errors to /var/log/nginx/error.log, Apache to /var/log/apache2/error.log. To view the latest lines:
tail -n 50 /var/log/nginx/error.logLook for lines with crit, error, or alert levels. notice and info are informational and do not affect the site. The most common log errors are: permission denied (wrong file permissions), no such file or directory (incorrect path to the site root), upstream timed out (the application is not responding in time).
Diagnostic table: symptom — cause — solution
This summary table will help you quickly orient yourself by a specific symptom and understand where to look first.
| Symptom | Possible cause | What to check / do |
|---|---|---|
| ERR_NAME_NOT_RESOLVED | The DNS record is missing or points to the wrong IP | Check the A record with nslookup or dig |
| ERR_CONNECTION_REFUSED | The port is closed or the web server is not running | Check ss -tlnp and the nginx / Apache status |
| ERR_CONNECTION_TIMED_OUT | The firewall is blocking the port or the server is unreachable over the network | Check ufw / iptables, run ping and traceroute |
| Opens by IP but not by domain | DNS has not updated or the A record is wrong | Check DNS through public servers, wait for propagation |
| Works for some users | Incomplete DNS record propagation | Wait up to 48 hours, check via whatsmydns.net |
| 502 Bad Gateway | nginx is working, but the backend (PHP-FPM, Node, Gunicorn) has crashed | Check PHP-FPM, pm2, Gunicorn, and uwsgi status |
| 403 Forbidden | Incorrect permissions on the site files | Check the owner and chmod of files in the document root |
| HTTP opens, HTTPS does not | The SSL certificate was not issued, has expired, or is configured incorrectly | Check certbot certificates and the HTTPS config in nginx / Apache |
| No SSH access either | The server is down or the network is unavailable at the provider level | Use the hosting web console and check the VPS status in the panel |
| Empty response (white page) | The web server responds but does not know what to serve | Check the virtual host, document root, and whether an index file exists |
Three typical scenarios — and how to handle them
Scenario 1: The site worked, but stopped after a server reboot
One of the most common cases. After the VPS reboots, the web server does not start automatically — because autostart was not enabled. Check whether the systemd unit is set to start on boot:
systemctl is-enabled nginxIf the answer is disabled, enable autostart and start the service:
systemctl enable nginx && systemctl start nginxAlso check all dependent services: PHP-FPM, MySQL or MariaDB, Redis — if your application needs them. They should all have the enabled status so they start after reboot without manual intervention.
Scenario 2: A new site on a new domain does not open
If you have just created the A record and configured the server, the site may not open simply because DNS has not propagated yet. In practice, this takes anywhere from a few minutes to a few hours. To confirm that the A record is already visible in public DNS, use dig with an explicit resolver:
dig @1.1.1.1 example.com A +shortIf the IP is already correct, check whether port 80 is open on the server and whether the web server is running. New servers are often shipped with the firewall closed by default, and the virtual host for the domain must be created separately in the nginx or Apache config.
Scenario 3: The site does not open only over HTTPS
HTTPS requires a valid SSL certificate. If the certificate was not issued, has expired, or is configured incorrectly in the config, the browser will show a connection error. Check Certbot status:
certbot certificatesAn expired certificate is renewed with certbot renew --force-renewal. If the certificate is issued and valid, but HTTPS still does not work, check the nginx config: there must be a server block for port 443 that points to the correct certificate and private key file paths. Port 443 must also be open in the firewall at both levels — system and infrastructure.
Common mistakes during diagnosis
The first and most common mistake is making several changes at once. If the site starts working, it is impossible to know what actually fixed it. If things get worse, it is impossible to know what broke. Change one thing at a time and check the result after each step.
The second mistake is confusing the server IP with the IP the domain points to. Sometimes DNS is configured to point to the previous host’s address, while the site has already moved. Run nslookup and compare the returned IP with the one shown in the current VPS control panel.
The third is forgetting about two independent firewall layers. UFW on the server and the security group at the provider’s infrastructure level work separately. Even if UFW allows port 80, a rule in the control panel may block it — and vice versa. Both layers need to be checked.
The fourth is diagnosing only from your own browser. DNS cache, extensions, VPN, and corporate proxy settings can all distort the picture. For an independent check, use curl, nslookup with an external server, or online tools that test the site’s availability from an independent location.
The fifth is ignoring logs. Most people check them last, even though that is where the exact explanation is usually written: “permission denied,” “no such file,” “upstream timed out.” Logs are faster than guessing.
Limits of diagnosis and when support is needed
The tools described above cover most typical situations, but there are cases where self-diagnosis hits a wall. If traceroute shows packets are being lost before the server is reached, the problem is at the provider level or in its infrastructure, and in that case you will need to contact support. The same applies to complete loss of network connectivity: if the server does not ping, SSH is unavailable, and the web console in the panel also does not open, the machine is probably down or there is an incident on the data center side.
Another limitation is mirrored issues at the BGP routing level: the site is unavailable only from certain regions or autonomous systems, while it opens normally from others. Such cases are rare, but hard to diagnose on your own — tools such as BGP.tools or the provider’s Looking Glass are needed.
In such cases, it helps that a VPS on Serverspace is accessible through a web console even when SSH is completely unavailable — this lets you log into the server and begin diagnosing from the inside without waiting for support.
Conclusion
When a site on a VPS does not open, panic is a poor advisor. Most problems can be solved in 10–15 minutes if you work methodically. Start with the network: does the server ping, does traceroute reach it. Then check the ports: is 80 or 443 open, what does nmap show from the outside and ss from the inside. Then DNS: does the IP from nslookup match the server’s real address. And only after that check the web server itself: is it running, are there config errors, what do the logs say.
The commands ping, curl, ss, nslookup, dig, and systemctl status are the basic toolkit for diagnosing any availability problem. With them, you can handle most typical situations on your own without special knowledge or outside help.
FAQ
Use online services such as ping.eu, host-tracker.com, or downforeveryoneorjustme.com. They test availability from servers in different regions and return results in a few seconds — no extra software required.
It depends on the TTL value. With a TTL of 3600 seconds, changes usually spread in about 1–2 hours. With a TTL of 86400 (one day), the cache can persist for up to 48 hours. To speed things up next time, lower the TTL to 300–600 seconds in advance, a few hours before the change.
Most cloud providers offer a web console — direct access to the server from the browser, bypassing SSH. Through it, you can run any commands: check network status, start stopped services, and read error logs. If the console is also unavailable, the server is probably down and you should contact the hosting provider’s support.
Most likely, this is DNS propagation: your resolver already sees the new records, while other users’ DNS caches still hold the old ones. Check with dig using two public servers — 8.8.8.8 and 1.1.1.1. If both return the correct IP, the issue is caching for specific users and it will resolve on its own within a few hours.
Check three things. First — which address the web server is listening on: if it is 127.0.0.1, it accepts only local connections. Second — SELinux or AppArmor: they may prevent the web server from reading files or connecting to sockets. Third — the security group rules in the cloud provider’s control panel: the system firewall and the infrastructure firewall work independently.
Use whatsmydns.net — it shows which IP DNS servers around the world return for your domain. If all locations show the correct IP, propagation is complete. If some still return the old address, you need to wait.
