ПОСТМАН: Розетка повесить

Question

Я только начал использовать POSTMAN. У меня была эта ошибка "Ошибка: сокет повесить трубку", когда я выполнял запуск сборщика. Я прочитал несколько постов, касающихся зависания сокета и упоминания об отправке запроса, а ответа со стороны сервера нет и, возможно, истекло время ожидания. Как продлить время запроса в POSTMAN Runner? спасибо ребята и это мой первый пост в переполнении стека:)

Answer 1

Для меня это произошло потому, что мое приложение было переключено на https, а в моих запросах почтальона все еще был http. Смена почтальона на https исправила.

Answer 2

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

Например:- порт 6455 является выделенным портом для какой-либо другой услуги или соединения. Нельзя использовать один и тот же порт (6455) для подключения к базе данных на одном сервере.

Answer 3

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

Если вы являетесь тем, кто написал сервер, это относительно легко реализовать. Если нет, проверьте документацию по серверу, который вы используете.

Answer 4

Почтальон выдавал "Не удалось получить ответ" "Ошибка: розетка зависла". Я решил эту проблему, добавив в свой запрос http-заголовок Content-Length.

Answer 5

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

Answer 6

Я определил метод Authenticate для создания токена и упомянул его возвращаемый тип как строку, допускающую значение NULL, как:

      public string? Authenticate(string username, string password) 
{
  if(!users.Any(u => u.Key==username && u.Value == password))
    {
      return null;
    }
  var tokenHandler = new JwtSecurityTokenHandler();


  var tokenKey = Encoding.ASCII.GetBytes(key);
  var tokenDescriptor = new SecurityTokenDescriptor()
  {
    Subject = new ClaimsIdentity(new Claim[]
    {
       new Claim(ClaimTypes.Name, username)
    }),
    Expires = DateTime.UtcNow.AddHours(1),
    SigningCredentials = new SigningCredentials(new 
    SymmetricSecurityKey(tokenKey), 
    SecurityAlgorithms.HmacSha256Signature)
  };
   var token = tokenHandler.CreateToken(tokenDescriptor);
   return tokenHandler.WriteToken(token);
}

Изменение строки, допускающей значение NULL, на простую строку исправило для меня проблему «зависания сокета»!

Answer 7

Вы используете nodemon или какой-нибудь другой файловый наблюдатель? В моем случае я создавал некоторые локальные файлы, загружал их, а затем отправлял URL-адрес моему пользователю. К сожалению, nodemon увидит "изменения" в проекте и запустит перезапуск до того, как будет отправлен ответ. Я проигнорировал каталоги сборки из моего файлового наблюдателя и решил эту проблему.

Вот ридми Nodemon об игнорировании файлов: https://github.com/remy/nodemon

Answer 8

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

Answer 9

Для меня проблема была связана с несоответствием версий http на клиенте и сервере.

Клиент предполагал http v2, в то время как сервер (весенняя загрузка/tomcat) в случае был http v1

Когда на сервере я настроил сервер на v2, проблема была решена сразу.

При весенней загрузке вы можете настроить http v2, как показано ниже:

      server.http2.enabled=true

Примечание. Также сценарий был связан с использованием механизма аутентификации клиента (например, MTLS).

Без клиентской аутентификации / MTLS он работал без проблем, но для клиентской аутентификации настройка версии в весенней загрузке была важной точкой спасения.

Answer 10

Что мне помогло, так это замена "localhost" в URL- адресе на http://127.0.0.1/ или любой другой адрес, который ваш локальный компьютер назначил localhost.

Answer 11

Решил эту проблему отключением моего vpn. вы должны проверить, подключен ли vpn.

Answer 12

Это произошло, когда клиент долго ждал ответа, пытаясь синхронизировать ваши запросы API от почтальона

затем сделайте вход в систему, и все готово

Answer 13

Большая ошибка, она настолько общая, что каждому помогает что-то свое.

В моем случае я не смог это исправить, и что действительно забавно, так это то, что я ожидаю получить составной файл на одной конечной точке. Когда я готовлю запрос в почтальоне, я получаю «Ошибка: зависание сокета». Если я перейду на другую конечную точку (даже не существующую), будет точно такая же ошибка. Но когда я вызываю любую конечную точку без тела, этот запрос работает, и после этого все последующие попытки работают отлично.

В моем случае это чисто почтальонская проблема. Любой запрос с использованием curl никогда не дает этой ошибки.

Answer 14

Если Почтальон не получит ответа в течение указанного времени, он выдаст ошибку "Зависание сокета".

Я делал что-то вроде ниже, чтобы добиться 60-минутной задержки между каждым сценарием в коллекции:

get https://postman-echo.com/delay/10
pre request script :-
setTimeout(function(){}, [50000]);

Я уменьшил время до 30 секунд:

setTimeout(function(){}, [20000]);

