ERR_CONNECTION_RESET เว็บเดียว

มีเว็บเดียวขึ้น ERR_CONNECTION_RESET แต่เว็บอื่นใช้ได้? ตรวจทีละขั้น: เครือข่าย ส่วนขยาย พร็อกซี DNS นาฬิกา และการกรอง SNI ด้วย curl

เผยแพร่ อ่าน 22 นาทีอ่านเป็นภาษาอังกฤษ →

เว็บอื่นโหลดได้หมด แต่มีเว็บหนึ่งขึ้นว่า "This site can't be reached" พร้อม ERR_CONNECTION_RESET ซ้ำ ๆ รีโหลดก็ไม่ช่วย คู่มือนี้เป็นแผนผังการตัดสินใจ แต่ละขั้นจะหาต้นเหตุเจอ หรือตัดสาเหตุหนึ่งออกไป เรียงจากการตรวจที่เร็วที่สุดไปถึงการตรวจที่บอกได้มากที่สุด

"connection reset" หมายความว่าอะไรจริง ๆ

การเชื่อมต่อ TCP จบได้อย่างสุภาพ หรือถูกรื้อทิ้งทันทีด้วยแพ็กเก็ตรีเซ็ต (RST) Chrome และเบราว์เซอร์ Chromium อื่น ๆ แสดง ERR_CONNECTION_RESET เมื่อมีการรีเซ็ตก่อนหน้าเว็บจะส่งมาถึง Firefox แสดงหน้าคล้ายกันว่า "The connection was reset" การรีเซ็ตอาจมาจากเซิร์ฟเวอร์ของเว็บไซต์ จากซอฟต์แวร์บนคอมพิวเตอร์ของคุณเอง หรือจากอุปกรณ์กลางเครือข่ายที่แกล้งทำเป็นปลายทางฝั่งใดฝั่งหนึ่ง

นั่นคือเหตุผลที่ข้อผิดพลาดเดียวกันมีสาเหตุต่างกันมาก เคล็ดลับคือหาว่าใครส่งการรีเซ็ต และส่งเมื่อไร

ขั้นที่ 1: เป็นแค่เว็บเดียวจริงไหม?

เปิดเว็บไซต์ที่ไม่เกี่ยวข้องกันสองสามเว็บ รวมถึงเว็บที่คุณไม่ค่อยเข้า ถ้าหลายเว็บเข้าไม่ได้ ปัญหาอยู่ที่การเชื่อมต่อ เราเตอร์ หรืออุปกรณ์ของคุณ ไม่ใช่เว็บไซต์นั้น รีสตาร์ตเราเตอร์ แล้วตรวจว่าอุปกรณ์อื่นบนเครือข่ายเดียวกันใช้ได้ไหม ถ้ามีแค่เว็บเดียวที่เข้าไม่ได้ ให้ไปต่อ

ขั้นที่ 2: เป็นแค่เครือข่ายเดียวไหม?

นี่คือการทดสอบที่ให้ข้อมูลมากที่สุด และไม่เสียเงิน เปิดเว็บไซต์ด้วยเน็ตมือถือแทน Wi-Fi หรือแชร์เน็ตจากมือถือให้แล็ปท็อป ถ้าเว็บเปิดได้บนเครือข่ายหนึ่งแต่ถูกรีเซ็ตบนอีกเครือข่าย แสดงว่าเครือข่ายที่ล้มเหลวมีส่วนเกี่ยวข้อง สาเหตุที่พบบ่อยอยู่ใน ทำไมเว็บไซต์เปิดได้บนเน็ตมือถือแต่ไม่ได้บน Wi-Fi? ถ้าเข้าไม่ได้ทุกที่ ต้นเหตุน่าจะเป็นตัวเว็บไซต์เองหรืออุปกรณ์ของคุณ

ขั้นที่ 3: เบราว์เซอร์อื่น หน้าต่างส่วนตัว ปิดส่วนขยาย

ลองหน้าต่างส่วนตัวหรือ incognito ซึ่งส่วนขยายส่วนใหญ่ปิดไว้เป็นค่าเริ่มต้น แล้วลองเบราว์เซอร์อื่น ตัวบล็อกโฆษณา ส่วนขยายด้านความเป็นส่วนตัว ส่วนเสริม "safe browsing" และนโยบายเบราว์เซอร์ขององค์กร ล้วนปิดการเชื่อมต่อได้ทั้งนั้น ถ้าเว็บไซต์ใช้ได้ในหน้าต่างส่วนตัว ให้เปิดส่วนขยายกลับทีละตัวจนกว่าข้อผิดพลาดจะกลับมา

