Kenapa Ping Berhasil tapi Website Tidak Bisa Dibuka? Ini Cara Troubleshooting dari Layer 3 hingga Layer 7

Pernah mengalami situasi ketika sebuah server berhasil merespons perintah ping, tetapi website yang dihosting di server tersebut justru tidak bisa dibuka melalui browser?

Misalnya, Anda menjalankan perintah berikut dari komputer klien:

ping 192.168.1.10

Hasilnya menunjukkan bahwa server merespons dengan normal. Tidak ada packet loss, dan waktu respons terlihat rendah. Namun, ketika alamat http://192.168.1.10 atau https://example.com dibuka melalui browser, halaman tidak muncul, koneksi mengalami timeout, atau muncul pesan seperti This site can’t be reached.

Situasi ini sering membingungkan administrator jaringan, teknisi IT, siswa TKJ/TJKT, hingga system administrator yang sedang melakukan troubleshooting server.

Apakah server mengalami kerusakan? Apakah routing bermasalah? Atau justru layanan web yang tidak berjalan?

Jawabannya bergantung pada bagian jaringan dan aplikasi yang mengalami gangguan.

Ping berhasil tidak menjamin website dapat diakses. Perintah ping umumnya menggunakan ICMP untuk menguji keterjangkauan alamat IP. Sementara itu, akses website membutuhkan lebih banyak proses, mulai dari resolusi DNS, routing, koneksi TCP, negosiasi TLS untuk HTTPS, komunikasi HTTP, hingga pemrosesan aplikasi web.

Artikel ini membahas cara menganalisis masalah tersebut secara sistematis dari Layer 3 hingga Layer 7, lengkap dengan perintah troubleshooting Linux, pengujian DNS, firewall, routing, MTU, proxy, SNI, serta layanan aplikasi.

Memahami Mengapa Ping Berhasil tetapi Website Gagal

Untuk memahami masalah ini, kita perlu membedakan pengujian konektivitas jaringan dengan pengujian akses layanan.

Perintah ping mengirimkan ICMP Echo Request dan menunggu ICMP Echo Reply. Jika balasan diterima, berarti jalur komunikasi ICMP antara sumber dan tujuan berfungsi untuk paket tersebut.

Namun, website tidak menggunakan ICMP sebagai protokol utama komunikasinya.

Ketika browser mengakses website, prosesnya kurang lebih seperti berikut:

1. Browser memeriksa URL dan konfigurasi proxy.
2. Sistem melakukan resolusi nama domain melalui DNS jika diperlukan.
3. Klien menentukan alamat IP tujuan dan memilih rute.
4. Klien membuat koneksi TCP, biasanya ke port 80 untuk HTTP atau port 443 untuk HTTPS.
5. Jika menggunakan HTTPS, klien menjalankan negosiasi TLS dan memvalidasi sertifikat.
6. Browser mengirimkan HTTP request.
7. Web server, reverse proxy, atau aplikasi memproses permintaan.
8. Server mengirimkan respons yang kemudian ditampilkan browser.

Kegagalan pada salah satu tahapan tersebut dapat membuat website tidak bisa dibuka, meskipun ping ke alamat IP tertentu berhasil.

Analogi sederhana

Bayangkan sebuah gedung kantor.

Perintah ping seperti memastikan bahwa gedung tersebut dapat dijangkau dan seseorang di pos keamanan menjawab panggilan.

Namun, untuk mengakses website, Anda harus melewati beberapa proses tambahan:

• Mengetahui alamat gedung yang benar.
• Menemukan pintu masuk yang sesuai.
• Melewati pemeriksaan keamanan.
• Menemukan ruangan yang dituju.
• Memastikan petugas di ruangan tersebut sedang bekerja.

Gedungnya dapat dijangkau, tetapi layanan di dalamnya belum tentu tersedia.

Memahami Layer 3 hingga Layer 7

Layer	Fungsi	Contoh masalah
Layer 3 – Network	Pengalamatan IP dan routing	Rute salah, gateway bermasalah
Layer 4 – Transport	Komunikasi TCP dan UDP	Port 443 diblokir, koneksi TCP gagal
Layer 5 – Session	Pengelolaan sesi komunikasi	Sesi koneksi atau perantara bermasalah
Layer 6 – Presentation	Representasi data dan enkripsi	Negosiasi TLS gagal, cipher tidak cocok
Layer 7 – Application	Protokol dan layanan aplikasi	DNS, HTTP, virtual host, aplikasi web

