Client network socket disconnected before secure TLS connection was established

Con fetch() es la causa de «TypeError: fetch failed»; npm y yarn lo imprimen dentro de sus mensajes «request to … failed». Las mismas palabras con otro código (por ejemplo, ETIMEDOUT) apuntan a un tiempo de espera agotado y no a un restablecimiento.

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

Qué significa

El otro extremo (o algo intermedio) cerró la conexión TCP después de que Node.js enviara su ClientHello y antes de que terminara el handshake TLS. No llegó ninguna alerta TLS, así que Node.js no puede saber el motivo; informa de un restablecimiento de la conexión con el código ECONNRESET. El motivo está en el servidor, en un proxy o en un firewall, no en el certificado.

Por qué ocurre

• Hace falta un proxy corporativo, pero no se usa (o está mal configurado)

  frecuente

  Las redes que solo permiten HTTPS saliente a través de un proxy a menudo dejan que la conexión TCP se establezca y luego cortan el handshake. Node.js no lee HTTPS_PROXY de forma predeterminada, así que las herramientas que funcionan en el navegador fallan aquí.

• Un firewall o un filtro TLS corta el handshake

  frecuente

  Los firewalls de nueva generación bloquean por SNI o por huella TLS y simplemente cierran la conexión; los clientes VPN y el filtrado DNS pueden hacer lo mismo.

• El servidor cierra los handshakes que no puede atender

  ocasional

  Algunos servidores y balanceadores de carga cierran la conexión en lugar de enviar una alerta cuando falta el SNI, el nombre es desconocido o no coincide ninguna versión del protocolo.

• Sobrecarga, límites de frecuencia o límites de conexiones

  ocasional

  Los servidores que han alcanzado su límite de conexiones, o los limitadores de frecuencia situados por delante, restablecen las conexiones nuevas; entonces el error aparece de forma intermitente bajo carga.

Cómo solucionarlo

1. 1.

   Comprobar la configuración del proxy

   Compara el entorno con lo que usa tu navegador (a menudo, un archivo PAC). Normalmente, las URL de proxy deberían ser http://, y los hosts internos deben ir en 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.

   Repetir el handshake con openssl s_client

   Si s_client también se corta, el problema está en la red o en el servidor; cambia el SNI para ver si el servidor lo necesita.

   # 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.

   Hacer que Node.js use las variables de entorno del proxy

   Las versiones recientes de Node.js respetan HTTP_PROXY, HTTPS_PROXY y NO_PROXY para http, https y fetch cuando se establece NODE_USE_ENV_PROXY=1; bibliotecas como axios, got o el ProxyAgent de undici tienen sus propias opciones 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

← Explorar toda la base de datos de errores de firma