ERR_CONNECTION_RESET di satu situs saja

Satu situs gagal dengan ERR_CONNECTION_RESET, yang lain normal? Cek langkah demi langkah: jaringan, ekstensi, proxy, DNS, jam, dan filter SNI dengan curl.

Semua situs lain terbuka, tetapi satu situs terus gagal dengan "This site can't be reached" dan ERR_CONNECTION_RESET. Memuat ulang tidak membantu. Panduan ini berupa pohon keputusan. Setiap langkah menemukan penyebabnya atau menyingkirkan satu kemungkinan, dan urutannya dimulai dari pemeriksaan tercepat sampai yang paling menentukan.

Apa sebenarnya arti "connection reset"

Koneksi TCP bisa berakhir dengan sopan, atau langsung diputus dengan paket reset (RST). Chrome dan browser Chromium lain menampilkan ERR_CONNECTION_RESET ketika reset datang sebelum halaman terkirim. Firefox menampilkan halaman serupa, "The connection was reset". Reset bisa datang dari server situs, dari perangkat lunak di komputer Anda sendiri, atau dari perangkat di tengah jaringan yang berpura-pura menjadi salah satu ujungnya.

Itulah sebabnya error yang sama punya penyebab yang sangat beragam. Kuncinya adalah mencari tahu siapa yang mengirim reset dan kapan.

Langkah 1: benarkah hanya satu situs?

Buka dua atau tiga situs yang tidak berkaitan, termasuk satu yang jarang Anda kunjungi. Jika beberapa gagal, masalahnya ada di koneksi, router, atau perangkat Anda, bukan di situs itu. Restart router dan periksa apakah perangkat lain di jaringan yang sama berfungsi. Jika hanya satu situs yang gagal, lanjutkan.

Langkah 2: apakah hanya di satu jaringan?

Ini tes yang paling informatif, dan gratis. Buka situsnya lewat data seluler, bukan Wi-Fi, atau sambungkan laptop ke hotspot ponsel. Jika situs terbuka di satu jaringan dan ter-reset di jaringan lain, jaringan yang gagal ikut berperan. Penyebab umumnya dibahas di Kenapa situs terbuka di data seluler tapi tidak di Wi-Fi? Jika gagal di mana-mana, kemungkinan besar penyebabnya situs itu sendiri atau perangkat Anda.

Langkah 3: browser lain, jendela privat, tanpa ekstensi

Coba jendela privat atau incognito, tempat sebagian besar ekstensi nonaktif secara bawaan. Lalu coba browser lain. Pemblokir iklan, ekstensi privasi, add-on "safe browsing", dan kebijakan browser perusahaan semuanya bisa menutup koneksi. Jika situs berfungsi di jendela privat, nyalakan kembali ekstensi satu per satu sampai error muncul lagi.

Langkah 4: matikan VPN lain, proxy, dan pemindaian HTTPS

Apa pun yang berada di jalur lalu lintas Anda bisa me-reset koneksi yang tidak disukainya:

  • Aplikasi VPN atau proxy lain. Matikan sepenuhnya lalu uji lagi.
  • "HTTPS scanning" atau "web protection" di antivirus. Sebagian paket keamanan memeriksa lalu lintas terenkripsi dan memutus koneksi yang dianggap berisiko. Jeda fitur itu sebentar untuk menguji, lalu nyalakan kembali.
  • Proxy sistem. Di Windows, lihat di Settings → Network & internet → Proxy. Di macOS, lihat di System Settings → Network → koneksi Anda → Details → Proxies. Proxy yang tidak Anda kenali, atau sisa dari aplikasi lama, bisa merusak situs tertentu. Hapus hanya yang Anda tahu pasti Anda pasang sendiri, dan tanyakan ke tim IT jika komputernya dikelola kantor.

Langkah 5: bersihkan cache DNS dan coba DNS terenkripsi

Jika situsnya pindah server, perangkat Anda mungkin masih memakai alamat lama, yang bisa ter-reset atau timeout. Bersihkan cache-nya:

# Windows (Command Prompt)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

Selanjutnya, bandingkan jawaban jaringan Anda dengan resolver independen: nslookup example.com lalu nslookup example.com 1.1.1.1. Jika hasilnya berbeda dan hanya jawaban independen yang berfungsi, DNS jaringan Anda yang bermasalah. DNS terenkripsi mengatasi blokir jenis ini, seperti dijelaskan di DoH dan DoT. Alamat yang berbeda saja belum menjadi bukti, karena situs besar memberikan server berbeda ke jaringan yang berbeda.

Langkah 6: periksa tanggal dan jam

Jam yang salah biasanya menimbulkan error sertifikat, bukan reset, tetapi ini pemeriksaan sepuluh detik. Nyalakan tanggal dan jam otomatis, lalu muat ulang. Jangan pernah mengklik lewat peringatan sertifikat hanya untuk "melewati" halaman yang gagal.

Langkah 7: apakah situsnya down?

Periksa halaman status situs atau akun media sosial resminya, atau pakai pemeriksa publik "down for everyone or just me". Jika situsnya down, tunggu. Ingat bahwa pemeriksa itu menguji dari server mereka sendiri, jadi status "up" di sana tidak membuktikan situs bisa dijangkau dari jaringan Anda.

Langkah 8: baca reset dengan curl

Jika situs masih ter-reset hanya di satu jaringan, lihat handshake-nya secara langsung. curl sudah tersedia di Windows 10 dan 11, macOS, dan sebagian besar sistem Linux. Jalankan di terminal dengan situs Anda sebagai ganti example.com:

curl -v https://example.com

Koneksi yang sehat menampilkan beberapa baris seperti ini, lalu header halaman. Kata-kata persisnya tergantung versi curl dan pustaka TLS Anda:

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
< HTTP/2 200

