Client network socket disconnected before secure TLS connection was established

Avec fetch(), il s’agit de la cause de « TypeError: fetch failed » ; npm et yarn l’affichent dans leurs messages « request to … failed ». Les mêmes mots avec un autre code (par exemple ETIMEDOUT) indiquent un dépassement de délai plutôt qu’une réinitialisation.

Node.js tls / https / fetch — code ECONNRESET during the TLS handshake

Ce que cela signifie

L’autre extrémité (ou un équipement intermédiaire) a fermé la connexion TCP après l’envoi du ClientHello par Node.js et avant la fin du handshake TLS. Aucune alerte TLS n’est arrivée : Node.js ne peut donc pas en indiquer la raison et signale une réinitialisation avec le code ECONNRESET. La cause se trouve sur le serveur, un proxy ou un pare-feu, pas dans le certificat.

Pourquoi cela se produit

• Un proxy d’entreprise est requis, mais n’est pas utilisé (ou est mal configuré)

  fréquente

  Les réseaux qui n’autorisent le HTTPS sortant que via un proxy laissent souvent la connexion TCP aboutir, puis abandonnent le handshake. Par défaut, Node.js ne lit pas HTTPS_PROXY : des outils qui fonctionnent dans le navigateur échouent donc ici.

• Un pare-feu ou un filtre TLS coupe le handshake

  fréquente

  Les pare-feu de nouvelle génération bloquent selon le SNI ou l’empreinte TLS et ferment simplement la connexion ; les clients VPN et le filtrage DNS peuvent faire de même.

• Le serveur ferme les handshakes qu’il ne peut pas servir

  occasionnelle

  Certains serveurs et répartiteurs de charge ferment la connexion au lieu d’envoyer une alerte lorsque le SNI est absent, que le nom est inconnu ou qu’aucune version de protocole ne correspond.

• Surcharge, limitation de débit ou limites de connexions

  occasionnelle

  Les serveurs qui ont atteint leur limite de connexions, ou les limiteurs de débit en amont, réinitialisent les nouvelles connexions ; l’erreur apparaît alors de façon intermittente sous charge.

Comment corriger l’erreur

1. 1.

   Vérifier les paramètres de proxy

   Comparez l’environnement avec ce qu’utilise votre navigateur (souvent un fichier PAC). Les URL de proxy devraient normalement commencer par http://, et les hôtes internes ont leur place dans NO_PROXY.

   env | grep -i -E '^(https?|no)_proxy='
   npm config get proxy; npm config get https-proxy
   # Proxy URL with http:// and internal hosts in NO_PROXY
   export HTTPS_PROXY=http://proxy.example.net:3128 NO_PROXY=localhost,127.0.0.1,.internal.example.com

2. 2.

   Refaire le handshake avec openssl s_client

   Si s_client est lui aussi coupé, le problème vient du réseau ou du serveur ; faites varier le SNI pour voir si le serveur en a besoin.

   # Same handshake without Node.js: does the server or network cut it too?
   openssl s_client -connect api.example.com:443 -servername api.example.com -brief </dev/null
   openssl s_client -connect api.example.com:443 -noservername -brief </dev/null

3. 3.

   Laisser Node.js utiliser les variables d’environnement de proxy

   Les versions récentes de Node.js tiennent compte de HTTP_PROXY, HTTPS_PROXY et NO_PROXY pour http, https et fetch lorsque NODE_USE_ENV_PROXY=1 est défini ; des bibliothèques comme axios, got ou le ProxyAgent d’undici ont leurs propres options de proxy.

   # Node.js does not use HTTPS_PROXY by itself; recent releases can be told to
   NODE_USE_ENV_PROXY=1 HTTPS_PROXY=http://proxy.example.net:3128 node app.js

← Parcourir toute la base de données des erreurs de signature