Request: Error: el enchufe cuelga

Tengo el mismo problema, pero la opción de agregar gzip:true funcionará.

¿Qué versión de node.js estás usando? Estamos viendo excepciones ocasionales de ECONNRESET después de actualizar de 0.10 a 0.12. Al investigar los errores de node.js, parece que esto podría haberse roto en 0.12 y arreglado después.

Mismo problema aquí. Alguna actualización ? Estoy usando node.js 4.2.2 y recibo un error ECONNRESET periódico (3-4 veces por minuto).

Hola, @aymeba , parece que la primera versión 4.x que tiene esta corrección es la 4.4.0.

Busque confirmaciones tituladas http: handle errors on idle sockets . Hay un montón de compromisos diferentes con este título, ya que se aplicó a diferentes ramas.

No importa, me confundí y estaba hablando de un error ECONNRESET en node.js (#3595).

No creo que suceda debido al error que señalaste. En nuestro caso aparece:

• Enviar una solicitud a nuestro backend
• Backend procesa la solicitud
• De alguna manera, la solicitud se está desconectando sin esperar la respuesta y estamos obteniendo ECONNRESET
• Estamos seguros de que nuestro servidor backend no interrumpe la conexión.

Me confunde recibir este error porque, en un caso habitual, nuestro servidor backend debería arrojar este error o?

¿Alguna actualización sobre esto?. Veo el error con botkit 0.2.1.

Tengo un problema similar. He hecho horas de investigación, pruebas y depuración. En mi caso, al publicar en el mismo restapi a través de Postman, el punto final funciona bien. Hacer la solicitud a través de la llamada http.request nativa de NodeJS falla. Todos los encabezados y la carga útil (cuerpo) son iguales. (excepto que no tengo el token de cartero en los encabezados)

Divulgación completa, estoy usando restify para mi servidor.

En caso de que use restify en el lado del servidor, sería útil habilitar el auditor, que debería proporcionar alguna pista sobre lo que está sucediendo. Además, asegúrese de configurar el "Tipo de contenido" correcto en su solicitud para que el servidor sepa qué esperar. He visto este error cuando el servidor no entiende la solicitud, por lo que será útil proporcionar el tipo de contenido.

¿Alguna actualización sobre este tema? Todavía veo que este problema ocurre con Node v5.0.0. Veo que arroja un error exactamente después de 45 segundos desde el momento en que se realiza la solicitud.

He visto este mismo problema con HapiJS. El problema era un encabezado de longitud de contenido incorrecto

quiero hacer una solicitud de suscripción y notificación gracias...

sucediendo con Node v6.9.2.

  get: async function(ctx) {
    let body = await new Promise(function(resolve, reject) {
      return ctx.req.pipe(request('/path/to/my/backend', function(err, res, body) {
        if (err) { return reject(err) }
        resolve(body)
      }))
    })
    return body
  }

Estoy viendo esto también con el nodo 6.6.0. El servidor al que me estoy conectando no envía un encabezado de longitud de contenido en la respuesta, en cuyo caso, de acuerdo con la especificación HTTP, el servidor debe cerrar la transmisión después de enviar todos los datos. Sospecho que esto se está malinterpretando como un enchufe colgado. Hacer la misma solicitud con cURL funciona bien.

+1
Nodo 6.9.4
solicitud 2.79.0

Funciona bien con rizo.
La URL que trato de obtener devuelve el encabezado Content-Length

+1
Nodo 6.9.1
solicitud 2.79.0

Wget, curl - éxito, pero solicitud - error.

Nodo - v6.9.4
Solicitud - 2.79.0

# node req.js
REQUEST { uri: 'http://wtfismyip.com', callback: [Function] }
REQUEST make request http://wtfismyip.com/

{ Error: socket hang up
    at createHangUpError (_http_client.js:254:15)
    at Socket.socketOnEnd (_http_client.js:346:23)
    at emitNone (events.js:91:20)
    at Socket.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9) code: 'ECONNRESET' }

Tener el mismo problema. Curiosamente, parece ser independiente de la versión de solicitud, ya que el mismo código funciona para mí en 6.4.0, pero se rompe en 6.9.2 (estas son solo las 2 versiones de nodejs que tengo instaladas).

En mi caso, pude solucionar el problema configurando el encabezado Connection: keep-alive .

