ERR_CONNECTION_CLOSED: Arti & Cara Mengatasi di Chrome

Membuka satu halaman web jarang berarti satu permintaan. Sebuah halaman berita biasa dapat menarik puluhan berkas sekaligus — gambar, skrip, huruf, lembar gaya — dan browser tidak membuka jalur baru untuk masing-masing. Ia membuka satu jalur ke server, lalu memakainya berulang kali sampai tidak dibutuhkan lagi.

Cara kerja ini membuat halaman terbuka jauh lebih cepat. Ia juga melahirkan satu bentuk kegagalan yang khas: jalur yang sudah terbuka itu ditutup dari seberang, tepat ketika browser hendak memakainya lagi. Google Chrome menamai kejadian tersebut ERR_CONNECTION_CLOSED.

Artikel ini membahas arti kode itu, apa yang terjadi di jaringan, dan cara menemukan pihak yang menutup sambungan — dari sisi pengunjung maupun pemilik website.

ERR_CONNECTION_CLOSED Artinya Sambungan Ditutup Baik-Baik

ERR_CONNECTION_CLOSED artinya sambungan antara browser dan server ditutup dengan tertib sebelum jawaban sempat dikirim. Bila Anda terjemahkan ERR_CONNECTION_CLOSED dari bahasa Inggris potong demi potong, hasilnya tiga keping makna. ERR menandai sebuah galat, CONNECTION merujuk pada sambungan jaringan, dan CLOSED berarti ditutup.

Kata "ditutup" perlu dibaca apa adanya. Pesan ini tidak berbicara tentang kabel yang lepas atau sinyal yang hilang. Ada pihak yang mengakhiri sambungan lewat prosedur yang benar, lengkap dengan salam penutup di tingkat protokol. Yang membuatnya terasa seperti gangguan hanyalah waktunya — penutupan itu datang saat browser masih menunggu jawaban.

Pesan tersebut pun disusun browser Anda sendiri sesudah jalurnya tertutup, bukan dikirim oleh website tujuan.

Bentuk lain yang sering Anda temui: net::ERR_CONNECTION_CLOSED di tab Console alat pengembang, dan err connection closed tanpa garis bawah di forum. Ketiganya menunjuk kondisi yang sama persis. Microsoft Edge, Opera, dan Brave menampilkan kode ini juga, karena ketiganya dibangun di atas mesin Chromium.

Membaca Layar "Tiba-Tiba Menutup Sambungan" di Chrome

Judul besar di layar ini tidak membedakan apa pun. Chrome memasang "Situs ini tidak dapat dijangkau" pada belasan kegagalan berbeda, sehingga membacanya saja belum memberi petunjuk.

Kalimat di bawah judul itulah pembedanya, dan kalimat tersebut punya satu ciri yang tidak dimiliki layar error koneksi lain: ia menyebut nama situsnya. Bunyinya "namasitus.com tiba-tiba menutup sambungan.", yang dalam versi Inggris berbunyi namasitus.com unexpectedly closed the connection.

Ciri itu berguna saat membandingkan tangkapan layar dari orang lain: kalimat bernama situs berarti penutupan tertib, sedangkan "Sambungan direset." tanpa nama situs berarti pemutusan paksa dengan penyebab berbeda.

Setelah itu Chrome menulis "Coba:" dengan dua saran, "Periksa sambungan" serta "Memeriksa proxy dan firewall". Pengguna Windows mendapat saran ketiga, "Jalankan Diagnostik Jaringan Windows". Kode ERR_CONNECTION_CLOSED tercetak kecil di baris terakhir, tepat di atas tombol Detail dan Muat ulang.

Potongan yang paling sering disalin orang ke kolom pencarian justru menggabungkan dua baris berbeda, saran pertama dan kode terbawah, sehingga berbunyi "periksa sambungan err_connection_closed". Sebagian menuliskannya ulang dengan kata umum, "situs tiba-tiba menutup sambungan", karena nama domain di layar berbeda untuk tiap orang. Gabungan itu belum menunjuk penyebabnya, sebab daftar saran yang sama dipakai Chrome untuk beberapa kode sekaligus.