Perlu dipahami bahwa model OSI merupakan model konseptual. DNS dan HTTP biasanya dikategorikan sebagai protokol aplikasi, sedangkan TLS modern beroperasi di antara lapisan aplikasi dan transport dalam berbagai pemetaan model jaringan.

Karena itu, troubleshooting tidak harus dilakukan dengan menganggap setiap masalah selalu berada tepat pada satu lapisan OSI. Yang lebih penting adalah mengisolasi tahapan komunikasi yang gagal.

Penyebab Pertama: DNS Mengarah ke IP yang Salah

DNS menerjemahkan nama domain menjadi alamat IP. Ketika pengguna membuka https://portal.example.com, browser harus memperoleh alamat tujuan yang sesuai, kecuali informasi tersebut sudah tersedia di cache atau berasal dari mekanisme resolusi lain.

Ping menggunakan alamat IP secara langsung tidak menguji resolusi DNS. Bahkan, ping menggunakan nama domain belum tentu membuktikan bahwa browser menggunakan alamat IP yang sama.

Gejala yang sering muncul

• Ping ke IP server berhasil, tetapi domain tidak dapat dibuka.
• Domain mengarah ke alamat IP lama.
• Website hanya bisa diakses dari jaringan tertentu.
• Domain utama bisa dibuka, tetapi subdomain gagal.
• Resolusi IPv4 berhasil, tetapi koneksi IPv6 bermasalah.

Langkah 1: Periksa resolusi DNS

Di Linux, jalankan:

dig example.com A
dig example.com AAAA
dig example.com CNAME

Untuk melihat hasil resolusi melalui resolver yang digunakan sistem:

getent ahosts example.com

Pada Windows:

nslookup example.com

Bandingkan alamat IP yang diperoleh dengan alamat IP server yang seharusnya melayani website.

Jika DNS mengarah ke IP lama, periksa record A, AAAA, atau CNAME pada penyedia DNS. Perhatikan juga TTL, cache resolver, dan kemungkinan adanya DNS split-horizon pada jaringan internal.

Langkah 2: Bandingkan DNS dengan IP tujuan yang benar

Jika Anda mengetahui IP publik server, gunakan curl untuk menguji domain tersebut melalui IP yang ditentukan:

curl -v --resolve example.com:443:203.0.113.10 \
  https://example.com/

Ganti 203.0.113.10 dengan IP server yang sebenarnya.

Opsi --resolve memaksa curl menggunakan IP yang ditentukan untuk pasangan hostname dan port tersebut, tetapi tetap mempertahankan hostname dalam URL. Dengan demikian, pengujian HTTPS tetap menggunakan hostname untuk SNI dan validasi sertifikat.

Jika pengujian ini berhasil, tetapi akses normal gagal, periksa DNS dan perbedaan jalur koneksi yang digunakan klien.

Alamat 203.0.113.10 dalam contoh merupakan alamat dokumentasi, bukan alamat server publik yang dapat digunakan secara langsung.

Penyebab Kedua: Port HTTP atau HTTPS Tidak Dapat Diakses

Ping tidak menguji apakah port TCP 80 atau 443 terbuka.

Server dapat menjawab ICMP, tetapi layanan web mungkin berhenti, tidak melakukan listening pada alamat yang benar, atau koneksinya diblokir firewall.

Langkah 1: Periksa port dari sisi klien

Di Linux:

nc -vz example.com 80
nc -vz example.com 443

Atau gunakan curl:

curl -v --connect-timeout 5 http://example.com/
curl -v --connect-timeout 5 https://example.com/

Interpretasi umum:

• Connection refused: koneksi ditolak; periksa apakah layanan listening dan apakah firewall mengirimkan penolakan aktif.
• Connection timed out: tidak ada respons yang diterima dalam batas waktu; periksa firewall, routing, jalur balik, atau server.
• Connected to ...: koneksi TCP berhasil, tetapi belum membuktikan bahwa TLS atau HTTP berjalan dengan benar.
• Connection reset: koneksi direset oleh salah satu perangkat atau endpoint pada jalur komunikasi.

Pesan-pesan tersebut merupakan petunjuk, bukan bukti tunggal mengenai penyebabnya.

Langkah 2: Periksa layanan web pada server

Jika menggunakan Nginx:

sudo systemctl status nginx
sudo nginx -t

Jika menggunakan Apache pada Debian atau Ubuntu:

sudo systemctl status apache2
sudo apache2ctl configtest

Periksa apakah layanan melakukan listening pada port yang benar:

sudo ss -lntp | grep -E ':(80|443)\b'

Pastikan layanan tidak hanya listening pada 127.0.0.1 ketika seharusnya menerima koneksi dari jaringan.

Jika layanan hanya terikat pada loopback, akses dari komputer lain tidak akan mencapai layanan tersebut meskipun server dapat diping.

4. Penyebab Ketiga: Firewall Memblokir TCP

Firewall dapat mengizinkan ICMP sekaligus menolak koneksi TCP ke port tertentu.

Ini sering terjadi ketika administrator hanya mengizinkan ping untuk monitoring, tetapi belum membuka port web. Kondisi serupa dapat terjadi pada firewall host, firewall jaringan, security group cloud, atau aturan NAT.

Periksa firewall Linux

Untuk sistem yang menggunakan UFW:

sudo ufw status verbose

Untuk sistem dengan nftables:

sudo nft list ruleset

Jika masih menggunakan iptables:

sudo iptables -vnL
sudo iptables -t nat -vnL

Periksa kebijakan input, forward, output, aturan DNAT, dan counter paket. Pada host yang menjalankan Docker, perhatikan juga rantai forwarding serta aturan khusus seperti DOCKER-USER.

Jangan langsung mengubah semua aturan firewall. Mulailah dengan membaca kebijakan yang aktif dan mengidentifikasi aturan yang cocok dengan alamat sumber, alamat tujuan, antarmuka, serta port yang diuji.

Periksa firewall di luar server

Jika server berada di cloud atau belakang router, periksa juga:

• Security group atau network ACL.
• Firewall MikroTik, pfSense, atau FortiGate.
• Port forwarding dan destination NAT.
• Kebijakan akses dari VLAN klien.
• Firewall pada reverse proxy atau load balancer.

Contohnya, server dapat diping melalui IP internal, tetapi port 443 pada IP publik belum diteruskan ke server web.

Cara memastikan firewall menjadi penyebab

Jalankan packet capture saat koneksi diuji:

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Kemudian akses website dari klien.

Jika SYN dari klien terlihat pada server tetapi tidak ada SYN-ACK, periksa listener, firewall lokal, serta kondisi server. Jika SYN sama sekali tidak terlihat, fokuskan pemeriksaan pada jalur jaringan sebelum server atau pada IP tujuan yang dipakai klien.

Jika SYN-ACK terlihat keluar dari server tetapi tidak sampai ke klien, periksa jalur balik dan perangkat yang memfilter paket.

5. Penyebab Keempat: Routing Salah atau Jalur Balik Bermasalah

Routing menentukan jalur yang digunakan paket menuju jaringan tujuan. Ping yang berhasil hanya membuktikan bahwa pertukaran ICMP berhasil pada jalur dan ukuran paket tertentu.

Koneksi TCP membutuhkan komunikasi dua arah yang konsisten. Paket SYN harus sampai ke server, dan respons SYN-ACK harus kembali ke klien.

Masalah dapat muncul ketika server memiliki beberapa gateway, menggunakan beberapa NIC, berada di belakang router yang berbeda, atau menggunakan kebijakan routing berdasarkan sumber paket.

Periksa tabel routing Linux

ip route
ip route get 192.168.1.100
ip rule show

Ganti 192.168.1.100 dengan alamat IP klien yang relevan.

Perintah ip route get membantu menunjukkan rute yang dipilih kernel untuk tujuan tersebut. Jika menggunakan policy-based routing, periksa aturan dan tabel routing tambahan.

Di MikroTik RouterOS:

/ip route print detail
/ip firewall nat print detail
/ip firewall filter print stats

Periksa rute menuju jaringan klien, gateway, aturan routing mark, serta NAT jika diperlukan oleh desain jaringan.

Contoh kasus

Server web memiliki dua antarmuka:

• eth0: jaringan internal.
• eth1: jaringan uplink.

Permintaan masuk melalui eth0, tetapi respons dikirim melalui eth1 karena default route mengarah ke gateway berbeda.

Dalam kondisi tertentu, routing asimetris seperti ini dapat menyebabkan koneksi gagal, terutama jika ada stateful firewall yang mengharapkan kedua arah melewati jalur yang sama.

Solusinya bukan selalu memaksakan satu default gateway. Periksa desain routing, tabel kebijakan, dan kebutuhan multihoming sebelum mengubah konfigurasi.

