Resposta "Não foi possível obter resposta" ao usar o carteiro com subdomínio

Estou usando o carteiro para testar uma API que tenho, tudo é bom quando a solicitação não contém subdomínio, no entanto, quando adiciono um subdomínio ao URL, estou recebendo essa resposta.

Não foi possível obter resposta

Ocorreu um erro ao conectar-se a http: //subdomain.localhost: port / api /

Por que isso pode ter acontecido:

O servidor não pôde enviar uma resposta: Verifique se o back-end está funcionando corretamente

Os certificados SSL autoassinados estão sendo bloqueados: corrija isso desativando a 'Verificação de certificado SSL' em Configurações> Geral

Proxy configurado incorretamente Verifique se o proxy está configurado corretamente em Configurações> Proxy

Tempo limite da solicitação: altere o tempo limite da solicitação em Configurações> Geral

Se eu copiar o mesmo URL do postman e colá-lo no navegador, recebo uma resposta adequada, há algum tipo de configuração que devo fazer para fazer o postman funcionar com subdomínios?

Primeiro, vá para Configurações no Postman :

1. Desative a verificação do certificado SSL na guia Geral :

   

2. Desativar a configuração global de proxy e usar o proxy do sistema na guia proxy:

   

3. Fazer com que o tempo limite da solicitação seja zero

Eu tive o mesmo problema. Isso foi causado por uma nova linha no final do valor do cabeçalho "Authorization", que eu havia definido manualmente ao colar e copiar o token do portador (que acidentalmente continha a nova linha no final)

Se você receber uma mensagem "Não foi possível obter resposta" dos aplicativos nativos do Postman ao enviar sua solicitação, abra o Postman Console (Exibir> Mostrar o Postman Console), reenvie a solicitação e verifique se há logs de erro no console.

Graças a numaanashraf

Olá. Este problema foi resolvido para mim.

configuração -> geral -> tempo limite da solicitação em ms = 0

Se todos os métodos acima não funcionarem, verifique as variáveis ​​de ambiente e verifique se os seguintes ambientes não estão definidos. Se esses estiverem definidos e não forem necessários por qualquer outro aplicativo, remova-os.

HTTP_PROXY
HTTPS_PROXY

Link de referência

Para mim, era o http: // localhost em vez de https: // localhost .

Ao obter o seguinte erro,

você precisa fazer o seguinte.

Etapa 1: No Postman, clique no ícone de chave inglesa, vá para configurações e, em seguida, vá para a guia Proxy.

Etapa 2: Crie um proxy personalizado. Este artigo explica como criar um proxy personalizado. Depois de criar o Proxy personalizado, desative o botão de alternância do Proxy. Coloquei 61095 no servidor proxy e funcionou para mim.

Etapa 3 :

Sucesso

Eu vim com esta solução

1. No carteiro, vá para configuração -> proxy
2. E fora da configuração global de proxy

3. no Usar proxy do sistema

4. E vá para o arquivo de configuração do host do Windows 'C: \ Windows \ System32 \ drivers \ etc \ hosts'

5. Abra esse arquivo no modo administrador
6. E adicione o subdomínio ao arquivo hosts

Para mim, o que funcionou foi adicionar 127.0.0.1 subdomain.localhostao meu arquivo host. No OSX, isso era / etc / hosts. Não sei por que isso era necessário, pois eu poderia alcançar o subdomínio no chrome.

1. No carteiro, vá para configuração -> proxy
2. E fora da configuração global de proxy

Para mim, era a rota que eu estava chamando no meu servidor de nó não estava retornando nada. Adicionando

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

para a rota que eu estava chamando resolveu o problema.

Você mencionou que está usando um certificado CER.

De acordo com a página Postman sobre certificados.

Escolha seu arquivo de certificado do cliente no campo arquivo CRT. Atualmente, suportamos apenas o formato CRT. Suporte para outros formatos (como PFX) em breve.

O nome da extensão CER, CRT não torna o certificado esse tipo de certificado, mas esses são os nomes de extensões exceto.

CER é um certificado X.509 em formato binário, codificado pelo DER.

CRT é um certificado X.509 binário, encapsulado em codificação de texto (base-64).

Você pode usar o OpenSSL para alterar um arquivo CER para um arquivo CRT. Não tive boa sorte com isso, mas é assim.

openssl x509 -forma PEM -em certificado.cer -out certificado.crt

ou

openssl x509 -informe DER -no certificado.cer -out certificado.crt

Nenhuma dessas soluções funciona para mim. O Postman não está enviando nenhuma solicitação ao servidor porque o Postman não está localizando o host. Portanto, se você modificar seus / etc / hosts para 127.0.0.1 localhost 127.0.0.1 subdomain.localhost

Funciona para mim.

Para mim, a questão era que Content-Lengthera grande demais. Coloquei o conteúdo do corpo no NotePad ++ e contei os caracteres, coloquei a figura PostMane funcionou.

