Troubleshooting Website Unavailability: A Four-Layer Diagnostic Approach

When a website is inaccessible, the most time-wasting approach is to randomly try multiple directions simultaneously—checking nginx, then the database, then suspecting DNS—ultimately failing to thoroughly investigate any single layer.

An efficient approach is layered localization: working from the outside in, eliminating issues one layer at a time. Each layer only needs to answer one question: “Is this layer broken?” If yes, dig deeper; if no, move immediately to the next layer. The key isn’t how many commands you know, but whether you can determine “this layer is functioning correctly.”

Four-Layer Structure and Criteria

Layer 1: DNS

# Resolve to which IP
dig +short example.com A
nslookup example.com

# Compare across regions (check for pollution/sync delays)
dig @8.8.8.8 example.com +short
dig @114.114.114.114 example.com +short

# Check remaining TTL
dig example.com | grep -i ttl

# Exclude local cache interference
ipconfig /flushdns        # Windows
systemd-resolve --flush-caches   # Linux

Verdict: If the resolved IP matches the target server’s public IP → This layer is fine, proceed. If resolution fails or the IP is incorrect → The issue is here.

# Typical DNS layer errors
** server can't find example.com: NXDOMAIN
curl: (6) Could not resolve host: example.com

Layer 2: Network & Ports

# Basic connectivity (Note: Some servers block ICMP; failure doesn't necessarily mean an issue)
ping -c 4 ServerIP

# Port connectivity — more reliable than ping
nc -zv ServerIP 80
nc -zv ServerIP 443

# Equivalent to telnet
telnet ServerIP 443

# Find where the route breaks
traceroute ServerIP
mtr ServerIP

Verdict: If nc shows succeeded → Network and ports are open. If timeout or refused:

• Timeout → Likely blocked by firewall/security group
• Refused → No service listening on the port (proceed to Layer 3)

Layer 3: Web Service

# Service status
systemctl status nginx
systemctl status httpd
systemctl --failed

# Check if port is listening
ss -lntp | grep -E ':80|:443'

# Configuration syntax (mandatory check after config changes)
nginx -t

# Error logs
tail -50 /var/log/nginx/error.log
journalctl -u nginx -n 50

# Typical Web layer errors
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Job for nginx.service failed because the control process exited with error code

Verdict: Process is running, port is listening, and nginx -t passes → Web layer is normal. If port is occupied or config errors occur → The issue is here.

Layer 4: Application

# php-fpm status
systemctl status php-fpm
tail -50 /var/log/php-fpm/www-error.log

# Database
systemctl status mysqld
mysqladmin ping

# Disk & inode — full disks cause various strange failures
df -h && df -i

# Memory (OOM kills processes, causing intermittent unavailability)
free -m
dmesg | grep -i oom

# Typical application layer errors
Error establishing a database connection
No space left on device
PHP Fatal error: Allowed memory size exhausted

Decision Tree

Website Unavailable
├─ Check if dig resolves correctly
│  └─ Incorrect/Failed    → DNS Layer: Fix resolution, wait for TTL, check for pollution
├─ Test port with nc
│  ├─ Timeout        → Firewall / Security Group blocking traffic
│  └─ Refused     → Proceed Down (Service not listening)
├─ Check Web Service with systemctl + ss
│  ├─ Not Started      → Run nginx -t to check config → Fix then start
│  ├─ Port Occupied  → Identify the occupying process
│  └─ Normal        → Proceed Down
└─ Application Layer
   ├─ 502         → php-fpm not started / process exhaustion / OOM
   ├─ 500         → Application code error → Check app logs
   ├─ DB Connection Error → MySQL down / Wrong credentials / Max connections reached
   └─ Disk Full      → Clean up (Use truncate instead of rm)

Scenario Walkthrough: When Everyone Has a Different Conclusion

Symptom: Feedback that “the website is down” at the same time. Some say it works, others say it doesn’t;
some suspect server downtime, others suspect domain expiration, and some think the program crashed.

1. Unify facts first: Clarify what “down” means → Ask the reporter for specific symptoms and status codes.
   Result: It’s a timeout, not a specific error code — timeouts point to link issues.
2. Check if domain resolution is normal → Resolution is normal and points to the expected address, ruling out domain-level issues.
3. Test network connectivity → Host is reachable, indicating the machine is not down.
4. Test if ports are accessible → Key dividing line: Web ports cannot establish connections.
   Host is reachable but ports are not, narrowing the scope to “link blocked” or “service not listening.” This step provides the most valuable judgment in troubleshooting.
5. Exclude control layers separately → Web service on the host is confirmed running,
   system firewall rules do not allow it; cloud platform security groups also do not allow the port.
6. Verify layer by layer after allowing access → Confirm recovery step-by-step: port, page status code, then actual content.

# 1. Resolution
dig +short example.com A

# 2. Is the host alive?
ping -c 2 TargetIP

# 3. Is the port accessible? (The most critical step)
nc -zv TargetIP 80 -w 3
nc -zv TargetIP 443 -w 3

# 4. Is the service listening?
ss -lntp | grep -E ':80|:443'

# 5. Is the page actually normal? (Check status code, not just accessibility)
curl -sS -o /dev/null -w '%{http_code}n' https://example.com/

Root Cause: Both the firewall and security group failed to allow the Web port, an oversight after configuration changes.
The real delay was caused by prior arguments — each party drew conclusions based on their own observations without following a unified exclusion sequence.

Two Key Takeaways:

• “Unavailable” must first be translated into specific phenomena: timeout, connection refused, or status code.
  These three point in completely different directions. Without unifying facts first, troubleshooting wastes time in cross-purposes.
• Follow the order: “Resolution → Host → Port → Service → Application,” using one command per layer.
  The value of the order lies in eliminating entire categories of possibilities at each step, rather than guessing.

8 Common Pitfalls

1. Judging server downtime by ping failure: Many environments block ICMP; ping may fail while the site works. Use port probing, not ping.
2. Not distinguishing between timeout and refused: These point to entirely different layers; mixing them leads you astray.
3. Skipping syntax checks after config changes: nginx -t is zero-cost; skipping it is gambling.
4. Only checking Web logs, not application logs: The cause of a 502 is in the php-fpm log, not the nginx log.
5. Ignoring disk and inode usage: Full disks cause seemingly unrelated failures. Checking df -h and df -i takes only 10 seconds.
6. Forgetting about OOM: Intermittent unavailability with auto-recovery? Check dmesg first.
7. Misleading local DNS cache: Just because you can open it doesn’t mean others can; compare using public DNS.
8. Checking from scratch when multiple layers have issues: This is correct. After fixing one layer, you must re-test; don’t assume the rest are fine.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (providers include our store and competitors, provided for reference only, not fictional tickets from this site):

10***77 2022-09-19 5.0 Affordable Price | Skilled Tech | Patient & Professional Received filing rectification notice, found this service正好, handled quickly 10***49 2022-04-12 5.0 On-time Delivery | Affordable Price | Skilled Tech Needed rectification, fast configuration, good

b****4 Rating: 5.0 Points 2025-06-23 16:57 b****4 Rating: 5.0 Points 2025-06-23 16:56 Jian****Wei Rating: 5.0 Points 2021-01-20 15:03 Technology is awesome! Speed is very fast! Originally Baidu global hijacking caused by a trojan!!!!!! 1 f****u Rating: 5.0 Points 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 Points 2020-11-20 10:03 Consistently good service as always 1****1 Rating: 5.0 Points 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 Points 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 Points 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 Points 2020-07-24 09:49 Many thanks! 1