Request: Fehler: Socket hängt auf

Ich habe das gleiche Problem, aber das Hinzufügen der Option gzip:true wird funktionieren.

Welche Version von node.js verwenden Sie? Wir sehen gelegentlich ECONNRESET Ausnahmen nach dem Upgrade von 0.10 auf 0.12. Nach dem Durchstöbern der node.js-Bugs sieht es so aus, als ob dies in 0.12 defekt und danach behoben worden sein könnte.

Gleiches Problem hier. Irgendwelche Aktualisierungen? Ich verwende node.js 4.2.2 und erhalte einen periodischen (3-4 Mal pro Minute) ECONNRESET-Fehler.

Hallo @aymeba, es sieht so aus, als ob die erste 4.x-Version mit diesem Fix 4.4.0 ist.

Suchen Sie nach Commits mit dem Titel http: handle errors on idle sockets . Es gibt eine Reihe verschiedener Commits mit diesem Titel, da er auf verschiedene Branches angewendet wurde.

Egal, ich war verwirrt und sprach von einem ECONNRESET-Bug in node.js (#3595).

Ich glaube nicht, dass es aufgrund des Fehlers passiert, auf den Sie hingewiesen haben. In unserem Fall erscheint:

• Senden Sie eine Anfrage an unser Backend
• Backend verarbeitet die Anfrage
• Irgendwie wird die Anfrage getrennt, ohne auf die Antwort zu warten, und wir erhalten ECONNRESET
• Wir sind uns sicher, dass unser Backend-Server die Verbindung nicht unterbricht

Ich bin verwirrt, diesen Fehler zu erhalten, da unser Backend-Server in einem normalen Fall diesen Fehler ausgeben sollte oder?

Irgendein Update dazu?. Ich sehe den Fehler mit Botkit 0.2.1.

Ich habe ein ähnliches Problem. Ich habe stundenlang geforscht, getestet und debuggt. In meinem Fall funktioniert das Posten an das gleiche Restapi über Postman gut. Die Anforderung über den nativen NodeJS-http.request-Aufruf schlägt fehl. Alle Header und Nutzlast (Body) sind gleich. (außer ich habe das Postboten-Token nicht in den Headern)

Vollständige Offenlegung, ich verwende restify für meinen Server.

Falls Sie serverseitig restify verwenden, wäre es hilfreich, den Auditer zu aktivieren, der einen Hinweis darauf geben sollte, was vor sich geht. Stellen Sie außerdem sicher, dass Sie in Ihrer Anfrage den richtigen "Content-Type" einstellen, damit der Server weiß, was ihn erwartet. Ich habe diesen Fehler gesehen, wenn der Server die Anforderung falsch versteht, daher hilft die Angabe des Inhaltstyps.

Irgendein Update zu diesem Thema? Ich sehe dieses Problem immer noch mit Node v5.0.0. Ich sehe, dass es genau 45 Sekunden nach dem Zeitpunkt der Anforderung einen Fehler ausgibt.

Ich habe das gleiche Problem mit HapiJS gesehen. Das Problem war ein Header mit falscher Inhaltslänge

Ich möchte eine Anfrage für ein Abonnement und eine Benachrichtigung stellen, danke...

passiert mit 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
  }

Ich sehe dies auch mit Knoten 6.6.0. Der Server, mit dem ich mich verbinde, sendet in der Antwort keinen Content-Length-Header. In diesem Fall sollte der Server gemäß der HTTP-Spezifikation den Stream schließen, nachdem alle Daten gesendet wurden. Ich vermute, dass dies als Socket-Auflegen fehlinterpretiert wird. Die gleiche Anfrage mit cURL zu stellen funktioniert einwandfrei.

+1
Knoten 6.9.4
2.79.0 anfordern

Funktioniert gut mit curl
Die URL, die ich versuche zu erhalten, gibt den Header Content-Length zurück

+1
Knoten 6.9.1
2.79.0 anfordern

Wget, curl - Erfolg, aber Anfrage - Fehler.

Knoten - v6.9.4
Anfrage - 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' }

