Request: Ошибка: зависание сокета

У меня такая же проблема, но добавление опции gzip:true будет работать.

Какую версию node.js вы используете? Мы наблюдаем случайные исключения ECONNRESET после обновления с 0.10 до 0.12. Судя по ошибкам node.js, это могло быть сломано в 0.12 и впоследствии исправлено.

Та же проблема здесь. Любые обновления ? Я использую node.js 4.2.2, и я получаю периодическую (3-4 раза в минуту) ошибку ECONNRESET.

Привет @aymeba, похоже, первая версия 4.x с этим исправлением - 4.4.0.

Найдите коммиты под названием http: handle errors on idle sockets . Существует куча разных коммитов с таким названием, так как оно применялось к разным веткам.

Ничего, я запутался и говорил об ошибке ECONNRESET в node.js (#3595).

Я не думаю, что это происходит из-за ошибки, которую вы указали. В нашем случае это выглядит так:

• Отправить запрос в наш бэкенд
• Бэкенд обрабатывает запрос
• Почему-то запрос отключается, не дождавшись ответа и получаем ECONNRESET
• Мы уверены, что наш backend сервер не обрывает соединение

Я сбит с толку этой ошибкой, потому что в обычном случае наш внутренний сервер должен выдавать эту ошибку или?

Любое обновление об этом? Я вижу ошибку с боткитом 0.2.1.

У меня похожая проблема. Я провел часы исследований, тестирования и отладки. В моем случае отправка на тот же рестапи через Postman конечная точка работает нормально. Не удалось выполнить запрос через собственный вызов NodeJS http.request. Все заголовки и полезная нагрузка (тело) одинаковы. (за исключением того, что у меня нет токена почтальона в заголовках)

Полное раскрытие, я использую restify для своего сервера.

В случае, если вы используете restify на стороне сервера, было бы полезно включить аудитора, который должен дать некоторую подсказку о том, что происходит. Кроме того, убедитесь, что вы устанавливаете правильный «Content-Type» в своем запросе, чтобы сервер знал, чего ожидать. Я видел эту ошибку, когда сервер неправильно понимает запрос, поэтому может помочь указание типа содержимого.

Есть новости по этому вопросу? Я все еще вижу эту проблему в Node v5.0.0. Я вижу, что он выдает ошибку ровно через 45 секунд с момента запроса.

Я видел эту же проблему с HapiJS. Проблема заключалась в неправильном заголовке длины содержимого.

я хочу сделать запрос на подписку и уведомление, спасибо...

происходит с 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
  }

Я тоже это вижу с узлом 6.6.0. Сервер, к которому я подключаюсь, не отправляет заголовок Content-Length в ответе, и в этом случае в соответствии со спецификацией HTTP сервер должен закрыть поток после отправки всех данных. Я подозреваю, что это неправильно интерпретируется как зависание сокета. Выполнение того же запроса с помощью cURL отлично работает.

+1
Узел 6.9.4
запрос 2.79.0

Отлично работает с завитком
URL-адрес, который я пытаюсь получить, возвращает заголовок Content-Length

+1
Узел 6.9.1
запрос 2.79.0

Wget, curl — успех, а запрос — ошибка.

Узел - v6.9.4
Запрос - 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' }

Имея ту же проблему. Интересно, что это не зависит от версии запроса, поскольку тот же код работает для меня в 6.4.0, но ломается в 6.9.2 (это только две версии nodejs, которые я установил).

В моем случае мне удалось обойти проблему, установив заголовок Connection: keep-alive .

@dieseldjango Спасибо за предложение. Хотя не решил мой случай.

Вот сайт, который выдает эту ошибку, для воспроизведения:

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

..используя request-debug для отладки отправленных заголовков

Это еще не решено? Он работал нормально, как две недели назад, и теперь я получаю эту ошибку
{ [Error: socket hang up] code: 'ECONNRESET', response: undefined }
узел -v 4.4.7

попробуйте удалить «accept-encoding»: «gzip, deflate» в заголовках решили эту проблему.