ขั้นที่ 4: ปิด VPN ตัวอื่น พร็อกซี และการสแกน HTTPS

อะไรก็ตามที่อยู่บนเส้นทางของทราฟฟิกคุณ รีเซ็ตการเชื่อมต่อที่มันไม่ชอบได้:

  • แอป VPN หรือพร็อกซีตัวอื่น ปิดให้หมดแล้วทดสอบอีกครั้ง
  • "HTTPS scanning" หรือ "web protection" ของแอนติไวรัส ชุดความปลอดภัยบางตัวตรวจทราฟฟิกที่เข้ารหัสและตัดการเชื่อมต่อที่มันเห็นว่าเสี่ยง หยุดฟีเจอร์นั้นชั่วครู่เพื่อทดสอบ แล้วเปิดกลับ
  • พร็อกซีของระบบ บน Windows ดูที่ Settings → Network & internet → Proxy บน macOS ดูที่ System Settings → Network → การเชื่อมต่อของคุณ → Details → Proxies พร็อกซีที่คุณไม่รู้จัก หรือที่ค้างมาจากแอปเก่า อาจทำให้บางเว็บเข้าไม่ได้ ลบเฉพาะที่คุณรู้ว่าตั้งเอง และถ้าเป็นคอมพิวเตอร์ที่องค์กรดูแล ให้ถามทีมไอที

ขั้นที่ 5: ล้างแคช DNS และลอง DNS เข้ารหัส

ถ้าเว็บไซต์ย้ายเซิร์ฟเวอร์ อุปกรณ์ของคุณอาจยังใช้ที่อยู่เก่า ซึ่งอาจถูกรีเซ็ตหรือหมดเวลา ล้างแคช:

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

ต่อไป เปรียบเทียบคำตอบของเครือข่ายคุณกับเซิร์ฟเวอร์ DNS อิสระ: nslookup example.com แล้วตามด้วย nslookup example.com 1.1.1.1 ถ้าคำตอบต่างกันและมีแค่คำตอบจากเซิร์ฟเวอร์อิสระที่ใช้ได้ แสดงว่า DNS ของเครือข่ายคุณเป็นปัญหา DNS เข้ารหัสแก้การบล็อกแบบนี้ได้ ตามที่อธิบายใน DoH และ DoT แค่ที่อยู่ต่างกันยังไม่ใช่หลักฐาน เพราะเว็บไซต์ใหญ่ ๆ แจกเซิร์ฟเวอร์ต่างกันให้แต่ละเครือข่าย

ขั้นที่ 6: ตรวจวันที่และเวลา

นาฬิกาผิดมักทำให้เกิดข้อผิดพลาดเรื่องใบรับรองมากกว่าการรีเซ็ต แต่ตรวจได้ในสิบวินาที เปิดวันที่และเวลาอัตโนมัติ แล้วรีโหลด อย่ากดข้ามคำเตือนเรื่องใบรับรองเพื่อ "ผ่าน" หน้าที่โหลดไม่ได้

ขั้นที่ 7: เว็บไซต์ล่มหรือเปล่า?

ดูหน้าสถานะของเว็บไซต์หรือบัญชีโซเชียลอย่างเป็นทางการ หรือใช้เว็บตรวจสอบสาธารณะแบบ "ล่มสำหรับทุกคนหรือแค่ฉัน" ถ้าเว็บไซต์ล่มอยู่ ให้รอ จำไว้ว่าเว็บตรวจสอบทดสอบจากเซิร์ฟเวอร์ของตัวเอง ผล "ใช้ได้" ที่นั่นจึงไม่ได้พิสูจน์ว่าเครือข่ายของคุณเข้าถึงได้

ขั้นที่ 8: อ่านการรีเซ็ตด้วย curl

ถ้าเว็บไซต์ยังถูกรีเซ็ตเฉพาะบนเครือข่ายเดียว ให้ดูที่ตัว handshake เอง curl มีมาในตัวกับ Windows 10 และ 11, macOS และระบบ Linux ส่วนใหญ่ รันในเทอร์มินัล โดยใส่เว็บไซต์ของคุณแทน example.com:

curl -v https://example.com

การเชื่อมต่อที่ปกติจะแสดงบรรทัดประมาณนี้ แล้วตามด้วยเฮดเดอร์ของหน้าเว็บ ถ้อยคำจริงขึ้นกับรุ่นของ curl และไลบรารี TLS:

*   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

รูปแบบที่ชี้ไปยังการกรองด้วยชื่อมีหน้าตาแบบนี้:

*   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

อ่านทีละบรรทัด "Connected" หมายความว่าการเชื่อมต่อ TCP ไปยังที่อยู่ IP ของเซิร์ฟเวอร์สำเร็จ ที่อยู่นั้นจึงไม่ได้ถูกบล็อกตรง ๆ "Client hello" คือข้อความ TLS แรก ซึ่งมีชื่อเว็บไซต์เป็นข้อความธรรมดาอยู่ในช่องที่เรียกว่า SNI "Connection reset by peer" ที่ตามมาทันทีหมายความว่ามีบางอย่างตัดการเชื่อมต่อทันทีที่มองเห็นชื่อนั้น ก่อนที่เซิร์ฟเวอร์จะตอบได้ บางเครือข่ายปิดการเชื่อมต่ออย่างเงียบ ๆ แทน ซึ่ง curl รายงานว่าเป็น unexpected end of file หรือข้อผิดพลาด SSL "syscall" และ Chrome อาจแสดง ERR_CONNECTION_CLOSED

เปรียบเทียบกับผลแบบอื่น:

สิ่งที่ curl แสดงความหมายที่เป็นไปได้
Could not resolve hostDNS ล้มเหลวหรือการบล็อกด้วย DNS กลับไปขั้นที่ 5
ค้างที่ "Trying" แล้วหมดเวลาเข้าถึงที่อยู่ IP ไม่ได้ เช่น การบล็อก IP ไฟร์วอลล์ หรือเซิร์ฟเวอร์ล่ม
ถูกรีเซ็ตหรือปิดทันทีหลัง "Client hello" เฉพาะบนเครือข่ายเดียวน่าจะเป็นการกรอง SNI บนเครือข่ายนั้น
handshake สำเร็จ แล้วได้รหัสข้อผิดพลาด HTTPเว็บไซต์ตอบแล้ว ปัญหาอยู่ฝั่งเว็บไซต์หรือบัญชีของคุณ

เพื่อให้หลักฐานหนักแน่นขึ้น ให้รันคำสั่งเดียวกันบนเครือข่ายอื่น ถ้าใช้ได้ที่นั่น ตัวกรองเป็นของเครือข่ายแรก นี่ไม่ใช่การเดาสถานการณ์ที่หายาก งานศึกษาของ OONI และ Centre for Internet and Society ปี 2020 พบว่าการเชื่อมต่อ TLS ถูกตัดทันทีหลัง ClientHello สำหรับบางเว็บไซต์บน Bharti Airtel และพบการใช้ SNI ร่วมกับที่อยู่ปลายทางบน Reliance Jio นอกจากนี้ CIS ยังรายงานแยกว่า Jio ใช้การตรวจ SNI และรายงานนั้นถูกพูดถึงในฟอรัม ntc.party ข้อมูลเพิ่มเติม: วิธีตรวจว่าเว็บไซต์ถูกบล็อกหรือไม่

GreenTunnel ช่วยได้ตรงไหน และช่วยไม่ได้ตรงไหน

GreenTunnel เป็น VPN ในเครื่องที่ทำงานบนอุปกรณ์ ซึ่งเราเป็นผู้สร้าง โปรดอ่านส่วนนี้โดยรู้ว่าเรามีอคติ มันรับมือกับสองสาเหตุจากข้างบน:

  • การกรอง SNI มันปรับรูปแพ็กเก็ต TLS แรก ๆ ของการเชื่อมต่อ เช่น แบ่ง Client hello หรือ TLS record ของมัน ตัวกรองที่มองหาชื่อเว็บไซต์จึงไม่เจอชื่อแบบครบในชิ้นเดียว วิธีทำงาน: SNI, DPI และการแบ่ง TLS record
  • การบล็อกด้วย DNS การค้นหาวิ่งผ่าน DNS เข้ารหัส (DoH หรือ DoT) ไปยัง Cloudflare, Google หรือ Quad9 เครือข่ายจึงส่งคำตอบปลอมกลับมาเงียบ ๆ ไม่ได้