6. Penyebab Kelima: MTU dan Path MTU Discovery

MTU adalah ukuran maksimum paket yang dapat dikirim melalui suatu antarmuka tanpa fragmentasi pada kondisi tertentu. Jalur VPN, PPPoE, GRE, IPsec, atau tunnel lainnya dapat memiliki overhead tambahan sehingga MTU efektif lebih kecil daripada Ethernet standar.

Masalah MTU dapat menghasilkan gejala yang membingungkan: ping kecil berhasil, koneksi TCP mulai terbentuk, tetapi website macet ketika data tertentu dikirim.

Mengapa ping kecil bisa berhasil?

Paket ICMP berukuran kecil mungkin melewati jaringan dengan normal. Namun, paket yang lebih besar dapat memerlukan fragmentasi atau mekanisme Path MTU Discovery.

Jika paket terlalu besar dan pesan ICMP yang diperlukan untuk memberi tahu ukuran maksimum jalur diblokir, koneksi dapat mengalami black-hole MTU.

Gejala ini dapat muncul saat mengakses halaman HTTPS, mengunduh file, atau melewati VPN.

Langkah 1: Uji ukuran paket

Pada Linux dengan IPv4:

ping -M do -s 1472 192.168.1.10

Opsi -M do meminta ping menggunakan mekanisme IPv4 Don’t Fragment. Payload 1472 byte ditambah 28 byte header IPv4 dan ICMP menghasilkan paket IP 1500 byte.

Jika gagal, coba ukuran yang lebih kecil:

ping -M do -s 1400 192.168.1.10
ping -M do -s 1300 192.168.1.10

Gunakan pengujian ini hanya jika ICMP diizinkan. Kegagalan ping berukuran besar belum otomatis membuktikan masalah MTU, karena ICMP dapat difilter atau dibatasi oleh perangkat jaringan.

Langkah 2: Periksa MTU antarmuka

ip link show

Jika menggunakan tunnel, periksa juga MTU antarmuka tunnel dan MTU jalur sebenarnya.

Langkah 3: Lakukan penyesuaian berdasarkan bukti

Perbaikan dapat mencakup penyesuaian MTU atau TCP MSS pada jalur tunnel, serta memastikan pesan ICMP Packet Too Big atau Fragmentation Needed tidak diblokir.

Hindari menurunkan MTU secara sembarangan. Perubahan harus sesuai dengan jalur jaringan dan diuji kembali menggunakan aplikasi nyata.

7. Penyebab Keenam: Masalah TLS, Sertifikat, dan SNI

Website HTTPS membutuhkan lebih dari sekadar koneksi TCP ke port 443.

Setelah koneksi TCP terbentuk, klien dan server menjalankan TLS handshake. Pada tahap ini, masalah dapat muncul karena sertifikat tidak valid, hostname tidak cocok, versi TLS tidak kompatibel, cipher suite tidak cocok, atau server salah memilih sertifikat.

Apa itu SNI?

Server Name Indication (SNI) merupakan ekstensi TLS yang memungkinkan klien menyampaikan nama hostname yang ingin diakses saat handshake.

Fitur ini penting ketika beberapa domain menggunakan satu alamat IP yang sama.

Misalnya, satu server memiliki:

• portal.example.com
• mail.example.com
• api.example.com

Ketiganya dapat menggunakan IP yang sama, tetapi konfigurasi virtual host TLS berbeda. Jika SNI tidak sesuai atau konfigurasi server keliru, server dapat memberikan sertifikat yang salah atau memilih konfigurasi default.

Langkah 1: Uji TLS menggunakan OpenSSL

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error

Perintah tersebut menguji koneksi TLS, mengirimkan SNI, dan meminta verifikasi hostname serta sertifikat.

Periksa hasil verifikasi, rantai sertifikat, masa berlaku, dan pesan kesalahan handshake.

Langkah 2: Bandingkan akses menggunakan IP dan hostname

Menguji URL HTTPS secara langsung melalui IP tidak setara dengan mengakses domain, karena SNI dan nama yang divalidasi dapat berbeda.

Gunakan:

curl -v --resolve example.com:443:203.0.113.10 \
  https://example.com/

Jika pengujian dengan hostname berhasil tetapi akses melalui IP langsung gagal, hal tersebut dapat merupakan perilaku normal karena sertifikat dibuat untuk nama domain, bukan alamat IP.