Я вижу, что люди чаще получают эту ошибку. В моем случае это было очень просто. То, что я считал правильно сформированным URL-адресом, основанным на одном из моих алгоритмов, на самом деле было искажено. Я призываю всех вас, столкнувшихся с этой проблемой, предположить, что проблема в вашем коде. Уверяю вас, в 98% случаев первопричиной является что-то обыденное, что вы принимаете как должное или не замечаете. Я пробовал все вышеперечисленное, чтобы решить проблему, но в конце концов все свелось к дополнительной косой черте.

Я стараюсь следовать всем предложениям, которые вы говорите, но эта проблема все еще возникает. так грустно....

Если это кому-нибудь поможет, я в конце концов решил проблему, используя require('child_process').exec для вызова curl. Убедитесь, что вы правильно дезинфицируете свои входные данные, если они поступают из пользовательского пространства.

Попробуйте запросить google.com => hostname: 'google.com', чтобы проверить, работает это или нет.
В моем случае «имя хоста» обрабатывается nginx как прокси, и он не отвечает при получении запроса с пустым телом.
Этот код получает ошибку:

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

Этот код работает

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
Узел 6.9.5

Привет ребята, у меня такая же проблема. +1
К счастью, я использую «запрос» во втором инструменте мониторинга, поэтому мои проблемы минимальны. Мне очень нравится node.js, поэтому я оставляю отзыв. Я надеюсь, что мой отзыв немного поможет вам в ваших попытках решить проблему.

Ошибка теперь постоянно появляется в производственных средах с высоким трафиком.
Могу раскрутить "точную" реплику сервера и появляется ошибка "никогда". Я могу переключать конечные точки, и это всегда заканчивается тем, что производственная среда с высоким трафиком вызывает эту ошибку для клиента.
{ [Ошибка: зависание сокета] код: 'ECONNRESET' }.

Это началось как прерывистая ошибка, которую я заметил несколько дней назад, и после того, как служба мониторинга слишком много раз давала ложные срабатывания ..... и чертовски много раз тестировалось с помощью инструментов производственного тестирования, которые не используют «запрос», я начал поиск в Интернете, чтобы найти эту проблему здесь.

Теперь я не менял код/версию для этого приложения более 8 месяцев и не понимаю, как это может произойти из ниоткуда. Итак... что изменилось в мире «запросов», если я не изменил код клиента?

+1
Узел 6.9.1

Это происходит только время от времени, когда я тестирую свои конечные точки локально, выполняя множество запросов довольно быстро...

Мы также сталкиваемся с той же проблемой с node4 и node6. отлично работает с node0.12.

Пожалуйста, помогите исправить это.

аналогичная проблема в родной проблеме https.request
увидеть больше здесь ,

добавьте ниже, чтобы запросить опцию, чтобы обойти (исправить) эту проблему,

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

я попал в ловушку и провел весь день, пытаясь понять это... был в сложной среде с несколькими уровнями перенаправления: is this DNS issue? -> no way it's DNS -> definitely DNS -> no it's not
пока я не увидел пример @fractalf и не понял, что все это происходит только с сайтами, размещенными на IIS6 с https

Не повезло.

установка шифров на следующие не сработала для меня.
Параметры агента: {
шифры: «DES-CBC3-SHA»
}

@aganapan какой URL вы запрашивали? Мое решение исправит только проблемы, связанные с хостингом веб-сайтов на IIS6 + TLS1.0. Могут быть и другие проблемы, которые приводят к аналогичному сообщению об ошибке.

У меня такая же проблема. Я использовал ngrok и посмотрел запрос RAW. Оказалось, что к пользовательскому вводу был добавлен непечатаемый символ e2808b. Скорее всего копипаст. Я использовал encodeURIComponent() для этой части URI, предоставленной пользователем, и проблема исчезла.

У меня такая же проблема.

• узел V6.9.5
• запрос V2.69.0

@danielkhan Я использовал метод 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
запрос 2.72.0