Pola yang menunjukkan penyaringan berdasarkan nama terlihat seperti ini:

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

Baca baris demi baris. "Connected" berarti koneksi TCP ke alamat IP server berhasil, jadi alamatnya tidak diblokir total. "Client hello" adalah pesan TLS pertama, dan pesan ini membawa nama situs dalam teks biasa di kolom bernama SNI. "Connection reset by peer" tepat setelahnya berarti ada yang memutus koneksi begitu nama itu terlihat, sebelum server sempat menjawab. Sebagian jaringan menutup koneksi diam-diam, yang dilaporkan curl sebagai akhir file yang tidak terduga atau error SSL "syscall", dan Chrome mungkin menampilkan ERR_CONNECTION_CLOSED.

Bandingkan dengan hasil lain:

Yang ditampilkan curlKemungkinan artinya
Could not resolve hostDNS gagal atau blokir DNS. Kembali ke Langkah 5
Macet di "Trying", lalu timeoutAlamat IP tidak bisa dijangkau: blokir IP, firewall, atau server down
Reset atau tertutup tepat setelah "Client hello", hanya di satu jaringanKemungkinan filter SNI di jaringan itu
Handshake selesai, lalu muncul kode error HTTPSitus sudah menjawab. Masalahnya ada di pihak situs atau di akun Anda

Untuk memperkuat dugaan, jalankan perintah yang sama di jaringan lain. Jika berhasil di sana, filternya milik jaringan pertama. Ini bukan tebakan soal situasi langka. Studi OONI dan Centre for Internet and Society tahun 2020 menemukan koneksi TLS diputus tepat setelah ClientHello untuk situs tertentu di Bharti Airtel, dan SNI yang dikombinasikan dengan alamat tujuan di Reliance Jio. CIS secara terpisah melaporkan Jio memakai inspeksi SNI, dan laporan itu dibahas di forum ntc.party. Latar belakang lebih lanjut: Cara mengecek apakah sebuah situs diblokir.

Di mana GreenTunnel membantu, dan di mana tidak

GreenTunnel adalah VPN lokal di perangkat yang kami buat, jadi baca bagian ini dengan mengingat bahwa kami tidak netral. Ia menyasar dua penyebab di atas:

  • Filter SNI. Ia mengubah bentuk paket TLS pertama sebuah koneksi, misalnya dengan memecah Client hello atau record TLS-nya, sehingga filter yang mencari nama situs tidak menemukannya dalam satu potong. Cara kerjanya: SNI, DPI, dan pemecahan record TLS.
  • Blokir DNS. Pencarian DNS lewat DNS terenkripsi (DoH atau DoT) ke Cloudflare, Google, atau Quad9, sehingga jaringan tidak bisa diam-diam memberikan jawaban palsu.

Alat Periksa URL menjalankan perbandingan dari Langkah 5 dan 8 untuk satu situs di jaringan yang sedang Anda pakai, lalu menyebut apakah situs itu terkena filter nama, diberi jawaban DNS palsu, diblokir lewat alamat IP, atau baik-baik saja. Jika ada teknik yang berhasil, Anda bisa mengetuk Gunakan teknik ini.

Ia tidak akan membantu jika:

  • situsnya down, atau reset datang dari server situs itu sendiri atau layanan perlindungannya,
  • blokirnya berdasarkan alamat IP, yang terlihat sebagai timeout di "Trying",
  • jaringan kantor, sekolah, atau jaringan terkelola lain sengaja memblokir situs itu. Aturan jaringan itu hak pemiliknya. Hormati kebijakannya dan minta ke administrator jika Anda butuh akses untuk pekerjaan,
  • penyebabnya ekstensi, antivirus, atau DNS usang di perangkat Anda sendiri. Perbaiki langsung di sana.

Batasan yang jujur dan penggunaan yang bertanggung jawab

GreenTunnel tidak menyembunyikan alamat IP Anda dan bukan alat anonimitas. Ia tidak bisa menembus blokir IP, pemutusan jaringan, atau daftar izin (allowlist), dan tidak menjanjikan bisa membuka situs tertentu. Filter berubah dari waktu ke waktu dan berbeda antar ISP, jadi hasil hari ini bisa berbeda bulan depan.

Pertanyaan yang sering diajukan

Apakah ERR_CONNECTION_RESET selalu tanda bahwa situs diblokir?

Tidak. Ekstensi, pemindaian HTTPS antivirus, proxy sisa, DNS usang, atau situs itu sendiri bisa menjadi penyebabnya. Blokir baru patut dicurigai jika reset terjadi di satu jaringan, tepat setelah Client hello, dan situsnya berfungsi di tempat lain.

Kenapa situs berfungsi di data seluler tetapi ter-reset di Wi-Fi?

Kedua jaringan memakai penyedia, resolver, dan filter yang berbeda. Salah satunya mungkin membaca nama situs atau menjawab DNS secara berbeda. Jalankan curl -v di keduanya dan bandingkan di mana masing-masing berhenti.

Apakah menghapus cookie bisa memperbaiki connection reset?

Jarang. Cookie dikirim setelah koneksi terbentuk, sementara sebagian besar reset terjadi sebelumnya. Menghapus data situs bisa membantu jika situs itu sendiri menolak sesi yang rusak, yang biasanya justru menampilkan error HTTP.

Bisakah GreenTunnel memperbaiki reset yang disebabkan firewall kantor saya?

Itu bukan tujuannya. Jaringan terkelola memblokir situs sesuai kebijakan pemiliknya. Tanyakan ke administrator, jangan mencoba mengakalinya.

Sumber

← Semua artikel