Jangan menganggap opsi curl -k sebagai solusi produksi. Opsi tersebut menonaktifkan verifikasi sertifikat dan dapat menyembunyikan masalah keamanan.

8. Penyebab Ketujuh: Reverse Proxy atau Forward Proxy Bermasalah

Proxy bertindak sebagai perantara antara klien dan server tujuan. Pada banyak infrastruktur, Nginx, HAProxy, Apache, atau load balancer menerima koneksi klien lalu meneruskannya ke backend.

Dalam kondisi ini, ping ke server backend tidak membuktikan bahwa reverse proxy dapat meneruskan permintaan dengan benar.

Masalah pada reverse proxy

Contohnya:

• Nginx aktif, tetapi upstream aplikasi tidak tersedia.
• HAProxy dapat menerima koneksi, tetapi health check backend gagal.
• Konfigurasi proxy_pass mengarah ke port yang salah.
• Header Host tidak diteruskan sesuai kebutuhan aplikasi.
• Sertifikat pada proxy tidak sesuai dengan hostname.
• Timeout upstream terlalu pendek.

Periksa log Nginx:

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

Jika menggunakan HAProxy, periksa log layanan dan status backend sesuai konfigurasi yang digunakan.

Uji backend secara langsung

Jika backend memang dapat diakses dari server proxy, uji konektivitasnya:

curl -v --connect-timeout 5 http://127.0.0.1:8080/

Ganti alamat dan port sesuai konfigurasi backend.

Jika backend berjalan di container, pastikan alamat yang digunakan benar dari perspektif container atau host. 127.0.0.1 di dalam container menunjuk ke container itu sendiri, bukan otomatis ke host atau container lain.

Masalah forward proxy

Pada jaringan kantor atau sekolah, browser mungkin diwajibkan menggunakan proxy. Dalam kondisi ini, ping ke website dapat berhasil, tetapi browser gagal karena proxy tidak dapat dijangkau, autentikasi proxy bermasalah, atau kebijakan proxy memblokir domain.

Bandingkan hasil akses melalui browser dengan pengujian curl. Perhatikan environment variable seperti HTTP_PROXY, HTTPS_PROXY, dan NO_PROXY, serta konfigurasi proxy sistem atau browser.

9. Penyebab Kedelapan: Virtual Host dan Konfigurasi HTTP Salah

Web server dapat melayani banyak domain melalui satu alamat IP. Pemilihan situs biasanya bergantung pada hostname yang dikirimkan melalui HTTP Host header dan, untuk HTTPS, informasi hostname pada SNI.

Jika virtual host tidak dikonfigurasi dengan benar, server mungkin mengirimkan halaman default, error 404, atau situs yang berbeda dari yang diharapkan.

Uji HTTP dengan hostname yang benar

curl -v http://example.com/

Untuk menguji IP tertentu sambil mempertahankan hostname HTTP:

curl -v --resolve example.com:80:203.0.113.10 \
  http://example.com/

Perhatikan status HTTP:

• 200 OK: server mengembalikan respons sukses, tetapi isi halaman tetap perlu diperiksa.
• 301 atau 302: server mengarahkan klien ke URL lain.
• 400 Bad Request: permintaan mungkin tidak sesuai dengan konfigurasi server atau aplikasi.
• 401 Unauthorized atau 403 Forbidden: permintaan memerlukan autentikasi atau ditolak oleh kebijakan akses.
• 404 Not Found: resource atau rute tidak ditemukan pada konteks host yang dipilih.
• 502 Bad Gateway: proxy menerima respons yang tidak valid dari upstream atau gagal berkomunikasi dengan backend.
• 503 Service Unavailable: layanan tidak tersedia, misalnya karena backend tidak sehat.
• 504 Gateway Timeout: proxy tidak memperoleh respons upstream dalam batas waktu.

Status HTTP tidak selalu menunjukkan penyebab akhir. Periksa body respons, header, access log, error log, dan log backend.

Penyebab Kesembilan: Aplikasi Web Mengalami Gangguan

Koneksi TCP dan TLS dapat berhasil, tetapi aplikasi web tetap gagal memproses permintaan.

Contohnya:

• Database tidak dapat dihubungi.
• PHP-FPM berhenti.
• Aplikasi Node.js mengalami exception.
• Pool koneksi database habis.
• Redis tidak tersedia.
• API eksternal mengalami timeout.
• Disk penuh sehingga aplikasi tidak dapat menulis file atau log.
• Proses aplikasi kehabisan memori.

