How to Fix Slow & Unreachable Websites: Complete Guide to

“Hey, my website is down! I keep getting errors every time I try to access it!”

It was 9 AM. I was still sipping my first coffee when my phone rang. A shared hosting customer was panicking — their company profile website was showing a blank white page right before a client presentation. They had 30 minutes to fix it.

I opened my laptop and started checking from the server side: DNS resolution, service status, firewall logs. Everything was fine — nginx running, PHP-FPM active, disk space clear, LVE stats normal. After a 20-minute phone call, we found the issue: the customer was on office Wi-Fi that blocked port 443. The server was fine. Their office network was the bottleneck. They only realized it when I told them to tether via mobile data — and the site loaded instantly.

That case taught me something important: 90% of “slow website” or “unreachable” complaints aren’t server issues. The problem lies somewhere between the server and the user — DNS, routing, local firewall, ISP. But many junior NOC engineers still panic and rush to restart servers before even checking the user side.

This article is written specifically for you — the junior technician or NOC engineer who often doesn’t know where to start when a customer reports “slow website” or “can’t access.” We’ll cover everything from A to Z: how to read ping and traceroute results, what questions to ask customers, and how to determine whether the issue is on the server side or the user side. It’s long, but it’s worth every word.

Difficulty: Beginner — Intermediate
Last Updated: July 2026
Tested On: cPanel/WHM + CloudLinux, CSF, Imunify360, ModSecurity, VPS Linux (Ubuntu/Debian/CentOS), VPS Windows (Hyper-V/KVM)

Complaint Types: “Slow Website” vs “Unreachable” — Know the Difference First

Before you start troubleshooting, you need to know the difference between these two complaints because the approach to fixing them is completely different:

1. “Slow Website” (Slow Loading)

The customer can reach the site, but it takes forever to load — 5 seconds, 10 seconds, or more. Sometimes images don’t render, CSS/JS don’t load, and pages render half-finished.

Possible causes:

• High server resources (CPU/RAM/Disk I/O)
• The customer’s website is heavy (too many plugins, large images, slow queries)
• PHP workers exhausted (max_children reached)
• CloudLinux LVE throttle (CPU/RAM/IO limits hit)
• High database load (MariaDB slow queries)
• User’s connection to server has high latency
• CDN not active or misconfigured

2. “Unreachable” (Connection Refused / Timeout)

The website can’t be accessed at all — showing errors like “This site can’t be reached”, “Connection timed out”, “ERR_CONNECTION_REFUSED”, or even a blank white page.

Possible causes:

• DNS not propagated or pointing to wrong IP
• Server down / service stopped (nginx/apache crash)
• Firewall blocking user’s IP (CSF/Imunify360 block)
• SSL/TLS error (expired certificate, misconfiguration)
• ModSecurity blocking user’s request
• Network routing issues (tracert fails at a certain hop)
• Port closed (port 80/443 not open)
• Bandwidth quota exhausted
• Account suspended (cPanel suspend due to abuse/non-payment)

How to Read PING Results — What “Good” and “Bad” Mean

Ping is the most basic connectivity test between a user’s computer and your server. This is the first thing you should ask customers to run when they complain.

How to Ask Customers to Ping

Give these instructions to customers (or run from your SSH server):

From customer’s computer (Windows):

ping yoursite.com -t

From customer’s computer (Linux/Mac):

ping yoursite.com -c 20

From your server to customer’s IP (if available):

ping [CUSTOMER_IP] -c 10

How to Read Ping Results

✅ Good Ping Result (Normal)

Pinging example.com [103.56.123.45] with 32 bytes of data:
Reply from 103.56.123.45: bytes=32 time=12ms TTL=54
Reply from 103.56.123.45: bytes=32 time=11ms TTL=54
Reply from 103.56.123.45: bytes=32 time=13ms TTL=54
Reply from 103.56.123.45: bytes=32 time=12ms TTL=54

Ping statistics for 103.56.123.45:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Round trip min/avg/max = 11/12/13ms

What to look for:

• time=12ms → Normal latency. For domestic servers: 5-50ms is good. For international servers: 50-200ms is acceptable
• Lost = 0 (0% loss) → No packet loss. Connection is stable
• TTL=54 → Time To Live — indicates number of hops traversed. Low TTL (10-30) could mean many hops or packets being dropped en route

