ERR_CONNECTION_RESET sa iisang site lang

Isang site lang ang may ERR_CONNECTION_RESET? Sunud-sunod na pagsusuri: network, extension, proxy, DNS, orasan, at SNI filtering gamit ang curl.

Na-publish 9 minutong basaBasahin sa Ingles →

Naglo-load ang lahat ng ibang site, pero may isang paulit-ulit na pumapalya na may "This site can't be reached" at ERR_CONNECTION_RESET. Walang nagagawa ang pag-reload. Isang decision tree ang gabay na ito. Bawat hakbang ay alinman sa nakakahanap ng dahilan o nag-aalis ng isang posibilidad, at ang pagkakasunod ay mula sa pinakamabilis na pagsusuri hanggang sa pinakamalinaw.

Ano talaga ang ibig sabihin ng "connection reset"

Puwedeng magtapos nang maayos ang isang TCP connection, o puwede itong biglang putulin gamit ang reset packet (RST). Ipinapakita ng Chrome at ng ibang Chromium browser ang ERR_CONNECTION_RESET kapag dumating ang reset bago maihatid ang pahina. Nagpapakita ang Firefox ng katulad na pahinang "The connection was reset". Puwedeng manggaling ang reset sa server ng site, sa software sa sarili mong computer, o sa isang device sa gitna ng network na nagpapanggap na isa sa dalawang dulo.

Iyan ang dahilan kung bakit ibang-iba ang mga sanhi ng iisang error. Ang susi ay alamin sino ang nagpadala ng reset at kailan.

Hakbang 1: iisang site lang ba talaga?

Magbukas ng dalawa o tatlong walang kaugnayang site, kasama ang isang bihira mong bisitahin. Kung ilan ang pumapalya, ang koneksyon, router o device mo ang problema, hindi ang iisang site na iyon. I-restart ang router at tingnan kung gumagana ang ibang device sa parehong network. Kung isang site lang ang pumapalya, magpatuloy.

Hakbang 2: iisang network lang ba?

Ito ang pinakamaraming naibibigay na impormasyon, at libre ito. Buksan ang site gamit ang mobile data sa halip na Wi-Fi, o i-tether ang laptop mo sa phone mo. Kung nagbubukas ang site sa isang network at nagre-reset sa isa pa, may kinalaman ang network na pumapalya. Ipinaliwanag ang mga karaniwang dahilan sa Bakit nagbubukas ang site sa mobile data pero hindi sa Wi-Fi? Kung pumapalya ito kahit saan, mas malamang na ang site mismo o ang device mo ang dahilan.

Hakbang 3: ibang browser, private window, walang extension

Subukan ang private o incognito window, kung saan naka-off bilang default ang karamihan ng extension. Saka subukan ang ibang browser. Kayang isara ng mga ad blocker, privacy extension, "safe browsing" add-on at corporate browser policy ang mga koneksyon. Kung gumagana ang site sa private window, i-on muli ang mga extension mo nang isa-isa hanggang bumalik ang error.

Hakbang 4: i-off ang ibang VPN, proxy at HTTPS scanning

Kayang i-reset ng anumang nasa daanan ng traffic mo ang koneksyong ayaw nito:

  • Ibang VPN o proxy app. I-off ito nang buo at subukan ulit.
  • "HTTPS scanning" o "web protection" ng antivirus. May mga security suite na sumusuri sa encrypted traffic at pinuputol ang mga koneksyong itinuturing nilang mapanganib. Pansamantalang i-pause ang feature na iyon para sumubok, saka i-on ulit.
  • Ang system proxy. Sa Windows, tingnan sa Settings → Network & internet → Proxy. Sa macOS, tingnan sa System Settings → Network → ang koneksyon mo → Details → Proxies. Puwedeng masira ang ilang site dahil sa proxy na hindi mo kilala, o naiwan mula sa lumang app. Tanggalin lang ang alam mong ikaw mismo ang nag-set, at magtanong sa IT team mo kung managed computer ito.

