ERR_CONNECTION_REFUSED: Apa Artinya dan Cara Memperbaikinya Sepenuhnya

Kesalahan 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.

Secara praktis, ketika Chrome menampilkan "This site can't be reached. ERR_CONNECTION_REFUSED," itu berarti salah satu dari tiga hal: server target tidak mendengarkan pada port yang diminta, firewall atau lapisan keamanan mengirimkan paket TCP RST (reset) kembali ke klien Anda, atau tumpukan jaringan lokal Anda salah dikonfigurasi dan merutekan permintaan secara tidak benar sebelum mencapai server. Mengidentifikasi mana dari tiga kategori ini yang berlaku pada situasi Anda adalah cara tercepat untuk menemukan solusi.

Memahami Mekanisme Tingkat TCP

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

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

Penyebab umum di tingkat port meliputi:

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

Akar Penyebab: Rincian Terstruktur

Penyebab dari Sisi Klien

Penyebab dari Sisi Server

Panduan Diagnostik dan Perbaikan Langkah demi Langkah

Langkah 1: Tentukan Apakah Masalah Bersifat Global atau Lokal

Sebelum mengubah pengaturan lokal apa pun, pastikan apakah situs tidak aktif untuk semua orang atau hanya untuk Anda. Gunakan alat-alat berikut:

• downforeveryoneorjustme.com — pemeriksaan sederhana aktif/tidak aktif
• isitdownrightnow.com — mencakup riwayat waktu respons
• ping.pe — melakukan ping ke target dari beberapa lokasi global secara bersamaan

Jika situs dapat dijangkau dari node eksternal tetapi tidak dari mesin Anda, masalahnya bersifat lokal. Jika tidak dapat dijangkau secara global, masalahnya berada di sisi server dan di luar kendali Anda — hubungi administrator situs atau tunggu.

Bagi administrator server yang mengelola infrastruktur mereka sendiri, situs yang tidak dapat dijangkau 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 Anda terlebih dahulu.

Langkah 2: Verifikasi Server Benar-benar Mendengarkan (Untuk Admin Server)

Jika Anda mengelola server yang bersangkutan, masuk melalui SSH dan jalankan perintah berikut untuk mengonfirmasi apa yang mendengarkan pada 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

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

Langkah 3: Mulai Ulang Router dan Bersihkan Status Jaringan Lokal

Untuk masalah sisi klien, memulai ulang router membersihkan tabel NAT, lease DHCP, dan kegagalan perutean sementara. Cabut router selama 30 detik, lalu sambungkan kembali. Ini sangat efektif ketika kesalahan muncul tiba-tiba tanpa perubahan konfigurasi apa pun.

Langkah 4: Bersihkan Cache DNS

Entri cache DNS yang usang yang mengarah ke alamat IP lama atau yang sudah dinonaktifkan adalah salah satu penyebab paling umum dari ERR_CONNECTION_REFUSED di sisi klien. Server pada 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 membersihkan, verifikasi IP yang kini diselesaikan oleh domain:

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

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

Langkah 5: Bersihkan Cache dan Cookie Browser

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 pengujian lebih cepat tanpa menghapus data, buka jendela Penyamaran (Ctrl + Shift + N). Jika situs dimuat dalam mode Penyamaran 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 dikonfigurasi atau tidak aktif adalah penyebab umum ERR_CONNECTION_REFUSED di semua situs web 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 ditinggikan:

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 yang aktif.

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

Langkah 7: Ubah Resolver DNS Anda

Resolver DNS default ISP Anda mungkin mengembalikan hasil yang salah, mengalami gangguan, 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 Sementara Firewall dan Antivirus

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 dalam daftar blokir. Menonaktifkannya sementara (hanya untuk tujuan diagnostik) mengonfirmasi apakah mereka adalah penyebabnya.

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

Langkah 9: Uji dengan Browser dan Jaringan yang Berbeda

Uji URL di Firefox, Edge, atau Safari. Jika dimuat di browser lain, masalahnya spesifik pada 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 (Admin Server)

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

curl -vI https://yourdomain.com