Мы обнаружили ту же проблему при выполнении некоторых внутренних интеграционных тестов. Наш продукт подключается к нескольким сетевым устройствам по протоколу HTTPS. В этом сценарии мы устанавливаем несколько соединений HTTPS и выполняем несколько запросов POST и GET на каждое устройство.
Поскольку проблема возникла в нашей тестовой среде, обходной путь состоял в том, чтобы отключить постоянные соединения HTTP (установить заголовок HTTP Connection: close ). Делая это, мы просим сервер закрыть соединение после доставки ответа (HTTP/1.1). Однако мы теряем преимущества постоянных HTTP-соединений, поскольку теперь каждый TCP будет обслуживать только один запрос.

хром блокирует это решение DES-CBC3-SHA

Для меня завиток не работает. Я обнаружил, что раньше устанавливал прокси для своего инструмента командной строки. Теперь он отлично работает, когда я удаляю прокси.

Я все еще получаю эту проблему.

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

Наконец-то заставил это работать для recaptcha. Мне пришлось импортировать и использовать библиотеку https. Вот рабочий код:

вар https = требуется ('https');
var строка_запроса = требуется('строка_запроса');

var секрет = "ВАШ_КЛЮЧ";
вар ответ = RESPONSE_CODE;
var postData = "secret="+secret+"&"+"response="+response;

// Строим строку поста из объекта
вар post_data = querystring.stringify({
'compilation_level' : 'ДОПОЛНИТЕЛЬНЫЕ_ОПТИМИЗАЦИИ',
'выходной_формат': 'json',
'output_info': 'скомпилированный_код',
'warning_level' : 'ТИХО',
'js_code': данные поста
});

параметры переменной = {
имя хоста: ' www.google.com ',
порт: 443,
путь: '/recaptcha/api/siteverify',
метод: «ПОСТ»,
заголовки: {
«Тип контента»: «application/x-www-form-urlencoded»
//'контент-кодирование': 'gzip',
//'Соединение': 'закрыть'
},
Параметры агента: {
шифры: «DES-CBC3-SHA»
}
};
var req = https.request (параметры, функция (разрешение) {
console.log('Статус: ' + res.statusCode);
console.log('Заголовки: ' + JSON.stringify(res.headers));
res.setEncoding('utf8');
res.on('данные', функция (тело) {
console.log('Тело: ' + тело);
});
});
req.on('ошибка', function(e) {
console.log('проблема с запросом: ' + e.message);
});
// записываем данные в тело запроса
req.write(postData);
запрос.конец();

ПРИМЕЧАНИЕ. Запишите это для тех, кто, вероятно, наткнется на это обсуждение при поиске в Интернете этого конкретного сообщения об ошибке.

Как оказалось, большая часть приведенного выше обсуждения упускает суть, потому что ошибка не вызвана клиентским сайтом, и, следовательно, попытки использовать различные «обходные пути» для request , скорее всего, не сработают. Проблема в том, что сокет HTTP-запроса на стороне сервера упирается в тайм-аут простоя из-за большой задержки в фоновой операции, а затем закрывает сокет. Это приводит к ECONNRESET на стороне клиента.

Если вы также несете ответственность за исходный код на стороне сервера и используете инфраструктуру express/koa, вам следует отключить тайм-аут простоя в сокете HTTP-запроса, прежде чем инициировать длительную бэкэнд-операцию. Например, для обработчика маршрута ES6 koa:

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

Теперь моя проблема с тайм-аутом клиента исчезла без изменения какой-либо строки в клиентском коде...

убедитесь, что вы вызываете URL-адрес с правильным SSL - https или http

Это также проблема прокси в моем случае. После сброса http_proxy и https_proxy проблема исчезла.

Я была такая же проблема.

Для завитка:
HTTP/1.1 200 OK

Для собственного модуля http:
{ [Error: socket hang up] code: 'ECONNRESET' }

Для модуля запроса:
{ [Error: socket hang up] code: 'ECONNRESET' }

Причина была в ответе, в частности в неправильном синтаксисе http протокола.
Символ \n был после каждого заголовка, но должен быть \r\n , а после последнего заголовка - \r\n\r\n .

После исправления ошибка исчезла.

Может кому пригодится и сэкономит время.

У меня такая же проблема. В моем случае я установил User-Agent в заголовках в параметрах запроса, и проблема исчезла.