Hakbang 5: i-clear ang DNS cache at subukan ang encrypted DNS

Kung lumipat ng server ang site, baka ginagamit pa ng device mo ang lumang address, na puwedeng mag-reset o mag-time out. I-flush ang mga 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"

Susunod, ihambing ang sagot ng network mo sa isang independiyenteng resolver: nslookup example.com at pagkatapos ay nslookup example.com 1.1.1.1. Kung magkaiba sila at ang independiyenteng sagot lang ang gumagana, ang DNS ng network mo ang problema. Inaayos ng encrypted DNS ang ganoong uri ng block, gaya ng ipinaliwanag sa DoH at DoT. Hindi patunay ang magkaibang address lang, dahil nagbibigay ang malalaking site ng iba't ibang server sa iba't ibang network.

Hakbang 6: tingnan ang petsa at oras

Karaniwang certificate error ang idinudulot ng maling orasan sa halip na reset, pero sampung segundo lang ang pagsusuring ito. I-on ang awtomatikong petsa at oras, saka mag-reload. Huwag kailanman mag-click lampas sa isang certificate warning para "malampasan" ang pumapalyang pahina.

Hakbang 7: down ba ang site?

Tingnan ang status page o opisyal na social account ng site, o gumamit ng pampublikong "down for everyone or just me" checker. Kung down ang site, maghintay. Tandaan na sumusubok ang checker mula sa sarili nitong mga server, kaya hindi patunay ang "up" doon na naaabot ito mula sa network mo.

Hakbang 8: basahin ang reset gamit ang curl

Kung nagre-reset pa rin ang site sa iisang network lang, tingnan ang handshake mismo. Built-in ang curl sa Windows 10 at 11, macOS at karamihan ng Linux system. Patakbuhin ito sa terminal at ilagay ang site mo kapalit ng example.com:

curl -v https://example.com

Nagpi-print ang malusog na koneksyon ng ilang linya tulad nito, saka ang mga header ng pahina. Nakadepende ang eksaktong salita sa bersyon ng curl at sa TLS library mo:

*   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

Ganito ang itsura ng pattern na tumuturo sa pag-filter batay sa pangalan:

*   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

Basahin ito linya por linya. Ang "Connected" ay nangangahulugang gumana ang TCP connection sa IP address ng server, kaya hindi tahasang naka-block ang address. Ang "Client hello" ang unang TLS message, at dala nito ang pangalan ng site bilang plain text sa field na tinatawag na SNI. Ang "Connection reset by peer" kasunod mismo nito ay nangangahulugang may pumutol sa koneksyon nang makita ang pangalang iyon, bago pa makasagot ang server. May mga network na tahimik na isinasara ang koneksyon sa halip, na iniuulat ng curl bilang di-inaasahang end of file o SSL "syscall" error, at maaaring ipakita ng Chrome ang ERR_CONNECTION_CLOSED.

Ihambing sa ibang resulta:

Ano ang ipinapakita ng curlMalamang na kahulugan
Could not resolve hostDNS failure o DNS blocking. Bumalik sa Hakbang 5
Natigil sa "Trying", saka nag-timeoutHindi maabot ang IP address: IP block, firewall o down na server
Na-reset o naisara kasunod mismo ng "Client hello", sa iisang network langMalamang SNI filtering sa network na iyon
Natapos ang handshake, saka may HTTP error codeSumagot ang site. Nasa panig nito o sa account mo ang problema

Para patibayin ang kaso, patakbuhin ang parehong command sa ibang network. Kung gumagana ito roon, pag-aari ng unang network ang filter. Hindi ito hula tungkol sa bihirang sitwasyon. Natuklasan ng isang pag-aaral ng OONI at Centre for Internet and Society noong 2020 na pinuputol ang mga TLS connection kasunod mismo ng ClientHello para sa ilang site sa Bharti Airtel, at SNI na sinamahan ng destination address sa Reliance Jio. Hiwalay na iniulat ng CIS na gumagamit ang Jio ng SNI inspection, at pinag-usapan ang ulat sa ntc.party forum. Dagdag na background: Paano malalaman kung naka-block ang isang website.

