ERR_CONNECTION_REFUSED: Apa Artinya dan Cara Memperbaikinya Sepenuhnya

Error ERR_CONNECTION_REFUSED berarti browser Anda mengirimkan permintaan koneksi ke server web, dan server tersebut secara aktif menolaknya — bukan mengabaikannya, tetapi secara eksplisit menolak TCP handshake. Ini adalah mode kegagalan yang secara fundamental berbeda dari timeout (ERR_CONNECTION_TIMED_OUT) atau kegagalan DNS (ERR_NAME_NOT_RESOLVED), dan perbedaan tersebut sangat penting saat mendiagnosis akar penyebabnya.

Dalam praktiknya, ketika Chrome menampilkan “Situs ini tidak dapat dijangkau. ERR_CONNECTION_REFUSED,” itu berarti salah satu dari tiga hal: server target tidak mendengarkan port yang diminta, firewall atau lapisan keamanan mengirimkan paket TCP RST (reset) kembali ke klien Anda, atau network stack lokal Anda salah konfigurasi dan merutekan permintaan secara tidak benar sebelum pernah mencapai server. Mengidentifikasi kategori mana dari ketiga kategori ini yang berlaku untuk situasi Anda adalah jalan tercepat menuju solusi.

Memahami Mekanika Tingkat TCP

Sebagian besar panduan pemecahan masalah browser memperlakukan ERR_CONNECTION_REFUSED sebagai “masalah jaringan” yang samar-samar. Ini tidak demikian. Pada lapisan TCP, koneksi yang ditolak berarti server (atau perantara) mengirim kembali paket RST/ACK sebagai respons terhadap paket SYN browser Anda. Ini adalah penolakan eksplisit, bukan penurunan senyap.

Perbedaan ini memiliki implikasi diagnostik praktis: jika koneksi dijatuhkan secara senyap oleh firewall, Anda akan melihat ERR_CONNECTION_TIMED_OUT. Koneksi yang ditolak berarti sesuatu merespons secara aktif — yang berarti host dapat dijangkau di tingkat jaringan, tetapi layanan di port target tidak tersedia atau diblokir.

Penyebab umum tingkat port meliputi:

• Proses server web (Apache, Nginx, Node.js) telah mogok atau berhenti
• Server mendengarkan di port non-standar dan URL tidak menentukannya
• Firewall berbasis host (iptables, ufw, Windows Defender Firewall) menolak koneksi di port 80 atau 443
• Reverse proxy (HAProxy, Nginx, Cloudflare) dikonfigurasi secara tidak benar dan mengembalikan paket RST upstream
• Aplikasi di belakang proxy telah mogok, meninggalkan proxy tanpa backend untuk diteruskan

Penyebab Akar: Analisis Terstruktur

Penyebab Sisi Klien

Penyebab Sisi Server

Panduan Diagnostik dan Perbaikan Langkah demi Langkah

Langkah 1: Tentukan Apakah Masalahnya Bersifat Global atau Lokal

Sebelum menyentuh pengaturan lokal apa pun, tentukan apakah situs tidak berfungsi untuk semua orang atau hanya untuk Anda. Gunakan alat-alat berikut:

• downforeveryoneorjustme.com — pemeriksaan naik/turun sederhana
• isitdownrightnow.com — mencakup riwayat waktu respons
• ping.pe — melakukan ping ke target dari berbagai lokasi global secara bersamaan

Jika situs dapat diakses dari node eksternal tetapi tidak dari mesin Anda, masalahnya bersifat lokal. Jika tidak dapat diakses secara global, masalahnya bersifat server-side dan di luar kontrol Anda — hubungi administrator situs atau tunggu.

Untuk administrator server yang mengelola infrastruktur mereka sendiri, situs yang tidak dapat diakses secara global memerlukan penyelidikan segera terhadap proses server web, aturan firewall, dan jaringan upstream. Jika Anda menjalankan lingkungan VPS Hosting, periksa daftar proses server dan konfigurasi firewall terlebih dahulu.

Langkah 2: Verifikasi Server Benar-Benar Mendengarkan (Untuk Administrator Server)

