O aplicativo ignora proxy: como encapsular o tráfego

```html

Você configurou um proxy nas configurações do Windows, reiniciou o programa — mas ele ainda está usando o IP doméstico. Ou, ao contrário: o navegador saiu corretamente através do proxy, enquanto o cliente de desktop ao lado continua a mostrar o endereço real. Isso não é um bug do proxy e nem credenciais erradas. É uma característica fundamental de como os sistemas operacionais lidam com o "proxy do sistema": ele não obriga, apenas sugere.

Abaixo estão quatro maneiras eficazes de forçar um aplicativo específico a usar SOCKS5, com as limitações de cada uma e os obstáculos onde as configurações costumam falhar.

Por que o proxy do sistema não funciona: a verdade técnica resumida

No Windows, não existe um único "proxy do sistema". Há pelo menos dois conjuntos independentes de configurações. O primeiro é o WinINET: o que você ajusta em "Configurações → Rede e Internet → Servidor Proxy". Ele é lido pelo Internet Explorer/Edge, parte dos aplicativos .NET e tudo que usa a pilha HTTP padrão do usuário. O segundo é o WinHTTP, utilizado por serviços do sistema e processos em segundo plano. E aqui está o ponto chave: o WinHTTP não usa as configurações do WinINET, a menos que você as importe explicitamente. Isso é feito com o comando netsh winhttp import proxy source=ie, e — um detalhe importante da documentação da Microsoft — o comando faz uma captura das configurações atuais. Mudou o proxy nas configurações depois? A captura não será atualizada automaticamente, o comando precisa ser executado novamente.

Mas mesmo a importação não salva você da principal categoria de problemas. Um grande número de programas não consulta o sistema: eles usam sua própria pilha de rede e abrem sockets TCP diretamente. Assim funcionam muitos clientes de desktop de redes sociais e mensageiros, lançadores de jogos, torrents, parte dos aplicativos Electron com configurações embutidas, utilitários compilados em Go e Rust. Para eles, a linha "proxy" nas configurações do sistema simplesmente não existe como conceito.

Daí a regra: se o aplicativo não tem seu próprio campo para proxy, o único caminho confiável é interceptar seu tráfego abaixo do nível do aplicativo. Existem quatro classes de métodos, e eles são fundamentalmente diferentes em custo, confiabilidade e permissões necessárias.

Passo 0: certifique-se de que o problema é esse

Inicie o aplicativo e veja qual IP ele mostra (perfil da conta, página de serviço, qualquer indicador embutido).
Abra o navegador através do mesmo proxy e verifique o endereço. IPs diferentes = o aplicativo ignora a configuração do sistema.
Verifique se o programa tem suas próprias configurações de proxy — muitas vezes estão escondidas em "Rede", "Conexão" ou em um arquivo de configuração. O suporte nativo é sempre melhor que a interceptação externa: menos camadas, menos falhas.
Verifique separadamente o DNS. Se o aplicativo resolve nomes localmente, e o tráfego vai através do proxy, seu provedor real ainda verá para onde você está indo.

Método 1. Proxifier — padrão comercial para Windows e macOS

Proxifier intercepta as conexões dos aplicativos e as redireciona para o proxy especificado de acordo com regras: você pode definir "este exe — através do proxy A, aquele — através do proxy B, o restante — diretamente", dividir por portas e endereços de destino, construir uma cadeia de vários proxies.

Versões atuais no momento da escrita: 4.14 para Windows (lançamento em 23 de abril de 2025) e 3.15 para macOS (18 de setembro de 2025). Licença — $39.95 por cópia, compra única, vitalícia, com atualizações menores gratuitas; há um teste funcional de 31 dias, descontos para compras em volume a partir de duas cópias e reembolso dentro de 30 dias.

Prática de configuração:

Servidores Proxy → Adicionar: especifique o endereço, porta, protocolo SOCKS5 e credenciais. Clique em Verificar — o teste deve passar antes de criar regras, caso contrário, você estará depurando dois problemas ao mesmo tempo.
Regras de Proxificação → Adicionar: em Aplicativos, selecione o arquivo executável específico, em Ação — seu proxy.
Deixe a regra Padrão como Direto, a menos que você queira redirecionar toda a máquina. Este é o erro mais comum de iniciantes: Padrão → Proxy coloca no túnel tanto o atualizador do sistema quanto o antivírus, e tráfego desnecessário pelo qual você paga em gigabytes.
Veja a aba Conexões em tempo real: lá é possível ver qual conexão saiu através do proxy e qual saiu diretamente.

Pontos fortes — maturidade, regras estáveis e diagnóstico claro. Fracos — custo e o fato de que, em sistemas anti-cheat agressivos, a interceptação por driver pode ser detectada.

Método 2. ProxiFyre — alternativa gratuita para Windows com suporte a UDP

Se o orçamento é zero e a plataforma é Windows, há um projeto aberto chamado ProxiFyre (licença AGPL-3.0). Ele é construído sobre NDISAPI/Windows Packet Filter — ou seja, funciona no nível do driver de filtragem de pacotes e tem a capacidade que muitas vezes falta: encaminhar de forma transparente não apenas TCP, mas também UDP para cada aplicativo separadamente. Isso é crucial para tudo que vive em UDP e QUIC — canais de voz, clientes de jogos, parte das conexões de navegadores modernos.

Entre as novidades nas versões recentes: suporte a IPv6 foi adicionado na v2.3.0, SOCKS5-over-TLS na v2.4.0, há regras de exceção para aplicativos e uma captura geral para todos os outros. Requisitos: Windows Packet Filter instalado, bibliotecas de tempo de execução do Visual Studio e permissões de administrador.

A configuração é feita através de um arquivo de configuração com uma lista de aplicativos e seus endpoints SOCKS5 associados. A barreira de entrada é maior do que a do Proxifier, mas você não paga e ainda tem suporte a UDP.

Método 3. proxychains-ng — opção rápida para Linux, com ressalvas

Clássico para sistemas Unix: proxychains4 curl https://example.com. O mecanismo — LD_PRELOAD: a biblioteca substitui chamadas de sockets em um programa vinculado dinamicamente e redireciona para SOCKS.

Limitações que você deve conhecer antes de construir um fluxo de trabalho com isso:

Apenas TCP. UDP e ICMP não são redirecionados de forma alguma — ping através do proxychains não verifica nada significativo.
Apenas binários vinculados dinamicamente. Utilitários compilados estaticamente (situação típica para Go) ignoram silenciosamente o LD_PRELOAD — o tráfego irá diretamente, e você não perceberá.
No macOS, enfrenta o SIP. A Proteção de Integridade do Sistema bloqueia o carregamento da biblioteca em binários do sistema: proxychains4 ssh user@host não funcionará. Um caminho alternativo é copiar o binário para seu diretório (cp /usr/bin/ssh ~/.local/bin/) e executar a cópia. Não recomendo desativar o SIP por conveniência: você enfraquece a proteção de todo o sistema por causa de uma única utilidade.

Para tarefas pontuais (curl, script python, utilitário de console), o proxychains continua sendo a maneira mais rápida — é instalado com um único comando e não requer root.

Método 4. Modo TUN: interceptação no nível da interface virtual

A classe de soluções mais universal. Uma interface de rede virtual é criada, as rotas do sistema são redirecionadas para ela, e a pilha TCP/IP do usuário processa os pacotes e os envia para fora através do SOCKS5. Assim funcionam tun2socks (usa a pilha gVisor, suporta TCP e UDP, disponível para todas as plataformas) e sing-box no modo TUN.

A principal vantagem em relação ao LD_PRELOAD: tudo é interceptado, incluindo binários estáticos e aplicativos com sua própria pilha. O sing-box também tem roteamento por processos — os campos process_name, process_path e process_path_regex, o que fornece regras reais por aplicativo; de acordo com a documentação, isso é suportado no Linux, Windows e macOS (em plataformas móveis, as regras são definidas pelo nome do pacote ou ID do bundle).

Duas armadilhas onde praticamente todos tropeçam:

Loop de rota. Se todo o tráfego vai para o TUN, a conexão com o próprio servidor SOCKS5 também tenta ir para o TUN — o túnel começa a se redirecionar. Isso é corrigido com uma rota de exceção explícita até o IP do proxy através da interface física. Este é um problema conhecido e que frequentemente aparece nas configurações do sing-box.
Permissões. Criar uma interface TUN e modificar a tabela de roteamento requer root/admin. Em uma máquina corporativa com políticas, isso pode não estar disponível.

No Linux, existem mais duas abordagens relacionadas: redsocks — interceptação através de regras iptables com redirecionamento para uma porta local (apenas Linux, requer root), e sshuttle, que cria um roteamento semelhante a VPN sobre acesso SSH comum, contornando o clássico problema "TCP sobre TCP".

O que quebra com mais frequência

Vazamento de DNS. Mesmo com um SOCKS5 configurado corretamente, o aplicativo pode resolver domínios localmente. Verifique se a resolução está indo para o proxy, e não para o seu provedor.
SOCKS4 selecionado em vez de SOCKS5. SOCKS4 não suporta UDP de forma alguma e não consegue transmitir o nome de domínio em várias implementações. Para interceptar tráfego arbitrário, use apenas SOCKS5 — o porquê disso é detalhado no material sobre os princípios de funcionamento do SOCKS5.
Proxy HTTP em vez de SOCKS. Proxy HTTP pode proxyar HTTP e através de CONNECT — conexões TLS. Tráfego TCP arbitrário de um cliente de jogo ou mensageiro não é redirecionado.
Regra padrão para todo o tráfego. Redirecionando toda a máquina, você consome o tráfego do pool residente em atualizações e telemetria.
Falta de verificação após a configuração. Sempre verifique o IP de saída real do próprio aplicativo, e não do navegador ao lado.

Qual tipo de proxy escolher para interceptação

Tecnologicamente, a interceptação funciona com qualquer endpoint SOCKS5, mas o tipo escolhido determina se seu cenário chegará ao resultado.

Residenciais — quando o aplicativo trabalha com um serviço que avalia a reputação do IP: redes sociais, marketplaces, painéis de anúncios, formulários de pagamento. Endereços de data center são reconhecidos quase instantaneamente. Proxy residenciais com suporte a SOCKS5 e sessões fixas são adequados — o último é crítico, pois mudar o IP no meio de uma sessão ativa parece pior para o anti-fraude do que ter um IP "estranho" desde o início.
Data center — para tarefas técnicas sem um anti-fraude rigoroso: acesso à API, serviços internos, ambientes de teste, tudo onde a velocidade e a estabilidade do canal são mais importantes do que a aparência "residencial" do endereço. Aqui, proxies de data center oferecem melhor latência e previsibilidade.
Móveis — quando o aplicativo é móvel por natureza (emulador, cliente de rede social) e requer a máxima confiança da plataforma.

Separadamente: a interceptação no nível do aplicativo não é uma VPN, e não deve ser confundida com uma. Se você precisa de um único canal seguro para toda a máquina, e não de IPs diferentes para diferentes programas, a comparação de abordagens está na análise WireGuard contra proxy.

Como escolher um método em um minuto

O aplicativo tem suas próprias configurações de proxy → use-as, não interceptem nada.
Windows, precisa de resultado hoje, há orçamento → Proxifier.
Windows, precisa de UDP e gratuitamente → ProxiFyre.
Linux, tarefa pontual com utilitário de console → proxychains-ng.
Precisa interceptar um binário estático, um jogo ou tudo de uma vez com regras por aplicativo → modo TUN (sing-box, tun2socks), não se esqueça da rota de exceção até o proxy.

A conclusão principal é simples: "o proxy não funciona" em nove casos de dez significa "o proxy não está configurado no nível correto". A configuração do sistema é um pedido educado ao aplicativo, enquanto a interceptação no nível do driver, LD_PRELOAD ou interface TUN é uma imposição. Escolha a camada corretamente, verifique o IP de saída real do próprio aplicativo e não se esqueça do DNS — e o problema será resolvido uma vez, e não surgirá após cada atualização do programa.