Quick answer: Work down the chain: does the domain resolve (dig)? To the right IP? Does the server answer (ping, curl -I)? Is the web server running and the firewall open? Each step isolates whether the problem is DNS, network, or the server itself.
Overview
“The site is down” has exactly four usual suspects: DNS, the network path, the web server, or the application. Checking them in order takes five minutes and tells you precisely where to dig deeper — or what to send support.
Before you start
- Your server's IP from the Client Area service page.
- SSH access to the server for the later steps.
Step-by-step guide
- DNS: does the name resolve, and to your server?
dig +short A example.comNo answer → NXDOMAIN troubleshooting. Wrong IP → fix the A record.
- Network: is the server reachable?
ping -c3 203.0.113.10
curl -I --connect-timeout 5 http://203.0.113.10- Ports & firewall (on the server via SSH or the Client Area KVM Console):
sudo ss -tlnp | grep -E ':80|:443'
sudo ufw status- Web server & app:
systemctl status nginx # or apache2
sudo tail -n50 /var/log/nginx/error.log- Fix what the failing step reveals: restart the service, open the port, correct the vhost's
server_name, or debug the application error.
Common issues
- Resolves + pings, but connection refused: web server not running or listening only on localhost.
- Times out only for you: your IP may be blocked by fail2ban/firewall — test from another network.
- Default page instead of your site: the vhost
server_namedoes not match the domain.
When to contact support
If step 2 fails from multiple networks (server unreachable) or you suspect a network issue on our side, open a ticket with your service ID, the domain, and the outputs above — it speeds diagnosis a lot.
Frequently asked questions
The domain resolves but the site does not load — what next?
Test the server directly: curl -I with the IP, then check on the server that the web service is running and ports 80/443 are open. That narrows it to firewall, service or app.
Why does my site work for some people and not others?
Usually DNS caches during a record change, or a firewall/fail2ban rule blocking specific source IPs. Compare dig answers from several resolvers and test from another network.
What should I include in a support ticket about a down site?
The domain, your service ID, when it broke, and outputs of dig, ping and curl -I. With those four items support can usually localize the problem in one pass.
Related articles
- How to troubleshoot DNS_PROBE_FINISHED_NXDOMAIN
- How to point a domain to Cloud2Y VPS
- How long does DNS propagation take?
- Common DNS mistakes
Need a hand? Contact Cloud2Y support →