Isi layar menyusut di perangkat lain. Chrome di macOS dan Linux tidak punya tombol diagnostik, sedangkan Chrome Android hanya menyisakan "Periksa sambungan". Firefox memakai kalimatnya sendiri untuk kondisi serupa, "Dokumen tidak mengandung data.", jadi jangan mencari kalimat yang sama persis di dua browser.

Paket FIN dan Kode −100: Apa yang Terjadi di Jaringan

Sambungan antara browser dan server dibawa oleh TCP (Transmission Control Protocol), aturan pengiriman yang menjaga data tiba lengkap dan berurutan. TCP mengenal dua cara mengakhiri sambungan, dan keduanya menghasilkan pengalaman yang berbeda.

Cara pertama memakai paket FIN (finish), yang berarti "saya sudah selesai mengirim". Pengirimnya menunggu pihak seberang menutup gilirannya, dan data yang masih di jalan tetap diantar sampai tujuan. Cara kedua memakai paket RST (reset), yang membatalkan sambungan seketika dan membuang sisa datanya.

ERR_CONNECTION_CLOSED lahir dari cara yang pertama. Komentar pada kode sumber Chromium menyebutkannya tanpa basa-basi:

// A connection was closed
// (corresponding to a TCP FIN).
NET_ERROR(CONNECTION_CLOSED, -100)

Ada satu perbedaan teknis yang menjelaskan banyak hal. Kegagalan koneksi lain sampai ke browser sebagai nomor galat dari sistem operasi, misalnya penolakan atau waktu habis. Penutupan yang rapi tidak demikian, sebab secara teknis ia bukan kesalahan. Sistem operasi hanya melaporkan bahwa tidak ada lagi yang bisa dibaca. Chromium yang kemudian memutuskan laporan itu berarti galat, karena permintaan yang sudah dikirim belum berbalas apa pun.

Pemutusan paksa lewat RST punya kode dan penanganannya sendiri, dan dibahas terpisah di artikel ERR_CONNECTION_RESET.

Kenapa ERR_CONNECTION_CLOSED Hanya Lahir di Sambungan Bekas Pakai

Laporan "tidak ada lagi yang bisa dibaca" tadi tidak selalu menjadi −100. Chromium menimbang satu hal lebih dulu: apakah jalur yang baru saja ditutup itu jalur baru, atau jalur yang sudah pernah dipakai.

1. Jalur baru, ditutup sebelum mengirim apa pun. Hasilnya ERR_EMPTY_RESPONSE, dengan layar berjudul "Halaman ini tidak berfungsi".
2. Jalur yang dipakai ulang, ditutup sebelum mengirim apa pun. Hasilnya ERR_CONNECTION_CLOSED.

Alasannya masuk akal begitu dibaca dari sisi server. Jalur yang dipakai ulang sudah terbukti bekerja sekali. Penutupannya karena itu hampir pasti berasal dari server yang memang sedang menutup jalur, bukan dari permintaan Anda.

Melihat ERR_CONNECTION_CLOSED berarti browser Anda pernah berhasil memakai jalur tersebut. Masalah yang biasa dituduhkan pada kegagalan koneksi — alamat server keliru, rute yang tidak sampai, port yang tertutup — semuanya sudah tersingkir sebelum Anda mulai memeriksa.

Chrome menyimpan jalur yang sudah dipakai selama 300 detik, dan jalur yang disiapkan tetapi belum terpakai selama 60 detik. Sebelum memakainya kembali, Chrome mengintip jalur itu sesaat untuk memastikan belum ada tanda penutupan. Pemeriksaan tersebut menangkap hampir semua jalur basi; yang lolos hanya penutupan yang tiba persis di antara pemeriksaan dan pengiriman.

