Відповідь "Не вдалося отримати відповіді" під час використання листоноші з субдоменом

Я використовую листоношу для тестування API, який у мене є, все добре, коли запит не містить піддомен, проте коли я додаю субдомен до URL, я отримую цю відповідь.

Не вдалося отримати відповіді

Під час підключення до http: //subdomain.localhost: port / api / сталася помилка

Чому це могло статися:

Сервер не зміг надіслати відповідь: Переконайтесь, що бекенд працює належним чином

Самопідписані сертифікати SSL блокуються: виправте це, вимкнувши "Перевірка сертифіката SSL" у Налаштуваннях> Загальне

Неправильно налаштований проксі Переконайтеся, що проксі правильно налаштовано в Налаштуваннях> Проксі

Запити час очікування: змінити час очікування запиту в Налаштуваннях> Загальне

Якщо я скопіюю ту саму URL-адресу з листоноші та вставте її у браузер, я отримаю належну відповідь, чи є якісь конфігурації, які я повинен зробити, щоб листоноша працювала з піддоменами?

Спочатку перейдіть до " Налаштування" у листоноші :

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

   

2. Off в глобальної конфігурації проксі - сервера і проксі Використання системи в закладці Proxy:

   

3. Зробити час запиту на нуль

У мене було те саме питання. Це було викликано новим рядком наприкінці значення заголовка "Авторизація", яке я встановив вручну, вставивши копію маркера носія (який випадково містив новий рядок в його кінці)

Якщо під час надсилання запиту ви отримаєте повідомлення "Не вдалося отримати відповідь" від натільних програм Postman, відкрийте консоль Postman (Перегляд> Показати консоль листоноші), надішліть повторно запит і перевірте, чи немає в консолі журналів помилок.

Завдяки numaanashraf

Привіт Ця проблема вирішена для мене.

налаштування -> загальне -> Запит часузавершення в мс = 0

Якщо всі вищезазначені методи не працюють, перевірте змінні середовища, і переконайтеся, що наступні середовища не встановлені. Якщо вони встановлені і не потрібні жодному іншому додатку, видаліть їх.

HTTP_PROXY
HTTPS_PROXY

Посилання на посилання

Для мене це був http: // localhost замість https: // localhost .

Отримавши таку помилку,

вам потрібно зробити наступне.

Крок 1. У листоноші натисніть значок гайкового ключа, перейдіть до налаштувань, а потім перейдіть на вкладку проксі.

Крок 2. Створіть спеціальний проксі. У цій статті пояснюється, як створити користувацький проксі. Після створення користувацького проксі переконайтесь, що вимкнено кнопку перемикання проксі. Я поклав 61095 на проксі-сервер, і він працював на мене.

Крок 3:

Успіх

Я придумав таке рішення

1. У листоноші перейдіть до налаштування -> проксі
2. І вимкнути глобальну конфігурацію проксі

3. на системному проксі

4. І перейдіть до файлу налаштування хоста Windows "C: \ Windows \ System32 \ driver \ etc \ hosts"

5. Відкрийте цей файл у режимі адміністратора
6. І додайте піддомен у файл хостів

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

1. У листоноші перейдіть до налаштування -> проксі
2. І вимкнути глобальну конфігурацію проксі

Для мене саме той маршрут, який я дзвонив на своєму сервері вузлів, нічого не повертав. Додавання

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

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

Ви згадали, що використовуєте сертифікат CER.

Відповідно до сторінки листоноші на сертифікати.

Виберіть файл сертифіката клієнта у полі файлу CRT. В даний час ми підтримуємо лише формат CRT. Підтримка інших форматів (наприклад, PFX) незабаром.

Ім'я розширення CER, CRT не робить сертифікат такого типу сертифіката, але це виключені імена розширень.

CER - сертифікат X.509 у двійковій формі, кодується DER.

CRT - це бінарний сертифікат X.509, інкапсульований у текстовому (базовому-64) кодуванні.

Ви можете використовувати OpenSSL для зміни файла CER у файл CRT. Мені не пощастило з цим, але це виглядає приблизно так.

openssl x509 -інформація PEM -в сертифікаті.cer -out сертифікат.crt

або

openssl x509 -інформація DER -в сертифікаті.cer -out сертифікат.crt

Жодне з цих рішень для мене не працює. Листоноша не надсилає жодного запиту на сервер, оскільки листоноша не знаходить хоста. Отже, якщо ви модифікуєте ваш / etc / hosts 127.0.0.1 localhost 127.0.0.1 subdomain.localhost

Це працює для мене.

Для мене питання полягало в тому, що Content-Lengthбуло занадто великим. Я розмістив вміст тіла в NotePad ++ і порахував символи, поставив цю фігуру, PostManа потім вона спрацювала.

Я знаю, що це не відповідає безпосередньо тому, чому піддомен оп не працює, але це може комусь допомогти.

У моєму випадку це був невидимий пробіл, який листоноша не розпізнавав, наведений вище рядок тексту виглядає як без пробілів у листоноші. Я вимкнув SSL сертифікат Validation і System Proxy навіть приміряв розширення хроману листоноші (що вже буде застарілим), але коли я завантажив і спробував Insomnia, він дав ці червоні точки в тому місці, де були ці простори, мусив потрапити туди під час копіювання / пасти

Для тих, хто відчув цю проблему з реальним доменом замість localhost і не зміг її вирішити, використовуючи БУДЬ-ЯК ЗОВІДЬ .

Спробуйте змінити мережевий DNS (WIFI або LAN) на інший DNS. Для мене я використовував Google DNS 8.8.8.8, 8.8.4.4 і він працював!

рішення дуже просте, якщо ви використовуєте додаток asp.net core 2. Метод Inside 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, який листоноша не любив. Я виявив це, активувавши View-> Show the Postman console та повторно повторивши запит. Потім консоль показала помилку сертифіката. У Налаштуваннях-> Загальне I вимкнено підтвердження SSL сертифікатів.

Для вирішення цієї проблеми для мене, як я використовую застаріле Postmanрозширення Chrome, мені довелося:

1. Зателефонуйте до GETзапиту за допомогоюChrome браузера.
2. Зачекайте на сторінці помилки "Ваше з'єднання не є приватним" .
3. Клацніть на, ADVANCEDа потім proceed to [url] (unsafe)посилання.

Після цього запити через само розширення повинні спрацювати.

У моєму випадку це була неправильно налаштована підмережа. Працювала лише одна з двох підмереж в ELB.

Я зрозумів це, зробивши nslookup і намагаючись згортати повернуті IP-адреси безпосередньо. Працював лише один. Листоноша просто продовжував користуватися неправильно налаштованим.

У мене було те саме питання.

Виявилося, мій час очікування був встановлений занадто низько. Я змінив його на 30 мс, думаючи, що це 30 секунд. Я повернув його до 0, і він знову почав працювати.

Я отримав те саме питання "Не вдалося отримати відповідь" через неправильний параметр у заголовку. Я виправив це, видаливши параметр HOST із заголовка.

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

У моєму випадку я забув встановити значення змінної у полі "ТОЧНА ЗНАЧЕННЯ".

У моєму випадку проблема полягала в тому, що для середовища 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

добре працював.

Сподіваюся, це допомагає тому, хто випадково прочитав так далеко ...