When a site "is down", the cause can be DNS, the route between you and the server, a firewall, or the application itself. Six small tools let you test each layer in turn, so you can fix the problem yourself or send support exactly the evidence they need.
Before you start
- A terminal: Command Prompt or PowerShell on Windows, Terminal on macOS and Linux.
- The domain and, if you know it, the server IP (shown in cPanel under General Information).
- Your own public IP from /tools/ip-checker, in case a firewall blocked you.
Tip: Work from the bottom up: DNS → reachability → route → port → HTTP. The first test that fails tells you where the problem is.
Check DNS with nslookup or dig
First confirm the domain points where you expect. nslookup is built into Windows and macOS:
nslookup example.comOn macOS and Linux, dig gives cleaner output. Ask a public resolver and the authoritative nameserver to compare:
dig +short example.com A
dig +short example.com A @1.1.1.1
dig +short NS example.comIf the answers differ, a recent change is still propagating (see DNS propagation and TTL). If there is no answer at all, check the zone in cPanel Zone Editor and the domain's nameservers.
Test reachability with ping
ping -c 10 example.comOn Windows use ping -n 10 example.com. Read three things: whether replies arrive, the average time (latency in milliseconds) and the packet loss percentage. Some servers and firewalls block ICMP, so no ping reply does not prove the server is down; continue with the port test. What counts as good latency is covered in what is latency.
Follow the route with traceroute or mtr
traceroute example.comOn Windows the command is tracert example.com. Each line is a router (hop) on the way. Rows of * * * in the middle are normal when routers do not answer traceroute; stars that start at one hop and continue to the end suggest the path breaks there. For a far better picture, run mtr and read it with how to read an MTR report.
Test a port with telnet, nc or PowerShell
Ping can work while the service port is blocked. Test the exact port:
nc -zv example.com 443On Windows PowerShell:
Test-NetConnection example.com -Port 443Classic telnet example.com 25 still works where installed and is handy for mail servers, because you see the SMTP banner. "Connection refused" means nothing listens; a timeout means a firewall drops the traffic. Common port numbers are in common server ports.
Check the HTTP response with curl
curl -I https://example.comThe first line shows the status code (200 OK, 301/302 redirect, 403 forbidden, 500/503 server error). To bypass DNS and test a specific server IP, which is useful before switching DNS or behind a CDN:
curl -I --resolve example.com:443:203.0.113.25 https://example.comFor timing details:
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.comWhat the results tell you
| Symptom | Likely cause |
|---|---|
| DNS returns no answer or the wrong IP | DNS records or nameservers |
| Port times out from your network only | Your IP is blocked by the server firewall, or your network blocks the port |
| Port times out from everywhere | Service down or firewall closed on the server |
| Port open, curl shows 5xx | Application or web server error: check error logs |
| Everything works but slowly | Latency, packet loss or slow application (compare curl timings) |
Troubleshooting
- Only you cannot reach the site: try mobile data. If it works there, your IP is probably blocked; see unblock an IP in Imunify360 or cPanel IP Blocker.
- curl shows an SSL error: the certificate may be missing or the hostname wrong; run the HTTPS checks after SSL is issued.
Still stuck? Open a ticket and paste the output of these commands with your public IP.