❌ Bad Ping Result (Packet Loss)

Pinging example.com [103.56.123.45] with 32 bytes of data:
Reply from 103.56.123.45: bytes=32 time=12ms TTL=54
Reply from 103.56.123.45: bytes=32 time=11ms TTL=54
Request timed out.
Reply from 103.56.123.45: bytes=32 time=145ms TTL=50
Request timed out.
Request timed out.
Reply from 103.56.123.45: bytes=32 time=230ms TTL=48

Ping statistics for 103.56.123.45:
    Packets: Sent = 6, Received = 3, Lost = 3 (50% loss),
Round trip min/avg/max = 11/129/230ms

What it means:

• 50% loss → Half the packets are lost en route. Website will be very slow or timeout
• time=230ms → Latency spiked from 12ms to 230ms. Network disruption present
• TTL varies (48-54) → Different routes being taken, possibly load balancing or unstable routing

❌ Bad Ping Result (Total Timeout)

Pinging example.com [103.56.123.45] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 103.56.123.45:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

What it means:

• 100% loss → No connectivity to the server at all. Could be firewall blocking, server down, or routing failure
• But don’t conclude “server down” immediately! The user’s firewall (Windows Defender, office firewall) might be blocking ICMP (ping protocol)

⚠️ Special Case: “Destination Host Unreachable”

Pinging example.com [103.56.123.45] with 32 bytes of data:
Reply from 192.168.1.1: Destination host unreachable.

What it means: The user’s local router/gateway doesn’t know the route to the server’s IP. This is a user-side issue — usually wrong DNS or gateway problem.

How to Read TRACERT/TRACEROUTE — Finding Where the Problem Is

If ping shows issues, the next step is traceroute. It shows every hop (transition point) that data packets traverse from the user’s computer to your server.

How to Run Traceroute

Windows:

tracert yoursite.com

Linux/Mac:

traceroute yoursite.com

How to Read Traceroute Results

✅ Good Traceroute (All Hops Normal)

Tracing route to example.com [103.56.123.45] over a maximum of 30 hops:

  1    <1ms    <1ms    <1ms  192.168.1.1      ← Local gateway (Wi-Fi router)
  2     8ms     7ms     8ms  10.10.10.1       ← ISP backbone
  3    12ms    11ms    12ms  172.16.0.1       ← ISP regional
  4    18ms    17ms    18ms  203.0.113.1      ← ISP international peering
  5    25ms    24ms    26ms  198.51.100.1     ← Transit provider
  6    35ms    33ms    36ms  103.56.123.45    ← Destination server ✅

Trace complete.

What to look for:

• All hops respond (no asterisks ***)
• Times between hops are reasonable (no huge jumps from 10ms to 500ms)
• Destination is reached (last hop = server IP)

❌ Bad Traceroute — Missing Hops (Asterisks ***)

Tracing route to example.com [103.56.123.45] over a maximum of 30 hops:

  1    <1ms    <1ms    <1ms  192.168.1.1      ← Local gateway OK
  2     8ms     7ms     8ms  10.10.10.1       ← ISP backbone OK
  3    12ms    11ms    12ms  172.16.0.1       ← ISP regional OK
  4     *       *       *     Request timed out.  ← Issue here!
  5     *       *       *     Request timed out.
  6    85ms    83ms    86ms  103.56.123.45    ← But still reaches destination

Trace complete.

What it means:

• Hops 4 and 5 don’t respond — but this isn’t necessarily a problem. Many routers are configured not to reply to ICMP (anti-DDoS policy)
• The key question: can the last hop (destination) be reached? If yes, the connection likely still works even though intermediate hops are “invisible”
• Compare times at hop 3 vs hop 6: if there’s a big jump (e.g., 12ms → 85ms), the latency issue is on the transit path, not your server

❌ Bad Traceroute — Latency Spike at a Specific Hop

  1    <1ms    <1ms    <1ms  192.168.1.1
  2     8ms     7ms     8ms  10.10.10.1
  3    12ms    11ms    12ms  172.16.0.1
  4   320ms   315ms   325ms  203.0.113.1      ← SPIKE! 12ms → 320ms!
  5   325ms   320ms   330ms  198.51.100.1
  6   335ms   330ms   340ms  103.56.123.45

