ข้อมูลอ้างอิงข้อผิดพลาดพร็อกซี · ข้อผิดพลาดการเชื่อมต่อและ TLS

การรีเซ็ตการเชื่อมต่อโดยฝั่งตรงข้าม (ECONNRESET) ผ่านพร็อกซี

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

อัปเดตล่าสุด: 13 ตุลาคม 2569

คำตอบด่วน

Connection reset by peer (ECONNRESET) หมายความว่าอย่างไรกับพร็อกซี?

การรีเซ็ตการเชื่อมต่อโดยฝั่งตรงข้าม หมายถึงอีกฝั่งปิดการเชื่อมต่อ TCP อย่างกะทันหันด้วยการรีเซ็ตแทนการปิดปกติ ผ่านพร็อกซีที่เป็น residential proxies ของ CrawlRelay สาเหตุที่พบบ่อยคือการใช้การเชื่อมต่อ keep-alive ที่ล้าสมัย, จุดออกที่หยุดทำงาน หรือไฟร์วอลล์เป้าหมายที่ตัดการเชื่อมต่อ ลองส่งคำขอที่ปลอดภัยใหม่บนการเชื่อมต่อใหม่และอย่าปล่อยให้การเชื่อมต่อว่างนานเกินไป

Connection reset by peer (ECONNRESET) แบบสั้นๆ

ข้อผิดพลาด	Connection reset by peer (ECONNRESET)
ประเภท	ข้อผิดพลาดซ็อกเก็ต
ส่งโดย	สแต็กเน็ตเวิร์ก หลังจากฝั่งตรงข้ามปิดการเชื่อมต่ออย่างกะทันหัน
กำหนดไว้ใน	TCP reset (RST segment): RFC 9293
ลองใหม่อีกครั้งไหม?	ใช่ สำหรับคำขอที่ปลอดภัย บนการเชื่อมต่อใหม่
ตรวจสอบก่อน	ดูว่าการรีเซ็ตเกิดขึ้นกับการเชื่อมต่อที่ใช้ซ้ำแบบว่างหรือการเชื่อมต่อใหม่

Connection reset by peer (ECONNRESET) หมายความว่าอย่างไร?

TCP สามารถสิ้นสุดการเชื่อมต่อได้อย่างราบรื่นหรือด้วยการรีเซ็ต การรีเซ็ตจะบอกเครื่องของคุณว่าฝั่งตรงข้ามทิ้งการเชื่อมต่อ ทำให้ข้อมูลใด ๆ ที่ส่งไปเสียหาย Python จะยก ConnectionResetError ขึ้น; Node.js จะยก ECONNRESET หรือ 'socket hang up' ขึ้น

'peer' คือผู้ที่ซ็อกเก็ตของคุณติดต่อโดยตรง ซึ่งก็คือพร็อกซีเกตเวย์ การรีเซ็ตนี้อาจเกิดจากจุดอื่นในเส้นทางและถูกส่งต่อมา

a connection reset เป็นอย่างไรใน Python, curl, Node.js และเบราว์เซอร์?

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

Python: ConnectionResetError: [Errno 104] Connection reset by peer, หรือ [WinError 10054] บน Windows
requests: ConnectionError(ProtocolError('Connection aborted.', ConnectionResetError(...)))
Node.js: Error: socket hang up หรือ read ECONNRESET
curl: curl: (56) Recv failure: Connection reset by peer

อะไรเป็นสาเหตุของ a connection reset?

โอกาสสูงสุดอันดับแรก:

การเชื่อมต่อ keep-alive ล้าสมัย. การเชื่อมต่อรวม (pool) นั่งอยู่เฉย ๆ แล้วถูกปิดจากฝั่งตรงข้าม; คำขอถัดไปจะล้มเหลวทันที
จุดออกที่หยุดทำงาน ซึ่งจะตัดการเชื่อมต่อทุกครั้งที่ใช้มัน
ไฟร์วอลล์เป้าหมาย ที่รีเซ็ตการเชื่อมต่อที่ไม่ชอบ
การอัปโหลดหรือดาวน์โหลดนาน ที่ถูกจำกัดด้วยเวลาว่าง (idle limit) บนเส้นทางใดเส้นทางหนึ่ง

ฉันวินิจฉัย a connection reset ทีละขั้นตอนอย่างไร?

