Muita automação brasileira roda em VPS no exterior — é mais barato, a oferta é maior e a latência para APIs globais é boa. O problema aparece quando o destino é brasileiro: sites que só respondem a acessos do Brasil, preço e conteúdo diferentes por país, painéis que estranham login vindo de um datacenter na Europa ou nos Estados Unidos.
Um proxy com IP brasileiro dá à VPS uma saída no Brasil sem mudar de servidor. Esta página mostra quando isso compensa, como configurar e quando a melhor resposta é outra.
Quando o proxy compensa — e quando não
| Situação | Melhor caminho |
|---|---|
| Servidor roda bem fora e só parte do tráfego precisa sair do Brasil | Proxy nas aplicações que acessam destinos brasileiros |
| Várias contas ou instâncias na mesma VPS precisam de IPs diferentes | Proxy, um IP por conta ou instância |
| Todo o tráfego precisa sair do Brasil e a latência importa | VPS no Brasil pode ser mais simples |
| Coleta em volume com troca de IP | Residencial por GB, não VPS com IP fixo |
Sendo direto: se a sua aplicação inteira precisa estar no Brasil, contratar a VPS numa região brasileira pode resolver sem proxy. O proxy ganha quando você quer manter o servidor onde está, separar IPs por conta ou ter origem residencial.
Qual produto usar
| Uso na VPS | Produto | Por quê |
|---|---|---|
| Bots, integrações e painéis com IP fixo | IPv4 dedicado | Endereço fixo no Brasil, sem cobrança por GB |
| WhatsApp API por número | Proxy para Evolution API | Um IP por instância, fora do IP compartilhado da VPS |
| Contas sensíveis a datacenter | ISP residencial | IP de provedor de internet |
| Coleta e scraping | Residencial por GB | IP que troca, pago pelo tráfego |
| Origem numa região | Por cidade e estado | Estado ou cidade na credencial |
Como configurar no servidor
A autenticação é por usuário e senha, então a VPS não precisa ter IP liberado: a mesma credencial funciona de qualquer servidor.
Por aplicação (recomendado)
Configure o proxy só no que precisa sair do Brasil. É o jeito mais previsível, porque o resto do servidor — atualizações, SSH, APIs globais — continua pela rota normal.
``bash``
curl -x http://usuario:[email protected]:8000 https://api.ipify.org
Guias por ferramenta: Python, n8n, Evolution API, Playwright, Puppeteer e Scrapy.
Por variável de ambiente
Muitas bibliotecas e ferramentas de linha de comando leem estas variáveis:
``bash``
export HTTP_PROXY="http://usuario:[email protected]:8000"
export HTTPS_PROXY="http://usuario:[email protected]:8000"
export NO_PROXY="localhost,127.0.0.1"
Defina no serviço específico — no arquivo do systemd, no docker-compose ou no .env da aplicação — e não no sistema inteiro, para não mandar pelo proxy o tráfego que não precisa.
Em containers
No Docker, passe as mesmas variáveis no environment do serviço. Cada container pode usar um proxy diferente, o que resolve o caso de várias instâncias com IPs separados na mesma VPS.
Confira a saída
Depois de configurar, confira de dentro da aplicação ou do container:
``bash``
curl -s -x http://usuario:[email protected]:8000 https://ipwho.is/ | head -c 400
O país deve ser Brasil e o IP, o do proxy. Se der erro, veja erro 407 e proxy não conecta.
O que o proxy não resolve
- Não reduz a latência. O tráfego faz um desvio até o Brasil; para aplicações sensíveis a tempo de resposta, uma VPS no Brasil é melhor.
- Não substitui firewall nem segurança do servidor. SSH, portas e atualizações continuam sendo sua responsabilidade.
- Não autoriza uso proibido. Envio em massa não solicitado, ataques e acesso não autorizado estão fora da nossa política de uso aceitável.