Такая же проблема с Node 8.x

+1
Узел 8.1.2
"запрос": "= 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
    }),

У меня такая же ошибка, но немного другая, у меня такая ситуация.
testapp -> API A -> API B
-> означает запрос
тестовое приложение получает ошибку зависания, когда A очень медленно запрашивает B, и, наконец, получает ошибку 500 от B (ошибка обрабатывается в API A).
Я уверен, что это не проблема тайм-аута, так как API A делает много вещей и всегда возвращает ответ очень медленно, но без ошибок.
Теперь я действительно запутался, как работает экспресс и запрос, ошибка 500 уже обрабатывается API A, и за ней следуют другие действия. почему тестовое приложение по-прежнему будет получать ошибку зависания сокета?

Я также сталкиваюсь с этой проблемой в последнем узле (8.6), а также в последнем выпуске 7.x. Подробности здесь, если кто-то хочет нанести удар: https://stackoverflow.com/questions/46666079/node-js-http-get-econnreset-error-on-read

Пожалуйста, дайте мне знать, если я могу предоставить любую дополнительную информацию!

Та же проблема с Node 6.10.0

Другое возможное объяснение: вы отправляете больше данных в теле HTTP, чем указано в заголовке Content-Length.

+1
Узел 8.6.0

Чтобы устранить проблему, вам следует:
1-Добавить process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
2-Обновите zone.js до версии 0.7.4

У меня была та же проблема, и решение состояло в том, чтобы использовать переменную среды NO_PROXY="yourcompany.com" а также strictSSL:false , поскольку наш запрос был сделан на внутренний URL-адрес компании и пытался использовать прокси-сервер. Вы можете использовать process.env.NO_PROXY="yourcompany.com" программно.

+1
Узел 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' }

похоже, проблема с моей стороны заключалась в том, что Vagrant «занимал» порт и отправлял TCP-пакет с флагом FIN сразу после моего запроса GET хотя до сих пор неясно, почему у хрома и почтальона не было проблем обойти это - возможно, у них есть дополнительная устойчивость

У меня была эта проблема, GZIP был включен, Keep Alive тоже был включен.
Проблема исчезла после добавления пакетов.

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

Та же проблема - исправлена ​​​​путем изменения URL-адреса с локального хоста на фактический IP-адрес хост-компьютера, просто для справки.

Все еще есть эта проблема .... Без видимой причины.

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)

привет, я не знаю, решили ли вы эту проблему еще, но я решил эту сегодня, когда я отлаживаю, я нахожу,

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

если ваш удаленный сервер запускается с помощью koa (или другого сервера nodejs), а данные равны {} , функция postData помощью stringify преобразуется в {} , но сервер koa получает {} вызовет parser error , поэтому этот запрос вызовет ошибку

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)

поэтому я должен был сделать это: __postData = postData === '{}'? '': postData__

надеюсь, это может помочь вам

Для меня это происходит при отправке запроса POST с content-length : 0 в заголовках запроса. Я не знаю, является ли этот результат разумным, но, по крайней мере, я думаю, что вы можете попробовать удалить каждый элемент в заголовках, которые вы добавили, чтобы выяснить причину проблемы.

когда я меняю «GET» на «POST», исправьте это. но не знаю почему, я исправил это с https://cnodejs.org/topic/57a6c35282e6ea4870ecd3f2 , кто-то сказал, что если вы используете «GET», код не может работать res.on('data', cb)

@LvChengbin Я также столкнулся с той же проблемой по запросу POST . У меня сработала замена Content-Length : 0 фактической длиной тела.

Кто-нибудь, спасите меня :angel:

У меня тоже такая же проблема в боде v.8.9