@dieseldjango Gracias por la sugerencia. Sin embargo, no resolvió mi caso.

Aquí hay un sitio que da este error, para la reproducción:

{ request: 
   { debugId: 1,
     uri: 'https://www.deal.no/',
     method: 'GET',
     headers: 
      { Connection: 'keep-alive',
        host: 'www.deal.no',
        'accept-encoding': 'gzip, deflate' } } }
error:  Error: socket hang up
    at TLSSocket.onHangUp (_tls_wrap.js:1111:19)
    at TLSSocket.g (events.js:291:16)
    at emitNone (events.js:91:20)
    at TLSSocket.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

..usando request-debug para depurar los encabezados enviados

¿Aún no está resuelto esto? Estaba funcionando bien como hace dos semanas y ahora recibo este error
{ [Error: socket hang up] code: 'ECONNRESET', response: undefined }
nodo -v 4.4.7

intente eliminar 'aceptar codificación': 'gzip, desinflar' en los encabezados resuelto esto.

Veo que la gente recibe este error con más frecuencia. En mi caso fue muy sencillo. Lo que pensé que era una URL correctamente formada basada en uno de mis algoritmos, en realidad estaba mal formada. Animo a todos los que experimentan este problema a asumir que el problema está en su código. Te aseguro que en el 98% de los casos la causa principal es algo mundano que das por sentado o pasas por alto. Intenté todo lo anterior para resolver el problema, pero al final, se redujo a una barra diagonal adicional.

Trato de seguir todas las sugerencias que usted dice, pero este problema aún ocurre. muy triste....

Si ayuda a alguien, eventualmente solucioné el problema usando require('child_process').exec para llamar a curl. Asegúrese de desinfectar adecuadamente sus entradas si provienen de la tierra del usuario.

Intente solicitar a google.com => nombre de host: 'google.com' para comprobar si funciona o no.
En mi caso, "nombre de host" fue manejado por nginx como proxy y no responde cuando recibe una solicitud con un cuerpo vacío.
Este código obtiene un error:

var http = require("http");
var options = {
  hostname: 'myAddressNginx',
  port: 80,
  path: '/',
  method: 'GET',
  headers: {
    'Content-Type': 'text/html',
    'Content-Length': Buffer.byteLength("")
  }
};

var req = http.request(options, (res) => {
  res.on('data', (chunk) => {console.log("%s", chunk);});
  res.on('end', () => {});
});

// write data to request body
req.write("");
req.end();

Este código funciona

var http = require("http");
var options = {
  hostname: 'myAddressNginx',
  port: 80,
  path: '/',
  method: 'GET',
  headers: {
    'Content-Type': 'text/html',
    'Content-Length': Buffer.byteLength("")
  }
};

var req = http.request(options, (res) => {
  res.on('data', (chunk) => {console.log("%s", chunk);});
  res.on('end', () => {});
});

// write data to request body
req.write("abc");
req.end();

+1
Nodo 6.9.5

Hola chicos, tengo el mismo problema. +1
Afortunadamente, uso 'solicitud' dentro de una segunda herramienta de monitoreo, por lo que mis problemas son mínimos. Me gusta mucho node.js, así que estoy publicando algunos comentarios. Espero que mis comentarios ayuden un poco con sus intentos de solucionar el problema.

El error ahora aparece constantemente en entornos de producción de alto tráfico.
Puedo hacer girar una réplica "exacta" del servidor y aparece el error "nunca". Puedo cambiar los puntos finales, y siempre termina que el entorno de producción de alto tráfico causa este error para el cliente.
{ [Error: el socket cuelga] código: 'ECONNRESET' }.

Esto comenzó como un error intermitente que noté hace varios días y después de que el servicio de monitoreo emitiera falsas alarmas demasiadas veces... y muchísimas veces probando con herramientas de prueba de producción que no usan 'solicitud', comencé buscando en la web para encontrar este problema aquí.

Ahora no he cambiado ningún código/versión en más de 8 meses para esta aplicación y estoy confundido sobre cómo esto puede suceder de la nada. Entonces... ¿qué cambió en el mundo de las 'solicitudes' si no cambié ningún código de cliente?

+1
Nodo 6.9.1

Esto solo sucede de vez en cuando, cuando pruebo mis puntos finales localmente, ejecutando muchas solicitudes de una manera bastante rápida...

