Geonode logo
Geonode Team

Geonode Team

Atualizado: 7 de outubro de 2026

Publicado: 2 de setembro de 2026

Como configurar um proxy no Postman

O Postman tem duas funcionalidades chamadas «proxy» e que têm funções opostas. Uma envia os teus pedidos através do proxy de outra pessoa; a outra transforma o Postman num proxy através do qual outras aplicações enviam pedidos. Ao pesquisar por «Postman proxy», aparecem resultados de documentação para ambas as funcionalidades, o que torna tudo mais confuso do que deveria ser. Este guia aborda cada uma delas separadamente, além do passo relativo ao certificado necessário para a captura HTTPS e das definições que impedem o envio das solicitações quando estão incorretas.

O nosso ponto de vista: somos a Geonode e comercializamos proxies, pelo que a primeira metade deste artigo trata da utilização do nosso tipo de produto com o Postman. A verdade é que o Postman é uma ferramenta pouco adequada para trabalhos que envolvem muitos proxies — aplica as definições de proxy globalmente, em vez de o fazer por pedido, pelo que não é possível enviar facilmente um pedido através de um proxy e outro diretamente. É excelente para testar se um proxy funciona e para explorar uma API através dele; é a ferramenta errada para uma carga de trabalho que necessite de um encaminhamento diferente por cada chamada. Utilize-o para verificar a sua configuração e, em seguida, transfira o trabalho propriamente dito para um cliente que lhe permita controlar cada pedido individualmente.

Que funcionalidade pretende?

Decida isso primeiro e o resto é simples.

Quer que o Postman envie os seus pedidos através de um proxy. Razões: um proxy corporativo é a única via de saída da sua rede, ou está a testar uma API através de um proxy para verificar a geolocalização ou o acesso. Esta é a configuração do proxy global, abordada a seguir.

Quer capturar pedidos de outra aplicação. Motivos: ver o que uma aplicação móvel ou um navegador envia realmente, ou depurar uma integração de terceiros. Trata-se do proxy integrado do Postman, abordado mais adiante. O Postman torna-se o intermediário e outro software aponta para ele.

São configurados em locais diferentes e resolvem problemas não relacionados.

Configurar um proxy global

A documentação do Postman descreve três abordagens.

O proxy predefinido utiliza automaticamente o proxy configurado no seu sistema. Se o seu sistema operativo já tiver um definido, o Postman deteta-o e não precisa de fazer nada.

O proxy do sistema ativa explicitamente o proxy do sistema para os pedidos; esta é a opção a verificar quando tiver um proxy do sistema configurado e o Postman parecer estar a ignorá-lo.

O proxy personalizado permite-lhe especificar um servidor diferente. É esta a opção a utilizar para um serviço de proxy comercial e é definida em «Definições», no separador «Proxy».

Os protocolos suportados são mais abrangentes do que se poderia esperar. A documentação enumera «os protocolos HTTP, SOCKS5, SOCKS5H, SOCKS4 e SOCKS4A», com uma limitação claramente indicada: «O Postman apenas suporta o envio de pedidos HTTP e HTTPS através de um proxy SOCKS.»

Vale a pena reparar na entrada SOCKS5H. A variante «h» envia o nome do anfitrião ao proxy para resolução, em vez de o resolver localmente, o que impede que as consultas DNS vazem para o seu próprio resolvedor enquanto o tráfego sai por outro lado. Se estiver a utilizar o SOCKS especificamente para alterar a sua localização aparente, opte pelo SOCKS5H em vez do «SOCKS5».

A autenticação é uma opção separada. Para um proxy que exija credenciais, a documentação indica que se «adicionem as credenciais à aplicação de ambiente de trabalho do Postman», introduzindo um nome de utilizador e uma palavra-passe no separador «Definições de proxy». Note-se que se trata da aplicação de ambiente de trabalho — a versão do navegador não consegue aceder a um proxy na sua rede local.

A lista de exclusão permite-lhe excluir hosts: «introduza uma lista de hosts separados por vírgulas. Os pedidos enviados para estes hosts não utilizarão o proxy personalizado.» Coloque aqui localhost, 127.0.0.1 e quaisquer nomes de host internos; caso contrário, os pedidos para o seu próprio servidor de desenvolvimento serão encaminhados através do proxy e falharão, o que pode causar confusão.

Verificar se funciona mesmo

O passo que as pessoas costumam ignorar e que poupa uma hora.

Envie um pedido a um serviço que indique o endereço que vê:

GET https://api.ipify.org?format=json

Execute-o com o proxy desativado, anote o endereço, depois ative o proxy e execute-o novamente. Se o endereço não mudar, o proxy não está a ser utilizado. Não haverá nenhuma mensagem de erro a indicar isso — a solicitação simplesmente segue diretamente e é bem-sucedida.

