빠른 답변
프록시에서 Connection reset by peer (ECONNRESET)는 무엇을 의미하나요?
연결 재설정은 상대편이 TCP 연결을 정상 종료 대신 재설정으로 갑자기 닫았음을 의미합니다. CrawlRelay 주거용 프록시를 통해서는 일반적으로 만료된 재사용 유지 연결, 드롭된 출구, 대상 방화벽이 연결을 끊는 경우가 원인입니다. 안전한 요청은 새 연결에서 재시도하고 유휴 연결을 너무 오래 유지하지 마십시오.
Connection reset by peer (ECONNRESET) 한눈에 보기
| 오류 | Connection reset by peer (ECONNRESET) |
|---|---|
| 유형 | 소켓 오류 |
| 전송 주체 | 상대편이 연결을 갑자기 종료한 후 네트워크 스택에서 발생함 |
| 정의 위치 | TCP reset (RST segment): RFC 9293 |
| 다시 시도할까요? | 안전한 요청(예: GET)의 경우 새 연결에서 발생함 |
| 먼저 확인하세요 | 재사용된 유휴 연결이나 새 연결에서 재설정이 발생하는지 확인하십시오 |
Connection reset by peer (ECONNRESET)가 무엇을 의미하나요?
TCP는 연결을 정상 종료하거나 재설정으로 종료할 수 있습니다. 재설정은 상대편이 연결을 폐기하여 전달 중인 데이터가 손실될 수 있음을 알리는 신호입니다. Python에서는 ConnectionResetError 예외가 발생하고 Node.js에서는 ECONNRESET 또는 'socket hang up'이 발생합니다.
'피어(peer)'란 소켓이 직접 통신하는 상대를 의미하며, 이는 프록시 게이트웨이입니다. 재설정 신호는 체인 상 더 먼 곳에서 발생해 전달될 수도 있습니다.
Python, curl, Node.js, 브라우저에서 a connection reset는 어떻게 나타나나요?
같은 실패가 도구마다 다르게 출력됩니다. 로그에서 검색할 메시지들:
- Python:
ConnectionResetError: [Errno 104] Connection reset by peer, 또는 Windows에서[WinError 10054] - 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의 원인은 무엇인가요?
가장 가능성 높은 첫 번째 원인:
- 만료된 유지 연결: 유휴 상태이던 연결이 상대편에서 닫혔으며 다음 요청은 즉시 실패합니다.
- 드롭된 출구: 해당 출구를 이용한 모든 연결이 종료됩니다.
- 대상 방화벽: 허용하지 않는 연결을 재설정합니다.
- **길고 느린 업로드/다운로드가 경로상의 유휴 제한에 의해 중단됨.
a connection reset를 단계별로 진단하는 방법은?
- 연결의 첫 요청에서 재설정이 발생하는지, 아니면 유휴 재사용 후에 발생하는지 확인합니다.
- 호스트별 재설정 수를 집계합니다: 한 호스트면 대상, 여러 호스트면 경로나 연결 풀 문제입니다.
- 정확히 N초 유휴 후 재설정은 유휴 제한 설정을 가리킵니다.
# 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_URLa connection reset를 어떻게 고치나요?
- 멱등성 요청(GET, HEAD)은 새 연결에서 한 번 재시도하세요.
- 유휴 재사용 시간을 줄이세요: 몇 초 이상 유휴인 풀 연결은 닫거나, 새 IP가 필요할 때마다 새 연결을 여세요.
- 반복적으로 재설정되는 위치 고정 세션은 종료하고 새 세션을 시작하세요.
- 부하에 따라 재설정되는 호스트는 속도를 늦추세요.
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에서는 회전이 새 연결마다 발생합니다. 하나의 연결을 유지하면 동일한 출구를 계속 사용하므로 출구가 드롭되면 연결이 재설정됩니다. 새로운 출구를 얻으려면 연결을 다시 여십시오; 세션 가이드가 패턴을 보여줍니다].
게이트웨이: gw.crawlrelay.com, 포트 7777 (CONNECT를 통한 HTTP, HTTPS) 및 포트 7778 (SOCKS5). 사용자 이름 형식: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. 관련: 502 Bad Gateway · 읽기 시간 초과 · 세션 가이드.
Connection reset by peer (ECONNRESET): 개발자들이 묻는 질문들
프록시에서 Node.js 사용 시 'socket hang up'이 발생하는 이유는?
응답 도착 전 연결이 닫혔습니다. 프록시 사용 시 일반적 원인은 만료된 재사용 유지 소켓, 드롭된 출구 또는 대상에서 연결을 끊은 경우입니다. GET 요청은 새 소켓에서 재시도하고, 유휴 소켓이 풀에 오래 머무르지 않도록 제한하세요.
연결 재설정이 차단 신호인가요?
때때로 그렇습니다. 방화벽은 거부 대상 클라이언트의 연결을 재설정할 수 있지만, 주거용 네트워크에서 무해한 이유로도 재설정이 발생합니다. 패턴을 보세요: 한 호스트에 국한되고 요청 속도에 따라 재설정이 증가하면 그 호스트가 제지를 시도하는 것입니다.
스크래핑할 때 유지 연결(keep-alive)을 비활성화해야 하나요?
완전히 그렇지는 않습니다. 유지 연결로 같은 호스트에 여러 요청을 보내면 시간이 절약됩니다. 반면, 매 요청마다 새 IP가 필요하다면 요청마다 새 연결을 여는 편이 더 깔끔합니다. 두 방식을 혼합하면 만료된 연결 재설정이 자주 발생합니다.
이 참조에서 다른 프록시 오류들
HTTP 상태 코드
- 401 Unauthorized vs 407
- 403 Forbidden
- 407 Proxy Authentication Required
- 429 Too Many Requests
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
브라우저 및 클라이언트 오류
연결 및 TLS 오류
실패 사례를 다루는 문서가 있는 레지덴셜 프록시들
US$0.50/GB의 레지덴셜 프록시 CrawlRelay개, 트래픽이 절대 만료되지 않음.