เครื่องมือ Inspect URL (ตรวจสอบ URL) ของมันทำการเปรียบเทียบแบบขั้นที่ 5 และ 8 ให้หนึ่งเว็บไซต์บนเครือข่ายที่คุณใช้อยู่ และบอกว่าเว็บไซต์ถูกกรองด้วยชื่อ ได้คำตอบ DNS ปลอม ถูกบล็อกด้วยที่อยู่ IP หรือปกติดี ถ้ามีเทคนิคที่ใช้ได้ คุณแตะ Use this technique ได้

มันจะไม่ช่วยเมื่อ:

  • เว็บไซต์ล่ม หรือการรีเซ็ตมาจากเซิร์ฟเวอร์หรือบริการป้องกันของเว็บไซต์เอง
  • การบล็อกทำด้วยที่อยู่ IP ซึ่งแสดงเป็นการหมดเวลาที่ "Trying"
  • ที่ทำงาน โรงเรียน หรือเครือข่ายที่มีผู้ดูแลอื่น ๆ บล็อกเว็บไซต์โดยเจตนา กฎของเครือข่ายนั้นเป็นสิทธิ์ของเจ้าของ เคารพนโยบายนั้น และถามผู้ดูแลถ้าคุณต้องเข้าถึงเพื่อทำงาน
  • ต้นเหตุคือส่วนขยาย แอนติไวรัส หรือ DNS ค้างเก่าบนอุปกรณ์ของคุณเอง ให้แก้ที่ตัวนั้นโดยตรง

ข้อจำกัดตามจริงและการใช้อย่างรับผิดชอบ

GreenTunnel ไม่ได้ซ่อนที่อยู่ IP ของคุณ และไม่ใช่เครื่องมือปกปิดตัวตน มันเลี่ยงการบล็อก IP การตัดอินเทอร์เน็ต หรือ allowlist ไม่ได้ และไม่ได้รับประกันว่าจะเปิดเว็บไซต์ใดได้ ตัวกรองเปลี่ยนไปตามเวลาและต่างกันไปตาม ISP ผลวันนี้จึงอาจต่างจากเดือนหน้า

คำถามที่พบบ่อย

ERR_CONNECTION_RESET เป็นสัญญาณว่าเว็บไซต์ถูกบล็อกเสมอไหม?

ไม่ ส่วนขยาย การสแกน HTTPS ของแอนติไวรัส พร็อกซีที่ค้างอยู่ DNS ค้างเก่า หรือตัวเว็บไซต์เอง ล้วนเป็นสาเหตุได้ การบล็อกจะเป็นไปได้สูงก็ต่อเมื่อการรีเซ็ตเกิดบนเครือข่ายเดียว ทันทีหลัง Client hello และเว็บไซต์ใช้ได้ที่อื่น

ทำไมเว็บไซต์ใช้ได้บนเน็ตมือถือแต่ถูกรีเซ็ตบน Wi-Fi?

สองเครือข่ายใช้ผู้ให้บริการ เซิร์ฟเวอร์ DNS และตัวกรองต่างกัน เครือข่ายหนึ่งอาจอ่านชื่อเว็บไซต์หรือตอบ DNS ต่างออกไป รัน curl -v บนทั้งสองเครือข่ายแล้วเปรียบเทียบว่าแต่ละตัวหยุดตรงไหน

ล้างคุกกี้จะแก้การรีเซ็ตการเชื่อมต่อได้ไหม?

แทบไม่ได้ คุกกี้ถูกส่งหลังการเชื่อมต่อตั้งขึ้นแล้ว ขณะที่การรีเซ็ตส่วนใหญ่เกิดก่อนหน้านั้น การล้างข้อมูลเว็บไซต์ช่วยได้เมื่อตัวเว็บไซต์ปฏิเสธเซสชันที่เสีย ซึ่งปกติจะแสดงเป็นข้อผิดพลาด HTTP แทน

GreenTunnel แก้การรีเซ็ตที่เกิดจากไฟร์วอลล์ของบริษัทได้ไหม?

มันไม่ได้มีไว้ทำแบบนั้น เครือข่ายที่มีผู้ดูแลบล็อกเว็บไซต์ตามนโยบายของเจ้าของ ให้ถามผู้ดูแลแทนการพยายามเลี่ยง

แหล่งข้อมูล

← บทความทั้งหมด