Três razões comuns pelas quais isto não surte efeito:

A lista de exclusões corresponde ao seu destino. Verifique se existe alguma entrada que, inadvertidamente, o abranja.

Está a utilizar a versão para navegador do Postman, que não consegue aceder a um proxy no seu computador. É necessária a aplicação para computador.

A configuração está no separador errado. «Padrão», «sistema» e «personalizado» são opções distintas, e configurar um proxy personalizado enquanto a opção de proxy do sistema está selecionada não tem qualquer efeito.

No caso de proxies com segmentação geográfica, verificar o endereço não é suficiente. Verifique pelo resultado — solicite algo que diferencie genuinamente por região e confirme se a resposta muda. Um serviço de pesquisa que indique o país correto, enquanto a sua API devolve dados da sua região de origem, significa que a segmentação não está a atingir o destino pretendido.

As definições que impedem o envio de pedidos

Duas definições do Postman interagem com a utilização do proxy e provocam erros confusos.

Verificação do certificado SSL. Se o seu proxy interceptar o TLS — o que é comum nos proxies empresariais —, o Postman rejeitará o certificado porque este foi emitido pela própria autoridade do proxy, em vez de por uma autoridade de confiança. O sintoma é um erro TLS em todas as solicitações HTTPS.

A solução correta consiste em adicionar o certificado da autoridade certificadora (CA) da sua organização nas definições de certificados do Postman. A solução tentadora é desativar a verificação de SSL globalmente, mas vale a pena compreender o que isso implica: todas as solicitações no Postman passam a aceitar qualquer certificado, inclusive em APIs onde seria muito importante saber se algo está a interceptar a sua conexão. Se tiver de desativá-la, faça-o com conhecimento de causa e reative-a posteriormente.

Tempos de espera das solicitações. O tempo de espera padrão do Postman é generoso, mas um proxy — especialmente um residencial — acrescenta latência real a cada solicitação. Se as solicitações através de um proxy atingirem o tempo de espera, enquanto as mesmas solicitações funcionam diretamente, aumente o tempo de espera nas definições antes de concluir que o proxy está avariado.

Uma observação relacionada às execuções de coleções: através de um proxy com limite de tráfego, uma execução de coleção com um ficheiro de dados grande efetua uma solicitação por linha e pagas por cada uma delas. Isso é óbvio em retrospetiva, mas surpreendente quando aparece na fatura.

Proxy integrado do Postman: Captura de tráfego

A outra funcionalidade, e uma que é verdadeiramente útil.

A documentação descreve-a diretamente: «A aplicação de secretária do Postman possui um proxy integrado capaz de capturar tráfego HTTP e HTTPS.» Este proxy intercepta os pedidos das aplicações cliente, reencaminha-os, captura as respostas e também pode recolher cookies.

A porta predefinida é a 5559.

Para configurar outro dispositivo para utilizar este proxy, a documentação indica três passos: descubra o endereço IP local do seu computador, configure as definições de rede sem fios do dispositivo para utilizar um proxy HTTP com esse IP e a porta do proxy e — especificamente para o iOS — aceda a Definições, Wi-Fi, ao ícone de informação, a «Configurar Proxy», «Manual» e, em seguida, introduza o IP e a porta do servidor.

Esta é a forma mais rápida de responder à pergunta «o que é que esta aplicação móvel está realmente a enviar?», que, de outra forma, seria uma questão surpreendentemente complicada.

O HTTPS requer um certificado. A documentação é explícita ao afirmar que o proxy «requer a instalação do certificado postman-proxy-ca.crt nos dispositivos clientes para capturar tráfego HTTPS seguro» e que, no computador anfitrião, «a instalação do certificado permite que o proxy do Postman capture tráfego HTTPS seguro enviado por navegadores e outras aplicações clientes».

Compreenda o que isso significa antes de o fazer. Está a instalar uma autoridade certificadora que pode emitir certificados para qualquer domínio, e o Postman descodifica então o seu tráfego TLS para lho mostrar. Esse é todo o mecanismo — não há forma de inspecionar tráfego encriptado sem interromper a encriptação.

Duas consequências que devem ser levadas a sério. Remova o certificado quando terminar, especialmente num telemóvel que utilize para assuntos pessoais. E não capture tráfego que contenha credenciais importantes para si enquanto o certificado estiver instalado, porque essas credenciais estão a ser desencriptadas e exibidas.

Utilizar ambientes para gerir tarefas dependentes de proxy

Uma vez que o Postman não consegue alterar o proxy por pedido, a solução prática consiste em alterar tudo o resto — e a sua funcionalidade de ambientes é ideal para isso.

