Référence d’erreur proxy · Erreurs de connexion et TLS

Réinitialisation de connexion par le pair (ECONNRESET) via un proxy

Erreur de socket : message exact dans chaque outil, causes probables par ordre, et solution efficace.

Dernière mise à jour: 13 octobre 2026 · 5 min de lecture

Réponse rapide

Que signifie Connection reset by peer (ECONNRESET) avec un proxy ?

Réinitialisation de connexion par le pair signifie que l'autre extrémité a fermé la connexion TCP brusquement avec un reset au lieu d'une fermeture normale. Avec les proxies résidentiels CrawlRelay, les causes habituelles sont une connexion keep-alive réutilisée devenue périmée, une sortie coupée, ou un pare-feu cible qui interrompt les connexions. Retentez les requêtes sûres sur une nouvelle connexion et ne gardez pas les connexions inactives trop longtemps.

Connection reset by peer (ECONNRESET) en un coup d'œil

Erreur	Connection reset by peer (ECONNRESET)
Type	Erreur de socket
Envoyé par	La pile réseau, après que l'autre côté a fermé la connexion brutalement
Défini dans	TCP reset (RST segment): RFC 9293
Réessayer ?	Oui, pour les requêtes sûres, sur une nouvelle connexion
Vérification initiale	Vérifiez si les réinitialisations suivent des connexions réutilisées inactives ou des connexions nouvelles

Que signifie Connection reset by peer (ECONNRESET) ?

TCP peut terminer une connexion proprement ou par un reset. Un reset indique à votre machine que l'autre côté a abandonné la connexion, donc toute donnée en cours est perdue. Python déclenche ConnectionResetError ; Node.js déclenche ECONNRESET ou 'socket hang up'.

Le « peer » est celui avec qui votre socket communique directement, ici la passerelle proxy. Le reset peut toutefois provenir plus loin dans la chaîne et être relayé.

À quoi ressemble a connection reset en Python, curl, Node.js et navigateurs ?

La même erreur s'affiche différemment selon chaque outil. Voici les messages à rechercher dans vos logs :

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

Quelles sont les causes de a connection reset ?

Probablement en premier lieu :

Connexions keep-alive périmées. Une connexion du pool est restée inactive et a été fermée côté distant ; la requête suivante échoue immédiatement.
Une sortie coupée, qui termine toutes les connexions qui l'utilisent.
Un pare-feu cible qui réinitialise les connexions indésirables.
Longs téléchargements ou envois interrompus par une limite d'inactivité sur le chemin.

Comment diagnostiquer a connection reset étape par étape ?

Vérifiez si les réinitialisations surviennent dès la première requête d'une connexion ou après réutilisation inactive.
Comptez les réinitialisations par hôte : un seul hôte implique la cible ; tous les hôtes impliquent le chemin ou le pool.
Notez le timing : des resets après exactement N secondes d'inactivité indiquent une limite d'inactivité.

Tester l'URL en échec avec curl (port HTTP, mode verbeux)

# 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

Comment résoudre a connection reset ?

Retentez une fois les requêtes idempotentes (GET, HEAD) sur une nouvelle connexion.
Réduisez la durée d'inactivité : fermez les connexions du pool restées inactives plus de quelques secondes, ou ouvrez une nouvelle connexion par requête si vous avez besoin d'une nouvelle IP.
Terminez une session persistante qui se réinitialise sans cesse et démarrez-en une nouvelle.
Ralentissez sur les hôtes qui réinitialisent sous charge.

Python : réessayer avec Retry-After, backoff exponentiel et 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))

Dois-je réessayer après a connection reset ?

Retentez une réinitialisation une fois pour les requêtes sûres telles que GET. Ne retentez pas aveuglément les POST qui modifient les données : la première peut avoir été traitée. Un pic de réinitialisations sur un hôte signifie que cet hôte vous coupe ; ralentissez la cadence.

Quelle est l'incidence de Connection reset by peer (ECONNRESET) sur CrawlRelay ?

Chez CrawlRelay, la rotation se fait à chaque nouvelle connexion. Un client qui garde une connexion active utilise la même sortie pour toutes les requêtes sur cette connexion, donc une sortie coupée provoque une réinitialisation. Rouvrez la connexion pour obtenir une nouvelle sortie ; le guide des sessions montre ces schémas.

Passerelle : gw.crawlrelay.com, port 7777 (HTTP, HTTPS via CONNECT) et port 7778 (SOCKS5). Format du nom d'utilisateur : USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. Voir aussi : 502 Bad Gateway · Read timed out · Guide des sessions.

Connection reset by peer (ECONNRESET) : questions fréquentes des développeurs

Pourquoi ai-je 'socket hang up' dans Node.js avec un proxy ?

La connexion s'est fermée avant la réponse. Avec un proxy, les causes fréquentes sont un socket keep-alive réutilisé périmé, une sortie coupée ou une cible qui a interrompu la connexion. Retentez les GET sur un nouveau socket et limitez la durée d'inactivité des sockets dans le pool.

Une réinitialisation de connexion est-elle un signe que je suis bloqué ?

Parfois. Les pare-feux peuvent réinitialiser les connexions des clients qu'ils rejettent, mais les réinitialisations arrivent aussi pour des raisons bénignes sur n'importe quel réseau résidentiel. Regardez le schéma : des resets limités à un hôte et croissants avec le nombre de vos requêtes suggèrent que l'hôte vous repousse.

Dois-je désactiver le keep-alive pour le scraping ?

Pas complètement. Le keep-alive fait gagner du temps quand vous envoyez plusieurs requêtes à un même hôte via une sortie persistante. Quand vous voulez une nouvelle IP à chaque requête, ouvrir une connexion par requête est plus propre. Mélanger les deux sans précaution génère des resets dus aux connexions périmées.

Autres erreurs de proxy dans cette référence

Codes d'état HTTP

Erreurs du navigateur et du client

Erreurs de connexion et TLS

Proxies résidentiels avec documentation couvrant les cas de défaillance

Proxies résidentiels CrawlRelay de 0,50 $US/GB, trafic sans expiration.

Voir les tarifs Démarrage rapide