Saan nakakatulong ang GreenTunnel, at saan hindi

Ang GreenTunnel ay isang on-device na local VPN na gawa namin, kaya basahin ang bahaging ito nang alam mong may kinikilingan kami. Tinatarget nito ang dalawa sa mga dahilan sa itaas:

  • SNI filtering. Binabago nito ang hugis ng mga unang TLS packet ng isang koneksyon, halimbawa sa paghahati ng Client hello o ng TLS record nito, para hindi ito makita nang buo ng filter na naghahanap ng pangalan ng site. Paano ito gumagana: SNI, DPI at TLS record splitting.
  • DNS blocking. Dumadaan ang mga lookup sa encrypted DNS (DoH o DoT) papunta sa Cloudflare, Google o Quad9, kaya hindi tahimik na makapagbabalik ng pekeng sagot ang network.

Pinapatakbo ng Inspect URL tool nito ang mga paghahambing mula sa Hakbang 5 at 8 para sa isang site sa network na kinaroroonan mo, at sinasabi kung naka-filter ang pangalan ng site, binigyan ng pekeng DNS answer, naka-block ayon sa IP address, o maayos. Kung may gumaganang technique, puwede mong i-tap ang Use this technique.

Hindi ito makakatulong kapag:

  • down ang site, o galing ang reset sa sariling server o protection service ng site,
  • ayon sa IP address ang block, na lumalabas bilang timeout sa "Trying",
  • sadyang bina-block ng trabaho, paaralan o ibang managed network ang site. May-ari ng network ang nagtatakda ng mga patakaran nito. Igalang ang patakaran at magtanong sa administrator kung kailangan mo ng access para sa trabaho mo,
  • extension, antivirus o lumang DNS sa sarili mong device ang dahilan. Direktang ayusin ang mga iyon.

Tapat na mga limitasyon at responsableng paggamit

Hindi itinatago ng GreenTunnel ang IP address mo at hindi ito anonymity tool. Hindi nito kayang lampasan ang mga IP block, network shutdown o allowlist, at hindi ito nangangako na mabubuksan ang anumang partikular na site. Nagbabago ang mga filter sa paglipas ng panahon at iba-iba sa bawat ISP, kaya puwedeng iba ang resulta ngayon sa susunod na buwan.

Mga madalas itanong

Palagi bang senyales ng naka-block na site ang ERR_CONNECTION_RESET?

Hindi. Puwede itong idulot ng mga extension, HTTPS scanning ng antivirus, naiwang proxy, lumang DNS o ng site mismo. Nagiging malamang lang ang blocking kapag nangyayari ang reset sa iisang network, kasunod mismo ng Client hello, at gumagana ang site sa ibang lugar.

Bakit gumagana ang site sa mobile data pero nagre-reset sa Wi-Fi?

Magkakaibang provider, resolver at filter ang ginagamit ng dalawang network. Maaaring binabasa ng isa sa kanila ang pangalan ng site o iba ang pagsagot nito sa DNS. Patakbuhin ang curl -v sa pareho at ihambing kung saan humihinto ang bawat isa.

Maaayos ba ng pag-clear ng cookies ang connection reset?

Bihira. Ipinapadala ang cookies pagkatapos mabuo ang koneksyon, habang karamihan ng reset ay nangyayari bago iyon. Puwedeng makatulong ang pag-clear ng site data kapag ang site mismo ang tumatanggi sa sirang session, na kadalasang nagpapakita ng HTTP error sa halip.

Kaya bang ayusin ng GreenTunnel ang reset na dulot ng firewall ng kumpanya ko?

Hindi iyan ang layunin nito. Nagba-block ang managed network ng mga site ayon sa patakaran ng may-ari nito. Magtanong sa administrator sa halip na subukang lampasan ito.

Mga pinagmulan

← Lahat ng post