Coloque o URL base de destino numa variável de ambiente, e não na solicitação. Uma coleção cujas solicitações utilizem todas {{baseUrl}}

pode ser direcionada para um host diferente ao alternar entre ambientes, o que permite comparar o comportamento entre regiões sem editar nada:

{{baseUrl}}/api/products?region={{region}}

Crie um ambiente por cenário. Um ambiente «direto» e um ambiente «via proxy», cada um com as suas próprias variáveis, permitem-lhe alternar o contexto num único menu suspenso. Ainda terá de alterar a própria configuração do proxy em «Definições», mas tudo o resto muda com o ambiente.

Guarde a verificação do endereço como uma solicitação na coleção. Um GET https://api.ipify.org?format=json

guardado juntamente com as suas solicitações reais significa que a confirmação do proxy requer apenas um clique, em vez de uma nova aba. Adicione um script de teste para que registe o que encontrou:

const ip = pm.response.json().ip;
pm.environment.set("observedIp", ip);
console.log("Exit address:", ip);

Verifique o conteúdo dependente da região, não o endereço. Para trabalhos com segmentação geográfica, a verificação útil é se a resposta difere efetivamente:

pm.test("Response is region-specific", function () {
    pm.expect(pm.response.json().currency).to.eql(pm.environment.get("expectedCurrency"));
});

Este é o mesmo princípio que se aplica em qualquer outro contexto de trabalho com proxy: uma pesquisa de IP indica o que o serviço de pesquisa pensa, e apenas a resposta do próprio destino indica se a segmentação funcionou.

E mantenha as credenciais fora da coleção. As credenciais de proxy devem estar nas definições do Postman, e as credenciais da API devem estar em variáveis de ambiente marcadas como secretas — não na solicitação e, certamente, não numa coleção que pretenda exportar ou partilhar. Uma coleção exportada transporta consigo os valores das suas variáveis, a menos que estas estejam marcadas como secretas, o que constitui uma forma fácil de publicar um token acidentalmente.

Que cliente usar para cada tarefa

O Postman é uma boa ferramenta com uma finalidade específica, e saber até onde vai a sua utilidade poupa tempo.

Use o Postman para: explorar uma API de forma interativa, verificar se um proxy funciona, capturar o tráfego de um dispositivo e partilhar uma coleção de pedidos com colegas.

Utilize o curl para: tudo o que pretenda reproduzir, automatizar ou colar num ticket. Controlo do proxy por pedido com -x

, saída detalhada que mostra exatamente o que passou pela rede e um comando que funciona de forma idêntica em qualquer máquina:

curl -x http://user:pass@proxy.example.com:9000 https://api.ipify.org

O Postman pode gerar um comando curl a partir de qualquer pedido, o que é a forma mais rápida de passar da exploração para algo reproduzível.

Utilize um cliente HTTP adequado no código para: qualquer coisa com volume significativo, encaminhamento por pedido, lógica de repetição de tentativas ou gestão de sessões. A configuração global de proxy do Postman é um valor único para toda a aplicação, pelo que uma carga de trabalho que necessite de saídas diferentes por pedido não pode ser representada nessa configuração.

Um fluxo de trabalho prático: verifique se o proxy funciona no Postman, exporte a solicitação como curl para a confirmar fora da GUI e, em seguida, implemente-a no código com controlo por solicitação. Cada passo é mais rápido do que depurar o anterior na ferramenta errada.

Resolução de problemas

As solicitações funcionam sem o proxy, mas falham com ele. Verifique primeiro as credenciais — um código de estado 407 significa que o proxy rejeitou o acesso, o que é uma falha diferente de um código 401 proveniente do destino. Em seguida, verifique se o seu fornecedor utiliza uma lista de IPs autorizados na qual o seu endereço atual não consta.

Tudo está lento. Os proxies residenciais acrescentam uma latência real por pedido, e isso é uma questão de física e não uma avaria. Aumente o tempo de espera e faça uma medição antes de concluir que algo está avariado.

Erros TLS em todos os pedidos HTTPS. O proxy está a interceptar o TLS. Adicione o certificado da CA em vez de desativar a verificação.

A configuração do proxy parece estar a ser ignorada. Verifique a lista de exceções, certifique-se de que está na aplicação para computador e confirme se ativou a opção correta — «personalizada», «sistema» e «padrão» são opções distintas.

A captura não mostra nada. Confirme se o dispositivo está na mesma rede, se a porta corresponde e se nenhuma firewall no seu computador está a bloquear ligações de entrada na porta 5559.

A captura HTTPS mostra ligações, mas nenhum conteúdo. O certificado da CA não está instalado ou não é considerado de confiança no dispositivo cliente. Em algumas plataformas, instalar um certificado e considerá-lo de confiança são passos distintos.