ตรวจสอบว่าการรีเซ็ตเกิดขึ้นกับคำขอแรกของการเชื่อมต่อหรือหลังจากใช้ซ้ำแบบว่าง
นับจำนวนรีเซ็ตต่อโฮสต์: โฮสต์เดียวแปลว่าเป้าหมาย; ทุกโฮสต์แปลว่าเส้นทางหรือพูล
สังเกตช่วงเวลา: การรีเซ็ตที่เกิดขึ้นหลังจากว่างเต็ม N วินาทีชี้ไปที่การจำกัด idle

ทดสอบ URL ที่ล้มเหลวด้วย curl (พอร์ต HTTP, โหมดละเอียด)

# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:[email protected]:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL

ฉันจะแก้ไข a connection reset อย่างไร?

ลองใหม่กับคำขอที่ทำซ้ำได้ (GET, HEAD) บนการเชื่อมต่อใหม่ครั้งหนึ่ง
ลดเวลาการใช้ซ้ำว่าง: ปิดการเชื่อมต่อรวมที่ว่างนานเกินไม่กี่วินาที หรือเปิดการเชื่อมต่อใหม่ตามคำขอเมื่อคุณต้องการ IP ใหม่
ยุติ session ที่ติดและรีเซ็ตบ่อย ๆ และเริ่มต้น session ใหม่
ลดความเร็ว บนโฮสต์ที่รีเซ็ตภายใต้ความเร็วสูง

Python: ลองใหม่ด้วย Retry-After, การหน่วงเพิ่มขึ้นแบบเอ็กซ์โพเนนเชียล และ jitter

import random
import time

import requests

PROXY = "http://USERNAME:[email protected]:7777"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUSES = {429, 502, 503, 504}


def fetch(url, attempts=5, timeout=(10, 30)):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=timeout)
        except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
            r = None  # dropped exit, reset or timeout: a new connection gets a new exit
        if r is not None and r.status_code not in RETRY_STATUSES:
            return r
        retry_after = r.headers.get("Retry-After", "") if r is not None else ""
        if retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)
    raise RuntimeError("giving up on %s after %d attempts" % (url, attempts))

ฉันควรลองใหม่หลังจาก a connection reset ไหม?

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

Connection reset by peer (ECONNRESET) มีผลอย่างไรกับ CrawlRelay?

บน CrawlRelay การสลับเกิดขึ้นทุกครั้งที่มีการเชื่อมต่อใหม่ ลูกค้าที่รักษาการเชื่อมต่อหนึ่งไว้ จะได้จุดออกเดียวกันสำหรับคำขอทุกคำขอบนมัน ดังนั้นถ้าจุดออกหยุดทำงาน การเชื่อมต่อจะรีเซ็ต เปิดการเชื่อมต่อใหม่เพื่อรับจุดออกใหม่; sessions guide แสดงรูปแบบต่าง ๆ

เกตเวย์: gw.crawlrelay.com, พอร์ต 7777 (HTTP, HTTPS ผ่าน CONNECT) และพอร์ต 7778 (SOCKS5). รูปแบบชื่อผู้ใช้: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. ที่เกี่ยวข้อง: 502 Bad Gateway · Read timed out · Sessions guide.

Connection reset by peer (ECONNRESET): คำถามที่นักพัฒนาถาม

ทำไมฉันจึงเจอ 'socket hang up' ใน Node.js กับพร็อกซี?

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

การรีเซ็ตการเชื่อมต่อเป็นสัญญาณว่าฉันถูกบล็อกหรือไม่?

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

ฉันควรปิดการใช้งาน keep-alive สำหรับการขูดข้อมูลหรือไม่?

ไม่ทั้งหมด keep-alive ช่วยประหยัดเวลาหากคุณส่งคำขอหลายคำไปยังโฮสต์เดิมผ่านจุดออกที่ติดอยู่ เมื่อคุณต้องการ IP ใหม่ทุกคำขอ การเชื่อมต่อใหม่ทุกคำขอเป็นทางเลือกที่สะอาดกว่า การใช้ทั้งสองแบบแบบไม่ระวังทำให้เกิดการรีเซ็ตการเชื่อมต่อที่ล้าสมัย

ข้อผิดพลาดพร็อกซีอื่นๆ ในเอกสารอ้างอิงนี้

รหัสสถานะ HTTP

ข้อผิดพลาดของเบราว์เซอร์และไคลเอนต์

ข้อผิดพลาดการเชื่อมต่อและ TLS

พร็อกซีเรซิเดนเชียลที่มีเอกสารอธิบายกรณีล้มเหลว

พร็อกซีเรซิเดนเชียล CrawlRelay จาก US$0.50/GB, ปริมาณข้อมูลที่ไม่หมดอายุ

ดูราคา เริ่มต้นอย่างรวดเร็ว