Jika Anda mengelola server yang dimaksud, SSH masuk dan jalankan perintah berikut untuk mengkonfirmasi apa yang mendengarkan di port mana:

sudo ss -tlnp | grep -E ':80|:443'

Jika output kosong untuk port 80 atau 443, proses server web Anda tidak berjalan. Mulai ulang:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Juga verifikasi bahwa firewall Anda tidak memblokir koneksi masuk:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Jika port 443 diblokir, izinkan:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Untuk administrator yang menjalankan Dedicated Servers, juga periksa apakah aturan firewall upstream penyedia hosting atau security group Anda memblokir port di perimeter jaringan — ini terpisah dari firewall tingkat OS.

Langkah 3: Mulai Ulang Router Anda dan Flush Status Jaringan Lokal

Untuk masalah sisi klien, restart router menghapus tabel NAT, sewa DHCP, dan kegagalan routing transien apa pun. Cabut router selama 30 detik, lalu sambungkan kembali. Ini sangat efektif ketika kesalahan muncul tiba-tiba tanpa perubahan konfigurasi apa pun.

Langkah 4: Flush Cache DNS

Entri cache DNS yang sudah usang menunjuk ke alamat IP lama atau yang telah dihentikan adalah salah satu penyebab paling umum dari ERR_CONNECTION_REFUSED di sisi klien. Server di IP yang di-cache mungkin tidak lagi menjalankan situs target.

• Di Windows:

ipconfig /flushdns

• Di macOS (Ventura, Sonoma, dan sebagian besar versi modern):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• Di Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Setelah flush, verifikasi IP apa yang sekarang diselesaikan domain:

nslookup example.com
# or
dig +short example.com

Bandingkan dengan IP situs yang diketahui. Jika berbeda, propagasi DNS mungkin masih berlangsung.

Langkah 5: Hapus Cache Browser dan Cookie

Di Google Chrome, navigasikan ke chrome://settings/clearBrowserData atau gunakan pintasan keyboard:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Atur rentang waktu ke Semua waktu, centang Gambar dan file yang di-cache dan Cookie dan data situs lainnya, lalu klik Hapus data. Mulai ulang Chrome sepenuhnya (bukan hanya tab) sebelum menguji ulang.

Untuk tes yang lebih cepat tanpa menghapus data, buka jendela Incognito (Ctrl + Shift + N). Jika situs dimuat di Incognito tetapi tidak di jendela normal, sumber daya yang di-cache atau ekstensi browser adalah penyebabnya.

Langkah 6: Audit dan Nonaktifkan Pengaturan Proxy

Server proxy yang salah konfigurasi atau mati adalah penyebab umum dari ERR_CONNECTION_REFUSED di semua situs secara bersamaan. Chrome menggunakan pengaturan proxy sistem secara default.

• Di Windows:

Navigasikan ke Pengaturan > Sistem > Proxy dan nonaktifkan “Gunakan server proxy” jika diaktifkan tanpa sepengetahuan Anda. Atau, jalankan ini dari Command Prompt yang ditingkatkan:

netsh winhttp reset proxy

• Di macOS

Buka Pengaturan Sistem > Jaringan, pilih antarmuka aktif Anda, klik Detail, lalu tab Proxy, dan hapus centang semua protokol proxy aktif.

Setelah menonaktifkan proxy, uji situs. Jika dimuat, konfigurasi proxy Anda adalah penyebabnya. Baik konfigurasikan ulang dengan benar atau hapus sepenuhnya.

Langkah 7: Ubah Resolver DNS Anda

Resolver DNS default ISP Anda mungkin mengembalikan hasil yang salah, mengalami pemadaman, atau secara aktif memblokir domain tertentu. Beralih ke resolver publik menghilangkan variabel ini.

Resolver DNS publik yang direkomendasikan:

• Di Windows (melalui PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

• Di macOS:

Buka Pengaturan Sistem > Jaringan > [Antarmuka Anda] > Detail > DNS, hapus entri yang ada, dan tambahkan 1.1.1.1 dan 1.0.0.1.

• Di Linux (systemd-resolved):

Edit /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Kemudian mulai ulang resolver:

sudo systemctl restart systemd-resolved

Langkah 8: Nonaktifkan Firewall dan Antivirus Sementara

Beberapa produk antivirus dan firewall berbasis host mencegat lalu lintas HTTPS melalui proxy lokal dan dapat mengeluarkan paket RST ketika mesin inspeksi mereka gagal atau ketika domain target ada di daftar blokir. Menonaktifkannya sementara (hanya untuk tujuan diagnostik) mengkonfirmasi apakah mereka adalah penyebabnya.

Jika menonaktifkan perangkat lunak keamanan menyelesaikan kesalahan, tambahkan pengecualian khusus untuk domain target daripada membiarkan perangkat lunak dinonaktifkan. Aktifkan kembali segera setelah pengujian.

Langkah 9: Uji dengan Browser dan Jaringan Berbeda

Uji URL di Firefox, Edge, atau Safari. Jika dimuat di browser lain, masalahnya khusus Chrome — kemungkinan profil yang rusak, ekstensi yang tidak berfungsi, atau pengaturan proxy khusus Chrome. Coba buat profil Chrome baru untuk mengisolasi masalah.

Jika situs gagal di semua browser, beralih ke hotspot seluler. Jika dimuat melalui data seluler, ISP atau router rumah Anda adalah sumber masalahnya.

Langkah 10: Periksa Masalah Konfigurasi SSL/TLS (Administrator Server)

Sertifikat SSL yang salah konfigurasi dapat menyebabkan server mogok atau menolak koneksi TLS, yang dilaporkan Chrome sebagai ERR_CONNECTION_REFUSED daripada kesalahan sertifikat dalam beberapa kasus tepi. Gunakan berikut ini untuk menguji dari baris perintah:

curl -vI https://yourdomain.com

Cari tahap jabat tangan TLS dalam output verbose. Kegagalan di sini menunjukkan masalah sertifikat atau cipher suite. Anda juga dapat menguji dengan:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Jika sertifikat SSL Anda telah kedaluwarsa atau salah konfigurasi, memperbarui atau menggantinya menyelesaikan masalah. Pastikan SSL Certificates Anda valid, berantai dengan benar, dan dipasang di antarmuka server yang benar.

ERR_CONNECTION_REFUSED vs. Kesalahan Browser Serupa

Memahami bagaimana kesalahan ini berbeda dari kesalahan terkait mencegah diagnosis yang salah:

Kasus Tepi Lanjutan dan Jebakan

1) Konflik resolusi IPv6 vs. IPv4:

Jika domain diselesaikan ke alamat IPv6 tetapi jaringan Anda tidak mendukung IPv6 dengan benar, Chrome dapat mencoba koneksi IPv6 yang ditolak, kemudian gagal untuk kembali ke IPv4 dengan cepat. Menonaktifkan IPv6 pada adaptor jaringan secara sementara dapat mengkonfirmasi hal ini. Di Linux, Anda dapat memaksa IPv4 dengan curl -4 https://example.com.

2) Cloudflare atau caching CDN kesalahan asal yang sudah usang:

Jika situs menggunakan Cloudflare dan server asal turun, Cloudflare dapat melayani versi yang di-cache untuk sementara, kemudian mulai mengembalikan kesalahan 521 (asal menolak koneksi) atau 522, yang mungkin ditampilkan Chrome sebagai ERR_CONNECTION_REFUSED tergantung pada bagaimana kesalahan di-proxy.

3) Lingkungan pengembangan Localhost:

Pengembang sering melihat ERR_CONNECTION_REFUSED saat mengakses localhost:3000 atau serupa. Penyebabnya hampir selalu bahwa proses server pengembangan tidak berjalan, mogok, atau terikat ke 127.0.0.1 di port yang berbeda dari yang diharapkan. Jalankan ss -tlnp | grep node (atau proses yang relevan) untuk mengkonfirmasi apa yang benar-benar mendengarkan.

4) Konflik port server email:

Jika Anda menjalankan Email Hosting di server yang sama dengan aplikasi web Anda, pastikan bahwa konflik port antara SMTP (25, 587), IMAP (993), dan HTTP/HTTPS (80, 443) tidak menyebabkan server web gagal untuk mengikat.

5) Keterbatasan shared hosting:

Di lingkungan Shared Web Hosting, penolakan koneksi dapat menunjukkan bahwa server penyedia hosting kelebihan beban, akun telah ditangguhkan, atau DNS domain belum menunjuk ke IP bersama yang benar. Periksa panel kontrol hosting Anda untuk status akun dan konfigurasi DNS.

Matriks Keputusan Praktis: Perbaikan Mana yang Harus Diterapkan Terlebih Dahulu

Gunakan daftar periksa ini untuk triase secara efisien:

• Error muncul di semua website secara bersamaan — Periksa pengaturan proxy dan konfigurasi VPN/firewall terlebih dahulu
• Error muncul hanya pada satu domain spesifik — Periksa apakah situs sedang down secara global; kemudian flush cache DNS
• Error muncul hanya di Chrome, bukan browser lain — Hapus cache Chrome, nonaktifkan ekstensi, atau buat profil Chrome baru
• Error muncul hanya di jaringan Anda, bukan di data seluler — Restart router; periksa DNS tingkat ISP atau firewall
• Error muncul setelah perubahan konfigurasi server — Periksa status proses web server, port bindings, dan aturan firewall di server
• Error muncul secara intermiten saat beban tinggi — Investigasi kelelahan sumber daya (file descriptors, memori, batas koneksi) di server
• Error muncul hanya pada HTTPS, bukan HTTP — Investigasi validitas sertifikat SSL dan konfigurasi TLS
• Error muncul setelah mengubah pengaturan DNS — Kembalikan perubahan DNS dan flush cache; verifikasi resolver baru dapat dijangkau

FAQ

1) Apa perbedaan antara ERR_CONNECTION_REFUSED dan ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED berarti server (atau firewall) secara aktif mengirimkan paket TCP reset, menolak koneksi segera. ERR_CONNECTION_TIMED_OUT berarti tidak ada respons yang diterima dalam periode timeout — paket-paket tersebut secara diam-diam dijatuhkan. Koneksi yang ditolak lebih cepat muncul dan menunjukkan penolakan aktif, sementara timeout menunjukkan aturan DROP routing atau firewall.

2) Dapatkah ERR_CONNECTION_REFUSED disebabkan oleh sertifikat SSL yang kadaluarsa?

Secara tidak langsung, ya. Dalam beberapa konfigurasi server, sertifikat SSL yang kadaluarsa atau salah konfigurasi menyebabkan proses web server gagal saat startup atau crash saat menangani koneksi TLS, menghasilkan tidak ada listener di port 443. Chrome kemudian melaporkan ERR_CONNECTION_REFUSED karena tidak ada yang mendengarkan, meskipun penyebab dasarnya adalah masalah sertifikat.

3) Mengapa ERR_CONNECTION_REFUSED hanya muncul di satu website tertentu?

Jika error terisolasi pada satu domain, penyebab paling mungkin adalah: layanan web server target telah crash, firewall server memblokir rentang IP Anda, catatan DNS domain menunjuk ke alamat IP lama di mana tidak ada layanan yang berjalan, atau situs telah dihapus. Gunakan curl -v https://thatdomain.com dari jaringan atau server yang berbeda untuk mengisolasi penyebabnya.

4) Bagaimana cara memperbaiki ERR_CONNECTION_REFUSED di localhost?

Server aplikasi tidak berjalan atau terikat ke port yang berbeda dari yang Anda minta. Konfirmasi apa yang mendengarkan dengan ss -tlnp di Linux/macOS atau netstat -ano | findstr :PORT di Windows. Mulai proses server aplikasi, dan pastikan terikat ke 0.0.0.0 atau 127.0.0.1 di port yang diharapkan.

5) Apakah flush DNS selalu memperbaiki ERR_CONNECTION_REFUSED?

Hanya ketika akar penyebabnya adalah entri cache DNS yang ketinggalan zaman yang menunjuk ke alamat IP di mana layanan tidak lagi berjalan. Jika server down, firewall memblokir koneksi, atau proxy salah konfigurasi, flush DNS tidak akan berpengaruh. Gunakan dig atau nslookup untuk memverifikasi resolusi DNS sebelum dan sesudah flush untuk mengkonfirmasi apakah DNS benar-benar menjadi masalahnya.