Chrome Sudah Mengirim Ulang Diam-Diam Sebelum Menyerah

Kami menguji perilaku ini pada 21 September 2026 memakai Chrome 153 di macOS, dengan server uji yang menutup sambungan pada permintaan kedua di tiap jalur.

Log jaringan Chrome mencatat urutannya dengan jelas. Sebuah jalur yang menganggur 5 milidetik dipakai ulang, permintaan terkirim, lalu FIN tiba dan tercatat sebagai −100. Chrome tidak menampilkan apa pun. Ia membuka jalur baru, mengulang permintaan yang sama, dan kali ini dijawab 200. Halaman termuat normal tanpa pengunjung tahu ada yang gagal.

Kirim ulang otomatis itu berlaku pada syarat sempit: jalurnya hasil pakai ulang, dan belum satu pun baris jawaban diterima. Batasnya 50 percobaan.

Artinya layar ERR_CONNECTION_CLOSED yang benar-benar Anda lihat bukan penutupan sesaat, melainkan penutupan yang konsisten. Server uji kedua menunjukkan di mana hal itu paling sering terjadi.

Server tersebut menutup sambungan tepat setelah menerima sapaan pembuka terenkripsi. Chrome membangun enam jalur baru dan semuanya gagal di titik yang sama, seluruhnya dalam 10 milidetik. Kecepatan itu sendiri sudah menjadi petunjuk bahwa kegagalannya bukan gangguan jaringan yang kebetulan.

Di Titik Mana FIN Jatuh: Lima Nasib dari Satu Paket

Paket FIN yang sama bisa berakhir menjadi lima hal berbeda, tergantung kapan ia tiba. Urutan berikut mengikuti perjalanan satu kunjungan HTTPS dari awal sampai akhir.

1. Saat jabat tangan TLS. Jalur sudah terbentuk, lalu ditutup ketika browser memperkenalkan diri untuk membuka jalur terenkripsi TLS. Hasilnya ERR_CONNECTION_CLOSED, dan inilah bentuk yang paling sering benar-benar tampil di layar.
2. Sesudah permintaan terkirim, pada jalur yang dipakai ulang. Hasilnya ERR_CONNECTION_CLOSED juga, tetapi Chrome mengirim ulang lebih dulu.
3. Sesudah permintaan terkirim, pada jalur baru. Hasilnya ERR_EMPTY_RESPONSE, "tidak mengirimkan data apa pun".
4. Saat baris jawaban baru masuk separuh. Pada alamat HTTPS, Chrome menolak jawaban yang terpenggal dan menampilkan ERR_RESPONSE_HEADERS_TRUNCATED.
5. Sesudah baris jawaban lengkap diterima. Chrome meneruskan jawaban itu apa adanya. Anda melihat halaman yang termuat separuh atau gambar yang terpotong, bukan layar error.

Dua hal otomatis tersingkir ketika layar menunjukkan ERR_CONNECTION_CLOSED. Pertama, nama situs sudah berhasil diterjemahkan menjadi alamat server, karena kegagalan DNS punya kodenya sendiri seperti DNS_PROBE_FINISHED_NXDOMAIN. Kedua, belum ada jawaban HTTP yang utuh, sehingga mencari kode 404 atau 503 di catatan server tidak akan menemukan jejaknya.

Tersingkir pula dua kode yang terjadi sebelum jalur terbentuk: ketukan pembuka yang ditolak menghasilkan ERR_CONNECTION_REFUSED, dan ketukan yang tidak pernah berbalas menghasilkan ERR_CONNECTION_TIMED_OUT.

Penyebab ERR_CONNECTION_CLOSED di Perangkat dan Jaringan Anda

Karena bentuk yang paling sering tampil adalah FIN pada tahap jabat tangan TLS, daftar tersangkanya menyempit. Yang mampu menutup sambungan di tahap itu hanyalah pihak yang duduk di jalur dan ikut membaca lalu lintasnya.