Sei que não responde diretamente por que o subdomínio da operação não estava funcionando, mas pode ajudar alguém.

No meu caso, eram espaços invisíveis que o carteiro não reconheceu, a sequência de texto acima é renderizada como sem espaços no carteiro. Desabilitei a validação do certificado SSL e o Proxy do sistema até tentei na extensão do postman chrome (que está prestes a ser preterida), mas quando baixei e experimentei o Insomnia e ele deu esses pontos vermelhos no local onde estavam esses espaços, deve ter chegado lá durante a cópia /colar

Para quem experimentou esse problema com domínio real, em vez de localhost, e não conseguiu resolvê-lo usando QUALQUER DOS ACIMA .

Tente alterar o DNS da rede (Wi-Fi ou LAN) para outro DNS. Para mim, usei o DNS do Google 8.8.8.8, 8.8.4.4 e funcionou!

solução é muito simples se você estiver usando o aplicativo asp.net core 2. O método Inside ConfigureServices dentro do arquivo startup.cs arquiva toda essa linha

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

Você só precisa ativar o SSL desativar o para enviar sua solicitação.

O proxy e outros vêm com vários erros.

Depois de todos os métodos acima, como desativar a verificação do certificado SSL, ativar apenas Usar o Proxy do Sistema e remover as variáveis ​​de ambiente do sistema HTTP_PROXY e HTTPS_PROXY, funcionou.

Nota: Foi necessário reiniciar o aplicativo Postman, pois as variáveis ​​de ambiente foram alteradas.

Desmarcar a verificação de proxy e certificado SSL não funcionou para mim.

A desativação das variáveis ​​de ambiente PROXY funcionou.

export http_proxy=
export ftp_proxy=
export https_proxy=

Mude para o diretório em que o Postman está instalado e, em seguida:

./Postman

Postman para Linux versão 6.7.1 - Ubuntu 18.04 - linux 4.15.0-43-generic / x64

Eu tive o mesmo problema e, por acaso, substituí http://localhostpor http://127.0.0.1e tudo funcionou.

Meu etc/hoststinha as entradas adequadas para localhostehttps://localhost solicitações sempre funcionou conforme o esperado.

Eu não tenho idéia por que mudar localhostpara httpcom 127.0.0.1resolveu o problema.

No meu caso, o MVC não conseguiu serializar os resultados (usei acidentalmente um modelo em vez do DTO). Eu depurei até passar uma string simples, que funcionou. Depois de consertar a serialização, tudo surgiu.

No meu caso, o proxy (corporativo) estava usando um certificado SSL autoassinado que Postman não gostava. Eu o descobri ativando o console View-> Show Postman e repetindo a solicitação. O console então mostrou o erro de certificado. Em Configurações-> Geral, desabilitei a verificação do certificado SSL.

A solução para mim, como estou usando a Postmanextensão obsoleta para Chrome, para resolver esse problema, tive que:

1. Ligue para alguma GETsolicitação usando oChrome próprio navegador.
2. Aguarde a página de erro "Sua conexão não é privada" para aparecer.
3. Clique em ADVANCEDe, em seguida, proceed to [url] (unsafe)vincule.

Depois disso, as solicitações através da própria extensão devem funcionar.

No meu caso, era uma sub-rede mal configurada. Apenas uma das 2 sub-redes do ELB funcionou.

Eu descobri isso fazendo uma pesquisa e tentando ondular os IPs retornados diretamente. Apenas um funcionou. O carteiro continuou usando o mal configurado.

Eu tive o mesmo problema.

Acabou que meu tempo limite estava muito baixo. Eu mudei para 30ms pensando que eram 30seg. Voltei a 0 e ele começou a funcionar novamente.

Eu recebi o mesmo problema "Não foi possível obter nenhuma resposta" devido a um parâmetro errado no cabeçalho. Corrigi-o removendo o parâmetro HOST do cabeçalho.

PS: Infelizmente, fui pressionado a instalar o outro software para obter essas informações. Deve ser ótimo receber essa mensagem de erro do Postman, em vez de obter bobagens gerais.

No meu caso, esqueci de definir o valor da variável no campo "CURRENT VALUE".

No meu caso, o problema era que, para o ambiente UAT , o URL da API começará com Http em vez de https . Além disso, o back-end atribui portas diferentes para Http e https.

por exemplo,

http://10.12.12.31:2001/api/example . - está correto para mim

https://10.12.12.31:2002/api/example . - está errado para mim

Porque eu estava usando a porta https e 2002 para acessar o ambiente UAT. Então, estou recebendo não foi possível obter nenhum erro de resposta no carteiro.

Acabei de experimentar este erro. No meu caso, o caminho foi muito longo. Url assim me deu esse erro no carteiro (exemplo falso)

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

enquanto que

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

funcionou bem.

Espero que ajude alguém que por acidente leia tão longe ...