También nos enfrentamos al mismo problema con node4 y node6. trabajando bien con node0.12.

Por favor, ayuda para arreglar esto.

problema similar en el problema https.request nativo
ver más aquí ,

agregar a continuación a la opción de solicitud evitará (solucionará) este problema,

agentOptions: {
  ciphers: 'DES-CBC3-SHA'
}

me atrapó y pasé toda la tarde tratando de resolverlo... estaba en un entorno complicado con varias capas de redirección: is this DNS issue? -> no way it's DNS -> definitely DNS -> no it's not
hasta que vi el ejemplo de @fractalf y me di cuenta de que todo esto sucedía solo en sitios alojados en IIS6 con https

Sin suerte.

establecer cifrados para seguir no funcionó para mí.
opciones de agente: {
cifrados: 'DES-CBC3-SHA'
}

@aganapan ¿cuál es la URL que estabas solicitando? Mi solución solo solucionará problemas relacionados con el alojamiento de sitios web en IIS6 + TLS1.0. Podría haber otros problemas que resulten en un mensaje de error similar.

Yo tuve el mismo problema. Usé ngrok y miré la solicitud RAW. Resultó que había un carácter no imprimible e2808b adjunto a la entrada del usuario. Lo más probable es copiar/pegar. Utilicé encodeURIComponent() en esa parte URI proporcionada por el usuario y el problema desapareció.

Yo tuve el mismo problema.

• nodo V6.9.5
• solicitud V2.69.0

@danielkhan He usado el método encodeURIComponent ;

// this is request
{
    "request": {
        "debugId": 5,
        "uri": "https://xxx.cdn.cn/js/information_main_27d1838a.js",
        "method": "GET",
        "headers": {
            "user-agent": "Mozilla/5.0 (Linux; Android 5.1.1; Nexus 6 Build/LYZ28E) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Mobile Safari/537.36",
            "host": "xxx.cdn.cn"
        }
    }
}

{
    "response": {
        "debugId": 5,
        "headers": {
            "expires": "Sat, 15 Apr 2017 11:01:16 GMT",
            "date": "Thu, 16 Mar 2017 11:01:16 GMT",
            "content-type": "application/x-javascript; charset=utf-8",
            "content-length": "49785",
            "last-modified": "Sun, 12 Mar 2017 14:30:49 GMT",
            "cache-control": "max-age=2592000",
            "access-control-allow-origin": "*",
            "accept-ranges": "bytes",
            "age": "19",
            "x-cache": "HIT from www.matocloud.com",
            "connection": "close",
            "alt-svc": "h2=\":443\""
        },
        "statusCode": 200
    }
}

Node.js 6.10.0
solicitud 2.72.0

Encontramos el mismo problema al ejecutar algunas pruebas de integración de back-end. Nuestro producto se conecta a varios dispositivos de red mediante HTTPS. En este escenario, estamos estableciendo varias conexiones HTTPS y ejecutando algunas solicitudes POST y GET para cada dispositivo.
Dado que el problema ocurrió en nuestro entorno de prueba, la solución fue deshabilitar las conexiones persistentes HTTP (establecer el encabezado HTTP Connection: close ). Al hacer esto, le pedimos al servidor que cierre la conexión después de entregar la respuesta (HTTP/1.1). Sin embargo, perdemos los beneficios de las conexiones persistentes HTTP ya que ahora cada TCP atenderá solo una solicitud.

Chrome está bloqueando esta solución DES-CBC3-SHA

Para mí, curl no funciona. Descubrí que había configurado el proxy en mi herramienta de línea de comandos antes. Funciona bien ahora cuando elimino el proxy.

Todavía estoy teniendo este problema.

{ Error: socket hang up
 at createHangUpError (_http_client.js:302:15)
 at Socket.socketOnEnd (_http_client.js:394:23)
 at emitNone (events.js:91:20)
 at Socket.emit (events.js:186:7)
 at endReadableNT (_stream_readable.js:974:12)
 at _combinedTickCallback (internal/process/next_tick.js:74:11)
 at process._tickDomainCallback (internal/process/next_tick.js:122:9) code: 'ECONNRESET' }

Finalmente conseguí que esto funcionara para el recaptcha. Tuve que importar y usar la biblioteca https. Aquí está el código de trabajo:

var https = require('https');
var cadena de consulta = require('cadena de consulta');