Habe das gleiche Problem. Interessanterweise scheint es unabhängig von der Request-Version zu sein, da der gleiche Code in 6.4.0 für mich funktioniert, aber in 6.9.2 bricht (dies sind nur die 2 nodejs-Versionen, die ich zufällig installiert habe).

In meinem Fall konnte ich das Problem umgehen, indem ich den Header Connection: keep-alive .

@dieseldjango Danke für den Vorschlag. Hat meinen Fall aber nicht gelöst.

Hier ist eine Site, die diesen Fehler zur Reproduktion ausgibt:

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

..mit request-debug zum Debuggen der gesendeten Header

Ist das noch nicht geklärt? Es hat wie vor zwei Wochen gut funktioniert und ich bekomme jetzt diesen Fehler
{ [Error: socket hang up] code: 'ECONNRESET', response: undefined }
Knoten -v 4.4.7

try remove 'accept-encoding': 'gzip, deflate' in den Headern hat dies gelöst.

Ich sehe, dass dieser Fehler häufiger auftritt. In meinem Fall war es ganz einfach. Was ich war zwar ein richtig gebildet URL basiert auf einer meiner Algorithmen, wurde tatsächlich fehlerhaft. Ich ermutige alle, die dieses Problem haben, davon auszugehen, dass das Problem in Ihrem Code liegt. Ich versichere Ihnen, in 98% der Fälle ist die Ursache etwas Alltägliches, das Sie für selbstverständlich halten oder übersehen. Ich habe alles oben Genannte versucht, um das Problem zu lösen, aber am Ende kam es zu einem zusätzlichen Schrägstrich.

Ich versuche, allen Vorschlägen zu folgen, die Sie sagen, aber dieses Problem tritt immer noch auf. so traurig....

Wenn es jemandem hilft, habe ich das Problem schließlich umgangen, indem ich require('child_process').exec zum Aufrufen von curl verwendet habe. Stellen Sie sicher, dass Sie Ihre Eingaben ordnungsgemäß desinfizieren, wenn sie aus dem Benutzerland stammen.

Bitte versuchen Sie eine Anfrage an google.com => Hostname: 'google.com', um zu überprüfen, ob es funktioniert oder nicht.
In meinem Fall wurde "hostname" von nginx als Proxy behandelt und antwortet nicht, wenn eine Anfrage mit leerem Text empfangen wird.
Dieser Code erhält einen Fehler:

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

Dieser Code funktioniert

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
Knoten 6.9.5

Hallo Leute, ich habe das gleiche Problem. +1
Zum Glück verwende ich 'request' in einem zweiten Überwachungstool, sodass meine Probleme minimal sind. Ich mag node.js sehr, deshalb poste ich etwas Feedback. Ich hoffe, mein Feedback hilft ein wenig bei Ihren Versuchen, das Problem zu beheben.

Der Fehler tritt jetzt ständig in Produktionsumgebungen mit hohem Datenverkehr auf.
Ich kann eine "genaue" Replik des Servers erstellen und der Fehler "nie" wird angezeigt. Ich kann Endpunkte umschalten, und es endet immer, dass die Produktionsumgebung mit hohem Datenverkehr diesen Fehler für den Client verursacht.
{ [Fehler: Socket aufgelegt] Code: 'ECONNRESET' }.

Dies begann als ein zeitweiliger Fehler, den ich vor einigen Tagen bemerkte und nachdem der Überwachungsdienst zu oft falsch alarmiert hatte... Suchen Sie im Internet nach diesem Problem hier.

Jetzt habe ich seit über 8 Monaten keinen Code / keine Version für diese Anwendung geändert und bin verwirrt, wie dies aus dem Nichts passieren kann. Also... was hat sich in der 'Anfrage'-Welt geändert, wenn ich keinen Client-Code ändere?

+1
Knoten 6.9.1

Dies passiert nur ab und zu, wenn ich meine Endpunkte lokal teste und viele Anfragen ziemlich schnell ausführe ...

Wir haben auch das gleiche Problem mit node4 und node6. funktioniert gut mit node0.12.