What it means:

• Dramatic spike from hop 3 (12ms) to hop 4 (320ms) → the issue is at the transit provider or peering between the ISP and international backbone
• This is beyond your server’s control. The customer needs to contact their ISP
• How to confirm: run a traceroute from your server to the customer’s IP — if latency is normal from the server side, it’s definitely the customer’s ISP path

❌ Bad Traceroute — Total Failure (Destination Unreachable)

Tracing route to example.com [103.56.123.45] over a maximum of 30 hops:

  1    <1ms    <1ms    <1ms  192.168.1.1
  2     8ms     7ms     8ms  10.10.10.1
  3    12ms    11ms    12ms  172.16.0.1
  4     *       *       *     Request timed out.
  5     *       *       *     Request timed out.
  ...
 30     *       *       *     Request timed out.

Trace complete. Destination not reached.

What it means:

• Packets never reach the server. Most likely port 80/443 is closed on the server, or firewall is blocking the route to that IP
• Or: DNS resolved to a wrong IP (old server IP, not yet updated)
• Next steps: check DNS, check firewall rules, check if port is open from customer’s IP

Required Questions for Customers — Guide for Junior NOC

This is the most critical section. Many junior NOC engineers jump straight to the server without gathering information from the customer first. Result? Troubleshooting takes 2-3x longer because they keep going back and forth asking questions.

Print or bookmark this checklist and use it every time a complaint comes in:

Basic Questions (Must Ask)

1. “Can you access it from a different device?”
   • From your phone on mobile data? From another computer on a different network?
   • Purpose: Determine if the issue is specific to one device or all of the customer’s devices
2. “What network are you on — office Wi-Fi, home Wi-Fi, or mobile data?”
   • Office Wi-Fi often blocks certain ports or uses proxies/filters
   • Purpose: Identify if the local network is the problem
3. “What exactly does the error say? Can you send a screenshot?”
   • “This site can’t be reached” ≠ “Connection timed out” ≠ “ERR_CONNECTION_REFUSED” ≠ “503 Service Unavailable” ≠ “403 Forbidden”
   • Purpose: Specific error messages directly point to different root causes
4. “Try clearing your browser cache first, then reload. Still error?”
   • Browser cache often stores old versions or expired redirects
   • Purpose: Eliminate local cache issues before deeper troubleshooting
5. “Try opening in an incognito/private window. Same result?”
   • Eliminates the influence of browser extensions that might block content
   • Purpose: Rule out browser extension interference

Advanced Questions (If Basics Check Out)

6. “Can you run this command in Command Prompt/Terminal?”

   ping example.com -n 10

   Then ask them to copy-paste the results. This is the raw data you need for analysis

7. “When did it last work, and when did it start failing?”
   • Could be: just installed SSL but not propagated yet, just updated DNS, just migrated server
   • Purpose: Timeline helps identify the trigger
8. “Who built the website? What CMS is it running?”
   • WordPress? Custom? Static HTML? Joomla? Magento?
   • WordPress with 50 plugins on shared hosting = recipe for slowness
   • Purpose: Evaluate whether the customer’s own website is resource-heavy
9. “From your phone using mobile data (not Wi-Fi), can you open it?”
   • This is the fastest test to determine if the issue is on the customer’s network or the server
   • Purpose: Quick test — if it works on mobile data, the problem is almost certainly the customer’s local network

Template Message for Customers

Copy-paste this into your chat/email with the customer:

Hi [Customer Name],

Thanks for reporting. To help me diagnose faster, could you please:

1. Screenshot the error message
2. Run this in Command Prompt (Windows) or Terminal (Mac/Linux):
   ping yoursite.com -n 10
   Then copy-paste the results here
3. Try opening the website from your phone using mobile data (turn off Wi-Fi first)
4. Try opening it in an incognito/private browser window

The results will really help me identify the issue faster.

Thank you!

Server-Side Troubleshooting: Shared Hosting (cPanel/CloudLinux)