Periksa resource server

Di Linux:

uptime
free -h
df -h
df -i

Periksa juga layanan aplikasi:

sudo systemctl --failed
sudo journalctl -p err -b

Untuk melihat log layanan tertentu:

sudo journalctl -u nginx --since "15 minutes ago"

Ganti nginx dengan nama layanan yang relevan, seperti php8.3-fpm atau layanan aplikasi Node.js.

Untuk aplikasi berbasis Docker:

docker ps
docker logs --tail 100 nama_container
docker stats

Jika web server menghasilkan 502, jangan langsung mengubah konfigurasi proxy. Pastikan backend berjalan, port listening, koneksi database sehat, dan log aplikasi tidak menunjukkan exception.

Tutorial Troubleshooting Step-by-Step

Pendekatan paling efisien adalah menguji komunikasi secara bertahap dan mengubah satu variabel pada satu waktu.

Langkah 1: Pastikan IP tujuan benar

getent ahosts example.com

Catat alamat IP yang dikembalikan. Bandingkan dengan IP server atau load balancer yang seharusnya digunakan.

Jika terdapat beberapa alamat A atau AAAA, uji setiap alamat secara terpisah bila diperlukan.

Langkah 2: Uji keterjangkauan jaringan

ping -c 4 192.168.1.10

Ping berhasil menunjukkan bahwa ICMP mendapat balasan. Ping gagal pun belum otomatis berarti server tidak dapat diakses, karena ICMP dapat diblokir.

Langkah 3: Periksa rute

ip route get 192.168.1.10

Jika tujuan berada di jaringan berbeda, pastikan gateway dan rute menuju jaringan tujuan benar.

Langkah 4: Uji port layanan

nc -vz 192.168.1.10 80
nc -vz 192.168.1.10 443

Jika TCP gagal, fokuskan pemeriksaan pada listener, firewall, NAT, routing, dan jalur balik.

Langkah 5: Uji HTTP atau HTTPS

curl -v --connect-timeout 5 https://example.com/

Baca tahapan output curl untuk mengetahui apakah kegagalan terjadi sebelum koneksi, ketika TCP terbentuk, saat TLS handshake, atau setelah HTTP request dikirim.

Langkah 6: Periksa DNS dan SNI

curl -v --resolve example.com:443:203.0.113.10 \
  https://example.com/

Jika pengujian menggunakan IP tertentu berhasil, bandingkan dengan hasil akses normal untuk mengisolasi perbedaan DNS atau jalur tujuan.

Langkah 7: Periksa web server dan aplikasi

sudo ss -lntp
sudo systemctl status nginx
sudo journalctl -u nginx -n 100 --no-pager

Periksa konfigurasi web server, log error, backend, dan database jika aplikasi membutuhkannya.

Langkah 8: Periksa paket jika penyebab belum ditemukan

sudo tcpdump -ni any 'host 192.168.1.100 and tcp port 443'

Ganti alamat tersebut dengan IP klien.

Cari pola TCP handshake: SYN, SYN-ACK, dan ACK. Jika koneksi telah terbentuk, lanjutkan dengan analisis TLS atau HTTP sesuai gejala yang ditemukan.

Studi Kasus: Ping Berhasil, tetapi Website Timeout

Sebuah sekolah memiliki server web dengan alamat internal 192.168.10.20. Komputer administrator dapat melakukan ping ke server, tetapi website tidak dapat dibuka.

Hasil pengujian:

ping 192.168.10.20
4 packets transmitted, 4 received, 0% packet loss

Kemudian administrator menjalankan:

nc -vz 192.168.10.20 443

Hasilnya menunjukkan koneksi gagal.

Langkah pemeriksaan berikutnya adalah mengecek apakah layanan HTTPS berjalan:

sudo ss -lntp | grep ':443'
sudo systemctl status nginx

Ternyata Nginx aktif, tetapi hanya melakukan listening pada alamat loopback 127.0.0.1:443. Akibatnya, klien jaringan tidak dapat membuka koneksi langsung ke alamat 192.168.10.20 pada port tersebut.

Setelah konfigurasi listener diperbaiki sesuai kebutuhan jaringan, konfigurasi divalidasi dan layanan dimuat ulang:

sudo nginx -t
sudo systemctl reload nginx

Pengujian TCP dan HTTPS kemudian diulang.

Kasus ini menunjukkan bahwa keberhasilan ping tidak membuktikan layanan web menerima koneksi pada alamat dan port yang dibutuhkan klien.

