ERR_CONNECTION_RESET pada satu laman

Satu laman gagal dengan ERR_CONNECTION_RESET? Semakan langkah demi langkah: rangkaian, extension, proksi, DNS, jam, dan penapisan SNI dengan curl.

Setiap laman lain dimuatkan, tetapi satu laman terus gagal dengan "This site can't be reached" dan ERR_CONNECTION_RESET. Memuat semula tidak membantu. Panduan ini ialah pepohon keputusan. Setiap langkah sama ada menemui punca atau menolak satu kemungkinan, dan urutannya bermula daripada semakan paling cepat hingga yang paling jelas.

Apa sebenarnya maksud "connection reset"

Sambungan TCP boleh tamat dengan sopan, atau diputuskan serta-merta dengan paket reset (RST). Chrome dan pelayar Chromium lain menunjukkan ERR_CONNECTION_RESET apabila reset tiba sebelum halaman dihantar. Firefox menunjukkan halaman serupa "The connection was reset". Reset itu boleh datang daripada pelayan laman, daripada perisian pada komputer anda sendiri, atau daripada peranti di tengah rangkaian yang berpura-pura menjadi salah satu daripada dua hujung.

Itulah sebabnya ralat yang sama mempunyai punca yang begitu berbeza. Helahnya ialah mengetahui siapa yang menghantar reset dan bila.

Langkah 1: adakah benar-benar hanya satu laman?

Buka dua atau tiga laman yang tidak berkaitan, termasuk satu yang jarang anda lawati. Jika beberapa gagal, masalahnya ialah sambungan, penghala atau peranti anda, bukan laman itu. Mulakan semula penghala dan semak sama ada peranti lain pada rangkaian yang sama berfungsi. Jika hanya satu laman gagal, teruskan.

Langkah 2: adakah hanya pada satu rangkaian?

Ini ujian yang paling bermaklumat, dan ia percuma. Buka laman itu menggunakan data mudah alih dan bukan Wi-Fi, atau sambungkan komputer riba anda ke telefon (tethering). Jika laman itu dibuka pada satu rangkaian dan reset pada rangkaian lain, rangkaian yang gagal itu terlibat. Punca biasa diterangkan dalam Mengapa laman dibuka dengan data mudah alih tetapi tidak dengan Wi-Fi? Jika ia gagal di mana-mana, laman itu sendiri atau peranti anda lebih mungkin puncanya.

Langkah 3: pelayar lain, tetingkap peribadi, tanpa extension

Cuba tetingkap peribadi atau inkognito, di mana kebanyakan extension dimatikan secara lalai. Kemudian cuba pelayar lain. Penyekat iklan, extension privasi, tambahan "safe browsing" dan dasar pelayar korporat semuanya boleh menutup sambungan. Jika laman itu berfungsi dalam tetingkap peribadi, hidupkan semula extension satu demi satu sehingga ralat itu kembali.

Langkah 4: matikan VPN lain, proksi dan imbasan HTTPS

Apa-apa sahaja yang berada di laluan trafik anda boleh me-reset sambungan yang tidak disukainya:

  • Aplikasi VPN atau proksi lain. Matikannya sepenuhnya dan uji semula.
  • "HTTPS scanning" atau "web protection" antivirus. Sesetengah suit keselamatan memeriksa trafik disulitkan dan memutuskan sambungan yang dianggap berisiko. Jeda ciri itu sebentar untuk menguji, kemudian hidupkannya semula.
  • Proksi sistem. Di Windows, lihat dalam Settings → Network & internet → Proxy. Di macOS, lihat dalam System Settings → Network → sambungan anda → Details → Proxies. Proksi yang anda tidak kenali, atau proksi tertinggal daripada aplikasi lama, boleh merosakkan laman tertentu. Buang hanya yang anda tahu anda tetapkan sendiri, dan tanya pasukan IT anda pada komputer yang diurus.