After gathering customer data, it’s time to check from the server side. Here’s a comprehensive guide for shared hosting environments.

1. Check Account Status (Most Common Issue!)

# Via WHM: List Accounts
# Find customer's domain, check status

# Via SSH:
cd /var/cpanel/users/
cat [username].yaml | grep -i suspend

Common reasons for account suspension:

• Bandwidth quota exceeded
• Inode quota exhausted (too many files)
• Disk space full
• Malware/abuse detected
• Payment overdue

Check via WHM:

WHM → Account Information → List Accounts
→ Find customer's domain
→ Check columns: Status, Bandwidth, Disk Usage

Check via SSH:

# Check bandwidth usage
cat /var/cpanel/bandwidth/[username].bytes

# Check disk usage
du -sh /home/[username]/

# Check inode count
find /home/[username] -maxdepth 1 -type f | wc -l

2. Check CloudLinux LVE Limits

CloudLinux can limit resources per account. If a customer exceeds CPU/RAM/IO limits, their website becomes very slow or times out.

# Via WHM: LVE Manager
# WHM → CloudLinux → LVE Manager → View Usage

# Via SSH: check LVE stats
lvetop

# Or check usage per user:
cat /var/lve/cloudlinux.db

Signs of LVE throttling:

• CPU Usage: 100% → website slow, PHP execution timeout
• Memory Usage: max → OOM killer, PHP-FPM crash
• IOPS: max → disk read/write slow, database slow queries
• EP (Entry Processes): max → Apache slots exhausted, 503 error

3. Check PHP-FPM Status

# Check PHP-FPM service status
systemctl status lsphp81-fpm.service

# Check active processes
ps aux | grep lsphp

# Check PHP error log
cat /home/[username]/logs/php.error.log | tail -50

# Check PHP-FPM pool status (if enabled)
curl http://localhost/status/php-fpm

Common PHP performance issues:

• max_children too low (default 5, increase to 25-50 depending on RAM)
• PHP memory_limit too low (default 128M, WordPress typically needs 256M+)
• OPcache not enabled (should be on)
• WordPress with many plugins = many PHP execution cycles

4. Check CSF Firewall

# Check if customer's IP is blocked
csf -g [CUSTOMER_IP]

# Check deny list
cat /etc/csf/csf.deny | grep [CUSTOMER_IP]

# Check temporary bans
cat /var/lib/csf/csf.tempban

Common case: Customer uses dynamic IP that was once brute-forced → IP enters temporary ban → website inaccessible from that IP

5. Check Imunify360

# Check if IP is blocked by Imunify360
cat /var/imunify360/event.log | grep [CUSTOMER_IP] | tail -20

# Via Imunify360 UI (cPanel plugin)
# Login to customer's cPanel → Imunify360 → Firewall

6. Check ModSecurity

# Check ModSecurity error log
cat /usr/local/apache/logs/error_log | grep "ModSecurity" | tail -20

# Check blocked rules
grep "ModSecurity" /usr/local/apache/logs/error_log | grep -o "id [0-9]*" | sort | uniq -c | sort -rn | head -10

How to disable ModSecurity for a specific domain:

# Via WHM: 
# WHM → Security → ModSecurity → Manage Vendors
# or
# WHM → ModSecurity → Enable/Disable per domain

7. Check DNS Resolution

# From server, check if DNS resolves correctly
dig [domain.com] +short
# Should output the server's IP

dig [domain.com] A +noall +answer
# Check TTL — very low TTL (e.g., 300 or less) means recently updated

# Check DNS from external server
dig @[8.8.8.8] [domain.com] +short
# Use Google DNS to verify

8. Check Service Status

# Check web server
systemctl status nginx
systemctl status lshttpd

# Check MySQL/MariaDB
systemctl status mariadb
mysqladmin status

# Check PHP-FPM
systemctl status lsphp*  # (could be lsphp74-fpm, lsphp80-fpm, lsphp81-fpm)

# Check cPanel services
systemctl status cpanel
systemctl status dovecot
systemctl status exim

Server-Side Troubleshooting: VPS & Dedicated Server

For VPS, you have full control. Here’s the comprehensive guide:

1. Check Server Resources (Disk Space, RAM, CPU)

