Entendendo o que é o Charles Proxy para desenvolvimento mobile
O Charles Proxy é uma ferramenta de debugging que intercepta todo o tráfego HTTP e HTTPS entre seu dispositivo e a internet. Ele funciona como um proxy local no seu computador, e você configura o celular ou tablet para usar esse mesmo proxy. Quando o app faz uma requisição, ela passa pelo Charles, que registra tudo: headers, payloads, status codes, tempo de resposta. É uma das ferramentas mais usadas por desenvolvedores frontend e mobile que precisam investigar por que uma API não responde como esperado. A instalação básica é simples. Você baixa o executável para Windows ou macOS no site oficial, abre, e ele já fica escutando na porta 8888. O passo que muita gente erra é a parte da configuração no dispositivo. No Wi-Fi do celular, você vai nas configurações avançadas da rede e coloca o IP do seu computador e a porta 8888. Se estiver testando no iOS, precisa instalar o certificado SSL do Charles também — senão, as requisições HTTPS ficam todas como "encrypted" na aba SSL e você não consegue ver nada.
Como configurar eletronica charles para capturar requisições
Eu já passei por um problema específico que demorou três horas pra resolver: requests de apps Android que usavam certificados fixos (certificate pinning). O Charles interceptava o TCP, mas o app rejeitava o certificado do proxy e fechava a conexão antes mesmo de enviar os dados. A solução não foi mudar configuração do Charles — foi descompilar o APK, remover o pinning, recompilar com o APK Multi-Tool. Sim, dá trabalho. Mas existem alternativas mais fáceis como usar versões debug dos apps que não fazem pinning, ou frameworks como Frida para contornar isso em tempo real. Depois de configurar o proxy e o certificado, você pode filtrar o tráfego pela aba Hosts. Isso é muito útil quando o app gera centenas de requests por minuto de trackers e analytics e você só quer ver as chamadas da sua API. Outra dica prática: ative o Map Local se quiser modificar respostas no voo. É comum precisar simular um erro 500 ou alterar um JSON de resposta para testar como o app se comporta sem depender do backend.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um detalhe que ninguém menciona bastante: a diferença entre breakpoints e interceptação completa. Breakpoints pausam cada request individualmente, permitindo editar o payload antes de enviar. Isso economiza muito tempo em comparação com apenas observar. Mas tem uma pegadinha — se o app usar streaming ou uploads de arquivos grandes, o breakpoint pode travar o processo inteiro porque o Charles precisa processar os dados antes de encaminhar. Nesse caso, prefira filtrar por endpoint específico e desligue o breakpoint, confiando apenas na captura passiva. O custo do Charles é cerca de US$ 49 por licença individual, e a trial dura 30 dias com funcionalidade completa. Tem alternativas gratuitas como o mitmproxy, que é baseado em linha de comando e roda no terminal. Para quem já programa, o mitmproxy pode ser mais flexível porque permite automação via scripts Python. Mas a interface visual do Charles ainda é bem mais rápida para uso spot onde você só quer entender rápido o que está acontecendo.
Há uma limitação importante que vale destacar: em dispositivos com Android 7+, apps podem usar trust anchors do sistema, o que significa que instalar o certificado do Charles no perfil de usuário pode não funcionar. Nesse cenário, você precisa de root ou usar emuladores como o Android Studio AVD, que não têm as mesmas restrições de segurança. Isso é especialmente frustrante quando você só quer testar um app rápido no seu próprio telefone sem perder tempo configurando coisas que não deveriam ser complicadas. A versão mais recente do Charles melhora significativamente a captura WebSocket e HTTP/2, duas coisas que anteriormente eram meio problemáticas. O histórico de sessões também ficou mais responsivo quando você tem dezenas de milhares de requests gravados. O único ponto fraco ainda persistente é a memória — com sessões muito longas e muitos requests, o Charles começa a consumir bastante RAM. Eu normalmente fecho e abro uma sessão nova quando percebo que a interface começa a travar, em vez de tentar limpar manualmente.
Se você trabalha com apps que comunicam com múltiplos backends ou microsserviços, vale a pena separar as sessões por ambiente. Desenvolvimento, staging e produção têm perfis diferentes de resposta e erro. Misturar tudo numa única sessão torna a análise muito mais lenta do que deveria ser. O Charles permite salvar configurações de sessão, então é viável ter um perfil pronto para cada ambiente com filtros já aplicados. Resumindo de forma que faz sentido na prática: o Charles Proxy resolve o problema de não conseguir ver o que acontece dentro do app quando ele fala com servidores. A configuração inicial dá trabalho, principalmente na parte do certificado SSL, mas depois disso o dia a dia de debugging melhora consideravelmente. Para casos mais avançados como certificate pinning, você precisa de soluções adicionais. O preço é razoável para quem faz isso profissionalmente, mas o mitmproxy é uma saída válida se o orçamento for restrito.