Di perangkat Anda:

1. Modul pemeriksa HTTPS pada antivirus. Fitur ini membuka lalu lintas terenkripsi memakai sertifikat milik antivirus, lalu menutup sambungan yang gagal diperiksa. Pada satu kasus Windows 11 yang terdokumentasi, Chrome dan Edge menampilkan error ini sementara satu browser lain di komputer yang sama tetap normal. Pelakunya modul perlindungan web antivirus, yang bermasalah sesudah antivirus kedua ikut terpasang. Hasil berbeda antar-browser karena itu tidak otomatis membersihkan antivirus dari kecurigaan.
2. Fitur perlindungan web pada aplikasi VPN. Fitur ini bekerja terpisah dari terowongan VPN, sehingga tetap dapat menutup sambungan saat VPN terlihat mati.
3. Proxy sistem dan ekstensi pemfilter. Proxy yang menolak sebuah alamat umumnya menutup sambungan dengan rapi, bukan mereset paksa.

Di jaringan perantara:

4. Penyaring konten jaringan kantor, kampus, atau sekolah. Perangkat yang memeriksa nama situs pada sapaan pembuka TLS dapat menutup sambungan sebelum enkripsinya terbentuk. Karena belum ada jalur terenkripsi, perangkat itu pun tidak dapat menyisipkan halaman pemberitahuan tanpa memicu peringatan keamanan.
5. Portal login Wi-Fi publik yang belum dilewati. Sebagian hotspot menutup sambungan keluar sampai Anda menekan tombol setuju di halaman persetujuannya.

Satu hal justru perlu dikeluarkan dari daftar ini. Pemutusan akses ke situs yang dilarang di Indonesia bekerja lewat paket reset, bukan penutupan rapi, sehingga layarnya berbeda. Mekanisme tersebut dibahas di artikel ERR_CONNECTION_RESET. Bila yang Anda lihat "tiba-tiba menutup sambungan", arahkan kecurigaan ke perangkat lunak di komputer Anda atau ke penyaring di jaringan yang sedang dipakai.

Dua Uji Cepat untuk ERR_CONNECTION_CLOSED Tanpa Mengubah Setelan

Kedua uji berikut tidak mengubah setelan apa pun. Hasilnya menjawab satu pertanyaan yang menentukan arah perbaikan: apakah jabat tangan terenkripsinya pernah selesai.

Uji pertama: tanyakan kepada openssl. Perintah ini tersedia di macOS dan Linux, dan menampilkan hasil jabat tangan apa adanya:

openssl s_client -connect contoh.id:443

Perhatikan baris keluaran yang berawalan New,. Sambungan yang sehat menyebut nama algoritma enkripsinya, misalnya New, TLSv1.3, Cipher is TLS_AES_256.... Sambungan yang ditutup di tengah jabat tangan menulis New, (NONE), Cipher is (NONE) dan diakhiri pesan shutdown while in init. Baris kedua itu memastikan penutupannya terjadi sebelum enkripsi terbentuk.

Uji kedua: baca kalimat kegagalan curl, bukan hanya nomornya. Perintah curl sudah terpasang di macOS, Linux, dan Windows 10 versi 1803 ke atas. Di Windows, ketik curl.exe pada Command Prompt supaya tidak tertukar dengan perintah bawaan PowerShell:

curl -sSI https://contoh.id

Kalimat pada pesan kegagalannya menunjuk tiga kondisi yang berbeda:

• Empty reply from server berarti permintaan terkirim lalu jalurnya ditutup tanpa satu byte jawaban. Ini penutupan rapi setelah jabat tangan selesai.
• Pesan yang menyebut kegagalan TLS, misalnya SSL_ERROR_SYSCALL, berarti penutupan terjadi saat jabat tangan masih berlangsung. Cocokkan dengan hasil uji pertama.
• Connection reset by peer berarti bukan penutupan rapi melainkan pemutusan paksa, dan penanganannya ada di artikel ERR_CONNECTION_RESET.