# Check disk usage
df -h
# Check: any partition above 85%? That could be the cause

# Check RAM
free -m
# Check: is available RAM low (< 100MB)?

# Check CPU load
top -bn1 | head -15
# Or clearer:
uptime
# Load average 15.00 (above CPU core count) = overloaded

# Check disk I/O
iotop
# Or:
dstat -td --disk-util 5

2. Check Network & Ports

# Check open ports
netstat -tulpn | grep -E ":80|:443|:21|:22|:3306"

# Check if port 80 and 443 are listening
ss -tlnp | grep -E ":80|:443"

# Check firewall (iptables)
iptables -L -n -v | head -50

# Check if any block exists for specific IP
iptables -L -n | grep [CUSTOMER_IP]

# Check from outside if port is open
# From another computer:
telnet [SERVER_IP] 80
telnet [SERVER_IP] 443

3. Check Web Server Logs

# Nginx access log
tail -100 /var/log/nginx/access.log | grep [domain.com]

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache access log
tail -100 /usr/local/apache/logs/access_log | grep [domain.com]

# Apache error log
tail -50 /usr/local/apache/logs/error_log

# Check error patterns
grep "503|502|500|403" /var/log/nginx/access.log | tail -20

4. Check DNS from Server

# Check if DNS points to this server
dig [domain.com] +short
# Should be: this server's IP

# Full dig
dig [domain.com] +noall +answer

# Check for DNS issues
dig [domain.com] @1.1.1.1 +short
dig [domain.com] @8.8.8.8 +short
# Compare — should be the same

5. Check Service Status

# Nginx
systemctl status nginx

# Apache
systemctl status httpd  # or apache2

# MariaDB/MySQL
systemctl status mariadb

# PHP-FPM
systemctl status php-fpm

# cPanel (if using)
systemctl status cpanel
systemctl status named    # DNS
systemctl status dovecot  # Email
systemctl status exim

6. Check SSL Certificate

# Check SSL expiration
openssl s_client -connect [domain.com]:443 2>/dev/null | openssl x509 -noout -dates

# Check Let's Encrypt status
certbot certificates

# Check if certificate is valid
echo | openssl s_client -connect [domain.com]:443 2>/dev/null | grep "Verify return code"

7. Specifically for Windows VPS

# Via PowerShell:
# Check IIS status
Get-Service W3SVC

# Check listening ports
netstat -an | findstr "80"
netstat -an | findstr "443"

# Check firewall
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} | Select DisplayName, Direction, Action

# Check disk space
Get-PSDrive C | Select Used, Free, @{N="UsedGB";E={[math]::round($_.Used/1GB,2)}}

# Check event log for errors
Get-WinEvent -LogName Application -MaxEvents 20 | Select TimeCreated, Message

Decision Table: Common Causes, Symptoms, and Solutions

For Shared Hosting (cPanel + CloudLinux)

Cause	Symptom	Solution
Account suspended	“This account has been suspended” or “Site suspended” page	Unsuspend via WHM → List Accounts → Unsuspend. Check reason first (bandwidth, abuse, payment)
LVE CPU throttle	Very slow website (10-30 sec), but 200 status	LVE Manager → Usage → increase CPU limit or adjust weight
Apache slots full (503)	503 Service Unavailable, errors during peak hours	Increase max_spare_servers or EP limit in LVE Manager
Inode exhausted	Can’t upload files, email bounce “Disk quota exceeded”	Clean cache, old files, large logs. Increase inode quota if needed
Disk space full	Email bounce, 500 errors, database can’t write	Clean /tmp, /home/[user]/logs, cache. Increase disk quota
PHP max_children exhausted	Website timeout, but server load normal	Increase max_children in PHP-FPM config (per-account or global)
ModSecurity block	403 Forbidden on specific pages (usually admin panel)	Check ModSecurity error log → disable rule for specific path or disable per domain
CSF/Imunify360 IP block	Website accessible from other networks, but NOT from customer’s network	Whitelist customer’s IP in CSF: csf -a [IP]
SSL expired	“Your connection is not private”, “NET::ERR_CERT_DATE_INVALID”	Renew SSL via cPanel → SSL/TLS, or via WHM → AutoSSL
DNS not yet propagated	Website works on some networks but not others	Wait for propagation (usually 24-48 hours), or use Google DNS on user side: 8.8.8.8
Heavy WordPress plugins	Slow from admin panel, but server resources normal	Disable plugins one by one to find bottleneck. Consider caching plugins
Malware/Abuse	Account auto-suspended, email notification from Imunify360	Scan malware → remove → hardening → request unsuspend