Perhatikan tahap TLS handshake dalam output verbose. Kegagalan di sini mengindikasikan 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 dikonfigurasi, memperbarui atau menggantinya akan menyelesaikan masalah. Pastikan SSL Certificates Anda valid, dirantai dengan benar, dan dipasang pada antarmuka server yang tepat.

ERR_CONNECTION_REFUSED vs. Kesalahan Browser Serupa

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

Kasus Tepi Lanjutan dan Jebakan

Konflik resolusi IPv6 vs. IPv4: Jika domain diselesaikan ke alamat IPv6 tetapi jaringan Anda tidak mendukung IPv6 dengan benar, Chrome mungkin mencoba koneksi IPv6 yang ditolak, lalu gagal beralih kembali ke IPv4 dengan cepat. Menonaktifkan IPv6 pada adaptor jaringan sementara dapat mengonfirmasi hal ini. Di Linux, Anda dapat memaksa IPv4 dengan curl -4 https://example.com.

Cloudflare atau CDN menyimpan kesalahan origin yang usang: Jika situs menggunakan Cloudflare dan server origin mati, Cloudflare mungkin menyajikan versi yang di-cache untuk sementara, lalu mulai mengembalikan kesalahan 521 (origin refused connection) atau 522, yang mungkin ditampilkan Chrome sebagai ERR_CONNECTION_REFUSED tergantung pada bagaimana kesalahan di-proxy.

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

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

Keterbatasan shared hosting: Pada lingkungan Shared Web Hosting, penolakan koneksi mungkin mengindikasikan bahwa server penyedia hosting kelebihan beban, akun telah ditangguhkan, atau DNS domain belum mengarah ke IP bersama yang benar. Periksa panel kontrol hosting Anda untuk status akun dan konfigurasi DNS.

Matriks Keputusan Praktis: Perbaikan Mana yang Diterapkan Terlebih Dahulu

Gunakan daftar periksa ini untuk melakukan triase secara efisien:

• Kesalahan muncul di semua situs web secara bersamaan — Periksa pengaturan proxy dan konfigurasi VPN/firewall terlebih dahulu
• Kesalahan hanya muncul pada satu domain tertentu — Periksa apakah situs tidak aktif secara global; kemudian bersihkan cache DNS
• Kesalahan hanya muncul di Chrome, bukan browser lain — Bersihkan cache Chrome, nonaktifkan ekstensi, atau buat profil Chrome baru
• Kesalahan hanya muncul di jaringan Anda, bukan pada data seluler — Mulai ulang router; periksa DNS atau firewall tingkat ISP
• Kesalahan muncul setelah perubahan konfigurasi server — Periksa status proses server web, binding port, dan aturan firewall pada server
• Kesalahan muncul secara intermiten di bawah beban — Selidiki kelelahan sumber daya (file descriptor, memori, batas koneksi) pada server
• Kesalahan hanya muncul pada HTTPS, bukan HTTP — Selidiki validitas sertifikat SSL dan konfigurasi TLS
• Kesalahan muncul setelah mengubah pengaturan DNS — Kembalikan perubahan DNS dan bersihkan cache; verifikasi resolver baru dapat dijangkau

FAQ

Apa perbedaan antara ERR_CONNECTION_REFUSED dan ERR_CONNECTION_TIMED_OUT?

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

Apakah ERR_CONNECTION_REFUSED dapat disebabkan oleh sertifikat SSL yang kedaluwarsa?

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

Mengapa ERR_CONNECTION_REFUSED hanya muncul pada satu situs web tertentu?

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

Bagaimana cara memperbaiki ERR_CONNECTION_REFUSED pada 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 pada port yang diharapkan.

Apakah membersihkan DNS selalu memperbaiki ERR_CONNECTION_REFUSED?

Hanya ketika akar penyebabnya adalah entri cache DNS yang usang yang mengarah ke alamat IP di mana layanan tidak lagi berjalan. Jika server tidak aktif, firewall memblokir koneksi, atau proxy salah dikonfigurasi, membersihkan DNS tidak akan berpengaruh. Gunakan dig atau nslookup untuk memverifikasi resolusi DNS sebelum dan sesudah pembersihan untuk mengonfirmasi apakah DNS benar-benar menjadi masalahnya.