После этого я перестал получать эту ошибку.

Answer 15

"Зависание сокета" - проблема, связанная с прокси. когда мы запускаем ту же коллекцию с помощью newman на jenkins, тогда все тесты проходят. изменить настройки прокси https://docs.cloudfoundry.org/cf-cli/http-proxy.html

Answer 16

У меня была такая же проблема: «Ошибка: зависание сокета» при отправке запроса на сохранение файла и журналов серверной части упоминали тайм-аут, как вы описали. В моем случае я использовал mongoDB, и настоящая проблема заключалась в том, что емкость массива моей коллекции была заполнена. Когда я очистил документы в этой коллекции, ошибка была отклонена. Надеюсь, это поможет тому, кто столкнется с подобным сценарием.

Answer 17

В моем случае я должен был предоставить--ssl-client-keyи--ssl-client-certфайлы для преодоления этих ошибок.

Answer 18

Следуя ответу Абхая : дважды проверьте схему. Защищенный сервер может отключиться, если вы позвоните в https конечная точка с http.

Это случилось со мной при отладке API-интерфейса ASP.NET Core, работающего на локальном хосте, с использованием локального сертификата. Мне потребовалось время, чтобы понять, так как это было в среде почтальона, а также был понедельник.

Answer 19

В моем случае я неправильно использовал порт, зарезервированный для https-версии моего API.

Например, я должен был использовать https://localhost:6211, но я использовал http://localhost:6211.

Answer 20

В моем случае добавление в заголовок параметра Content-length помогло.

Моя среда

Mac : [Команда терминала: sw_vers] ProductName: macOSProductVersion: 12.0.1. (Монтерей) Версия сборки: 21A559

mysql :
[Команда терминала: mysql --version] Версия 8.0.27 для macos11.6 на x86_64 (доморощенный)

Apache : [Команда терминала: httpd -v] Версия сервера: Apache/2.4.48 (Unix) Сервер построен: 1 октября 2021 г., 20:08:18.

*Laravel[Команда терминала: php artisan --version] Платформа Laravel 8.76.2

Почтальон Версия 9.1.5 (9.1.5)

Answer 21

в моем случае это была проблема с клиентом веб-почтальона,

когда я запрашиваю GET с тем же условием в приложении Postman (а не в Интернете), это разрешается

Answer 22

"Socket Hung Up" может быть локальной проблемой какое-то время, потому что из-за узкого места в папке%temp% попробуйте освободить папку "temp" и попробуйте

Answer 23

если это кому-нибудь поможет... В моем случае я просто забыл использовать синтаксический анализатор json (const jsonParser = express.json();), чтобы иметь доступ к объектам типа json, отправляемым на сервер с клиента. Будьте осторожны, не теряйте время =)

Answer 24

В моем случае это было связано с именем хоста, у моего URL-адреса API был старый хост.https://test-xyz.com/employee/1поэтому я изменил его наhttps://test.xyz.net/employee/1.

Таким образом, эта ошибка в основном возникает из-за неправильного URL-адреса. Проверьте свой URL-адрес один раз и укажите правильный, прежде чем продолжить.

Answer 25

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

      Key:Content-Length
Value:<calculated when request is sent>

Answer 26

Ошибка зависания сокета также может возникать из-за логики обработки внутреннего API.

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

Если вы выполнили все шаги, упомянутые в других комментариях, и все еще сталкиваетесь с проблемой. Я предлагаю вам тщательно проверить код обработчика API.

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

Answer 27

Для меня это давалоSocket Hung Upошибка только во время работыCollection Runnerне с одного запроса. Добавление небольшой задержки (100-300 мс) в коллекцию Runner решило проблему для меня.

Answer 28

Это случилось со мной, когда я изучал веб-API ASP.NET.

В моем случае это произошло из-за проверки SSL-сертификата .

Я использовал VS Code, поэтому я слежу за проверкой SSL-сертификата, и он поставляется с протоколом https .

Я решил это, проверив свои конечные точки с протоколом http .

Другим подходом может быть просто отключение проверки SSL-сертификата в настройках почтальона.

Answer 29

Я исправил эту проблему, отключив заголовок токена Postman. Скриншот

Answer 30

Скорее всего, одновременно происходят две вещи.
Во-первых, URL-адрес содержит порт, который обычно не используется, И, во-вторых, вы используете VPN или прокси, которые не поддерживают этот порт.
Лично у меня была такая же проблема. Порт моего сервера был 45860, и я использовал VPN с антифильтром pSiphon.
В этом состоянии мой почтальон сообщал о "зависании соединения" только тогда, когда сервер relpy был ошибкой с кодами состояния больше 0. (это было нормально, когда какой-то текст возвращался с сервера без кода ошибки).
Затем я изменил порт своего веб-сервиса на 8080 на моем сервере и, ВАУ, все заработало! хотя был подключен псифон впн.