Ответ «Не удалось получить ответ» при использовании почтальона с поддоменом

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

Не удалось получить ответ

При подключении к http: //subdomain.localhost: port / api / произошла ошибка

Почему это могло произойти:

Серверу не удалось отправить ответ: убедитесь, что серверная часть работает правильно

Самозаверяющие SSL-сертификаты блокируются. Исправьте это, отключив «Проверка SSL-сертификата» в меню «Настройки»> «Основные».

Прокси-сервер настроен неправильно Убедитесь, что прокси-сервер настроен правильно в Настройки> Прокси

Время ожидания запроса: Изменить время ожидания запроса в Настройки> Общие

Если я скопирую тот же URL-адрес из почты и вставлю его в браузер, я получу правильный ответ, есть ли какие-то конфигурации, которые я должен сделать, чтобы почтальон работал с поддоменами?

Сначала зайдите в Настройки в Почтальоне :

1. Off на проверки сертификата SSL в General Tab:

   

2. Off в глобальной конфигурации прокси - сервера и прокси Использование системы в закладке Proxy:

   

3. Сделать запрос тайм - аут на ноль

Я была такая же проблема. Это было вызвано символом новой строки в конце значения заголовка «Авторизация», который я установил вручную путем вставки копии токена носителя (который случайно содержал символ новой строки в конце)

Если при отправке запроса вы получаете сообщение «Не удалось получить ответ» от собственных приложений Postman, откройте консоль Postman («Просмотр»> «Показать консоль Postman»), повторно отправьте запрос и проверьте журналы ошибок в консоли.

Благодаря numaanashraf

Привет Этот вопрос решен для меня.

настройка -> общие -> время ожидания запроса в мс = 0

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

HTTP_PROXY
HTTPS_PROXY

Ссылка ссылка

Для меня это был http: // localhost вместо https: // localhost .

При получении следующей ошибки,

вам нужно сделать следующее.

Шаг 1: В Почтальоне, нажмите значок гаечного ключа, перейдите в настройки, затем перейдите на вкладку Прокси.

Шаг 2. Создайте собственный прокси. В этой статье объясняется, как создать собственный прокси. После того, как вы создадите пользовательский прокси-сервер, убедитесь, что вы выключили переключатель прокси-сервера. Я поставил 61095 для прокси-сервера, и он работал для меня.

Шаг 3 :

успех

Я придумал это решение

1. В почтальоне зайдите в настройки -> прокси
2. И отключить глобальную настройку прокси

3. на использование системного прокси

4. И перейдите в файл конфигурации хоста Windows 'C: \ Windows \ System32 \ drivers \ etc \ hosts'

5. Откройте этот файл в режиме администратора
6. И добавьте поддомен в файл hosts

Для меня то, что работало, было добавить 127.0.0.1 subdomain.localhostв мой файл хоста. На OSX это был / etc / hosts. Не уверен, почему это было необходимо, так как я мог получить доступ к поддомену из Chrome.

1. В почтальоне зайдите в настройки -> прокси
2. И отключить глобальную настройку прокси

Для меня это был тот маршрут, по которому я звонил на моем сервере узлов, ничего не возвращая. Добавление

    return res.status(200).json({
        message: 'success!',
        response: 'success!'
    });//

к маршруту, которому я звонил, решил проблему.

Вы упомянули, что используете сертификат CER.

Согласно странице почтальона на сертификатах.

Выберите файл сертификата клиента в поле CRT-файла. В настоящее время мы поддерживаем только формат CRT. Поддержка других форматов (например, PFX) появится в ближайшее время.

Имя расширения CER, CRT не делает сертификат таким типом сертификата, но это имена исключенных расширений.

CER - это сертификат X.509 в двоичной форме, кодированный DER.

CRT - это двоичный сертификат X.509, инкапсулированный в текстовую (base-64) кодировку.

Вы можете использовать OpenSSL для преобразования файла CER в файл CRT. Мне не повезло с этим, но это выглядит так.

openssl x509 -информ PEM -в сертификате.сер -ут сертификат.crt

или

openssl x509 -информировать DER -в сертификате.сер -ут сертификат.crt

Ни одно из этих решений не работает для меня. Почтальон не отправляет никаких запросов на сервер, потому что почтальон не находит хост. Итак, если вы измените ваш / etc / hosts на 127.0.0.1 localhost 127.0.0.1 subdomain.localhost

Меня устраивает.

Для меня проблема была в том, что он Content-Lengthбыл слишком большим. Я поместил содержимое тела в NotePad ++, подсчитал символы и вставил эту цифру, PostManи тогда она заработала.

Я знаю, что это не дает прямого ответа, почему не работает поддомен ОП, но это может кому-то помочь.