Langkah 5: kosongkan cache DNS dan cuba DNS disulitkan

Jika laman itu berpindah pelayan, peranti anda mungkin masih menggunakan alamat lama, yang boleh reset atau tamat masa. Kosongkan cache:

# 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"

Seterusnya, bandingkan jawapan rangkaian anda dengan penyelesai bebas: nslookup example.com dan kemudian nslookup example.com 1.1.1.1. Jika berbeza dan hanya jawapan bebas yang berfungsi, DNS rangkaian anda puncanya. DNS disulitkan membaiki sekatan jenis itu, seperti diterangkan dalam DoH dan DoT. Alamat yang berbeza sahaja bukan bukti, kerana laman besar memberikan pelayan berbeza kepada rangkaian berbeza.

Langkah 6: semak tarikh dan masa

Jam yang salah biasanya menghasilkan ralat sijil dan bukan reset, tetapi ia semakan sepuluh saat. Hidupkan tarikh dan masa automatik, kemudian muat semula. Jangan sekali-kali klik melepasi amaran sijil untuk "melepasi" halaman yang gagal.

Langkah 7: adakah laman itu down?

Semak halaman status laman itu atau akaun sosial rasminya, atau gunakan penyemak awam "down for everyone or just me". Jika laman itu down, tunggu. Ingat bahawa penyemak itu menguji dari pelayannya sendiri, jadi "up" di sana tidak membuktikan ia boleh dicapai dari rangkaian anda.

Langkah 8: baca reset dengan curl

Jika laman itu masih reset pada satu rangkaian sahaja, lihat jabat tangan itu sendiri. curl terbina dalam Windows 10 dan 11, macOS dan kebanyakan sistem Linux. Jalankannya dalam terminal dengan laman anda menggantikan example.com:

curl -v https://example.com

Sambungan yang sihat mencetak beberapa baris seperti ini, kemudian pengepala halaman. Perkataan tepatnya bergantung pada 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

Corak yang menunjukkan penapisan berasaskan nama kelihatan 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

Bacanya baris demi baris. "Connected" bermakna sambungan TCP ke alamat IP pelayan berjaya, jadi alamat itu tidak disekat terus. "Client hello" ialah mesej TLS pertama, dan ia membawa nama laman dalam teks biasa dalam medan yang dipanggil SNI. "Connection reset by peer" sejurus selepasnya bermakna ada sesuatu memutuskan sambungan sebaik sahaja nama itu kelihatan, sebelum pelayan sempat menjawab. Sesetengah rangkaian sebaliknya menutup sambungan secara senyap, yang dilaporkan curl sebagai penghujung fail yang tidak dijangka atau ralat SSL "syscall", dan Chrome mungkin menunjukkan ERR_CONNECTION_CLOSED.

Bandingkan dengan hasil lain:

Apa yang ditunjukkan curlKemungkinan maksud
Could not resolve hostKegagalan DNS atau sekatan DNS. Kembali ke Langkah 5
Tersekat di "Trying", kemudian tamat masaAlamat IP tidak dapat dicapai: sekatan IP, firewall atau pelayan down
Reset atau ditutup sejurus selepas "Client hello", hanya pada satu rangkaianMungkin penapisan SNI pada rangkaian itu
Jabat tangan selesai, kemudian kod ralat HTTPLaman itu menjawab. Masalahnya di pihak laman atau akaun anda

Untuk menguatkan bukti, jalankan arahan yang sama pada rangkaian lain. Jika ia berfungsi di sana, penapis itu milik rangkaian pertama. Ini bukan tekaan tentang keadaan yang jarang berlaku. Kajian OONI dan Centre for Internet and Society pada 2020 mendapati sambungan TLS diputuskan sejurus selepas ClientHello untuk laman tertentu pada Bharti Airtel, dan SNI digabungkan dengan alamat destinasi pada Reliance Jio. CIS secara berasingan melaporkan Jio menggunakan pemeriksaan SNI, dan laporan itu dibincangkan di forum ntc.party. Latar belakang lanjut: Cara menyemak sama ada laman web disekat.

