Fiddler para depuração de tráfego HTTP em aplicativos Windows e UWP: guia completo com configuração de proxy

Instalação e configuração inicial

A instalação do Fiddler Classic leva cerca de dois minutos. Baixe o instalador do site oficial telerik.com/fiddler e execute-o. Após a instalação, o Fiddler se registra automaticamente como proxy do sistema Windows na porta 127.0.0.1:8888.

Logo após iniciar, você verá a janela principal com três áreas:

• Painel esquerdo (Sessions) — lista de todas as solicitações interceptadas em tempo real
• Painel superior direito — detalhes da solicitação selecionada (cabeçalhos, corpo, parâmetros)
• Painel inferior direito — resposta do servidor

A primeira coisa a fazer é configurar a filtragem, caso contrário, a lista incluirá todo o tráfego do sistema Windows (atualizações, telemetria, OneDrive etc.), e será difícil encontrar as solicitações desejadas. Vá para a aba Filters na parte direita e ative Use Filters. No campo Show only the following Hosts, insira os domínios que você está interessado.

Também recomendamos configurar a salvaguarda automática das sessões: File → Capture Traffic e File → Save → All Sessions. Isso permitirá que você retorne ao tráfego gravado mais tarde e o analise offline.

Interceptação de tráfego HTTPS: configuração do certificado

Por padrão, o Fiddler intercepta apenas tráfego HTTP. Para trabalhar com HTTPS (que representa mais de 95% do tráfego moderno), é necessário configurar a descriptografia SSL. O Fiddler atua como um Man-in-the-Middle: ele gera seu próprio certificado raiz e assina todas as conexões HTTPS com ele.

Configuração passo a passo da interceptação HTTPS:

1. Abra Tools → Options → HTTPS
2. Marque a opção Capture HTTPS CONNECTs
3. Marque a opção Decrypt HTTPS traffic
4. No menu suspenso, selecione ...from all processes
5. Clique no botão Actions → Trust Root Certificate
6. Confirme a instalação do certificado no armazenamento do sistema Windows
7. Reinicie o Fiddler

Após isso, na coluna Protocol, você verá HTTPS em vez de CONNECT, e poderá visualizar o conteúdo descriptografado das solicitações e respostas.

Alguns aplicativos utilizam Certificate Pinning — eles verificam um certificado específico do servidor e se recusam a funcionar através do Fiddler. Nesse caso, você verá um erro de conexão no aplicativo. Contornar o pinning é um tópico separado, que está além do escopo deste artigo.

Como interceptar o tráfego de aplicativos UWP

UWP (Universal Windows Platform) são aplicativos da Microsoft Store: Mail, Maps, Movies & TV, Spotify, Netflix e muitos outros. A característica deles é que, por motivos de segurança, eles operam em um contêiner isolado (App Container) e não utilizam o proxy do sistema. É por isso que a configuração padrão do Fiddler não intercepta seu tráfego.

Para resolver esse problema, o Fiddler fornece uma ferramenta especial — AppContainer Loopback Exemption Utility. Ela adiciona o aplicativo UWP à lista de exceções, permitindo que ele acesse o proxy local do Fiddler.

Método 1 — através da interface do Fiddler:

1. No menu, selecione WinConfig (botão na barra de ferramentas ou Tools → Win8 Loopback Exemptions)
2. Uma lista de todos os aplicativos UWP instalados será aberta
3. Encontre o aplicativo desejado e marque a caixa ao lado dele
4. Clique em Save Changes
5. Reinicie o aplicativo UWP

Método 2 — através do prompt de comando (para automação):

CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsMaps_8wekyb3d8bbwe"

Substitua Microsoft.WindowsMaps_8wekyb3d8bbwe pelo Package Family Name do aplicativo desejado. Você pode encontrá-lo no PowerShell com o comando:

Get-AppxPackage | Select-Object Name, PackageFamilyName | Sort-Object Name

Após adicionar a exceção, o aplicativo UWP começará a enviar tráfego através do Fiddler. Você verá suas solicitações na lista de sessões — geralmente elas são facilmente identificáveis pelo User-Agent ou pelo host de destino.

Filtros, breakpoints e modificação de solicitações

As três funções mais poderosas do Fiddler para depuração são a filtragem de sessões, breakpoints e AutoResponder. Vamos analisar cada uma delas.

Filtragem de sessões

A aba Filters permite mostrar apenas as solicitações desejadas. As principais opções:

• Show only the following Hosts — filtro por domínio (por exemplo, api.example.com)
• Show only if URL contains — filtro por parte da URL
• Show only if response Content-Type — apenas JSON, XML, imagens etc.
• Hide if URL contains — excluir solicitações de ruído (por exemplo, telemetry, analytics)