В моем случае это были невидимые пробелы, которые почтальон не мог распознать, приведенная выше строка текста выглядит как без пробелов в почтальоне. Я отключил проверку SSL-сертификата, а системный прокси-сервер даже пытался использовать расширение для почтовой системы Chrome (что должно быть объявлено устаревшим), но когда я скачал и попробовал Insomnia, и он дал эти красные точки в том месте, где находились эти пробелы, он, должно быть, попал туда во время копирования /вставить

Для тех, кто сталкивался с этой проблемой в реальном домене вместо localhost и не мог решить ее, используя ЛЮБОЕ ИЗ ВЫШЕГО решения.

Попробуйте изменить сетевой DNS (WIFI или LAN) на другой DNS. Я использовал Google DNS 8.8.8.8, 8.8.4.4, и это сработало!

Решение очень простое, если вы используете приложение asp.net core 2. Внутри метода ConfigureServices внутри файла startup.cs вся эта строка

services.AddMvc()
                .SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
                .AddJsonOptions(x => x.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore);

Вам просто нужно отключить SSL, чтобы отправить запрос.

Прокси и другие приходят с различными ошибками.

После всех вышеперечисленных методов, таких как отключение проверки сертификата SSL, включение только Использовать системный прокси и удаление системных переменных среды HTTP_PROXY и HTTPS_PROXY, все заработало.

Примечание: пришлось перезапустить приложение Postman, так как переменные среды были изменены.

Снятие галочки с прокси-сервера и SSL-сертификата у меня не сработало.

Сброс переменных окружения PROXY сделал свое дело.

export http_proxy=
export ftp_proxy=
export https_proxy=

Перейдите в каталог, где установлен Postman, а затем:

./Postman

Почтальон для Linux версии 6.7.1 - Ubuntu 18.04 - linux 4.15.0-43-generic / x64

У меня была такая же проблема , и я случайно заменил http://localhostс http://127.0.0.1и все работало.

мой etc/hosts были правильные записи для localhostиhttps://localhost запросы всегда работали, как ожидалось.

Я понятия не имею , почему изменяющийся localhostдля httpс 127.0.0.1решить эту проблему.

В моем случае MVC не смог сериализовать результаты (я случайно использовал модель вместо DTO). Я отладил до передачи простой строки, которая работала. Как только я исправил сериализацию, все вышло.

В моем случае (корпоративный) прокси-сервер использовал самозаверяющий SSL-сертификат, который Postman не любил. Я обнаружил это, активировав View-> Show console Postman и повторив запрос. Затем консоль показала ошибку сертификата. В Настройки-> Общие я отключил проверку SSL-сертификата.

Решение для меня, поскольку я использую устаревшее Postmanрасширение для Chromeрешения этой проблемы, мне пришлось:

1. Вызовите какой-либо GETзапрос с помощью самого Chromeбраузера.
2. Дождитесь появления страницы с сообщением об ошибке «Ваше соединение не является частным» .
3. Нажмите ADVANCEDи затем proceed to [url] (unsafe)ссылку.

После этого запросы через само расширение должны работать.

В моем случае это была неправильно настроенная подсеть. Работает только одна из 2 подсетей в ELB.

Я понял это, выполнив nslookup и попытавшись свернуть возвращенные IP-адреса напрямую. Работал только один. Почтальон просто продолжал использовать неправильно настроенный.

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

Оказалось, что мое время ожидания было установлено слишком низким. Я изменил его на 30 мс, думая, что это 30 сек. Я установил его обратно на 0, и он снова начал работать.

Я получил ту же проблему «Не удалось получить ответ» из-за неправильного параметра в заголовке. Я исправил это, удалив параметр HOST из заголовка.

PS: К сожалению, я был вынужден установить другое программное обеспечение, чтобы получить эту информацию. Было бы здорово получить это сообщение об ошибке от Почтальона, вместо того, чтобы получать общую чушь.

В моем случае я забыл установить значение переменной в поле «CURRENT VALUE».

В моем случае проблема заключалась в том, что для среды UAT URL API будет начинаться с Http вместо https . Кроме того, бэкэнд назначает разные порты для Http и https.

например,

http://10.12.12.31:2001/api/example . - правильно для меня

https://10.12.12.31:2002/api/example . - это неправильно для меня

Потому что я использовал https и порт 2002 для попадания в среду UAT. Так что я получаю не могу получить ни одной ошибки ответа в почтальоне.

Я только что испытал эту ошибку. В моем случае путь был СЛИШКОМ ДЛИННЫМ. Так URL-адрес, который дал мне эту ошибку в почтальоне (поддельный пример)

http://127.0.0.1:5000/api/batch/upload_import_deactivate_from_ready_folder

в то время как

http://127.0.0.1:5000/api/batch/upld_impt_deac_ready_folder

работал нормально.

Надеюсь, это поможет кому-то, кто случайно прочитал это далеко ...