ERR_CONNECTION_REFUSED — Penyebab dan Cara Mengatasinya

Refused, timed out, reset — tiga hal berbeda

Ketiganya sering dianggap sama, sekadar "situsnya rusak", padahal masing-masing memberi tahu sesuatu yang sangat spesifik tentang di mana kegagalannya terjadi.

Penyebab umum, dari yang paling sering

• Tidak ada yang mendengarkan di port itu. Web server crash, dihentikan, atau tidak ikut menyala setelah reboot. Ini penyebab nomor satu kalau Anda pemilik situsnya.
• Anda memakai port yang salah. Mengakses https:// pada server yang hanya melayani HTTP biasa, atau menghubungi dev server di port 3000 yang sudah tidak berjalan.
• Firewall diatur REJECT, bukan DROP. Keduanya memblokir Anda, tapi REJECT mengirim balik penolakan yang menghasilkan error ini persis.
• Layanan hanya bind ke localhost. Sangat sering terjadi pada lingkungan development dan database yang baru dikonfigurasi — prosesnya jalan, tapi hanya menerima koneksi dari mesin itu sendiri.
• Konfigurasi proxy atau ekstensi browser yang salah. VPN atau ekstensi proxy yang menunjuk ke proxy yang tidak berjalan akan menolak setiap koneksi.
• Software lokal yang memblokir — antivirus, agen keamanan perusahaan, atau alat kontrol akses yang menolak koneksi keluar ke host tersebut.
• Situsnya memang sudah pindah atau tutup, dan sekarang ada hal lain yang menjawab di alamat IP itu.

Pertama: hanya Anda atau semua orang?

Dua menit di langkah ini menghemat satu jam memperbaiki server yang sebenarnya tidak pernah rusak.

• Buka situs lewat data seluler dengan Wi-Fi dimatikan. Kalau bisa, servernya baik-baik saja dan masalahnya ada di jaringan, komputer, atau browser Anda.
• Coba jendela penyamaran, lalu browser lain. Ini mencoret ekstensi dan pengaturan proxy tersimpan dari daftar kecurigaan.
• Gunakan alat pemeriksa "down for everyone" mana pun. Alat itu mengakses dari server eksternal dan memberi jawaban objektif.
• Coba situs yang sama dari perangkat lain di jaringan yang sama. Kalau semua perangkat gagal tapi data seluler berhasil, masalahnya ada di router atau penyaringan tingkat ISP.

Kalau Anda pengunjung — periksa dengan urutan ini

• Pastikan alamatnya benar, termasuk protokolnya. Sebagian server hanya mendengarkan HTTP dan akan menolak HTTPS mentah-mentah, begitu pula sebaliknya.
• Matikan VPN atau ekstensi proxy lalu coba lagi. Kalau proxy dikonfigurasi tapi software proxy-nya tidak berjalan, semua koneksi akan ditolak.
• Periksa pengaturan proxy sistem. Di Windows ada di Internet Options; di macOS di Network settings. Bersihkan apa pun yang tidak Anda atur dengan sengaja.
• Bersihkan cache browser dan cache DNS. Di macOS jalankan "sudo dscacheutil -flushcache"; di Windows jalankan "ipconfig /flushdns".
• Matikan sementara proteksi web pada antivirus. Beberapa paket keamanan menolak koneksi ke host dalam daftar blokirnya tanpa memberi tahu dengan jelas.
• Restart router. Ini membersihkan status NAT lama yang kadang membuat koneksi ke satu tujuan tertentu ditolak.
• Kalau tetap gagal sementara orang lain bisa, ISP Anda mungkin sedang memfilter. Uji dengan data seluler untuk memastikan sebelum menghabiskan waktu lebih banyak.

Kalau Anda pemilik situs — diagnosis yang menentukan

Ketika Anda mengendalikan servernya, "ditolak" adalah salah satu error yang paling mudah dilacak, karena ia menunjuk pada satu pertanyaan yang sangat spesifik: apakah ada yang mendengarkan di port itu, dan apakah ia menerima koneksi dari luar?

