Cara Mengatasi Website Lambat & Gagal Diakses: Panduan

“Mas, website saya kok nggak bisa diakses? Sudah saya buka berkali-kali, bolak-balik error terus!”

Percakapan jam 9 pagi itu seharusnya masih di meja kopi. Tapi HP saya sudah berdering. Seorang pelanggan shared hosting komplain website-nya tidak bisa diakses. Suaranya panik — dia lagi presentasi ke klien, dan website profil perusahaannya yang biasa dipakai buat referensi malah muncul blank putih. Deadline presentasi tinggal 30 menit.

Saya buka laptop, mulai cek dari sisi server: DNS resolve, service status, firewall logs. Tapi ternyata? Server-nya fine-fine saja. Nginx running, PHP-FPM active, disk space aman, LVE stats normal. Setelah 20 menit ngobrol panjang lebar via telepon, ketemu masalahnya: pelanggan pakai Wi-Fi kantor yang memblok port 443. Jadi bukan server yang bermasalah — jaringan kantor pelanggan yang jadi bottleneck. Dan mereka baru sadar setelah saya suruh tethering pakai hotspot HP, langsung lancar.

Kasus itu mengajarkan saya satu hal penting: 90% komplain “website lambat” atau “gagal diakses” itu ternyata bukan masalah di server. Masalahnya ada di antara server dan user — bisa DNS, bisa routing, bisa firewall lokal, bisa ISP. Tapi banyak junior NOC engineer masih langsung panik dan buru-buru restart server padahal belum cek sisi user dulu.

Artikel ini saya tulis khusus buat kamu — teknisi atau NOC engineer yang masih junior dan sering bingung harus mulai dari mana saat pelanggan komplain “website lambat” atau “gagal diakses”. Kita akan bahas tuntas dari A sampai Z: cara membaca ping dan traceroute, pertanyaan apa yang harus ditanyakan ke pelanggan, dan cara menentukan apakah masalahnya ada di sisi server atau di sisi user. Panjang tapi dijamin worth it.

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

Jenis Komplain: “Website Lambat” vs “Gagal Diakses” — Pahami Dulu Perbedaannya

Sebelum mulai troubleshoot, kamu harus tahu dulu dua jenis komplain ini karena cara penanganannya sangat berbeda:

1. “Website Lambat” (Slow Loading)

Pelanggan bisa buka website, tapi loading-nya lama — bisa 5 detik, 10 detik, bahkan lebih. Kadang gambar tidak muncul, CSS/JS tidak load, halaman setengah jadi.

Kemungkinan penyebab:

• Resource server tinggi (CPU/RAM/Disk I/O)
• Website pelanggan sendiri heavy (terlalu banyak plugin, image besar, query lambat)
• PHP worker habis (max_children tercapai)
• CloudLinux LVE throttle (CPU/RAM/DI batas tercapai)
• Database load tinggi (MariaDB slow queries)
• Koneksi user ke server lambat (latency tinggi)
• CDN tidak aktif atau salah konfigurasi

2. “Gagal Diakses” (Unreachable / Connection Refused)

Website tidak bisa diakses sama sekali — muncul error “This site can’t be reached”, “Connection timed out”, “ERR_CONNECTION_REFUSED”, atau bahkan blank putih.

Kemungkinan penyebab:

• DNS belum propagasi atau salah pointing
• Server down / service berhenti (nginx/apache crash)
• Firewall memblok IP user (CSF/Imunify360 block)
• SSL/TLS error (expired certificate, misconfiguration)
• ModSecurity memblok request user
• Network routing bermasalah (tracert gagal di hop tertentu)
• Port tertutup (port 80/443 tidak terbuka)
• Bandwidth account habis
• Account suspended (cPanel suspend karena abuse/malpayment)

Panduan Membaca PING — Apa Artinya “Baik” dan “Buruk”

Ping adalah tes paling dasar untuk cek koneksi antara komputer user ke server. Ini yang pertama kali harus diminta ke pelanggan saat mereka komplain.

Cara Meminta Pelanggan Melakukan Ping

Kasih instruksi ini ke pelanggan (atau langsung jalankan dari SSH server kamu):

Dari komputer pelanggan (Windows):

ping syslogsolutions.net -t

