Buduję skrobak sieciowy z Node i Cheerio, a dla pewnej witryny pojawia się następujący błąd (zdarza się to tylko na tej jednej stronie, nie ma innych, które próbuję zeskrobać).

Zdarza się to za każdym razem w innym miejscu, więc czasami powoduje to url xbłąd, innym razem url xjest w porządku i jest to zupełnie inny adres URL:

    Error!: Error: socket hang up using [insert random URL, it's different every time]

Error: socket hang up
    at createHangUpError (http.js:1445:15)
    at Socket.socketOnEnd [as onend] (http.js:1541:23)
    at Socket.g (events.js:175:14)
    at Socket.EventEmitter.emit (events.js:117:20)
    at _stream_readable.js:910:16
    at process._tickCallback (node.js:415:13)

Jest to bardzo trudne do debugowania, tak naprawdę nie wiem od czego zacząć. Na początek, czym jest błąd zawieszenia gniazda? Czy to błąd 404 lub podobny? Czy to tylko oznacza, że ​​serwer odrzucił połączenie?

Nigdzie nie mogę tego wyjaśnić!

EDYCJA: Oto próbka kodu, który (czasami) zwraca błędy:

function scrapeNexts(url, oncomplete) {
    request(url, function(err, resp, body) {

        if (err) {
            console.log("Uh-oh, ScrapeNexts Error!: " + err + " using " + url);
            errors.nexts.push(url);
        }
        $ = cheerio.load(body);
        // do stuff with the '$' cheerio content here
    });
}

Nie ma bezpośredniego połączenia, aby zamknąć połączenie, ale używam Node Requesttego (o ile wiem), http.getwięc nie jest to wymagane, popraw mnie, jeśli się mylę!

EDYCJA 2: Oto rzeczywisty, używany fragment kodu, który powoduje błędy. prodURLa inne zmienne to głównie selektory jquery, które zostały wcześniej zdefiniowane. Używa asyncbiblioteki dla Węzła.

function scrapeNexts(url, oncomplete) {
    request(url, function (err, resp, body) {

        if (err) {
            console.log("Uh-oh, ScrapeNexts Error!: " + err + " using " + url);
            errors.nexts.push(url);
        }
        async.series([
                function (callback) {
                    $ = cheerio.load(body);
                    callback();
                },
                function (callback) {
                    $(prodURL).each(function () {
                        var theHref = $(this).attr('href');
                        urls.push(baseURL + theHref);
                    });
                    var next = $(next_select).first().attr('href');
                    oncomplete(next);
                }
            ]);
    });
}

Istnieją dwa przypadki socket hang uprzucenia:

Kiedy jesteś klientem

Gdy Ty, jako klient, wysyłasz żądanie do zdalnego serwera i nie otrzymujesz żadnej odpowiedzi w odpowiednim czasie. Twoje gniazdo jest zakończone, co generuje ten błąd. Powinieneś wychwycić ten błąd i zdecydować, jak go obsłużyć: czy ponowić żądanie, ustawić je w kolejce na później itp.

Gdy jesteś serwerem / proxy

Gdy jako serwer, być może serwer proxy, otrzymasz żądanie od klienta, a następnie zaczniesz na nim reagować (lub przekażesz żądanie do serwera nadrzędnego), a przed przygotowaniem odpowiedzi klient zdecyduje się anulować / przerwać prośba.

Ten ślad stosu pokazuje, co się dzieje, gdy klient anuluje żądanie.

Trace: { [Error: socket hang up] code: 'ECONNRESET' }
    at ClientRequest.proxyError (your_server_code_error_handler.js:137:15)
    at ClientRequest.emit (events.js:117:20)
    at Socket.socketCloseListener (http.js:1526:9)
    at Socket.emit (events.js:95:17)
    at TCP.close (net.js:465:12)

Linia http.js:1526:9wskazuje na to samo, o którym socketCloseListenermowa powyżej przez @Blender, w szczególności:

// This socket error fired before we started to
// receive a response. The error needs to
// fire on the request.
req.emit('error', createHangUpError());

...

function createHangUpError() {
  var error = new Error('socket hang up');
  error.code = 'ECONNRESET';
  return error;
}

Jest to typowy przypadek, gdy klient jest użytkownikiem przeglądarki. Żądanie załadowania części zasobów / strony trwa długo, a użytkownicy po prostu odświeżają stronę. Takie działanie powoduje, że poprzednie żądanie zostanie przerwane, co po stronie serwera zgłasza ten błąd.

Ponieważ ten błąd jest spowodowany życzeniem klienta, nie oczekuje on żadnego komunikatu o błędzie. Dlatego nie trzeba uważać tego błędu za krytyczny. Po prostu to zignoruj. Zachęca to fakt, że po takim błędzie resgniazdo, którego słuchał klient, jest, choć nadal zapisywalne, zniszczone.

console.log(res.socket.destroyed); //true

Więc nie ma sensu niczego wysyłać, z wyjątkiem jawnego zamknięcia obiektu odpowiedzi:

res.end();

Jednak to, co należy zrobić na pewno, jeśli jest serwer proxy, który już przekazał wniosek do Upstream jest do przerwania swojej wewnętrznej wniosku do Upstream, wskazując swój brak zainteresowania w odpowiedzi, co z kolei powie upstream serwer, aby być może zatrzymać kosztowną operację.

Spójrz na źródło :

function socketCloseListener() {
  var socket = this;
  var parser = socket.parser;
  var req = socket._httpMessage;
  debug('HTTP socket close');
  req.emit('close');
  if (req.res && req.res.readable) {
    // Socket closed before we emitted 'end' below.
    req.res.emit('aborted');
    var res = req.res;
    res.on('end', function() {
      res.emit('close');
    });
    res.push(null);
  } else if (!req.res && !req._hadError) {
    // This socket error fired before we started to
    // receive a response. The error needs to
    // fire on the request.
    req.emit('error', createHangUpError());
    req._hadError = true;
  }
}

Wiadomość jest emitowana, gdy serwer nigdy nie wysyła odpowiedzi.

Warto wspomnieć o jednym przypadku: kiedy łączę się z Node.js do Node.js za pomocą Express, dostaję „zawieszanie się gniazda”, jeśli nie poprzedzę żądanej ścieżki URL znakiem „/”.

Kiedyś korzystałem require('http')z usługi https , która pokazywała „ socket hang up”.

Potem zmieniłem require('http')na require('https')i to działa.

poniżej jest prosty przykład, w którym dostałem ten sam błąd, gdy brakowało mi dodania skomentowanego kodu w poniższym przykładzie. Usunięcie komentarza z kodu req.end()rozwiązuje ten problem.

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

var options = {
    host: "en.wikipedia.org",
    path: "/wiki/George_Washington",
    port: 443,
    method: "GET"
};

var req = https.request(options, function (res) {
    console.log(res.statusCode);
});


// req.end();

Rozwijając odpowiedź Blendera, dzieje się to w wielu sytuacjach. Najczęściej spotykane przeze mnie to:

1. Serwer się zawiesił.
2. Serwer odrzucił twoje połączenie, najprawdopodobniej zablokowane przez User-Agent.

socketCloseListener, jak opisano w odpowiedzi Blendera, nie jest jedynym miejscem, w którym powstają błędy zawieszenia.

Na przykład tutaj :

function socketOnEnd() {
  var socket = this;
  var req = this._httpMessage;
  var parser = this.parser;

  if (!req.res) {
    // If we don't have a response then we know that the socket
    // ended prematurely and we need to emit an error on the request.
    req.emit('error', createHangUpError());
    req._hadError = true;
  }
  if (parser) {
    parser.finish();
    freeParser(parser, req);
  }
  socket.destroy();
}

Możesz spróbować curlz nagłówkami i innymi, które są wysyłane z Węzła i sprawdzić, czy dostaniesz tam odpowiedź. Jeśli nie otrzymasz odpowiedzi curl, ale otrzymasz odpowiedź w przeglądarce, User-Agentnajprawdopodobniej Twój nagłówek zostanie zablokowany.

Innym przypadkiem, o którym warto wspomnieć (w przypadku systemu Linux i OS X) jest to, że jeśli korzystasz z biblioteki, takiej jak httpsdo wykonywania żądań, lub jeśli podasz https://...jako adres URL lokalnie obsługiwanej instancji, będziesz używać portu, 443który jest zarezerwowanym portem prywatnym, a ty może skończyć się w Socket hang uplubECONNREFUSED błędów.

Zamiast tego użyj port 3000, fe i wykonaj httpżądanie.

Miałem ten sam problem podczas korzystania z biblioteki Nano do łączenia się z wersją DB kanapy . Próbowałem dostroić pule połączeń za pomocą biblioteki keepaliveagent i nadal nie udawało się to z komunikatem rozłączenia się gniazda .

var KeepAliveAgent = require('agentkeepalive');

var myagent = new KeepAliveAgent({
    maxSockets: 10,
    maxKeepAliveRequests: 0,
    maxKeepAliveTime: 240000
});

nano = new Nano({
    url : uri,
    requestDefaults : {
        agent : myagent
    }
});

Po kilku zmaganiach udało mi się rozwiązać problem - jak się okazało, był to bardzo, bardzo prosty błąd. Łączyłem się z bazą danych za pomocą protokołu HTTPS, ale ciągle przekazywałem mojemu obiektowi nano agenta utrzymywania aktywności utworzonego jako przykłady użycia tego pokazu biblioteki (opierają się one na niektórych ustawieniach domyślnych, które używają http).

Jedna prosta zmiana w użyciu HttpsAgent załatwiła sprawę :

var KeepAliveAgent = require('agentkeepalive').HttpsAgent;

To spowodowało problemy, ponieważ robiłem wszystko tutaj wymienione, ale wciąż zgłaszano błędy. Okazuje się, że wywołanie req.abort () w rzeczywistości generuje błąd z kodem ECONNRESET, więc trzeba go złapać w module obsługi błędów.

req.on('error', function(err) {
    if (err.code === "ECONNRESET") {
        console.log("Timeout occurs");
        return;
    }
    //handle normal errors
});

Dla requestużytkowników modułu

Limit czasu

Istnieją dwa główne typy limitów czasu: limit połączenia i limitów odczytu . Connect limitu czasu występuje, jeśli limit czasu jest trafiony podczas gdy klient próbuje nawiązać połączenie ze zdalnym komputerem (odpowiadającejconnect()rozmowy na gnieździe). Odczytu limitu czasu występuje w każdej chwili serwer jest zbyt powolny, aby odesłać część odpowiedzi.

Pamiętaj, że limity czasu połączenia emitująETIMEDOUT błąd, a przekroczenia limitu czasu odczytu powodują ECONNRESETbłąd.

Miałem ten sam problem podczas żądania do jakiegoś serwera. W moim przypadku ustawienie dowolnej wartości na User-Agent w nagłówkach w opcjach żądania pomogło mi.

const httpRequestOptions = {
    hostname: 'site.address.com',
    headers: {
       'User-Agent': 'Chrome/59.0.3071.115'
    }
};

To nie jest ogólny przypadek i zależy od ustawień serwera.

Przyczyną może być również użycie appinstancji expresszamiast serverzconst server = http.createServer(app) jednocześnie tworząc gniazdo serwera.

Źle

const express = require('express');
const http = require('http');
const WebSocket = require('ws');


const app = express();

app.use(function (req, res) {
  res.send({ msg: "hello" });
});

const wss = new WebSocket.Server({ server: app }); // will throw error while connecting from client socket

app.listen(8080, function listening() {
  console.log('Listening on %d', server.address().port);
});

Poprawny

const express = require('express');
const http = require('http');
const WebSocket = require('ws');


const app = express();

app.use(function (req, res) {
  res.send({ msg: "hello" });
});

const server = http.createServer(app);
const wss = new WebSocket.Server({ server });

server.listen(8080, function listening() {
  console.log('Listening on %d', server.address().port);
});

Zajmuję się zarówno tworzeniem aplikacji internetowych (węzłów), jak i Androidem, a jednocześnie otwieram symulator urządzenia dokującego Android Studio i dokera, oba używają portu 8601, narzekał na socket hang upbłąd, po zamknięciu symulatora urządzenia Android Studio i działa dobrze po stronie węzła. Nie używaj razem symulatora urządzenia Android Studio i dokera.

Wystąpił podobny błąd podczas korzystania z CouchDB w klastrze OCP.

const cloudantSessionStore = sessionStore.createSessionStore(
  {
    type: 'couchdb',
    host: 'https://' + credentials['host'],
    port: credentials['port'],
    dbName: 'sessions',
    options: {
      auth: {
        username: credentials['username'],
        password: credentials['password']
      },
      cache: false
    }
  }

Który powinien być „http”, a nie „https”, aby połączyć się z moją instancją CouchDB. Mam nadzieję, że może to być pomocne dla każdego, kto ma podobny problem.

W moim przypadku było tak, ponieważ odpowiedź aplikacji / json była źle sformatowana (zawiera ślad stosu). Odpowiedź nigdy nie została wysłana na serwer. Debugowanie było bardzo trudne, ponieważ nie było dziennika. Ten wątek bardzo pomaga mi zrozumieć, co się dzieje.

Jeśli korzystasz z węzła-http-proxy, pamiętaj o tym problemie, który spowoduje błąd zawieszenia gniazda: https://github.com/nodejitsu/node-http-proxy/issues/180 .

Aby rozwiązać, także w tym łączu, po prostu przesuń deklarację trasy API (do proxy) w ramach tras ekspresowych przed express.bodyParser ().

Wystąpił wczoraj ten problem podczas uruchamiania mojej aplikacji internetowej i serwera node.js przez IntelliJ IDEA 2016.3.6. Wszystko, co musiałem zrobić, to wyczyścić pliki cookie i pamięć podręczną w przeglądarce Chrome.

Jeśli ten błąd występuje podczas połączenia https i występuje natychmiast, może to być problem z ustanowieniem połączenia SSL.

Dla mnie to był ten problem https://github.com/nodejs/node/issues/9845, ale dla ciebie może to być coś innego. Jeśli jest to problem z ssl, powinieneś być w stanie go odtworzyć za pomocą pakietu tod / ssl nodejs, który próbuje się połączyć z domeną

Myślę, że warto zauważyć ...

Tworzyłem testy interfejsów API Google. Przechwyciłem żądanie za pomocą prowizorycznego serwera, a następnie przesłałem je do prawdziwego interfejsu API. Próbowałem po prostu przekazać nagłówki w żądaniu, ale kilka nagłówków powodowało problem z ekspresowym na drugim końcu.

Mianowicie, musiałem usunąć connection, accepti content-lengthnagłówki przed użyciem modułu żądania do przekazania dalej.

let headers = Object.assign({}, req.headers);
delete headers['connection']
delete headers['accept']
delete headers['content-length']
res.end() // We don't need the incoming connection anymore
request({
  method: 'post',
  body: req.body,
  headers: headers,
  json: true,
  url: `http://myapi/${req.url}`
}, (err, _res, body)=>{
  if(err) return done(err);
  // Test my api response here as if Google sent it.
})

W moim przypadku nie był to błąd, ale oczekiwane zachowanie przeglądarki Chrome. Chrome utrzymuje połączenie tls przy życiu (myślę, że dla szybkości), ale serwer node.js zatrzymuje go po 2 minutach i pojawia się błąd.

Jeśli spróbujesz uzyskać polecenie GET przy użyciu przeglądarki krawędzi, nie wystąpi żaden błąd. Jeśli zamkniesz okno chrome - natychmiast otrzymasz błąd.

Co więc zrobić? 1) Możesz filtrować te błędy, ponieważ tak naprawdę nie są to błędy. 2) Może jest lepsze rozwiązanie :)

Wydaje się, że istnieje tutaj jeden dodatkowy przypadek, którym jest to, że Electron nie jest fanem nazwy domeny „localhost”. W moim przypadku musiałem to zmienić:

const backendApiHostUrl = "http://localhost:3000";

do tego:

const backendApiHostUrl = "http://127.0.0.1:3000";

Po tym problem zniknął.

Oznacza to, że rozpoznawanie DNS (lokalne lub zdalne) może również powodować pewne problemy.

Po długim debugowaniu w kodzie js węzła, ciągu połączenia mongodb, sprawdzaniu CORS itp. Dla mnie po prostu przełączenie na inny numer portu server.listen(port);sprawiło, że działało postman, spróbuj też. Brak zmian w proxyustawieniach, tylko wartości domyślne.