Bitte helfen Sie, dies zu beheben.

ähnliches Problem im nativen https.request- Problem
Mehr sehen Sie hier ,

Unten zur Anfrage-Option hinzufügen wird dieses Problem umgehen (beheben).

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

Ich wurde erwischt und verbrachte den ganzen Nachmittag damit, es herauszufinden... war in einer komplizierten Umgebung mit mehreren Umleitungsebenen: is this DNS issue? -> no way it's DNS -> definitely DNS -> no it's not
bis ich das Beispiel von @fractalf gesehen

Kein Glück.

Das Setzen von Chiffren auf folgende hat bei mir nicht funktioniert.
agentOptionen: {
Chiffren: 'DES-CBC3-SHA'
}

@aganapan was ist die URL, die Sie angefordert haben? Meine Lösung behebt nur Probleme im Zusammenhang mit dem Website-Hosting auf IIS6 + TLS1.0. Es könnte andere Probleme geben, die zu ähnlichen Fehlermeldungen führen.

Ich hatte das gleiche Problem. Ich habe ngrok verwendet und mir die RAW-Anfrage angesehen. Es stellte sich heraus, dass an die Benutzereingabe ein nicht druckbares e2808b-Zeichen angehängt wurde. Wahrscheinlich kopieren/einfügen. Ich habe encodeURIComponent() vom Benutzer bereitgestellten URI-Teil verwendet und das Problem verschwand.

Ich hatte das gleiche Problem.

• Knoten V6.9.5
• V2.69.0 anfordern

@danielkhan Ich habe die Methode encodeURIComponent verwendet;

// 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
2.72.0 . anfordern

Wir haben das gleiche Problem beim Ausführen einiger Back-End-Integrationstests festgestellt. Unser Produkt verbindet sich über HTTPS mit mehreren Netzwerkgeräten. In diesem Szenario stellen wir mehrere HTTPS-Verbindungen her und führen einige POST- und GET-Anfragen an jedes Gerät aus.
Da das Problem in unserer Testumgebung auftrat, bestand die Problemumgehung darin, die persistenten HTTP-Verbindungen zu deaktivieren (set HTTP header Connection: close ). Dabei fordern wir den Server auf, die Verbindung nach Zustellung der Antwort (HTTP/1.1) zu schließen. Wir verlieren jedoch die Vorteile persistenter HTTP-Verbindungen, da jetzt jeder TCP nur eine Anfrage bedient.

Chrome blockiert diese DES-CBC3-SHA Lösung

Bei mir funktioniert Curl nicht. Ich habe festgestellt, dass ich zuvor einen Proxy für mein Befehlszeilentool festgelegt hatte. Es funktioniert jetzt gut, wenn ich den Proxy entferne.

Ich bekomme dieses Problem immer noch.

