Every developer knows the sudden panic 😱 when a production website goes down. You immediately open your terminal, check your Git logs, and start questioning every line of code you wrote in the last 24 hours.
But today, I learned a valuable lesson: Sometimes, your code is 100% fine. The culprit is sitting right at the hosting infrastructure level.
Recently, my website went completely dark. Instead of guessing or changing my production files, I used 4 basic terminal commands to track down the exact problem. Here is the step-by-step breakdown of how I diagnosed it and why these commands are lifesaving for any developer.
Step 1: Check DNS Health
First, I needed to ensure that global DNS networks actually knew where my website was supposed to live.
Bash
dig myawesomesite.com +short
// Output: 192.0.2.1
- Why Use This: The dig command checks your domain's public DNS records. If it quickly returns your server’s correct A-record IP address, it means your domain pointing setup is working fine. The issue lies deeper in the network.
Step 2: Test Network Ports (The Red Flag)
Next, I tried to check the connection to the web traffic ports (Port 80 for HTTP and Port 443 for HTTPS).
Bash
curl -I -m 5 https://myawesomesite.com
// Output: curl: (28) Connection timed out after 5000 milliseconds
nc -z -v -w 5 myawesomesite.com 80
// Output: Operation timed out
- Why Use This: curl fetches website HTTP headers, and nc (Netcat) checks if a specific network port is open. Because both commands ended in a brutal "Connection timed out", it proved that outside traffic was being completely dropped or blocked before reaching my server space.
Step 3: Verify the Host Server Response
To see if the hosting provider's internal routing grid recognized my domain traffic, I passed my domain header directly to one of their central system nodes:
curl -I -H "Host: myawesomesite.com" -m 5 http://198.51.100.5
// Output: HTTP/1.1 301 Moved Permanently (Server: WebServer)
- Why Use This: This specific command tells you if the provider's server block acknowledges your website project. Getting a valid 301 Redirect gave me a massive clue: the hosting infrastructure was up and responsive, but something was explicitly blocking my main server IP.
Step 4: Test from the Inside Out (The Ultimate Proof)
To definitively prove whether my application code was broken or the host's firewall was blocking me, I used SSH to log directly into the backend server and tested the web environment locally.
Once inside the server terminal, I bypassed the external network completely and ran a local health check:
curl -I http://127.0.0.1
// Output: HTTP/1.1 403 Forbidden (Server: WebServer)
Why Use This: Calling 127.0.0.1 (localhost) triggers your web server internally, completely skipping the outside network firewall.
The Eureka Moment: The server instantly replied with a 403 Forbidden. In this situation, a 403 response is beautiful news! It proved that my backend web server was alive, running, and perfectly healthy inside the machine.
If my code or server configuration was broken, I would have received a Connection Refused error. Because it didn't, my code was officially proven innocent. The hosting provider's main network firewall was blocking outside web traffic to my hosting account.
🛠️ The Quick Resolution
The Fix:
I opened the support panel, bypassed the standard troubleshooting steps, and dropped this exact message to the support team:
"My website is timing out on ports 80/443. I checked via SSH, and LiteSpeed is running perfectly fine internally (getting a 403 on localhost). DNS is correct. It seems your main infrastructure firewall is dropping external web traffic to my account. Please clear the block."
Within minutes, the support system cleared the backend IP block, traffic flooded back in, and the site was instantly live.
💡 Summary for Developers
The next time your project goes down unexpectedly:
- Don't panic and rewrite your code.
- [ ] Check your DNS with dig And Don't Assume Your Hosting Provider is Flawless.
- Use nc to see if ports 80/443 are actually open.
- SSH inside and curl localhost.
Next time your site goes down, take a deep breath 😮💨, open your terminal, and test the network path before you start touching your codebase!
Has an automated server firewall ever trapped your project? Let me know your debugging horror stories in the comments below👇!
Top comments (0)