{ Ошибка: зависание сокета
в createHangUpError (_http_client.js:331:15)
в Socket.socketOnEnd (_http_client.js:423:23)
в emitNone (events.js:111:20)
в Socket.emit (events.js:208:7)
в endReadableNT (_stream_readable.js:1064:12)
в _combinedTickCallback (внутренний/процесс/next_tick.js:138:11)
в process._tickCallback (внутренний/процесс/next_tick.js:180:9) код: 'ECONNR
ESET' }

мой код ниже.

пусть запрос = требуется ("запрос");
запрос({
URL-адрес: " http://192.168.31.29 :3019/tactics/createMediaHotTotal20",
метод: "ПОЛУЧИТЬ",
json: правда,
заголовки: {
"тип контента": "приложение/json"
},
}, функция (ошибка, ответ, тело) {
если (ошибка) {
console.log(ошибка)
} еще {
решить (тело);
}
})

Та же проблема, узел 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"

РЕДАКТИРОВАТЬ : мне не хватало req.end() . Работает

У меня такая же ошибка. POST работает, когда к запросу добавляется Content-Length. Надеюсь, это поможет вам, ребята:
'Content-Length': Buffer.byteLength(data) // Content-Length необходим для POST

В моем случае мне удалось обойти проблему, установив заголовок Connection: keep-alive .

СОХРАНИТЕ МОЙ ДЕНЬ!

Я копаю это немного.
У меня раз в неделю возникает проблема с запросом при отправке POST на сервер nodejs.
После перехода в ковш я обнаружил, что nodejs просто зависает соединение, если запрос искажен.

Похоже, что возникает какая-то задняя ошибка, когда запрос POST передается в http.request

В моем случае тело было отправлено без последних символов, и ВОЗМОЖНО, это произошло из-за неправильного расчета Content-Length в setContentLength()

Использование протокола «http» вместо «https» также решает проблему.

Это очень неприятно. У меня нет контроля над сервером, но я не могу выполнить POST из Nodejs (используя запрос или суперагент), но могу успешно выполнить curl или Postman. Что еще более безумно, вызов будет успешным, если я приостановлю использование отладчика в операторе запроса и продолжу.

В моем случае просто удалили заголовок «Host», решено.

Мы столкнулись с этой проблемой после обновления до более новой версии nodejs ( 10.16.3 ). На стороне клиента мы использовали http-агент nodejs с keepAlive: true . Похоже, произошло следующее:

• клиент использует свободный сокет для выполнения запроса
• в то же время сервер закрывает сокет из-за настройки keepAliveTimeout, которая появилась в версии nodejs 8

Решение
Пока мы нашли два решения:
1) На стороне сервера отключите keepAliveTimeout , установив его равным 0
2) Закрытие свободных сокетов менее чем за keepAliveTimeout (по умолчанию это 5 секунд). Агент http по умолчанию не поддерживает такую ​​возможность (параметр timeout этого не делает). Итак, мы использовали 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);
});

Попробуй это.

Мы столкнулись с похожей проблемой — в настоящее время мы используем 6.11.x, но мы пробовали узел 10, но это не помогает.

Мы даже пытались обновить модуль запроса + добавить все предоставленные предложения, но безрезультатно.

Любые другие идеи или помощь в устранении неполадок.

мы можем решить эту проблему - у нашего шлюза API была настройка тайм-аута, которая вызывала эту проблему. спасибо, что заглянули.

мы можем решить эту проблему - у нашего шлюза API была настройка тайм-аута, которая вызывала эту проблему. спасибо, что заглянули.

Привет, не могли бы вы сказать мне, какая настройка тайм-аута приводит к этой проблеме?

у меня та же проблема, когда я тестирую свои маршруты с помощью chai-http. абсурд в том, что первые три проходят нормально!! я пытаюсь смотреть в лицо этому весь день

вот мой код:
```
лог("рабочий тест")
it("проверить маршруты /login", done => {
чай
.запрос(сервер)
.post("/логин")
.Отправить({ })
.end (функция (ошибка, разрешение) {
ожидать(ошибаться).to.be.null;
ожидать(рез.статус).чтобы.не.равно(404);
ожидать(res.body.message).to.not.be.equal("Не найдено");
Выполнено();
});
});

log (провал теста с ошибкой: зависание сокета)
it('проверить маршрут /getResetCodePassword', (готово)=> {
чай
.запрос(сервер)
.patch("/getResetCodePassword")
.Отправить({ })
.end( (ошибка, разрешение) => {
console.log(ошибка);
Выполнено();
})
})

```