{ 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' }

Habe dies endlich für das Recaptcha zum Laufen gebracht. Ich musste die https-Bibliothek importieren und verwenden. Hier ist der Arbeitscode:

var https = erfordern('https');
var querystring = require('querystring');

var geheim = "IHR_SCHLÜSSEL";
var-Antwort = RESPONSE_CODE;
var postData = "secret="+secret+"&"+"response="+response;

// Baue den Post-String aus einem Objekt
var post_data = querystring.stringify({
'compilation_level' : 'ADVANCED_OPTIMIZATIONS',
'output_format': 'json',
'output_info': 'compiled_code',
'warning_level' : 'RUHIG',
'js_code': postData
});

var-Optionen = {
Hostname: ' www.google.com ',
Hafen: 443,
Pfad: '/recaptcha/api/siteverify',
Methode: 'POST',
Überschriften: {
'Content-Type': 'application/x-www-form-urlencoded'
//'Inhaltscodierung': 'gzip',
//'Verbindung': 'schließen'
},
agentOptionen: {
Chiffren: 'DES-CBC3-SHA'
}
};
var req = https.request(Optionen, Funktion(res) {
console.log('Status: ' + res.statusCode);
console.log('Header: ' + JSON.stringify(res.headers));
res.setEncoding('utf8');
res.on('data', function (body) {
console.log('Körper: ' + Körper);
});
});
req.on('Fehler', Funktion(e) {
console.log('Problem mit Anfrage: ' + e.message);
});
// Daten in Anforderungstext schreiben
req.write (postData);
req.ende();

HINWEIS: Zeichnen Sie dies für andere auf, die wahrscheinlich über diese Diskussion stolpern, wenn sie im Internet nach dieser bestimmten Fehlermeldung suchen.

Wie sich herausstellte, geht der Großteil der obigen Diskussion über den Punkt, da der Fehler nicht von der Client-Site verursacht wird und daher das Ausprobieren verschiedener "Problemumgehungen" für request höchstwahrscheinlich nicht funktionieren wird. Das Problem besteht darin, dass der HTTP-Request-Socket auf der Serverseite aufgrund einer langen Verzögerung bei einer Hintergrundoperation in das Leerlauf-Timeout läuft und dann den Socket schließt. Daraus ergibt sich auf der Client-Seite das ECONNRESET.

Wenn Sie auch für den serverseitigen Quellcode verantwortlich sind und das express/koa-Framework verwenden, sollten Sie das Leerlauf-Timeout am HTTP-Request-Socket deaktivieren, bevor Sie den lang anhaltenden Backend-Vorgang einleiten. ZB für einen ES6-Koa-Route-Handler:

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

Jetzt ist mein Client-Timeout-Problem behoben, ohne dass eine Zeile im Clientcode geändert wurde ...

Stellen Sie sicher, dass Sie die URL mit dem richtigen SSL aufrufen - entweder https oder http

In meinem Fall ist es auch ein Proxy-Problem. Nach dem Zurücksetzen von http_proxy und https_proxy ist das Problem behoben.

Ich hatte das gleiche Problem.

Für Locken:
HTTP/1.1 200 OK

Für natives http-Modul:
{ [Error: socket hang up] code: 'ECONNRESET' }

Für Anfragemodul:
{ [Error: socket hang up] code: 'ECONNRESET' }

Der Grund war eine Reaktion, insbesondere eine falsche Syntax des http-Protokolls.
\n Symbol stand nach jedem Header, muss aber \r\n , und nach dem letzten Header - \r\n\r\n .

Als es behoben war, verschwand der Fehler.

Vielleicht ist es nützlich und spart Zeit für jemanden.

Ich hatte das gleiche Problem. In meinem Fall habe ich den User-Agent in den Headern in den Anfrageoptionen eingestellt und das Problem ist weg.

Habe das gleiche Problem mit Node 8.x

+1
Knoten 8.1.2
"Anfrage": "=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
    }),

Ich habe den gleichen Fehler, aber ein bisschen anders, meine Situation ist so.
Testapp -> API A -> API B
-> bedeutet Anfrage
Test-App bekommt den Auflegefehler, wenn A B sehr langsam anfordert, und bekommt schließlich einen 500-Fehler von B (der Fehler wird in API A behandelt).
Ich bin sicher, es ist kein Zeitüberschreitungsproblem, da API A viele Dinge tut und immer sehr langsam reagiert, aber kein Fehler.
Jetzt bin ich wirklich verwirrt, wie Express und Request funktionieren, der 500-Fehler wird bereits von API A behandelt und hat andere Aktionen zur Folge. Warum wird die Test-App immer noch einen Socket-Aufhängungsfehler erhalten?

Ich stoße auch auf dieses Problem im neuesten Knoten (8.6) sowie in der neuesten 7.x-Version. Details sind hier, wenn jemand einen Versuch machen möchte: https://stackoverflow.com/questions/46666079/node-js-http-get-econnreset-error-on-read

Bitte lassen Sie mich wissen, wenn ich weitere Informationen liefern kann!

Habe das gleiche Problem mit Node 6.10.0

Eine andere mögliche Erklärung: Sie senden mehr Daten im HTTP-Body als im Content-Length-Header angegeben

+1
Knoten 8.6.0