Bila kedua uji berhasil sementara browser tetap gagal, masalahnya ada di dalam browser, dan Langkah #2 di bawah memisahkannya dalam sepuluh detik.

Pola sebaliknya sama informatifnya. Error yang muncul di semua browser yang terpasang justru mencoret seluruh isi browser dari daftar. Tersisa dua tersangka: perangkat lunak yang menyaring lalu lintas seluruh komputer, atau jaringan yang sedang dipakai. Kedua uji di atas menjawabnya karena berjalan di luar browser mana pun.

Untuk masalah pada satu halaman saja, file HAR dari alat pengembang adalah bukti paling ringkas untuk dikirim ke pengelola situs.

Cara Mengatasi ERR_CONNECTION_CLOSED di Chrome dan Windows 11

Kelima langkah berikut diurutkan dari yang paling tepat sasaran, bukan dari yang paling mudah. Masing-masing disertai syarat kapan tidak perlu dijalankan, dan berlaku untuk Windows 10 maupun 11.

Langkah #1: Kosongkan kumpulan jalur yang tersimpan Chrome

Buka chrome://net-internals/#sockets di tab baru, lalu tekan Close idle sockets dan Flush socket pools. Halaman ini memang berbahasa Inggris karena ditujukan untuk diagnosa, dan tidak memiliki padanan Indonesia.

Kedua tombol itu membuang seluruh jalur yang Chrome simpan, termasuk jalur basi penyebab error. Peringatan di sebelah tombol kedua perlu dibaca: ia dapat memutus halaman yang sedang aktif. Lewati langkah ini bila error muncul pada setiap pemuatan ulang, karena pola itu menunjuk penutupan yang konsisten.

Langkah #2: Buka halaman lewat jendela tamu

Klik ikon profil di pojok kanan atas Chrome, lalu pilih Buka Jendela Tamu. Mode ini berbeda dari jendela samaran: ia menjalankan profil kosong tanpa satu pun ekstensi, tanpa data situs, dan tanpa kebijakan yang menempel pada akun Anda.

Bila halaman terbuka di sana, nyalakan ekstensi satu per satu sampai pelakunya ketahuan; pemblokir iklan dan ekstensi keamanan adalah tersangka pertama. Bila tetap gagal, seluruh isi browser dapat Anda coret.

Langkah #3: Kecualikan situs dari pemeriksaan HTTPS antivirus

Buka pengaturan perlindungan web pada antivirus Anda, cari bagian pemeriksaan HTTPS, lalu tambahkan domain yang bermasalah ke daftar pengecualian — jauh lebih aman daripada mematikan seluruh pemeriksaan. Langkah rincinya dibahas di artikel ERR_CONNECTION_RESET, karena modul yang sama memunculkan kedua kode tersebut.

Lewati langkah ini bila uji pertama tadi menunjukkan jabat tangan terenkripsinya berhasil, sebab modul pemeriksa bekerja justru pada tahap itu.

Langkah #4: Periksa fitur perlindungan web pada aplikasi VPN

Buka aplikasi VPN Anda, termasuk yang sedang tidak tersambung, lalu cari fitur bernama sejenis threat protection, web protection, atau pemblokir iklan bawaan. Matikan sebentar, muat ulang halaman, lalu nyalakan kembali bila terbukti bukan penyebabnya. Aplikasi penghemat kuota di komputer bekerja dengan cara yang sama.

Langkah #5: Uji lewat jaringan lain

Sambungkan komputer ke hotspot ponsel, lalu buka alamat yang sama. Bila situs terbuka, penutupnya berada di jaringan asal — penyaring konten di router, perangkat pemeriksa di kantor, atau kebijakan jaringan kampus. Kirimkan hasil uji openssl beserta alamat situsnya ke tim TI.

Bila situs tetap gagal di dua jaringan dan empat langkah sebelumnya bersih, tersangkanya bergeser ke sisi server.