Você também pode usar a linha QuickExec na parte inferior da janela para comandos rápidos. Por exemplo, select status 404 destacará todas as solicitações com erro 404, enquanto bold api destacará em negrito todas as sessões que contêm "api" na URL.

Breakpoints

Os breakpoints permitem interromper uma solicitação ou resposta antes de ser enviada/recebida e alterar o conteúdo manualmente. Isso é análogo a um ponto de interrupção em um depurador de código, mas para HTTP.

• Rules → Automatic Breakpoints → Before Requests — interrompe cada solicitação antes do envio
• Rules → Automatic Breakpoints → After Responses — interrompe cada resposta antes de ser passada para o aplicativo
• Clique com o botão direito na sessão → Breakpoint → Break on Request — breakpoint pontual em uma URL específica

Quando a solicitação é interrompida, você pode alterar qualquer cabeçalho, corpo da solicitação, URL e clicar em Run to Completion para continuar. Isso é especialmente útil para testar o comportamento do aplicativo com dados alterados.

AutoResponder

O AutoResponder é uma ferramenta para substituir respostas do servidor. Você cria uma regra: "se a URL corresponder ao padrão — retorne este arquivo/resposta". Aplicações:

• Teste de aplicativos com mocks de API sem backend real
• Simulação de erros de servidor (500, 503, timeouts)
• Substituição de recursos — carregar uma versão local de JS/CSS em vez da versão do servidor
• Aceleração do desenvolvimento — cache de solicitações lentas para APIs externas

Conexão de proxy externo através do Fiddler

Uma das funcionalidades importantes do Fiddler é operar em modo "proxy através de proxy" (upstream proxy). O Fiddler intercepta o tráfego localmente e, em seguida, o direciona através de um servidor proxy externo. Isso permite depurar solicitações e mudar o endereço IP ou a geolocalização ao mesmo tempo.

Quando isso é necessário:

• Teste do comportamento do aplicativo ao trabalhar através de um proxy corporativo
• Verificação de conteúdo geodependente — como o aplicativo funciona de outro país
• Depuração de um aplicativo que usa proxy
• Teste de API com restrições de IP (whitelist por IP)

Configuração do upstream proxy no Fiddler Classic:

1. Abra Tools → Options → Gateway
2. Selecione Manual Proxy Configuration
3. No campo Proxy, insira o endereço do proxy no formato host:port
4. Se o proxy exigir autenticação — forneça o login e a senha
5. Clique em OK e reinicie a captura de tráfego

O Fiddler suporta proxies HTTP, HTTPS e SOCKS5 como upstream. Para SOCKS5, o formato de registro é um pouco diferente:

socks=proxy.example.com:1080

Para tarefas de teste de comportamento geodependente de aplicativos, proxies residenciais são uma boa opção — eles usam IPs reais de usuários domésticos do país desejado, e o aplicativo recebe respostas exatamente como um usuário real dessa região. Isso é importante se a API retornar conteúdo diferente dependendo da geolocalização.

Se você precisa de alta velocidade para baixar grandes volumes de dados durante a depuração, proxies de datacenter são adequados — eles oferecem uma conexão estável e baixa latência, o que é conveniente ao trabalhar com APIs pesadas.

static function OnBeforeRequest(oSession: Session) {
  if (oSession.HostnameIs("api.us-service.com")) {
    oSession["x-OverrideGateway"] = "us-proxy.example.com:8080";
  }
}

Cenários práticos: parsing, teste de API, geo-bypass

Vamos analisar tarefas específicas que são convenientes de resolver com o Fiddler.

Cenário 1: Engenharia reversa da API de um aplicativo móvel

Você deseja automatizar ações em um aplicativo, mas ele não possui uma API pública. A solução: inicie o aplicativo em um emulador Android ou através do cliente Windows, configure-o para usar o Fiddler como proxy e registre todas as solicitações ao executar as ações desejadas.

Após o registro, você obtém uma visão completa: endpoints, formatos de solicitações, cabeçalhos de autenticação, tokens. Esses dados podem ser usados para escrever seu próprio cliente ou automatizar através de scripts.

Cenário 2: Depuração do parser de um marketplace

Ao desenvolver um parser para Wildberries, Ozon ou outros marketplaces, muitas vezes não está claro por que as solicitações são bloqueadas. O Fiddler permite comparar as solicitações do navegador (que passam) com as solicitações do parser (que são bloqueadas) e encontrar diferenças nos cabeçalhos, na ordem em que aparecem, nos valores de cookie ou no fingerprint TLS.

Uma descoberta típica: o parser envia os cabeçalhos em uma ordem diferente, falta o Accept-Language, ou User-Agent contém a versão do Python. Corrigindo esses detalhes no código do parser, você reduz a probabilidade de bloqueio.

Cenário 3: Teste de conteúdo geodependente