Namun, jika pada kasus lain port 443 berhasil tetapi browser tetap gagal, pemeriksaan harus dilanjutkan ke TLS, virtual host, proxy, dan aplikasi.

Kesalahan Troubleshooting yang Sering Terjadi

Menganggap ping berhasil berarti semua jaringan normal

Ping hanya menguji ICMP. Uji protokol dan port layanan secara terpisah.

Langsung menonaktifkan firewall

Menonaktifkan firewall dapat membuka akses yang tidak diperlukan dan menghilangkan bukti penyebab. Periksa aturan yang cocok, counter paket, dan log sebelum mengubah kebijakan.

Menguji HTTPS menggunakan IP saja

Akses HTTPS melalui IP dapat menggunakan SNI dan validasi sertifikat yang berbeda dari akses domain. Gunakan hostname yang benar dan curl --resolve untuk mengisolasi IP tujuan.

Mengubah DNS tanpa melakukan verifikasi

Sebelum mengganti record DNS, bandingkan hasil resolusi dari klien, resolver publik, dan resolver internal. Pastikan pula bahwa IP baru memang melayani domain tersebut.

Mengabaikan IPv6

Browser dapat memilih alamat IPv6 ketika DNS memiliki record AAAA. Jika jalur IPv6 rusak, akses dapat gagal atau melambat meskipun IPv4 normal.

Bandingkan pengujian:

curl -4 -v https://example.com/
curl -6 -v https://example.com/

Jangan menghapus record AAAA hanya untuk menutupi masalah routing IPv6. Perbaiki jalur IPv6 atau konfigurasi DNS sesuai kondisi sebenarnya.

Menganggap semua timeout disebabkan firewall

Timeout juga dapat disebabkan oleh rute yang salah, jalur balik, server yang kelebihan beban, backend lambat, atau masalah MTU. Gunakan packet capture dan log untuk membedakan kemungkinan tersebut.

Tips Profesional agar Troubleshooting Lebih Cepat

Pertama, buat urutan pemeriksaan yang konsisten: DNS, routing, TCP, TLS, HTTP, proxy, lalu aplikasi. Jika bukti menunjukkan kegagalan pada tahap tertentu, fokuskan analisis di sana.

Kedua, gunakan pengujian pembanding. Bandingkan akses dari server itu sendiri, dari VLAN yang sama, dari jaringan lain, dan dari koneksi internet eksternal. Perbedaan hasil membantu mempersempit lokasi masalah.

Ketiga, simpan bukti sebelum mengubah konfigurasi. Catat alamat IP tujuan, waktu kejadian, hasil curl, tabel routing, status firewall, dan potongan log yang relevan.

Keempat, lakukan perubahan secara terukur. Ubah satu konfigurasi, ulangi pengujian, kemudian bandingkan hasilnya. Cara ini lebih efektif daripada mengganti DNS, MTU, firewall, dan web server secara bersamaan.

Kelima, manfaatkan monitoring. Prometheus, Grafana, Uptime Kuma, Zabbix, atau sistem monitoring lainnya dapat membantu membedakan gangguan jaringan dari gangguan layanan. Pantau ICMP, TCP port, sertifikat TLS, kode HTTP, latency, dan kesehatan aplikasi secara terpisah.

Keenam, pertimbangkan arsitektur layanan. Pada sistem yang menggunakan CDN, reverse proxy, load balancer, container, atau Kubernetes, alamat IP yang berhasil diping belum tentu merupakan endpoint aplikasi yang sebenarnya. Periksa setiap komponen dalam jalur permintaan.

Kesimpulan

Ping berhasil tetapi website tidak bisa dibuka bukanlah kondisi yang bertentangan. Kedua pengujian tersebut memeriksa hal yang berbeda.

Ping menguji keterjangkauan melalui ICMP, sedangkan akses website melibatkan DNS, routing, TCP, TLS, HTTP, proxy, dan aplikasi.

Untuk menemukan penyebabnya, lakukan troubleshooting secara bertahap:

1. Verifikasi DNS dan alamat IP tujuan.
2. Periksa routing serta jalur balik.
3. Uji port TCP 80 dan 443.
4. Periksa firewall dan NAT.
5. Uji TLS, sertifikat, dan SNI.
6. Analisis HTTP, virtual host, dan proxy.
7. Periksa log serta kesehatan aplikasi.
8. Investigasi MTU dan paket jaringan jika gejalanya mengarah ke sana.