Dari komputer pelanggan (Linux/Mac):

ping syslogsolutions.net -c 20

Dari server kamu ke IP pelanggan (jika punya):

ping [IP_PELANGGAN] -c 10

Cara Membaca Hasil Ping

✅ Hasil Ping BAGUS (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

Yang diperhatikan:

• time=12ms → Latency normal. Untuk server dalam negeri: 5-50ms adalah bagus. Untuk server luar negeri: 50-200ms masih wajar
• Lost = 0 (0% loss) → Tidak ada packet loss. Artinya koneksi stabil
• TTL=54 → Time To Live — menunjukkan berapa hop yang dilalui. TTL rendah (10-30) bisa berarti banyak hop atau packet dibuang di tengah jalan

❌ Hasil Ping BURUK (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

Artinya:

• 50% loss → Setengah paket hilang di perjalanan. Website akan sangat lambat atau timeout
• time=230ms → Latency melonjak drastis dari 12ms ke 230ms. Ada gangguan di jaringan
• TTL bervariasi (48-54) → Rute yang dilalui berbeda-beda, bisa jadi load balancing atau routing unstable

❌ Hasil Ping BURUK (Request Timed Out Total)

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),

Artinya:

• 100% loss → Tidak ada koneksi sama sekali ke server. Bisa karena firewall blok, server down, atau routing putus
• Tapi jangan langsung simpulkan server down! Bisa juga firewall user (Windows Defender, kantor) memblok ICMP (protokol ping)

⚠️ Hasil Ping Khusus: “Destination Host Unreachable”

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

Artinya: Router/gateway lokal user tidak tahu jalur ke IP server. Ini masalah di sisi user — biasanya DNS salah atau gateway bermasalah.

Panduan Membaca TRACERT/TRACEROUTE — Menentukan di Mana Masalahnya Berada

Jika ping menunjukkan masalah, langkah berikutnya adalah traceroute. Ini akan menunjukkan setiap hop (titik perpindahan) yang dilalui paket data dari komputer user ke server.

Cara Menjalankan Traceroute

Windows:

tracert syslogsolutions.net

Linux/Mac:

traceroute syslogsolutions.net

Cara Membaca Hasil Traceroute

✅ Traceroute BAGUS (Semua Hop Normal)

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

  1    <1ms    <1ms    <1ms  192.168.1.1      ← Gateway lokal (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    ← Server tujuan ✅

Trace complete.

Yang diperhatikan:

• Semua hop merespons (bukan asterisk ***)
• Waktu antar hop wajar (tidak ada lompatan drastis dari 10ms ke 500ms)
• Tujuan tercapai (hop terakhir = IP server)

❌ Traceroute BURUK — Hop Hilang (Asterisk ***)

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

  1    <1ms    <1ms    <1ms  192.168.1.1      ← Gateway lokal 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.  ← Masalah di sini!
  5     *       *       *     Request timed out.
  6    85ms    83ms    86ms  103.56.123.45    ← Tapi masih sampai tujuan

Trace complete.

Artinya:

• Hop 4 dan 5 tidak merespons — tapi ini belum tentu masalah besar. Beberapa router memang dibuat untuk tidak membalas ICMP (anti-DDoS policy)
• Yang penting: apakah hop terakhir (tujuan) bisa dicapai? Kalau iya, kemungkinan besar koneksi masih bisa jalan meskipun beberapa hop intermediate “invisible”
• Perhatikan waktu di hop 3 vs hop 6: jika ada lompatan besar (misal 12ms → 85ms), berarti masalah latency terjadi di jalur transit, bukan di server

❌ Traceroute BURUK — Latency Spike di Hop Tertentu

  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

Artinya:

• Lonjakan drastis dari hop 3 (12ms) ke hop 4 (320ms) → masalah terjadi di transit provider atau peering antara ISP dan backbone international
• Ini di luar kendali server kamu. Pelanggan harus hubungi ISP-nya
• Cara konfirmasi: coba traceroute dari server kamu ke IP pelanggan — kalau dari sisi server latency-nya normal, berarti memang jalur ISP pelanggan yang bermasalah

❌ Traceroute BURUK — Total Failure (Tidak Sampai Tujuan)

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.
  6     *       *       *     Request timed out.
  ...
 30     *       *       *     Request timed out.

Trace complete. Destination not reached.

Artinya:

• Paket data tidak pernah sampai ke server. Artinya port 80/443 kemungkinan besar tertutup di server, atau firewall memblok route ke IP tersebut
• Atau juga bisa: DNS resolve ke IP yang salah (IP server lama, belum update)
• Langkah selanjutnya: cek DNS, cek firewall rules, cek apakah port terbuka dari IP pelanggan

Pertanyaan Wajib untuk Pelanggan — Panduan untuk Junior NOC

Ini bagian paling penting. Banyak junior NOC engineer langsung loncat ke server tanpa mengumpulkan informasi dari pelanggan dulu. Akibatnya? Troubleshooting jadi 2-3x lebih lama karena harus bolak-balik tanya-tanya.

Print atau bookmark daftar pertanyaan ini dan gunakan setiap kali ada komplain:

Pertanyaan Dasar (Wajib Ditanyakan)

1. “Bisa akses dari device lain nggak?”
   • Dari HP pakai data seluler? Dari komputer lain di jaringan berbeda?
   • Tujuan: Menentukan apakah masalahnya spesifik di 1 device atau di semua device pelanggan
2. “Website-nya akses dari mana — pakai Wi-Fi kantor, rumah, atau data seluler?”
   • Wi-Fi kantor seringkali memblok port tertentu atau pakai proxy/filter
   • Tujuan: Identifikasi apakah jaringan lokal yang jadi masalah
3. “Error-nya apa persisnya? Screenshot boleh?”
   • “This site can’t be reached” ≠ “Connection timed out” ≠ “ERR_CONNECTION_REFUSED” ≠ “503 Service Unavailable” ≠ “403 Forbidden”
   • Tujuan: Error message spesifik langsung mengarah ke root cause yang berbeda
4. “Coba clear cache browser dulu, lalu buka lagi. Masih error?”
   • Cache browser seringkali menyimpan versi lama atau redirect yang sudah expired
   • Tujuan: Eliminasi masalah cache lokal sebelum troubleshoot lebih jauh
5. “Coba buka dari incognito/private window. Sama nggak?”
   • Menyingkirkan pengaruh extension/plugin browser yang mungkin memblok konten
   • Tujuan: Eliminasi pengaruh browser extensions

Pertanyaan Lanjutan (Kalau Dasar Sudah Oke)

6. “Bisa jalankan perintah ini di Command Prompt/Terminal?”

   ping example.com -n 10

   Lalu minta mereka copy-paste hasilnya. Ini data mentah yang kamu butuhkan untuk analisis

7. “Kapan pertama kali bisa akses, dan kapan mulai error?”
   • Bisa jadi: baru install SSL tapi belum propagate, baru update DNS, baru migrasi server
   • Tujuan: Timeline kejadian membantu identifikasi trigger
8. “Siapa yang bikin website-nya? CMS apa yang dipakai?”
   • WordPress? Custom? Static HTML? Joomla? Magento?
   • WordPress dengan 50 plugin di shared hosting = resep lambat
   • Tujuan: Evaluasi apakah website pelanggan sendiri yang heavy
9. “Kalau dari HP pakai data seluler (bukan Wi-Fi), bisa buka nggak?”
   • Ini tes tercepat untuk menentukan apakah masalahnya di jaringan pelanggan atau di server
   • Tujuan: Quick test — kalau dari data seluler lancar, kemungkinan besar masalah di jaringan lokal pelanggan

Template Pesan untuk Pelanggan

Copy-paste ini ke chat/email pelanggan:

Halo [Nama Pelanggan],

Terima kasih atas laporannya. Untuk bantu saya diagnosa lebih cepat, 
bisakah tolong:

1. Screenshot error yang muncul
2. Jalankan ini di Command Prompt (Windows) atau Terminal (Mac/Linux):
   ping [domain-anda.com] -n 10
   Lalu copy-paste hasilnya ke sini
3. Coba buka website dari HP pakai data seluler (matikan Wi-Fi dulu)
4. Coba buka dari browser incognito/private window

Hasilnya akan sangat membantu saya identifikasi masalahnya lebih cepat.

Terima kasih!

Troubleshooting dari Sisi Server: Shared Hosting (cPanel/CloudLinux)

Setelah kamu mengumpulkan data dari pelanggan, sekarang waktunya cek dari sisi server. Ini panduan lengkap untuk shared hosting environment.

1. Cek Status Account Pelanggan (paling sering terjadi!)

# Via WHM: List Accounts
# Cari domain pelanggan, cek status

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

Penyebab umum account suspended:

• Bandwidth habis (quota bulanan terlampaui)
• Inode quota habis (terlalu banyak file)
• Disk space habis
• Abuse/malware detected
• Pembayaran overdue

Cara cek: via WHM

WHM → Account Information → List Accounts
→ Cari domain pelanggan
→ Cek kolom: Status, Bandwidth, Disk Usage

Cara cek via SSH:

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

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

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

2. Cek CloudLinux LVE Limits

CloudLinux bisa membatasi resource per akun. Jika pelanggan melebihi batas CPU/RAM/IO, website-nya bisa jadi sangat lambat atau bahkan timeout.

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

# Via SSH: cek LVE stats
lvetop

# Atau cek usage per user:
cat /var/lve/cloudlinux.db

Tanda-tanda LVE throttle:

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

3. Cek PHP-FPM Status

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

# Cek active processes
ps aux | grep lsphp

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

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

Yang sering bikin PHP lambat:

• max_children terlalu kecil (default 5, naikkan ke 25-50 sesuai RAM)
• PHP memory_limit terlalu kecil (default 128M, untuk WP biasanya butuh 256M+)
• Opcode cache belum aktif (OPcache harusnya on)
• WordPress dengan banyak plugin = banyak PHP execution time

4. Cek CSF Firewall

# Cek apakah IP pelanggan di-block
csf -g [IP_PELANGGAN]

# Cek deny list
cat /etc/csf/csf.deny | grep [IP_PELANGGAN]

# Cek temp ban
cat /var/lib/csf/csf.tempban

Kasus umum: Pelanggan pakai IP dinamis yang pernah kena brute force → IP masuk temporary ban → website tidak bisa diakses dari IP tersebut

5. Cek Imunify360

# Cek apakah IP di-block Imunify360
cat /var/imunify360/event.log | grep [IP_PELANGGAN] | tail -20

# Via Imunify360 UI (cPanel plugin)
# Login cPanel pelanggan → Imunify360 → Firewall

6. Cek ModSecurity

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

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

Cara disable ModSecurity untuk domain tertentu:

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

7. Cek DNS Resolution

8. Cek Service Status

# Cek web server
systemctl status nginx
systemctl status lshttpd

# Cek MySQL/MariaDB
systemctl status mariadb
mysqladmin status

# Cek PHP-FPM
systemctl status lsphp*  # (bisa lsphp74-fpm, lsphp80-fpm, lsphp81-fpm)

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

Troubleshooting dari Sisi Server: VPS & Dedicated Server

Untuk VPS, kamu punya kontrol penuh. Berikut panduan lengkapnya:

1. Cek Server Resources (Free Disk Space, RAM, CPU)

# Cek disk usage
df -h
# Cek: apakah ada partisi yang > 85%? Kalau iya, itu bisa jadi penyebab

# Cek RAM
free -m
# Cek: apakah available RAM tinggal sedikit (< 100MB)?

# Cek CPU load
top -bn1 | head -15
# Atau lebih jelas:
uptime
# Load average 15.00 (di atas jumlah CPU core) = overloaded

# Cek disk I/O
iotop
# Atau:
dstat -td --disk-util 5

2. Cek Network & Port

# Cek port terbuka
netstat -tulpn | grep -E ":80|:443|:21|:22|:3306"

# Cek apakah port 80 dan 443 listening
ss -tlnp | grep -E ":80|:443"

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

# Cek apakah ada block untuk IP tertentu
iptables -L -n | grep [IP_PELANGGAN]

# Cek dari luar apakah port terbuka
# Dari komputer lain:
telnet [IP_SERVER] 80
telnet [IP_SERVER] 443

3. Cek 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

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

4. Cek DNS dari Server

# Cek apakah DNS pointing ke IP server ini
dig [domain.com] +short
# Harusnya: IP server ini

# Cek dig lengkap
dig [domain.com] +noall +answer

# Cek apakah ada DNS issues
dig [domain.com] @1.1.1.1 +short
dig [domain.com] @8.8.8.8 +short
# Bandingkan — harusnya sama

5. Cek Service Status

# Nginx
systemctl status nginx

# Apache
systemctl status httpd  # atau apache2

# MariaDB/MySQL
systemctl status mariadb

# PHP-FPM
systemctl status php-fpm

# cPanel (jika pakai)
systemctl status cpanel
systemctl status named    # DNS
systemctl status dovecot  # Email
systemctl status exim

6. Cek SSL Certificate

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

# Cek Let's Encrypt status
certbot certificates

# Cek apakah sertifikat valid
echo | openssl s_client -connect [domain.com]:443 2>/dev/null | grep "Verify return code"

7. Khusus VPS Windows

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

# Cek port listening
netstat -an | findstr "80"
netstat -an | findstr "443"

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

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

# Cek event log untuk error
Get-WinEvent -LogName Application -MaxEvents 20 | Select TimeCreated, Message

Decision Table: Penyebab Umum, Gejala, dan Solusi

Untuk Shared Hosting (cPanel + CloudLinux)

Penyebab	Gejala	Solusi
Account suspended	"This account has been suspended" atau "Site suspended" di halaman	Unsuspend via WHM → List Accounts → Unsuspend. Cek dulu kenapa suspended (bandwidth, abuse, pembayaran)
LVE CPU throttle	Website sangat lambat (10-30 detik), tapi error 200	LVE Manager → Usage → naikkan CPU limit atau adjust weight
Apache slot full (503)	503 Service Unavailable, website error di jam ramai	Naikkan max_spare_servers atau EP limit di LVE Manager
Inode habis	Tidak bisa upload file, email bounce "Disk quota exceeded"	Bersihkan cache, file lama, log besar. Naikkan inode quota jika perlu
Disk space habis	Email bounce, website error 500, database tidak bisa ditulis	Bersihkan /tmp, /home/[user]/logs, cache. Naikkan disk quota
PHP max_children habis	Website timeout, tapi server load normal	Naikkan max_children di PHP-FPM config (per account atau global)
ModSecurity block	403 Forbidden di halaman tertentu (biasanya admin panel)	Cek error log ModSecurity → disable rule untuk path tertentu atau disable ModSecurity per domain
CSF/Imunify360 block IP	Website bisa diakses dari jaringan lain, tapi TIDAK dari jaringan pelanggan	Whitelist IP pelanggan di CSF: csf -a [IP]
SSL expired	"Your connection is not private", "NET::ERR_CERT_DATE_INVALID"	Renew SSL via cPanel → SSL/TLS, atau via WHM → AutoSSL
DNS belum propagasi	Website di beberapa jaringan bisa, di jaringan lain belum	Tunggu propagate (biasanya 24-48 jam), atau pakai Google DNS di sisi user: 8.8.8.8
Plugin WordPress heavy	Website lambat dari admin panel, tapi resource server normal	Disable plugin satu per satu untuk cari bottleneck. Pertimbangkan caching plugin
Malware/Abuse	Account suspended otomatis, email notifikasi dari Imunify360	Scan malware → hapus → hardening → request unsuspend

Untuk VPS & Dedicated Server

Penyebab	Gejala	Solusi
Web server down (nginx/apache crash)	Connection refused, website tidak bisa diakses dari mana pun	systemctl status nginx → cek error → restart → cari penyebab crash di error log
Firewall block port 80/443	SSH bisa, tapi website timeout dari luar	iptables -L -n → cek apakah ada DROP rule untuk port 80/443 → buka firewall
Disk space habis 100%	Semua service error, tidak bisa write, MySQL crash	df -h → du -sh /var/log/* → bersihkan log/cache → tambah disk
DNS pointing salah	Website di beberapa network bisa, di lain tidak	dig [domain] +short → bandingkan dengan IP server → update DNS di registrar
SSL/TLS misconfiguration	"SSL_ERROR_RX_RECORD_TOO_LONG" atau "ERR_SSL_PROTOCOL_ERROR"	nginx.conf → cek listen 443 ssl → pastikan sertifikat ada dan path benar
PHP-FPM down	502 Bad Gateway (nginx + php-fpm), atau website blank	systemctl status php-fpm → restart → cek log error PHP
MySQL/MariaDB down	"Error establishing a database connection"	systemctl status mariadb → cek error log → restart
DDoS attack	CPU 100%, bandwidth spike, semua website lambat	CentOS: netstat -an | grep :80 | wc -l → cek IP attacker → rate limit di nginx atau iptables
Kernel panic / OOM killer	Server restart tiba-tiba, semua website down sesaat	Cek /var/log/kern.log atau dmesg → tambah RAM atau kurangi service
NTP time desync	SSL errors, cron tidak jalan tepat waktu, log timestamps aneh	timedatectl → pastikan NTP sync → systemctl restart chronyd

Alur Kerja Troubleshooting — Step by Step untuk Junior NOC

Ini flowchart yang bisa kamu ikuti dari awal sampai selesai. Bookmark halaman ini — kamu akan sering butuh saat komplain datang.

Step 1: Kumpulkan Data dari Pelanggan

1. ✅ Screenshot error
2. ✅ Hasil ping [domain] -n 10
3. ✅ Coba dari data seluler (bukan Wi-Fi)
4. ✅ Coba dari browser incognito
5. ✅ Kapan mulai error?

Step 2: Quick Check dari Sisi Server

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: Cek dari Luar (External Check)

1. ✅ Ping dari server ke IP pelanggan (jika ada)
2. ✅ Traceroute dari server ke IP pelanggan
3. ✅ curl -I https://[domain] dari server
4. ✅ Cek DNS dari Google DNS: dig @[8.8.8.8] [domain]

Step 4: Cek Firewall & Security

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

Step 5: Cek Account-Specific (Shared Hosting)

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

Step 6: Diagnosis & Solusi

1. Bandingkan semua data yang terkumpul
2. Tentukan: masalah di server, jaringan, atau sisi user?
3. Terapkan solusi sesuai root cause
4. Verifikasi: minta pelanggan coba lagi
5. Dokumentasi: catat kasus ini untuk referensi ke depan

Pro Tips dari Lapangan

1. Selalu cek dari data seluler dulu. Ini tes paling cepat dan paling efektif. Kalau dari data seluler bisa, kemungkinan besar masalah di jaringan lokal pelanggan.
2. Jangan langsung restart server. Restart itu "nuclear option" — menghapus semua jejak diagnosa. Selalu kumpulkan data dulu sebelum restart.
3. Catat setiap kasus. Buat spreadsheet atau document: kasus → penyebab → solusi → waktu penyelesaian. Ini "database pengetahuan" kamu. 6 bulan lagi akan sangat berguna.
4. Hafalkan error code HTTP. 200 OK, 301 redirect, 403 forbidden, 404 not found, 500 internal error, 502 bad gateway, 503 service unavailable — setiap angka punya arti spesifik.
5. Pelanggan yang panik perlu kesabaran ekstra. Bicara dengan nada tenang, kasih langkah yang jelas (1, 2, 3), dan update progress mereka. Komunikasi lebih penting dari teknis.
6. Gunakan teknik "divide and conquer". Kalau ada 10 kemungkinan penyebab, jangan cek semuanya sekaligus. Eliminasi satu per satu — ini lebih efisien.
7. Domain baru vs domain lama beda treatment. Domain baru: cek DNS propagation dulu. Domain lama: cek apakah ada perubahan terakhir (DNS update, SSL renewal, migration).
8. Jika pelanggan pakai VPN, minta disable dulu. VPN bisa mengubah routing dan menyebabkan website tidak bisa diakses meskipun server fine.
9. Jangan lupa cek timezone server. Log dengan timestamp yang salah bisa bikin diagnosa makin membingungkan.

FAQ

1. Bedanya "Connection Timed Out" dan "Connection Refused"?

Connection Timed Out: Paket dikirim tapi tidak ada balasan dalam waktu tertentu. Penyebab: firewall blok, server down, atau routing putus. Connection Refused: Server aktif dan merespons, tapi menolak koneksi. Penyebab: service tidak jalan di port tersebut (misal nginx tidak listening di port 443) atau firewall di server menolak secara aktif.

2. Kenapa website bisa diakses dari data seluler tapi tidak dari Wi-Fi kantor?

Wi-Fi kantor biasanya pakai firewall/proxy yang memblok port tertentu (misal port 443, 25, atau port non-standard). Atau juga bisa jadi DNS cache kantor yang masih pointing ke IP lama. Minta pelanggan coba dari data seluler — kalau lancar, berarti masalah di jaringan kantor mereka.

3. Kalau ping hasilnya bagus tapi website tetap lambat, kenapa?

Ping hanya menguji konektivitas jaringan level dasar (ICMP). Website bisa lambat karena: PHP execution time lama (banyak plugin), database slow query, resource server (CPU/RAM) sudah di batas, atau content heavy (gambar besar tanpa kompresi). Ping tidak mengukur kualitas layanan HTTP.

4. Bagaimana cara cek apakah DNS sudah propagasi?

Gunakan tools online seperti dnschecker.org atau jalankan dig [domain] @8.8.8.8 dan dig [domain] @1.1.1.1 dari beberapa lokasi. Jika semua menunjukkan IP yang benar, propagasi sudah selesai. TTL yang rendah (misal 300 atau kurang) menunjukkan DNS baru di-update.

5. Apakah restart nginx/apache selalu menyelesaikan masalah?

Tidak. Restart hanya menyelesaikan masalah sementara jika root cause-nya adalah memory leak, process stuck, atau configuration reload. Tapi restart tidak menyelesaikan masalah seperti: disk space habis, DNS salah, firewall block, atau website yang memang heavy. Selalu cari root cause sebelum restart.

6. Kenapa dari command line saya bisa akses website tapi dari browser pelanggan tidak bisa?

Karena kamu akses dari IP server langsung (localhost atau IP internal), yang tidak melewati firewall external, DNS resolution, atau routing jaringan. Selalu test dari IP/user yang berbeda untuk mendapatkan gambaran akurat.

7. Apa artinya "ERR_CONNECTION_RESET"?

Server menutup koneksi secara paksa sebelum transfer selesai. Biasanya terjadi karena: firewall memblok di tengah transfer, SSL/TLS handshake gagal, atau server mengalami crash di tengah request. Cek error log web server untuk detail lebih lanjut.

Artikel Terkait

• Cara Mengatasi Apache Slot Penuh (503 Service Unavailable)
• Cara Troubleshoot Database Load Tinggi di MariaDB
• Cara Mengatasi CPU Interrupts Tinggi (240961/s) di Server cPanel CloudLinux
• Cara Mendeteksi Domain Penyebab Slot Webserver LiteSpeed Penuh
• Cara Install Netdata di Server Linux untuk Monitoring Real-Time
• Cara Update PHP di CloudLinux dengan yum groupupdate alt-php
• Cara Mendeteksi & Hapus Email Spam di Server cPanel

Kesimpulan

Komplain "website lambat" atau "gagal diakses" adalah salah satu kasus paling sering yang dihadapi NOC engineer — tapi juga salah satu yang paling sering disalahdiagnosa. Kunci utamanya: jangan panik, kumpulkan data dulu, dan mulai dari sisi user sebelum cek server.

Dengan memahami cara membaca ping dan traceroute, mengetahui pertanyaan apa yang harus ditanyakan ke pelanggan, dan mengenal karakteristik masing-masing environment (shared hosting cPanel/CloudLinux, VPS Linux, VPS Windows), kamu bisa menyelesaikan 90% komplain dalam waktu kurang dari 30 menit — tanpa harus restart server atau panik minta bantuan senior.

Simpan artikel ini sebagai referensi. Bookmark. Buka setiap kali komplain datang. Seiring waktu, kamu akan mulai mengenali pola-pola dan bisa langsung ke solusi tanpa harus membaca ulang dari awal. Dan yang paling penting: catat setiap kasus yang kamu tangani — itulah "dosen terbaik" yang tidak ada di bangku kuliah.

Author: NOC Engineer — Syslog Solutions
Credentials: 5+ tahun pengalaman menangani komplain pelanggan shared hosting dan VPS. Spesialisasi di network troubleshooting, server hardening, dan incident response untuk lingkungan cPanel/WHM + CloudLinux.