Um das Problem zu beheben, sollten Sie:
1-Prozess.env.NODE_TLS_REJECT_UNAUTHORIZED hinzufügen = "0";
2-Upgrade zone.js auf v0.7.4

Ich hatte das gleiche Problem und die Lösung bestand darin, die Umgebungsvariable NO_PROXY="yourcompany.com" sowie strictSSL:false zu verwenden , da unsere Anfrage an die interne Firmen-URL gerichtet war und versucht wurde, einen Proxy-Server zu verwenden. Sie können process.env.NO_PROXY="yourcompany.com" programmgesteuert verwenden.

+1
Knoten 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' }

Anscheinend war das Problem auf meiner Seite, dass Vagrant den Port "besetzt" und ein TCP-Paket mit einem FIN Flag direkt nach meiner GET Anfrage gesendet hat, obwohl es immer noch unklar ist, warum Chrome und der Postbote kein Problem hatten um das herum zu arbeiten - vielleicht haben sie etwas zusätzliche Widerstandsfähigkeit

Ich hatte dieses Problem, GZIP war an, Keep Alive war auch an.
Das Problem verschwand nach dem Hinzufügen von Paketen.

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

Gleiches Problem - behoben durch Ändern der URL von localhost auf die tatsächliche IP des Host-Rechners, nur eine Info

Habe immer noch dieses Problem.... Kein ersichtlicher Grund.

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)

hi， Ich weiß nicht, ob du dieses Problem noch gelöst hast， aber ich hatte das heute gelöst, als ich debugge, finde ich,

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

Wenn Ihr Remote-Server von koa (oder einem anderen nodejs-Server) gestartet wird und die Daten {} , wird die postData von der stringify-Funktion in {} , aber der Koa-Server erhält das {} wirft das parser error , also wirft diese Anfrage einen Fehler um

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)

also musste ich dies tun: __postData = postData === '{}'? '' : Post-Daten__

hoffe es kann dir helfen

Bei mir passiert dies beim Senden einer POST Anfrage mit content-length : 0 in den Anfrage-Headern. Ich weiß nicht, ob dieses Ergebnis vernünftig ist, aber ich denke zumindest, dass Sie vielleicht versuchen können, jedes Element in den Kopfzeilen zu entfernen, das Sie hinzugefügt haben, um den Grund für das Problem herauszufinden.

Wenn ich 'GET' in 'POST' ändere, behebe es. aber ich weiß nicht warum, ich repariere es von https://cnodejs.org/topic/57a6c35282e6ea4870ecd3f2 , jemand sagte, wenn Sie 'GET' verwenden, kann der Code nicht ausgeführt werden res.on('data', cb)

@LvChengbin Ich stand auch auf der Anfrage von POST vor dem gleichen Problem. Das Ersetzen von Content-Length : 0 durch die tatsächliche Länge des Körpers hat für mich funktioniert.

Jemand rettet mich :engel:

Ich habe auch das gleiche Problem in Bode v.8.9