• Periksa layanannya berjalan atau tidak: "systemctl status nginx" atau "systemctl status apache2". Kalau berhenti, nyalakan — lalu baca log untuk tahu kenapa ia berhenti, karena itu akan terulang.
• Lihat apa yang sebenarnya mendengarkan: "ss -tlnp" (atau "netstat -tlnp"). Ini perintah paling informatif untuk error ini. Anda harus melihat web server ter-bind di port 80 dan 443.
• Perhatikan alamat bind di hasilnya. "127.0.0.1:80" berarti layanan hanya menerima koneksi lokal dan akan menolak semua orang lain. Seharusnya "0.0.0.0:80" atau IP publik Anda.
• Periksa firewall. Dengan ufw jalankan "ufw status"; dengan firewalld "firewall-cmd --list-all"; di VPS, periksa juga firewall tingkat jaringan dari penyedia, yang terpisah dari firewall di mesin.
• Konfirmasi dari luar server. Jalankan "curl -I https://situsanda.com/" dari mesin lain, atau "telnet situsanda.com 443". Menguji dari server itu sendiri akan berhasil meskipun dunia luar diblokir total.
• Periksa port yang benar-benar dipakai layanan setelah mengubah konfigurasi. Salah ketik pada baris listen adalah penyebab yang sangat umum tepat setelah penyuntingan.
• Kalau layanan tidak mau menyala, baca error log sebelum mencoba lagi. Konflik port ("address already in use") dan kesalahan sintaks di file konfigurasi adalah dua alasan tersering.

Jebakan bind-address

Bagian ini layak dapat bab sendiri karena menghasilkan versi paling membingungkan dari error ini: layanannya jelas berjalan, firewall-nya jelas terbuka, tapi koneksi tetap ditolak.

Banyak layanan secara bawaan bind ke 127.0.0.1 — alamat loopback — yang berarti hanya menerima koneksi yang berasal dari mesin itu sendiri. Ini default keamanan yang masuk akal untuk database dan dev server, dan memang itulah yang Anda inginkan untuk MySQL pada umumnya.

Tapi bukan itu yang Anda inginkan untuk web server publik. Kalau ss menampilkan "127.0.0.1:80" alih-alih "0.0.0.0:80", perbaikannya ada di konfigurasi layanan, bukan di firewall. Di Nginx itu direktif listen; di Apache baris Listen; pada aplikasi Node atau Python itu argumen host saat menjalankan server — bind ke "localhost" alih-alih "0.0.0.0" adalah kesalahan satu kata yang menghasilkan persis error ini.

Alasan ini menjebak banyak orang adalah pengujian dari server selalu berhasil. Selalu uji dari mesin lain.

Mencegahnya terulang

• Aktifkan layanan agar bertahan setelah reboot: "systemctl enable nginx". Layanan yang dinyalakan manual tapi tidak di-enable akan hilang setelah restart berikutnya.
• Pasang monitoring uptime dengan peringatan. Mengetahuinya dari pelanggan membuat Anda kehilangan setengah jam pertama yang paling mahal.
• Uji perubahan konfigurasi sebelum diterapkan. "nginx -t" memvalidasi konfigurasi dan menangkap salah ketik yang membuat layanan gagal restart.
• Dokumentasikan aturan firewall. Aturan yang ditambahkan saat troubleshooting lalu lupa dihapus menyebabkan penolakan misterius berbulan-bulan kemudian.
• Pantau memori. Layanan yang dibunuh OOM killer berhenti dengan rapi dan menghasilkan persis error ini — jalankan "dmesg | grep -i oom" saat sebuah layanan mati tanpa alasan jelas.
• Siapkan jalan masuk kedua. VNC atau mode rescue memungkinkan Anda memperbaiki aturan firewall yang mengunci Anda di luar; tanpa itu, yang tersisa hanya menunggu tiket support.