var secret = "TU_CLAVE";
var respuesta = RESPONSE_CODE;
var postData = "secret="+secret+"&"+"response="+response;

// Construir la cadena de publicación a partir de un objeto
var post_data = cadena de consulta.stringify({
'nivel_de_compilación': 'OPTIMIZACIONES_AVANZADAS',
'formato_de_salida': 'json',
'output_info': 'código_compilado',
'warning_level': 'SILENCIO',
'js_code': datos posteriores
});

var opciones = {
nombre de host: ' www.google.com ',
puerto: 443,
ruta: '/recaptcha/api/siteverify',
método: 'POST',
encabezados: {
'Tipo de contenido': 'aplicación/x-www-form-urlencoded'
//'codificación de contenido': 'gzip',
//'Conexión': 'cerrar'
},
opciones de agente: {
cifrados: 'DES-CBC3-SHA'
}
};
var req = https.request(opciones, función(res) {
console.log('Estado: ' + res.statusCode);
console.log('Encabezados: ' + JSON.stringify(res.headers));
res.setEncoding('utf8');
res.on('datos', función (cuerpo) {
console.log('Cuerpo: ' + cuerpo);
});
});
req.on('error', function(e) {
console.log('problema con solicitud: ' + e.message);
});
// escribir datos en el cuerpo de la solicitud
req.write(postData);
req.end();

NOTA: registre esto para otros que probablemente tropezarán con esta discusión cuando busquen en Internet ese mensaje de error en particular.

Como resultado, la mayor parte de la discusión anterior pierde el punto, porque el error no es causado por el sitio del cliente y, por lo tanto, probar diferentes "soluciones alternativas" para request probablemente no funcionará. El problema es que el socket de solicitud HTTP en el lado del

Si también es responsable del código fuente del lado del servidor y usa el marco express/koa, entonces debe deshabilitar el tiempo de espera inactivo en el socket de solicitud HTTP antes de iniciar la operación de back-end de larga duración. Por ejemplo, para un controlador de ruta ES6 koa:

javascript ctx => { .... ctx.socket.setTimeout(0); // now trigger the long lasting backend operation .... }

Ahora mi problema de tiempo de espera del cliente se ha ido sin cambiar ninguna línea en el código del cliente...

asegúrese de llamar a la URL con el SSL correcto, ya sea https o http

También es un problema de proxy en mi caso. Después de restablecer http_proxy y https_proxy, el problema desaparece.

Tuve el mismo problema.

Para rizo:
HTTP/1.1 200 OK

Para el módulo http nativo:
{ [Error: socket hang up] code: 'ECONNRESET' }

Para el módulo de solicitud:
{ [Error: socket hang up] code: 'ECONNRESET' }

La razón fue en respuesta, particularmente en la sintaxis incorrecta del protocolo http.
\n símbolo \r\n , y después del último encabezado - \r\n\r\n .

Cuando se solucionó, el error desapareció.

Puede ser que sea útil y ahorre tiempo para alguien.

Yo tuve el mismo problema. En mi caso, configuré User-Agent en los encabezados de las opciones de solicitud y el problema desapareció.

Tener el mismo problema con Node 8.x

+1
Nodo 8.1.2
"solicitud": "=2.81.0"

{
    "method": "GET",
    "json": true,
    "uri": "http://www.bb.com/xxxxxxxxxxx",
    "baseUrl": null,
    "headers": {
        "cookie": "yyyyy",
        "user-agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Mobile/14G60"
    },
    "qs": {
        "app_version": "1.9.8.8",
        "env": "prod"
    }
}

//res
Error: socket hang up
InternalServerError: Internal Server Error

// setting
var _request = require('request').defaults({
        forever      : true,
        maxRedirects : 8
    }),

Recibí el mismo error, pero un poco diferente, mi situación es así.
aplicación de prueba -> api A -> api B
-> significa solicitud
la aplicación de prueba obtiene el error de colgar cuando A solicita B muy lentamente y finalmente obtiene un error 500 de B (el error se maneja en api A).
Estoy seguro de que no es un problema de tiempo de espera, ya que api A hace muchas cosas y siempre devuelve una respuesta muy lenta, pero sin errores.
Ahora estoy realmente confundido sobre cómo funciona express y request, el error 500 ya está manejado por api A y tiene otras acciones de seguimiento. ¿Por qué la aplicación de prueba seguirá teniendo un error de bloqueo del socket?

También me encuentro con este problema en el último nodo (8.6), así como con la última versión 7.x. Los detalles están aquí si alguien quiere intentarlo: https://stackoverflow.com/questions/46666079/node-js-http-get-econnreset-error-on-read

Por favor, hágamelo saber si puedo proporcionar cualquier información adicional!

Tener el mismo problema con Node 6.10.0

Otra posible explicación: está enviando más datos en el cuerpo HTTP que los especificados en el encabezado Content-Length

+1
Nodo 8.6.0

Para solucionar el problema, debe:
1-Agregue process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
2-Actualizar zone.js a v0.7.4

Tuve el mismo problema y la resolución fue usar la variable de entorno NO_PROXY="yourcompany.com" así como strictSSL:false , ya que nuestra solicitud se estaba realizando a la URL interna de la empresa e intentaba usar un servidor proxy. Puede usar process.env.NO_PROXY="yourcompany.com" programáticamente.

+1
Nodo 8.8.1

at createHangUpError (_http_client.js:329:15)
at Socket.socketOnEnd (_http_client.js:421:23)
at emitNone (events.js:110:20)
at Socket.emit (events.js:207:7)
at endReadableNT (_stream_readable.js:1056:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickDomainCallback (internal/process/next_tick.js:218:9) code: 'ECONNRESET' }

parece que el problema de mi parte fue que Vagrant estaba "ocupando" el puerto y enviando un paquete TCP con un indicador de FIN inmediatamente después de mi solicitud de GET aunque aún no está claro por qué Chrome y Postman no tuvieron ningún problema. trabajando alrededor de esto, tal vez tengan algo de resiliencia adicional

Tuve este problema, GZIP estaba activado, Keep Alive también estaba activado.
El problema desapareció después de agregar paquetes.

const zlib = require('zlib'); // for GZIP
const http = require('http');
const https = require('https');

El mismo problema: se solucionó cambiando la URL de localhost a la IP real de la máquina host solo para su información

Todavía tengo este problema... Sin razón aparente.

info:  Error: socket hang up
    at createHangUpError (_http_client.js:345:15)
    at Socket.socketOnEnd (_http_client.js:437:23)
    at emitNone (events.js:110:20)
    at Socket.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1059:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

hola, no sé si ya resolviste este problema, pero lo resolví hoy, cuando depuro, encuentro,

// Using native http
let postData = querystring.stringify(data);
...
req.write(postData);

si su servidor remoto es iniciado por koa (u otro servidor nodejs), y los datos son {} , el postData mediante la función stringify se transforma en {} , pero el servidor koa obtiene el {} arrojará el parser error , por lo que esta solicitud arrojará un error por

Error: socket hang up
    at createHangUpError (_http_client.js:345:15)
    at Socket.socketOnEnd (_http_client.js:437:23)
    at emitNone (events.js:110:20)
    at Socket.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1059:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

así que tuve que hacer esto: __postData = postData === '{}' ? '' : postData__

espero que te pueda ayudar

Para mí, esto sucede al enviar una solicitud de POST con content-length : 0 en los encabezados de la solicitud. No sé si este resultado es razonable, pero al menos creo que puede intentar eliminar cada elemento de los encabezados que agregó para averiguar el motivo del problema.

cuando cambio 'GET' a 'POST', arréglalo. pero no sé por qué, lo arreglo desde https://cnodejs.org/topic/57a6c35282e6ea4870ecd3f2 , alguien dijo que si usa 'GET', el código no puede ejecutar res.on('data', cb)

@LvChengbin También estaba enfrentando el mismo problema en la solicitud de POST . Reemplazar Content-Length : 0 con la longitud real del cuerpo funcionó para mí.

Que alguien me salve :angel:

También tengo el mismo problema en bode v.8.9

{ Error: el enchufe cuelga
en createHangUpError (_http_client.js:331:15)
en Socket.socketOnEnd (_http_client.js:423:23)
en emitNone (eventos.js:111:20)
en Socket.emit (eventos.js:208:7)
en endReadableNT (_stream_readable.js:1064:12)
en _combinedTickCallback (interno/proceso/next_tick.js:138:11)
en process._tickCallback (interno/proceso/next_tick.js:180:9) código: 'ECONNR
ESET' }

mi código está abajo.

let solicitud=requerir("solicitud");
solicitud({
URL: " http://192.168.31.29 :3019/tactics/createMediaHotTotal20",
método: "OBTENER",
json: cierto,
encabezados: {
"tipo de contenido": "aplicación/json"
},
}, función (error, respuesta, cuerpo) {
si (error) {
consola.log(error)
} demás {
resolver (cuerpo);
}
})

Mismo problema, nodo v9.5.0

const https = require("https");
const fs = require("fs");

process.env.NO_PROXY="yourcompany.com";

const options = {
  hostname: "en.wikipedia.org",
  port: 443,
  path: "/wiki/George_Washingtons",
  method: "POST",
  // ciphers: 'DES-CBC3-SHA'
};

const req = https.request(options, (res) => {
  let responseBody = "";
  console.log("Response started");
  console.log(`Server Status: ${res.statusCode} `);
  console.log(res.headers);
  res.setEncoding("UTF-8");

  res.once("data", (chunk) => {
    console.log(chunk);
  });

  res.on("data", (chunk) => {
    console.log(`--chunk-- ${chunk.length}`);
    responseBody += chunk;
  });

  res.on("end", () => {
    fs.writeFile("gw.html", responseBody, (err) => {
      if (err) throw err;
      console.log("Downloaded file");
    });
  });
});

req.on("error", (err) => {
  console.log("Request problem", err);
});

Request problem { Error: socket hang up
    at createHangUpError (_http_client.js:330:15)
    at TLSSocket.socketOnEnd (_http_client.js:423:23)
    at TLSSocket.emit (events.js:165:20)
    at endReadableNT (_stream_readable.js:1101:12)
    at process._tickCallback (internal/process/next_tick.js:152:19) code: 'ECONNRESET' }



md5-988987fef0feed585119ccc2fe5450ba



~/node-training> npm config ls -l
; cli configs
long = true
metrics-registry = "https://registry.npmjs.org/"
scope = ""
user-agent = "npm/6.1.0 node/v9.5.0 darwin x64"

; userconfig /Users/katsanos/.npmrc
strict-ssl = false

; default values
access = null
allow-same-version = false
also = null
always-auth = false
audit = true
auth-type = "legacy"
bin-links = true
browser = null
ca = null
cache = "/Users/katsanos/.npm"
cache-lock-retries = 10
cache-lock-stale = 60000
cache-lock-wait = 10000
cache-max = null
cache-min = 10
cafile = undefined
cert = null
cidr = null
color = true
commit-hooks = true
depth = null
description = true
dev = false
dry-run = false
editor = "vi"
engine-strict = false
fetch-retries = 2
fetch-retry-factor = 10
fetch-retry-maxtimeout = 60000
fetch-retry-mintimeout = 10000
force = false
git = "git"
git-tag-version = true
global = false
global-style = false
globalconfig = "/usr/local/etc/npmrc"
globalignorefile = "/usr/local/etc/npmignore"
group = 1493692218
ham-it-up = false
heading = "npm"
https-proxy = null
if-present = false
ignore-prepublish = false
ignore-scripts = false
init-author-email = ""
init-author-name = ""
init-author-url = ""
init-license = "ISC"
init-module = "/Users/katsanos/.npm-init.js"
init-version = "1.0.0"
json = false
key = null
legacy-bundling = false
link = false
local-address = undefined
loglevel = "notice"
logs-max = 10
; long = false (overridden)
maxsockets = 50
message = "%s"
; metrics-registry = null (overridden)
no-proxy = null
node-options = null
node-version = "9.5.0"
offline = false
onload-script = null
only = null
optional = true
otp = null
package-lock = true
package-lock-only = false
parseable = false
prefer-offline = false
prefer-online = false
prefix = "/usr/local"
production = false
progress = true
proxy = null
read-only = false
rebuild-bundle = true
registry = "https://registry.npmjs.org/"
rollback = true
save = true
save-bundle = false
save-dev = false
save-exact = false
save-optional = false
save-prefix = "^"
save-prod = false
scope = ""
script-shell = null
scripts-prepend-node-path = "warn-only"
searchexclude = null
searchlimit = 20
searchopts = ""
searchstaleness = 900
send-metrics = false
shell = "/usr/local/bin/fish"
shrinkwrap = true
sign-git-tag = false
sso-poll-frequency = 500
sso-type = "oauth"
; strict-ssl = true (overridden)
tag = "latest"
tag-version-prefix = "v"
timing = false
tmp = "/var/folders/kn/3cnpbcsx60n4fx_jv6sf4l80_mdkps/T"
umask = 18
unicode = true
unsafe-perm = true
usage = false
user = 356960985
; user-agent = "npm/{npm-version} node/{node-version} {platform} {arch}" (overridden)
userconfig = "/Users/katsanos/.npmrc"
version = false
versions = false
viewer = "man"

EDITAR : me faltaba req.end() . Obras

Tengo el mismo error. El POST funciona cuando se agrega Content-Length a la solicitud. Espero que esto les ayude chicos:
'Content-Length': Buffer.byteLength(data) //Se necesita Content-Length para un POST

En mi caso, pude solucionar el problema configurando el encabezado Connection: keep-alive .

¡SALVA MI DÍA!

Lo excavo un poco.
Tengo un problema posterior una vez a la semana con la solicitud cuando envío POST al servidor nodejs.
Después de ir a Dipper, descubrí que nodejs simplemente cuelga la conexión si la solicitud tiene un formato incorrecto.

Parece que ocurre un error posterior cuando la solicitud POST se pasa a http.request

En mi caso, el cuerpo se envió sin los últimos símbolos y TAL VEZ se debió a un error de cálculo de Content-Length en setContentLength()

El uso del protocolo 'http' en lugar de 'https' también resuelve el problema.

Esto es muy frustrante. No tengo control sobre el servidor, pero no puedo hacer POST desde Nodejs (usando solicitud o superagente), pero puedo hacer curl o Postman con éxito. Aún más loco, la llamada tendría éxito si hago una pausa usando el depurador en la declaración de solicitud y continúo.

En mi caso, simplemente eliminé el encabezado 'Host', resuelto.

Nos encontramos con este problema después de actualizar a un nodejs más nuevo ( 10.16.3 ). En el lado del cliente, usamos el agente http de nodejs con keepAlive: true . Parece que sucedió lo siguiente:

• el cliente usa un socket libre para hacer una solicitud
• al mismo tiempo, el servidor cierra el socket debido a la configuración de

Solución
Hasta ahora hemos encontrado dos soluciones:
1) En el lado del servidor, deshabilite keepAliveTimeout configurándolo igual a 0
2) Cierra sockets libres en menos de keepAliveTimeout valor (por defecto 5 segundos). El agente http predeterminado no admite dicha capacidad (la configuración timeout no lo hace). Así que usamos agentkeepalive lib