Di mana GreenTunnel membantu, dan di mana tidak

GreenTunnel ialah VPN tempatan pada peranti yang kami buat, jadi baca bahagian ini dengan mengetahui kami berat sebelah. Ia menyasarkan dua daripada punca di atas:

  • Penapisan SNI. Ia membentuk semula paket TLS pertama sesuatu sambungan, contohnya dengan memecahkan Client hello atau rekod TLS-nya, supaya penapis yang mencari nama laman tidak menemuinya dalam satu bahagian. Cara ia berfungsi: SNI, DPI dan pemecahan rekod TLS.
  • Sekatan DNS. Carian melalui DNS disulitkan (DoH atau DoT) ke Cloudflare, Google atau Quad9, jadi rangkaian tidak boleh diam-diam memulangkan jawapan palsu.

Alat Periksa URL-nya menjalankan perbandingan daripada Langkah 5 dan 8 untuk satu laman pada rangkaian yang anda gunakan, dan menyatakan sama ada laman itu ditapis nama, diberi jawapan DNS palsu, disekat mengikut alamat IP, atau baik. Jika ada teknik yang berfungsi, anda boleh ketik Guna teknik ini.

Ia tidak akan membantu apabila:

  • laman itu down, atau reset datang daripada pelayan laman itu sendiri atau perkhidmatan perlindungannya,
  • sekatan adalah mengikut alamat IP, yang kelihatan sebagai tamat masa di "Trying",
  • tempat kerja, sekolah atau rangkaian terurus lain sengaja menyekat laman itu. Peraturan rangkaian itu ditetapkan oleh pemiliknya. Hormati dasar itu dan tanya pentadbir jika anda memerlukan akses untuk kerja anda,
  • puncanya ialah extension, antivirus atau DNS lapuk pada peranti anda sendiri. Baiki perkara itu secara langsung.

Had yang jujur dan penggunaan bertanggungjawab

GreenTunnel tidak menyembunyikan alamat IP anda dan bukan alat anonimiti. Ia tidak dapat memintas sekatan IP, penutupan rangkaian atau senarai benar, dan ia tidak menjanjikan akan membuka mana-mana laman tertentu. Penapis berubah dari semasa ke semasa dan berbeza antara ISP, jadi hasil hari ini mungkin berbeza bulan depan.

Soalan lazim

Adakah ERR_CONNECTION_RESET sentiasa tanda laman disekat?

Tidak. Extension, imbasan HTTPS antivirus, proksi tertinggal, DNS lapuk atau laman itu sendiri boleh menyebabkannya. Sekatan menjadi mungkin hanya apabila reset berlaku pada satu rangkaian, sejurus selepas Client hello, dan laman itu berfungsi di tempat lain.

Mengapa laman berfungsi dengan data mudah alih tetapi reset pada Wi-Fi?

Kedua-dua rangkaian menggunakan penyedia, penyelesai dan penapis yang berbeza. Salah satunya mungkin membaca nama laman atau menjawab DNS secara berbeza. Jalankan curl -v pada kedua-duanya dan bandingkan di mana setiap satu berhenti.

Adakah mengosongkan kuki akan membaiki connection reset?

Jarang. Kuki dihantar selepas sambungan diwujudkan, manakala kebanyakan reset berlaku sebelum itu. Mengosongkan data laman boleh membantu apabila laman itu sendiri menolak sesi yang rosak, yang biasanya menunjukkan ralat HTTP.

Bolehkah GreenTunnel membaiki reset yang disebabkan firewall syarikat saya?

Ia bukan untuk itu. Rangkaian terurus menyekat laman mengikut dasar pemiliknya. Tanya pentadbir dan jangan cuba memintasnya.

Sumber

← Semua artikel