Um erro 407 que persiste mesmo com credenciais corretas. Verifique se a palavra-passe contém caracteres que necessitem de codificação e confirme se o seu fornecedor exige credenciais — muitos oferecem, em vez disso, listas de endereços IP autorizados, o que elimina completamente as credenciais da configuração e vale a pena utilizar quando o seu endereço é estável.

Perguntas frequentes

Como configuro um proxy no Postman?

Na aplicação para computador, abra as «Definições» e aceda ao separador «Proxy»; em seguida, selecione um proxy personalizado e introduza o host e a porta. O Postman também suporta a utilização automática do proxy do sistema. Adicione as credenciais no mesmo separador, caso o proxy as exija.

O Postman suporta proxies SOCKS?

Sim — a documentação indica HTTP, SOCKS5, SOCKS5H, SOCKS4 e SOCKS4A. A limitação indicada é que apenas pedidos HTTP e HTTPS podem ser enviados através de um proxy SOCKS. Dê preferência ao SOCKS5H em vez do SOCKS5, uma vez que este resolve nomes de anfitrião no proxy e evita a fuga de consultas DNS.

Por que razão o Postman está a ignorar as minhas definições de proxy?

Normalmente, uma de três coisas: o host de destino corresponde a uma entrada na lista de exclusões, está a utilizar a versão do navegador em vez da aplicação para computador, ou configurou um proxy personalizado enquanto está selecionada uma opção de proxy diferente. Verifique solicitando um serviço que indique o seu endereço.

Como posso capturar pedidos com o Postman?

Utilize o proxy integrado, cuja porta predefinida é a 5559. Descubra o IP local do seu computador, configure o dispositivo cliente para o utilizar como proxy HTTP nessa porta e instale o certificado postman-proxy-ca.crt no dispositivo, caso precise de capturar HTTPS.

Por que razão recebo erros SSL ao utilizar um proxy no Postman?

Porque o proxy está a interceptar o TLS e a apresentar o seu próprio certificado, no qual o Postman não confia. Adicione o certificado da autoridade certificadora (CA) da sua organização nas definições de certificados do Postman. Desativar a verificação SSL funciona e aplica-se a todas as solicitações subsequentes, o que representa um custo significativo.

Posso definir um proxy diferente para cada solicitação no Postman?

Não. A configuração do proxy aplica-se a toda a aplicação, o que constitui a principal razão pela qual o Postman não é adequado para cargas de trabalho que necessitem de saídas diferentes por pedido. Utilize um cliente baseado em código para esse efeito e utilize o Postman para verificar se o proxy funciona antes de o implementar.

Qual é a diferença entre as definições de proxy do Postman e o seu proxy de captura?

As definições de proxy encaminham as próprias solicitações do Postman através de um proxy externo. O proxy de captura faz com que o Postman atue como um proxy através do qual outras aplicações enviam solicitações, para que possa ver o que estas transmitem. Direções opostas, configurações não relacionadas.

É seguro instalar o certificado CA do Postman?

Trata-se de uma escolha deliberada. O certificado permite que o Postman descodifique o seu tráfego HTTPS, o que é a única forma de o inspecionar — e isso significa que qualquer entidade com esse certificado pode emitir certificados de confiança para qualquer domínio. Instale-o quando precisar da função de captura, remova-o quando terminar e evite lidar com credenciais confidenciais enquanto estiver instalado.

Conclusão

A confusão em torno deste tema deve-se inteiramente a uma questão de nomenclatura. As definições de proxy do Postman encaminham os teus pedidos através do proxy de terceiros; o proxy de captura do Postman faz com que o próprio Postman seja o intermediário para outras aplicações. Decidir qual deles queres demora dez segundos e poupa-te de ter de ler a documentação errada.

Para a primeira opção, utilize a aplicação para computador, defina um proxy personalizado nas «Definições», coloque localhost na lista de exceções e — o passo mais importante — verifique solicitando um serviço que indique o seu endereço, porque uma configuração de proxy que não faz nada não produz qualquer erro.

Para a segunda opção, utilize a porta 5559 e um certificado CA no dispositivo cliente. Tenha em conta que o certificado existe para que o Postman possa descodificar o seu tráfego e remova-o quando terminar.

E tenha em conta os limites do Postman. Ele aplica as definições de proxy globalmente, pelo que não permite, de todo, o encaminhamento por pedido. Utilize-o para confirmar que um proxy funciona, exporte o pedido como curl para o verificar fora da interface gráfica e, em seguida, implemente a solução definitiva em código — o que é mais rápido do que tentar fazer com que uma ferramenta interativa execute uma tarefa programada.