ERR_CONNECTION_CLOSED di HP dan Chrome Android

Di Chrome Android layar error ini lebih ringkas karena hanya menyisakan saran "Periksa sambungan". Kodenya tetap sama di Chrome Mobile mana pun, jadi err connection closed di Android maupun HP merek lain ditelusuri dengan logika yang sama seperti di komputer.

Android tidak menyediakan tombol pengosong jalur seperti di komputer. Padanan terdekatnya adalah menutup Chrome sepenuhnya dari daftar aplikasi terbaru lalu membukanya kembali, yang melepas seluruh jalur tersimpan. Cara itu sering cukup untuk kasus yang hilang-timbul.

• Aplikasi keamanan dengan perlindungan web. Antivirus Android dan aplikasi kontrol orang tua memeriksa lalu lintas situs seperti versi komputernya. Nonaktifkan fitur perlindungan webnya sebentar, lalu buka kembali halaman tersebut.
• Aplikasi pemblokir berbasis VPN lokal. Penghemat kuota dan pemblokir iklan mendaftarkan diri sebagai VPN agar dapat menyaring lalu lintas, dan satu daftar blokir yang terlalu agresif menutup sambungan ke domain tertentu.
• Wi-Fi berpenyaring konten. Error yang hanya muncul di satu Wi-Fi lalu hilang begitu berpindah ke paket data menunjuk penyaring di jaringan tersebut. Perangkat lain di jaringan yang sama akan mengalami hal serupa, dan itu uji pembeda yang paling cepat.
• Halaman web di dalam aplikasi. Aplikasi berbasis Android System WebView menampilkan net::ERR_CONNECTION_CLOSED alih-alih layar penuh. Perbarui Chrome dan WebView lewat Play Store, lalu ulangi di Chrome.

Pengguna iPhone menghadapi daftar yang lebih pendek. Seluruh browser di iOS memakai mesin jaringan bawaan sistem. Hasil yang sama di Chrome dan Safari karena itu mengarah ke profil VPN atau aplikasi penyaring di perangkat, bukan ke browsernya.

ERR_CONNECTION_CLOSED di Website Anda Sendiri

Laporan pengunjung paling mudah ditelusuri bila disertai jam kejadian, nama jaringan, IP publik pelapor, dan hasil uji openssl. Mintalah keempatnya sebelum mengubah konfigurasi.

Selaraskan batas jalur menganggur di semua lapisan. Jalur yang sengaja dibiarkan terbuka agar dapat dipakai ulang disebut keep-alive, dan setiap perangkat lunak punya batasnya sendiri. Nginx menutup jalur menganggur setelah 75 detik, atau setelah 1.000 permintaan pada jalur yang sama. Apache jauh lebih cepat: 5 detik dan 100 permintaan. Chrome sendiri menyimpan jalurnya sampai 300 detik.

Selisih itu wajar selama browser sempat melihat penutupannya. Masalah muncul ketika ada perantara. Perangkat pembagi beban atau proxy pembalik yang menahan jalur lebih lama daripada batas server di belakangnya akan memakai ulang jalur yang sudah ditutup. Aturan praktisnya: batas menganggur di perantara harus lebih pendek daripada batas di server — misalnya 60 detik pada perantara untuk Nginx yang menutup di detik ke-75.

Dua direktif inilah yang menentukan angka Nginx di atas:

keepalive_timeout 75s;
keepalive_requests 1000;

Cari aturan keamanan yang sengaja menutup sambungan. Manual ModSecurity menyebut aksi drop menutup sambungan TCP seketika dengan mengirim paket FIN, dan menganjurkannya untuk brute force serta denial of service karena menghemat bandwidth. Artinya pengunjung yang beberapa kali gagal masuk melihat layar ini, bukan halaman "akses ditolak" yang dapat dibaca. Periksa berkas aturan ModSecurity di server Anda:

grep -rn ',drop' /etc/modsecurity/