For VPS & Dedicated Server

Cause	Symptom	Solution
Web server down (nginx/apache crash)	Connection refused, website inaccessible from everywhere	systemctl status nginx → check error → restart → find crash cause in error log
Firewall blocks port 80/443	SSH works, but website times out externally	iptables -L -n → check for DROP rule on port 80/443 → open firewall
Disk space 100% full	All services error, can’t write, MySQL crash	df -h → du -sh /var/log/* → clean log/cache → add disk
DNS pointing wrong	Website works on some networks but not others	dig [domain] +short → compare with server IP → update DNS at registrar
SSL/TLS misconfiguration	“SSL_ERROR_RX_RECORD_TOO_LONG” or “ERR_SSL_PROTOCOL_ERROR”	nginx.conf → check listen 443 ssl → ensure certificate exists with correct path
PHP-FPM down	502 Bad Gateway (nginx + php-fpm), or blank website	systemctl status php-fpm → restart → check PHP error log
MySQL/MariaDB down	“Error establishing a database connection”	systemctl status mariadb → check error log → restart
DDoS attack	CPU 100%, bandwidth spike, all websites slow	CentOS: netstat -an | grep :80 | wc -l → check attacker IPs → rate limit in nginx or iptables
Kernel panic / OOM killer	Server restarts suddenly, all websites down momentarily	Check /var/log/kern.log or dmesg → add RAM or reduce services
NTP time desync	SSL errors, cron not running on time, log timestamps wrong	timedatectl → ensure NTP sync → systemctl restart chronyd

Troubleshooting Workflow — Step by Step for Junior NOC

This is the flowchart you can follow from start to finish. Bookmark this page — you’ll need it often when complaints arrive.

Step 1: Collect Data from Customer

1. ✅ Error screenshot
2. ✅ Results of ping [domain] -n 10
3. ✅ Test from mobile data (not Wi-Fi)
4. ✅ Test from incognito browser window
5. ✅ When did it start?

Step 2: Quick Check from Server Side

1. ✅ Service status (nginx/apache, mysql, php-fpm)
2. Disk space (df -h)
3. RAM usage (free -m)
4. CPU load (uptime)
5. Port listening (ss -tlnp | grep -E ":80|:443")

Step 3: Check from Outside (External Check)

1. ✅ Ping from server to customer’s IP (if available)
2. ✅ Traceroute from server to customer’s IP
3. ✅ curl -I https://[domain] from server
4. ✅ Check DNS from Google DNS: dig @[8.8.8.8] [domain]

Step 4: Check Firewall & Security

1. ✅ CSF deny list: csf -g [CUSTOMER_IP]
2. ✅ Imunify360 block log
3. ✅ ModSecurity error log
4. ✅ IPtables rules: iptables -L -n | grep [IP]

Step 5: Check Account-Specific (Shared Hosting Only)

1. ✅ Account status (suspended? quota exceeded?)
2. LVE usage (CPU/RAM/EP/IO)
3. PHP error log
4. cPanel feature status

Step 6: Diagnosis & Solution

1. Compare all collected data
2. Determine: issue on server, network, or user side?
3. Apply solution based on root cause
4. Verify: ask customer to test again
5. Document: record this case for future reference

Pro Tips from the Field

1. Always test from mobile data first. This is the fastest and most effective test. If it works on mobile data, the issue is almost certainly the customer’s local network.
2. Don’t restart the server immediately. Restarting is the “nuclear option” — it erases all diagnostic evidence. Always collect data first before restarting.
3. Document every case. Create a spreadsheet or document: case → cause → solution → resolution time. This is your “knowledge database.” It’ll be invaluable 6 months from now.
4. Memorize HTTP error codes. 200 OK, 301 redirect, 403 forbidden, 404 not found, 500 internal error, 502 bad gateway, 503 service unavailable — each number has a specific meaning.
5. Panicked customers need extra patience. Speak calmly, give clear numbered steps (1, 2, 3), and provide progress updates. Communication is more important than technical skills.
6. Use the “divide and conquer” technique. If there are 10 possible causes, don’t check them all at once. Eliminate one by one — it’s more efficient.
7. New domains vs old domains get different treatment. New domains: check DNS propagation first. Old domains: check for recent changes (DNS update, SSL renewal, migration).
8. If the customer uses a VPN, ask them to disable it first. VPNs can change routing and cause websites to be inaccessible even when the server is fine.
9. Don’t forget to check server timezone. Logs with wrong timestamps make diagnosis even more confusing.

FAQ

1. What’s the difference between “Connection Timed Out” and “Connection Refused”?

Connection Timed Out: Packet is sent but no response within timeout period. Causes: firewall blocking, server down, or routing failure. Connection Refused: Server is active and responding, but actively rejecting the connection. Causes: service not running on that port (e.g., nginx not listening on port 443) or server firewall actively refusing.

2. Why does the website work on mobile data but not on office Wi-Fi?

Office Wi-Fi usually uses a firewall/proxy that blocks certain ports (e.g., port 443, 25, or non-standard ports). Or the office DNS cache might still point to an old IP. Ask the customer to test on mobile data — if it works, the problem is their office network.

3. If ping results are good but the website is still slow, why?

Ping only tests basic network connectivity (ICMP). A website can be slow due to: long PHP execution time (many plugins), slow database queries, server resources (CPU/RAM) at their limit, or heavy content (uncompressed large images). Ping doesn’t measure HTTP service quality.

4. How do I check if DNS has propagated?

Use online tools like dnschecker.org or run dig [domain] @8.8.8.8 and dig [domain] @1.1.1.1 from multiple locations. If all show the correct IP, propagation is complete. Low TTL (e.g., 300 or less) indicates DNS was recently updated.

5. Does restarting nginx/apache always solve the problem?

No. Restarting only temporarily fixes issues if the root cause is memory leak, stuck process, or config reload. But restarting doesn’t solve: full disk, wrong DNS, firewall blocks, or a website that’s inherently heavy. Always find the root cause before restarting.

6. Why can I access the website from the command line but the customer can’t from their browser?

Because you’re accessing from the server’s IP directly (localhost or internal IP), which bypasses external firewall, DNS resolution, or network routing. Always test from a different IP/user for accurate results.

7. What does “ERR_CONNECTION_RESET” mean?

The server forcibly closed the connection before the transfer completed. Usually caused by: firewall blocking mid-transfer, SSL/TLS handshake failure, or server crash during the request. Check the web server error log for details.

Related Articles

• How to Fix Apache Slot Full (503 Service Unavailable)
• Troubleshoot High Database Load in MariaDB
• How to Fix High CPU Interrupts (240961/s) in cPanel CloudLinux
• Detect LiteSpeed WebServer Slot Full
• Install Netdata on Linux Server for Real-Time Monitoring
• Update PHP on CloudLinux with yum groupupdate alt-php
• Detect & Delete Email Spam on cPanel Server via Exim

Conclusion

“Slow website” or “unreachable” complaints are among the most frequent cases a NOC engineer handles — but also the most frequently misdiagnosed. The key is: don’t panic, collect data first, and start from the user side before checking the server.

By understanding how to read ping and traceroute results, knowing what questions to ask customers, and recognizing the characteristics of each environment (shared hosting cPanel/CloudLinux, Linux VPS, Windows VPS), you can resolve 90% of complaints in under 30 minutes — without restarting servers or panicking and asking senior engineers for help.

Save this article as a reference. Bookmark it. Open it every time a complaint comes in. Over time, you’ll start recognizing patterns and can jump straight to solutions without re-reading from the beginning. And most importantly: document every case you handle — that’s the “best professor” you won’t find in any classroom.

Author: NOC Engineer — Syslog Solutions
Credentials: 5+ years handling shared hosting and VPS customer complaints. Specializing in network troubleshooting, server hardening, and incident response for cPanel/WHM + CloudLinux environments.