Prinsip utamanya adalah mengidentifikasi tahap komunikasi yang gagal berdasarkan bukti. Dengan pendekatan ini, administrator jaringan dapat menemukan penyebab gangguan secara lebih cepat, terukur, dan aman tanpa melakukan perubahan konfigurasi yang tidak diperlukan.

Frequently Asked Questions (FAQ)

1. Kenapa ping berhasil tetapi website tidak bisa dibuka?

Karena ping menguji konektivitas menggunakan ICMP, sedangkan website membutuhkan DNS, koneksi TCP, TLS untuk HTTPS, HTTP, dan layanan aplikasi. Gangguan pada salah satu komponen tersebut dapat membuat website gagal diakses.

2. Apakah ping berhasil berarti server dalam kondisi normal?

Tidak. Ping hanya membuktikan bahwa server atau perangkat tujuan memberikan respons ICMP. Layanan web, database, dan aplikasi pada server masih dapat mengalami gangguan.

3. Bagaimana cara mengecek apakah port 80 dan 443 terbuka?

Gunakan perintah nc -vz nama-domain 80 dan nc -vz nama-domain 443 dari Linux. Anda juga dapat menggunakan curl -v untuk memeriksa proses koneksi dan respons layanan HTTP atau HTTPS.

4. Bagaimana cara mengetahui masalah website berasal dari DNS?

Periksa hasil resolusi menggunakan dig nama-domain A, dig nama-domain AAAA, atau nslookup nama-domain. Bandingkan IP yang diperoleh dengan IP tujuan yang seharusnya melayani website.

5. Mengapa website HTTPS gagal meskipun port 443 terbuka?

Penyebabnya dapat berupa sertifikat tidak valid, hostname tidak cocok, SNI salah, TLS handshake gagal, atau konfigurasi virtual host yang keliru. Periksa menggunakan curl -v dan openssl s_client.

6. Apakah firewall bisa mengizinkan ping tetapi memblokir website?

Ya. Firewall dapat mengizinkan ICMP tetapi menolak koneksi TCP ke port 80 atau 443. Periksa aturan firewall pada server, router, reverse proxy, dan firewall cloud.

7. Apa hubungan MTU dengan website yang tidak bisa dibuka?

MTU yang tidak sesuai atau masalah Path MTU Discovery dapat membuat paket tertentu gagal melewati jaringan. Akibatnya, ping kecil mungkin berhasil, tetapi koneksi aplikasi dapat macet atau mengalami timeout.

8. Bagaimana membedakan masalah jaringan dan masalah aplikasi?

Uji koneksi TCP, TLS, dan HTTP secara terpisah. Jika koneksi TCP dan TLS berhasil tetapi server mengembalikan error aplikasi, periksa web server, reverse proxy, backend, database, dan log aplikasi.

9. Apa fungsi perintah curl dalam troubleshooting website?

curl membantu menguji akses HTTP dan HTTPS, menampilkan proses koneksi, header, kode status, redirect, serta berbagai kesalahan koneksi dan TLS. Perintah ini berguna untuk mengisolasi masalah tanpa bergantung pada browser.

10. Apa urutan troubleshooting website yang paling efektif?

Mulai dari DNS dan alamat IP, kemudian routing, koneksi TCP, firewall, TLS, HTTP, reverse proxy, dan aplikasi. Gunakan packet capture serta log apabila penyebab belum ditemukan.

Pernah mengalami ping berhasil tetapi website tetap tidak bisa dibuka? Penyebabnya bisa berasal dari DNS, firewall, routing, MTU, TLS, reverse proxy, hingga aplikasi web.

Bagikan pengalaman troubleshooting Anda di kolom komentar. Ceritakan gejala yang ditemukan, perintah yang digunakan, dan bagaimana Anda mengidentifikasi akar masalahnya.

Jika artikel ini bermanfaat, bagikan kepada rekan administrator jaringan, teknisi IT, sysadmin Linux, serta siswa TKJ/TJKT yang sedang belajar troubleshooting jaringan.

Jangan lupa membaca artikel teknologi lainnya untuk memperdalam pengetahuan tentang Linux Server, MikroTik, Cisco, virtualisasi, cloud computing, DevOps, dan cybersecurity.

Ikuti terus pembaruan konten tutorial dan panduan teknis agar keterampilan troubleshooting Anda semakin terarah dan siap menghadapi masalah infrastruktur IT di dunia kerja.