Bedakan proses mana yang berhenti. Aplikasi yang mati di belakang Nginx — misalnya proses PHP-FPM yang dihentikan sistem karena kehabisan memori — biasanya menghasilkan kode 502, sebab Nginx masih hidup dan sempat menjawab. Layar ini muncul ketika yang berhenti justru proses yang berhadapan langsung dengan pengunjung. Karena itu web server yang dimulai ulang pada jam sibuk lebih masuk akal dijadikan tersangka daripada skrip yang lambat.

Perhatikan apa yang dilihat pengunjung di belakang CDN. Website di belakang Cloudflare menampilkan halaman Error 520 ketika server asal menutup sambungan tanpa jawaban, bukan layar ERR_CONNECTION_CLOSED. Bila pengunjung domain berproxy tetap melihat layar ini, penutupnya berada di jalur antara pengunjung dan Cloudflare.

Penutupan pada tahap jabat tangan tidak pernah sampai ke error log web server, karena permintaannya belum sempat terbaca. Laporan error tanpa satu pun baris log pada jam yang sama justru menguatkan dugaan bahwa penutupnya ada di jaringan pengunjung.

Pada VPS yang Anda kelola sendiri, batas jalur menganggur dan aturan modul keamanan sepenuhnya di tangan Anda. Pada layanan web hosting, keduanya diatur penyedia, jadi kirimkan jam kejadian beserta hasil openssl ke tim dukungan agar mereka memeriksa perangkat di depan server.

Saran Perbaikan yang Meleset dari ERR_CONNECTION_CLOSED

Beberapa saran kerap dianjurkan untuk error ini, padahal bekerja di tahap yang berbeda. Menjalankannya tidak berbahaya, tetapi menghabiskan waktu yang lebih berguna untuk dua uji di atas.

Menghapus cache dan cookie. Isi cache baru dipakai sesudah jawaban diterima, jadi tidak ikut menentukan apakah sebuah jalur ditutup atau dibiarkan terbuka.

Mengganti DNS publik atau membersihkan cache DNS. Penerjemahan nama sudah terbukti berhasil sebelum kode ini muncul, sebab tanpa alamat server, browser tidak punya tujuan untuk disambungi.

Memasang ulang atau mereset Chrome. Langkah itu menghapus ekstensi, halaman awal, mesin pencari, dan tab yang disematkan — padahal jendela tamu menjawab pertanyaan yang sama dalam sepuluh detik.

Menyalakan VPN sebagai obat. Aplikasi VPN justru muncul sebagai penyebab pada daftar sebelumnya. Menambah perangkat lunak yang ikut membaca lalu lintas Anda memperpanjang daftar tersangka.

Yang Perlu Ditimbang Sebelum Mengubah Setelan

Sebagian perbaikan di atas menukar satu masalah dengan masalah lain, dan itu perlu Anda sadari lebih dulu.

Mematikan pemeriksaan HTTPS mengurangi perlindungan. Berkas berbahaya yang dikirim lewat sambungan terenkripsi tidak lagi diperiksa. Pengecualian untuk satu domain tepercaya jauh lebih seimbang.

Mengosongkan kumpulan jalur memutus yang sedang berjalan. Unduhan besar, panggilan video, dan formulir yang sedang terkirim ikut terputus, jadi jalankan saat tidak ada pekerjaan yang menggantung.

Menaikkan batas jalur menganggur menahan kapasitas server. Setiap jalur yang hidup memakai slot koneksi dan memori meski tidak dilewati lalu lintas. Naikkan secukupnya untuk menutup selisih dengan perantara.

Melonggarkan aturan modul keamanan membuka celah. Aturan yang menutup sambungan setelah beberapa kali gagal masuk memang ikut mengenai pengunjung yang sah. Menaikkan ambangnya lebih baik daripada mematikannya.