const HttpsAgent = require('agentkeepalive').HttpsAgent;

const agent = new HttpsAgent({
    freeSocketTimeout: 4000
});

let req = http.get(options, (res) => {
    ...........
    ...........
}).on('error', function(e) {
        console.error(e);
});

Prueba esto.

Nos enfrentamos a un problema similar: actualmente, estamos usando 6.11.x pero probamos el nodo 10 pero no ayuda.

Incluso intentamos actualizar el módulo de solicitud + agregar todas las sugerencias proporcionadas, pero no hubo ayuda.

Cualquier otra idea o ayuda en la resolución de problemas.

podemos resolver este problema: nuestra puerta de enlace API tenía una configuración de tiempo de espera que causaba este problema. gracias por investigarlo

podemos resolver este problema: nuestra puerta de enlace API tenía una configuración de tiempo de espera que causaba este problema. gracias por investigarlo

Hola, ¿puede decirme qué tipo de configuración de tiempo de espera conduce a este problema?

tengo el mismo problema cuando pruebo mis rutas con chai-http. lo absurdo es que los tres primeros pasan ok!! Estoy tratando de enfrentarlo todo el día

aquí mi código:
''
log("prueba de trabajo")
it("probar las rutas de /inicio de sesión", hecho => {
Chai
.request(servidor)
.post("/iniciar sesión")
.enviar({ })
.end(función(err, res) {
esperar (err).to.be.null;
esperar(res.estado).to.no.igual(404);
expect(res.body.message).to.not.be.equal("Not Found");
hecho();
});
});

log (prueba fallida con error: el zócalo cuelga)
it('prueba la ruta /getResetCodePassword', (hecho)=> {
Chai
.request(servidor)
.patch("/getResetCodePassword")
.enviar({ })
.end( (err, res) => {
consola.log(err);
hecho();
})
})

''