{ Fehler: Socket hängt auf
at createHangUpError (_http_client.js:331:15)
bei Socket.socketOnEnd (_http_client.js:423:23)
bei emitNone (events.js:111:20)
bei Socket.emit (events.js:208:7)
bei endReadableNT (_stream_readable.js:1064:12)
bei _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickCallback (internal/process/next_tick.js:180:9) Code: 'ECONNR
ESET' }

mein Code ist unten.

let request=require("Anfrage");
Anfrage({
URL: " http://192.168.31.29 :3019/tactics/createMediaHotTotal20",
Methode: "GET",
json: wahr,
Überschriften: {
"content-type": "application/json"
},
}, Funktion (Fehler, Antwort, Hauptteil) {
wenn (Fehler) {
Konsole.log(Fehler)
} anders {
auflösen (Körper);
}
})

Gleiches Problem, Knoten 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"

EDIT : Mir fehlte req.end() . Funktioniert

Ich habe den gleichen Fehler. Der POST funktioniert, wenn Content-Length zur Anfrage hinzugefügt wird. Hoffe das hilft euch Jungs:
'Content-Length': Buffer.byteLength(data) //Content-Length wird für einen POST benötigt

In meinem Fall konnte ich das Problem umgehen, indem ich den Header Connection: keep-alive .

Rette meinen Tag!

Ich grabe es ein bisschen.
Ich habe einmal in der Woche ein Problem mit der Anfrage beim Senden von POST an den nodejs-Server.
Nachdem ich Dipper gegangen war, stellte ich fest, dass nodejs die Verbindung einfach aufhängt, wenn die Anforderung fehlerhaft ist.

Es sieht so aus, als ob ein hinterer Fehler passiert, wenn die POST-Anfrage an http.request übergeben wird

In meinem Fall wurde der Text ohne letzte Zeichen gesendet und MÖGLICHERWEISE lag es an einer falschen Berechnung der Inhaltslänge in setContentLength()

Die Verwendung von 'http' anstelle des 'https'-Protokolls löst das Problem ebenfalls.

Das ist sehr frustrierend. Ich habe keine Kontrolle über den Server, aber ich kann keinen POST von Nodejs aus durchführen (mithilfe von Request oder Superagent), aber ich kann curl oder Postman erfolgreich ausführen. Noch verrückter wäre der Aufruf, wenn ich die Verwendung des Debuggers für die Anforderungsanweisung anhalte und fortfahre.

In meinem Fall gerade den 'Host'-Header entfernt, gelöst.

Dieses Problem trat nach dem Upgrade auf ein neueres nodejs ( 10.16.3 ) auf. Auf der Clientseite haben wir den http-Agenten nodejs mit keepAlive: true . Es sieht so aus, als ob folgendes passiert ist:

• Client verwendet freien Socket, um eine Anfrage zu senden
• gleichzeitig schließt der Server den Socket wegen der Einstellung keepAliveTimeout, die in nodejs Version 8 aufgetreten ist

Lösung
Bisher haben wir zwei Lösungen gefunden:
1) Deaktivieren Sie auf der Serverseite keepAliveTimeout indem Sie es auf 0
2) Schließen Sie freie Sockets in weniger als keepAliveTimeout Wert (standardmäßig 5 Sekunden). Der Standard-HTTP-Agent unterstützt eine solche Funktion nicht (die Einstellung timeout tut dies nicht). Also haben wir agentkeepalive lib verwendet

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

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

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

Versuche dies.

Wir stehen vor einem ähnlichen Problem - derzeit verwenden wir 6.11.x, aber wir haben Knoten 10 ausprobiert, aber es hilft nicht.

Wir haben sogar versucht, das Anfragemodul zu aktualisieren + alle bereitgestellten Vorschläge hinzuzufügen, aber keine Hilfe.

Alle anderen Ideen oder Hilfe bei der Fehlerbehebung.

Wir sind in der Lage, dieses Problem zu beheben - unser API-Gateway hatte eine Zeitüberschreitungseinstellung, die dieses Problem verursachte. danke fürs reinschauen.

Wir sind in der Lage, dieses Problem zu beheben - unser API-Gateway hatte eine Zeitüberschreitungseinstellung, die dieses Problem verursachte. danke fürs reinschauen.

Hallo, können Sie mir sagen, welche Art von Timeout-Einstellung zu diesem Problem geführt hat?

Ich habe das gleiche Problem, wenn ich meine Routen mit Chai-http teste. Das Absurde ist, dass die ersten drei Durchgänge ok sind!! Ich versuche den ganzen Tag damit umzugehen

hier mein Code:
```
log("Arbeitstest")
it("testen Sie die /login-Routen", fertig => {
chai
.anfrage(server)
.post("/login")
.senden({ })
.end(funktion(err, res) {
erwarte(err).to.null;
erwarten (res.status).to.not.equal(404);
Expect(res.body.message).to.not.be.equal("Not Found");
fertig();
});
});

log(Fehlertest mit Fehler: Socket hängt auf)
it('testen Sie die /getResetCodePassword-Route', (erledigt)=> {
chai
.anfrage(server)
.patch("/getResetCodePassword")
.senden({ })
.end( (err,res) => {
Konsole.log(err);
fertig();
})
})

```