Bila kedua uji sudah dijalankan dan hasilnya menunjuk server milik pihak lain, berhentilah di sana. Kirimkan hasil openssl, jam kejadian, dan IP publik Anda kepada pengelolanya. Tiga keterangan itu memangkas waktu penanganan jauh lebih banyak daripada laporan "website Anda tidak bisa dibuka".

Pertanyaan Seputar ERR_CONNECTION_CLOSED

Apakah server yang menutup sambungan berarti sedang mati?

Justru sebaliknya. Server yang benar-benar mati tidak dapat menutup sambungan dengan tertib, karena penutupan itu sendiri membutuhkan pihak yang masih hidup untuk mengirimkannya. Yang mati biasanya menghasilkan penolakan atau keheningan sampai waktunya habis.

Kenapa errornya hilang sendiri ketika halaman dimuat ulang?

Pola itu khas jalur menganggur yang ditutup server tepat saat browser hendak memakainya. Pemuatan ulang membuka jalur baru, sehingga berhasil. Bila polanya berulang beberapa kali sehari pada situs yang sama, penyebabnya ada di batas jalur menganggur yang tidak selaras antara server dan perantara di depannya.

Kenapa hanya satu gambar atau skrip yang gagal, sementara halamannya terbuka?

Artinya jalur yang dipakai bersama oleh beberapa berkas ditutup di tengah pemuatan halaman. Halaman utamanya sudah diterima lebih dulu, jadi yang Anda lihat adalah halaman dengan gambar kosong, bukan layar error. Pemakaian jalur bersama untuk banyak berkas sekaligus dibahas di artikel HTTP/2.

Kapan paket FIN yang sama menghasilkan ERR_EMPTY_RESPONSE?

ERR_EMPTY_RESPONSE dan ERR_CONNECTION_CLOSED sama-sama lahir dari penutupan rapi. Pembedanya satu: ERR_EMPTY_RESPONSE muncul pada jalur yang baru dibuat, ERR_CONNECTION_CLOSED pada jalur yang sudah pernah dipakai. Layarnya pun berbeda — yang pertama berjudul "Halaman ini tidak berfungsi".

Browser lain di komputer yang sama membukanya normal, apa artinya?

Kemungkinan terbesarnya browser itu memakai tumpukan jaringan yang berbeda, atau tidak dilewati modul pemeriksa yang sama. Hasil yang berbeda menunjuk ke sesuatu yang menempel pada satu browser saja, seperti ekstensi atau modul perlindungan web. Namun hasil yang berbeda tidak membuktikan antivirus bukan penyebabnya, karena sebagian modul memang hanya menyaring browser tertentu.

Kenapa error ini muncul setelah beberapa kali gagal masuk ke panel?

Aturan anti-brute-force di banyak server sengaja menutup sambungan dari IP publik yang mencurigakan, dan sebagian aturan tersebut memilih penutupan rapi. Tunggu masa blokirnya habis, atau hubungi penyedia dengan menyertakan IP publik Anda supaya dilepaskan lebih cepat.

Kesimpulan

ERR_CONNECTION_CLOSED artinya sambungan ditutup dengan tertib lewat paket FIN, bukan koneksi yang putus. Kode ini hanya lahir pada jalur yang sudah pernah dipakai, sehingga kemunculannya justru membuktikan browser Anda sempat tersambung dengan baik.

Chrome mengirim ulang permintaan diam-diam sebelum menyerah, jadi layar yang benar-benar tampil menandakan penutupan yang konsisten — paling sering pada tahap jabat tangan terenkripsi. Mulailah dari dua uji yang tidak mengubah setelan: jalankan openssl s_client, lalu baca kalimat kegagalan curl. Sesudah itu baru kosongkan jalur tersimpan Chrome dan periksa perangkat lunak yang ikut membaca lalu lintas Anda. Bila hasilnya menunjuk jaringan atau server milik pihak lain, kirimkan bukti tersebut beserta jam kejadian kepada pengelolanya.

Semoga artikel ini membantu.