Referencja błędu proxy · Błędy połączenia i TLS

Połączenie zresetowane przez partnera (ECONNRESET) przez proxy

Błąd socketu: dokładny komunikat w każdym narzędziu, możliwe przyczyny w kolejności oraz działające rozwiązanie.

Ostatnia aktualizacja: 13 października 2026 · 4 min czytania

Szybka odpowiedź

Co oznacza Connection reset by peer (ECONNRESET) w kontekście proxy?

Połączenie zresetowane przez partnera oznacza, że druga strona nagle zamknęła połączenie TCP przez reset zamiast zamknięcia normalnego. Przez residential proxies CrawlRelay najczęstsze przyczyny to przeterminowane ponowne użycie keep-alive, porzucone wyjście lub zapora przeciwdziałająca celowi. Spróbuj ponownie bezpieczne żądania na nowym połączeniu i nie trzymaj bezczynnych połączeń zbyt długo.

Connection reset by peer (ECONNRESET) w skrócie

Błąd	Connection reset by peer (ECONNRESET)
Typ	Błąd socketu
Wysłane przez	Stos sieciowy, po tym jak druga strona nagle zamknęła połączenie
Zdefiniowano w	TCP reset (RST segment): RFC 9293
Spróbować ponownie?	Tak, dla bezpiecznych żądań, na nowym połączeniu
Najpierw sprawdź	Sprawdź, czy reset następuje po bezczynnych ponownych użyciach połączeń lub nowych połączeniach

Co oznacza Connection reset by peer (ECONNRESET)?

TCP może zakończyć połączenie łagodnie lub przez reset. Reset informuje Twoją maszynę, że druga strona porzuciła połączenie, więc dane w tranzycie są utracone. Python zgłasza ConnectionResetError; Node.js zgłasza ECONNRESET lub 'socket hang up'.

'Partner' to ten, z którym Twój socket rozmawia bezpośrednio, czyli proxy gateway. Reset może jednak pochodzić dalej w łańcuchu i być przekazany.

Jak wygląda a connection reset w Python, curl, Node.js i przeglądarkach?

Ten sam błąd wyświetla się inaczej w każdym narzędziu. Oto komunikaty, które warto wyszukać w logach:

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

Co powoduje a connection reset?

Najczęściej na początku:

Przeterminowane keep-alive. Połączenie w puli długo bezczynne zostało zamknięte przez drugą stronę; kolejne żądanie na nim kończy się natychmiast niepowodzeniem.
Porzucone wyjście, które kończy każde połączenie z niego korzystające.
Zapora na celu, która resetuje niechciane połączenia.
Długie przesyłanie lub pobieranie, przerwane limitem bezczynności na ścieżce.

Jak krok po kroku zdiagnozować a connection reset?

Sprawdź, czy reset pojawia się przy pierwszym żądaniu na połączeniu czy po bezczynnym ponownym użyciu.
Zlicz resety na hosta: jeden host to cel; wszystkie hosty to ścieżka lub pula.
Zwróć uwagę na czas: reset po dokładnie N sekundach bezczynności wskazuje limit bezczynności.

Przetestuj nie działający URL za pomocą curl (port HTTP, tryb verbose)

# 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

Jak naprawić a connection reset?

Ponów idempotentne żądania (GET, HEAD) raz na nowym połączeniu.
Skróć czas ponownego użycia bezczynnego połączenia: zamykaj połączenia w puli bezczynne dłużej niż kilka sekund lub otwieraj nowe połączenie na każde żądanie, gdy i tak trzeba nowego IP.
Zakończ powtarzającą się sesję ze zresetowanymi połączeniami i zacznij nową.
Zwolnij tempo przy hostach resetujących pod obciążeniem.

Python: ponów próbę z Retry-After, wykładniczym opóźnieniem i jitterem

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))

Czy warto ponawiać próbę po a connection reset?

Spróbuj ponownie reset raz dla bezpiecznych żądań takich jak GET. Nie powtarzaj bezmyślnie POST zmieniających dane: pierwsze mogło zostać już przetworzone. Skok resetów na jednym hoście oznacza, że ten host Cię odcina; zmniejsz tam tempo.

Jak Connection reset by peer (ECONNRESET) odnosi się do CrawlRelay?

Na CrawlRelay rotacja następuje na każde nowe połączenie. Klient, który utrzymuje jedno połączenie, używa tego samego wyjścia do wszystkich żądań na nim, więc porzucone wyjście resetuje połączenie. Otwórz ponownie połączenie, aby uzyskać nowe wyjście; sessions guide pokazuje wzorce.

Gateway: gw.crawlrelay.com, port 7777 (HTTP, HTTPS przez CONNECT) i port 7778 (SOCKS5). Format nazwy użytkownika: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. Powiązane: 502 Bad Gateway · Read timed out · Sessions guide.

Connection reset by peer (ECONNRESET): pytania, które zadają deweloperzy

Dlaczego w Node.js z proxy pytam o 'socket hang up'?

Połączenie zamknięte zanim nadszedł response. Z proxy, częste przyczyny to przeterminowany keep-alive, porzucone wyjście lub cel, który ściął połączenie. Spróbuj GET na nowym socket i ogranicz czas, jak długo bezczynne sockety są w puli.

Czy reset połączenia to znak, że jestem zablokowany?

Czasem. Zapory mogą resetować połączenia od odrzuconych klientów, ale reset pojawia się też z powodów bezpiecznych w każdej sieci residential. Patrz na wzorzec: reset ograniczony do jednego hosta i rosnący z tempem żądań wskazuje, że host Cię odpiera.

Czy powinienem wyłączyć keep-alive do scrapingu?

Nie całkiem. Keep-alive oszczędza czas przy wielu żądaniach do tego samego hosta przez to samo sticky wyjście. Gdy chcesz nowe IP przy każdym żądaniu, nowe połączenie na żądanie jest czystszym wyborem. Mieszanie bez opieki powoduje resety przeterminowanych połączeń.

Inne błędy proxy w tym odniesieniu

Kody statusu HTTP

Błędy w przeglądarce i kliencie

Błędy połączenia i TLS

Proxy rezydencjalne z dokumentacją opisującą przypadki błędów

CrawlRelay proxy rezydencjalne od 0,50 USD/GB, ruch, który nigdy nie wygasa.

Zobacz ceny Szybki start