Se seu aplicativo exibe conteúdo diferente para usuários de diferentes países, você precisa testá-lo com IPs reais desses países. Configure o Fiddler com um proxy upstream da região desejada, inicie o aplicativo — e você verá exatamente o que um usuário desse país vê, além de um log completo de todas as solicitações.

Cenário 4: Monitoramento da atividade em segundo plano de aplicativos

Quer saber para onde um programa instalado "liga"? Inicie o Fiddler, inicie o programa, aguarde 5-10 minutos. A lista de sessões mostrará todos os hosts que o programa acessou. Isso é útil para auditoria de segurança de software de terceiros, verificação de telemetria ou conexões indesejadas.

Cenário 5: Exportação de solicitações para reprodução

O Fiddler permite exportar solicitações interceptadas no formato cURL, que podem ser executadas imediatamente no terminal ou coladas no Postman. Clique com o botão direito na sessão → Copy → cURL Request. Isso é conveniente para passar uma solicitação para um colega ou para documentar uma API.

Fiddler Classic vs Fiddler Everywhere: qual escolher

A Telerik suporta duas versões do produto, e a escolha entre elas nem sempre é óbvia. Vamos analisar as principais diferenças.

Quando escolher o Fiddler Classic: você trabalha apenas no Windows, precisa trabalhar com aplicativos UWP, usa FiddlerScript para automação, ou valoriza uma versão totalmente gratuita sem limitações.

Quando escolher o Fiddler Everywhere: você trabalha no macOS ou Linux, precisa de uma interface moderna, valoriza a colaboração em coleções de solicitações compartilhadas, ou deseja integração com pipelines CI/CD.

Também vale mencionar alternativas: Charles Proxy (pago, popular no macOS), mitmproxy (gratuito, baseado em console, muito flexível), Wireshark (opera no nível de pacotes, não HTTP). Cada ferramenta tem seus pontos fortes, mas para a maioria das tarefas de depuração de aplicativos Windows, o Fiddler Classic continua sendo a escolha ideal.

Problemas típicos e suas soluções

Ao trabalhar com o Fiddler, problemas típicos podem surgir periodicamente. Aqui estão os mais comuns e suas soluções.

Problema: O aplicativo não funciona com o Fiddler ativado

Causas: Certificate Pinning, proxy rígido configurado no aplicativo, ou o aplicativo não confia no certificado do Fiddler. Soluções:

• Instale o certificado do Fiddler no armazenamento Local Machine → Trusted Root
• Verifique se o aplicativo não utiliza certificate pinning
• Adicione o host às exceções SSL: Tools → Options → HTTPS → Skip Decryption for following hosts

Problema: Após fechar o Fiddler, a internet não funciona

O Fiddler não conseguiu remover o proxy do sistema após um encerramento inesperado. Solução: abra Configurações do Windows → Rede → Proxy e desative o proxy manual. Ou inicie o Fiddler novamente e feche-o normalmente.

Problema: Apenas túneis CONNECT são visíveis, mas não o conteúdo HTTPS

A interceptação HTTPS não está configurada. Volte à seção sobre configuração do certificado e verifique se a opção Decrypt HTTPS traffic está ativada e se o certificado está instalado no armazenamento do sistema.

Problema: O tráfego do aplicativo UWP não aparece no Fiddler

A exceção de loopback não foi adicionada para este aplicativo. Use WinConfig (descrito na seção sobre UWP) e reinicie o aplicativo após adicionar a exceção.

Problema: O proxy upstream não funciona (erro de conexão)

Verifique: a correção do endereço e porta do proxy, a correção do login/senha, a disponibilidade do servidor proxy (tente conectar diretamente sem o Fiddler). Além disso, certifique-se de que o proxy suporta o protocolo necessário — nem todos os proxies HTTP suportam tunelamento HTTPS.

Conclusão

O Fiddler é uma ferramenta indispensável para todos que trabalham com tráfego HTTP de aplicativos Windows. Ele permite visualizar todas as solicitações em tempo real, modificá-las em tempo real, testar o comportamento dos aplicativos em diferentes condições e resolver tarefas que não podem ser realizadas pelas DevTools do navegador. O suporte a aplicativos UWP através do mecanismo de exceções de loopback é uma oportunidade única que a maioria dos concorrentes não oferece.

Para tarefas de teste de comportamento geodependente de aplicativos ou verificação de funcionamento através de proxies externos — configure o proxy upstream no Fiddler. Se você precisa de IPs reais de países específicos para testes adequados, considere usar proxies residenciais — eles oferecem uma geolocalização o mais realista possível e um risco mínimo de bloqueios por parte dos serviços testados.

Comece com o Fiddler Classic — ele é gratuito, bem documentado e cobre 90% das tarefas de depuração no Windows. À medida que suas necessidades crescem, você pode migrar para o Fiddler Everywhere ou complementar seu fluxo de trabalho com ferramentas especializadas como o mitmproxy para uma automação mais flexível.