Como Criei um Serviço de VPN em 2026: Desafios e Lições Aprendidas
Um relato detalhado sobre a criação de um serviço de VPN, abordando desafios de infraestrutura, bloqueios, detecção de VPNs e estratégias de contorno. O artigo explora as dificuldades enfrentadas, desde a configuração inicial até as táticas de evasão de bloqueios e a adaptação às mudanças regulatórias.
MundiX News·29 de maio de 2026·7 min de leitura·👁 20 views
Como Criei um Serviço de VPN em 2026
Introdução
Tudo começou de forma simples: levantei um VPS para uso pessoal, configurei 3x-ui e implementei VLESS+Reality. Funcionava bem. Compartilhei com amigos, que compartilharam com outros. Em algum momento, percebi que estava administrando a infraestrutura para dezenas de usuários, tudo manualmente, sem qualquer automação. Em fevereiro de 2026, transformei isso em um serviço formal, com banco de dados e um bot no Telegram.
A seguir, a cronologia do que enfrentei durante o desenvolvimento, o que foi feito reativamente e o que foi preventivamente.
Arquitetura e Stack
O serviço é construído em dois backends independentes, que operam com um único banco de dados.
O primeiro é um bot do Telegram (Node.js). O usuário escreve para o bot, recebe a configuração e importa para o cliente. O lado do servidor são VPSs russos com painel 3x-ui (XRay, VLESS).
O segundo backend (também Node.js) é a base para um futuro aplicativo móvel. Atualmente, ele contém toda a lógica de assinaturas, servidores e usuários. Os planos incluem lançar um aplicativo para iOS e Android com base nisso – estou recebendo muitos comentários de que muitos usuários acham difícil entender como instalar o aplicativo por conta própria e a citação – “gostaria de apertar um botão e fazer tudo funcionar”.
Infraestrutura do servidor: 12 máquinas. 4 de entrada (ENTRY) – russas. 8 de saída (EXIT) – Europa e EUA.
Na Zona de “Listas Brancas”
O primeiro problema sério surgiu antes mesmo do lançamento oficial do serviço – enquanto eu estava testando a infraestrutura.
Alguns usuários reclamaram que a VPN não estava funcionando, enquanto outros estavam perfeitamente bem. Como descobri mais tarde (isso aconteceu apenas com redes móveis), em algumas cidades havia problemas de conexão na zona de “listas brancas”: alguns estabeleciam a conexão, mas nada carregava, outros não conseguiam pingar os servidores.
Lendo este artigo, decidi tentar uma cadeia de servidor de entrada e saída. O cliente se conecta ao nó ENTRY russo (o tráfego interno russo não toca o TSPU), que encaminha o tráfego para o EXIT europeu. Os sistemas de monitoramento veem isso como uma troca de dados entre dois servidores, e não como um usuário indo diretamente para a Europa.
É por isso que a divisão ENTRY/EXIT apareceu na arquitetura, como uma resposta direta a uma técnica específica de bloqueio.
Encontrar IPs “Brancos”: Uma Loteria que Você Não Pode Ganhar
O IP do servidor ENTRY russo neste esquema deve estar na chamada “lista branca” – um conjunto de endereços IP que o TSPU permite sem modelagem. A verificação é simples: você levanta um servidor web na porta 443, abre-o do telefone na zona de listas brancas, sem VPN. Abriu – o endereço está funcionando.
Na prática, encontrei endereços de trabalho apenas em dois provedores – Yandex e VK. Em outros provedores de hospedagem russos, não consegui encontrar nenhum IP adequado.
O Yandex e o VK são empresas... Mas não há escolha.
Com o VK, toda uma história aconteceu, após a qual eu daria a esta empresa o status de “matador”:
Em algum momento – sem aviso prévio e notificações, um (de quatro) servidor falhou. Entrando no painel, vi que ele simplesmente não tinha um endereço IP (Sim, era branco e foi retirado) e não há como instalar um novo (já que o IP é emitido automaticamente com a máquina, e não comprado, não posso comprar outro e anexá-lo a esta máquina. Quem está no assunto sabe). Então, o segundo, o terceiro e o quarto foram retirados pelo mesmo esquema. O suporte respondeu no espírito: Oh, quem fez isso? Não sabemos de nada... E então eles simplesmente publicaram um anúncio para todos. Como resultado, no VK, só me restaram 2 servidores de 4, exatamente aqueles cujo IP foi comprado. Eu simplesmente comprei novos e substituí. Tive que me despedir das outras duas máquinas.
A Primeira Queda do Bot
Em algum momento, o Telegram foi bloqueado de todos os IPs russos. E o VPS no Timeweb, que antes não conhecia problemas, de repente perdeu a conexão com t.me e o bot parou de responder.
A solução rápida foi um proxy SOCKS5 – instalei, o bot subiu. Mas essa solução não poderia ser deixada por muito tempo: a velocidade das respostas do bot caiu 2-3 vezes, a confiabilidade do proxy levantou questões a longo prazo. E não havia desejo de enfrentar esse problema novamente.
A decisão foi tomada – estamos nos mudando.
Bloqueio de VPN em Provedores de Hospedagem Russos: Mudança Forçada
O próximo golpe (do qual eu já estava começando a me esquivar) foi a notícia de que os provedores de hospedagem russos começaram a receber ordens para restringir o trabalho de serviços de VPN em suas instalações – uma consequência direta do pacote de emendas “Anti-Fraude 2.0”, sobre o qual escreveram em detalhes aqui. O Ministério da Digitalização exigiu abertamente que as empresas de TI credenciadas implementassem módulos que ajudassem a bloquear servidores VPN pessoais.
Eu entendi que a decisão de transferir o backend para um servidor europeu foi tomada corretamente e, no próximo fim de semana, depois da meia-noite, peguei um tambor e comecei a dançar.
Eu lidei com isso em 2 horas e fui dormir com uma expressão satisfeita. Tecnicamente, a mudança ocorreu sem perdas, mas de manhã acordei com notificações e ligações de amigos com as palavras “Sanya, tudo se foi!!! AOAOAAOA”...
O problema acabou sendo prosaico – os registros DNS são atualizados em até 48 horas, e o Happ atualizava automaticamente a assinatura a cada hora! Parte dos usuários perdeu as assinaturas nesse período – o cliente continuou a ir para o IP antigo, que já não existia, e excluiu os servidores da assinatura. Depois de dois dias, tudo foi restaurado para todos.
Observação: desative a atualização automática de assinaturas se você seguir esse caminho))
Agentes por Toda Parte
Paralelamente aos bloqueios técnicos, estava em andamento o processo de detecção de VPNs no nível dos aplicativos.
Em março de 2026, o pesquisador runetfreedom publicou uma análise do mensageiro MAX. A engenharia reversa mostrou: o aplicativo recebe assincronamente o IP externo do usuário de várias fontes (ipify, ifconfig.me, ip.mail.ru, checkip.amazonaws.com – a lista é embaralhada a cada inicialização), verifica simultaneamente a disponibilidade do Telegram, WhatsApp, Google via ping e TCP:443, e envia tudo isso para os servidores com o campo vpn: 1 se a conexão VPN estiver ativa.
O módulo é ativado remotamente – direcionado para contas específicas. Múltiplas fontes de IP – especialmente para pegar usuários com split-tunneling, que não envolvem o tráfego russo no túnel.
Um pouco mais tarde, o Ministério da Digitalização enviou oficialmente um guia com a exigência de implementar módulos semelhantes em produtos de empresas credenciadas. Ou seja, o MAX não foi uma iniciativa do VKontakte – é um padrão regulatório de fato que se estenderá a todos os principais aplicativos russos.
Para nossa infraestrutura, isso significou o seguinte: a arquitetura com um único IP na entrada e na saída é um alvo ideal. Se o detector recebe o IP de saída e o bloqueia, o serviço cai por completo. ENTRY e EXIT separados aqui provaram ser a solução certa – o detector recebe o IP do ENTRY russo, que não emite nada.
Mais tarde, o recurso de detecção de VPN apareceu em quase todos os aplicativos russos – encontrei-o no Ozon, hh, VK, Gosuslugi. Todos os aplicativos (exceto Gosuslugi, haha) com VPN ativada se recusaram a funcionar.
No painel 3x-ui, o roteamento foi configurado – para sites e aplicativos russos por geoip e geosite, o tráfego vinha do servidor ENTRY russo. Isso funcionou, mas nem para todos e nem sempre de forma estável. Além disso, o IP, embora russo, ainda é um IP de um VPS.
Portanto, além disso, configurei uma configuração para Happ, para roteamento separado no nível do cliente por geoip e geosite, que ofereci a todos os usuários para instalar por e-mail.
Detecção de VPN por Serviços Ocidentais e WARP
Uma história separada – detecção por serviços estrangeiros. Google, OpenAI, Claude, Roblox e muitos outros bloqueiam ou desaceleram o tráfego VPN. Cada um tem suas próprias razões – anti-fraude, restrições de licença, geobloqueio. O método de detecção é predominantemente um: reputação do IP.
Os endereços de data center – e o VPS é sempre um data center – são marcados nos bancos de dados IPinfo, MaxMind e análogos. A categoria datacenter ou vpn/proxy significa automaticamente maior suspeita ou bloqueio direto.
A solução que está agora é o Cloudflare WARP nos servidores EXIT. Todo o tráfego de saída do EXIT é envolvido no túnel WARP e sai para o exterior com o IP do Cloudflare.
Cloudflare é um provedor de CDN com uma enorme rede, seus endereços não são marcados como “IP VPN”. Para o serviço-alvo, isso se parece com tráfego corporativo.
Um hop extra e alguns milissegundos de atraso são adicionados. Mas ChatGPT, Google, Claude funcionam sem captchas e bloqueios. Mesmo com o atraso, os servidores dos EUA funcionam confortavelmente.
Em vez de Conclusão
Em poucos meses de trabalho, o serviço sobreviveu: uma mudança na arquitetura devido a uma nova tática do TSPU, a perda de IPs “brancos” do provedor sem aviso prévio, uma mudança forçada dos nós russos com uma queda parcial nas assinaturas, o aparecimento de módulos de espionagem obrigatórios em aplicativos russos e uma vulnerabilidade pública nos próprios clientes VPN.
O projeto, do formato “para si mesmo”, cresceu para um grande jogo de xadrez com o RKN e outros players do mercado. Cada novo desafio só aumenta o interesse!
Esperamos que todos os jogadores sigam as regras. Embora a experiência dos últimos meses mostre que as regras aqui estão mudando bem no meio do jogo.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Como Criei um Serviço de VPN em 2026
Introdução
Tudo começou de forma simples: levantei um VPS para uso pessoal, configurei 3x-ui e implementei VLESS+Reality. Funcionava bem. Compartilhei com amigos, que compartilharam com outros. Em algum momento, percebi que estava administrando a infraestrutura para dezenas de usuários, tudo manualmente, sem qualquer automação. Em fevereiro de 2026, transformei isso em um serviço formal, com banco de dados e um bot no Telegram.
A seguir, a cronologia do que enfrentei durante o desenvolvimento, o que foi feito reativamente e o que foi preventivamente.
Arquitetura e Stack
O serviço é construído em dois backends independentes, que operam com um único banco de dados.
O primeiro é um bot do Telegram (Node.js). O usuário escreve para o bot, recebe a configuração e importa para o cliente. O lado do servidor são VPSs russos com painel 3x-ui (XRay, VLESS).
O segundo backend (também Node.js) é a base para um futuro aplicativo móvel. Atualmente, ele contém toda a lógica de assinaturas, servidores e usuários. Os planos incluem lançar um aplicativo para iOS e Android com base nisso – estou recebendo muitos comentários de que muitos usuários acham difícil entender como instalar o aplicativo por conta própria e a citação – “gostaria de apertar um botão e fazer tudo funcionar”.
Infraestrutura do servidor: 12 máquinas. 4 de entrada (ENTRY) – russas. 8 de saída (EXIT) – Europa e EUA.
Na Zona de “Listas Brancas”
O primeiro problema sério surgiu antes mesmo do lançamento oficial do serviço – enquanto eu estava testando a infraestrutura.
Alguns usuários reclamaram que a VPN não estava funcionando, enquanto outros estavam perfeitamente bem. Como descobri mais tarde (isso aconteceu apenas com redes móveis), em algumas cidades havia problemas de conexão na zona de “listas brancas”: alguns estabeleciam a conexão, mas nada carregava, outros não conseguiam pingar os servidores.
Lendo este artigo, decidi tentar uma cadeia de servidor de entrada e saída. O cliente se conecta ao nó ENTRY russo (o tráfego interno russo não toca o TSPU), que encaminha o tráfego para o EXIT europeu. Os sistemas de monitoramento veem isso como uma troca de dados entre dois servidores, e não como um usuário indo diretamente para a Europa.
É por isso que a divisão ENTRY/EXIT apareceu na arquitetura, como uma resposta direta a uma técnica específica de bloqueio.
Encontrar IPs “Brancos”: Uma Loteria que Você Não Pode Ganhar
O IP do servidor ENTRY russo neste esquema deve estar na chamada “lista branca” – um conjunto de endereços IP que o TSPU permite sem modelagem. A verificação é simples: você levanta um servidor web na porta 443, abre-o do telefone na zona de listas brancas, sem VPN. Abriu – o endereço está funcionando.
Na prática, encontrei endereços de trabalho apenas em dois provedores – Yandex e VK. Em outros provedores de hospedagem russos, não consegui encontrar nenhum IP adequado.
O Yandex e o VK são empresas... Mas não há escolha.
Com o VK, toda uma história aconteceu, após a qual eu daria a esta empresa o status de “matador”:
Em algum momento – sem aviso prévio e notificações, um (de quatro) servidor falhou. Entrando no painel, vi que ele simplesmente não tinha um endereço IP (Sim, era branco e foi retirado) e não há como instalar um novo (já que o IP é emitido automaticamente com a máquina, e não comprado, não posso comprar outro e anexá-lo a esta máquina. Quem está no assunto sabe). Então, o segundo, o terceiro e o quarto foram retirados pelo mesmo esquema. O suporte respondeu no espírito: Oh, quem fez isso? Não sabemos de nada... E então eles simplesmente publicaram um anúncio para todos. Como resultado, no VK, só me restaram 2 servidores de 4, exatamente aqueles cujo IP foi comprado. Eu simplesmente comprei novos e substituí. Tive que me despedir das outras duas máquinas.
A Primeira Queda do Bot
Em algum momento, o Telegram foi bloqueado de todos os IPs russos. E o VPS no Timeweb, que antes não conhecia problemas, de repente perdeu a conexão com t.me e o bot parou de responder.
A solução rápida foi um proxy SOCKS5 – instalei, o bot subiu. Mas essa solução não poderia ser deixada por muito tempo: a velocidade das respostas do bot caiu 2-3 vezes, a confiabilidade do proxy levantou questões a longo prazo. E não havia desejo de enfrentar esse problema novamente.
A decisão foi tomada – estamos nos mudando.
Bloqueio de VPN em Provedores de Hospedagem Russos: Mudança Forçada
O próximo golpe (do qual eu já estava começando a me esquivar) foi a notícia de que os provedores de hospedagem russos começaram a receber ordens para restringir o trabalho de serviços de VPN em suas instalações – uma consequência direta do pacote de emendas “Anti-Fraude 2.0”, sobre o qual escreveram em detalhes aqui. O Ministério da Digitalização exigiu abertamente que as empresas de TI credenciadas implementassem módulos que ajudassem a bloquear servidores VPN pessoais.
Eu entendi que a decisão de transferir o backend para um servidor europeu foi tomada corretamente e, no próximo fim de semana, depois da meia-noite, peguei um tambor e comecei a dançar.
Eu lidei com isso em 2 horas e fui dormir com uma expressão satisfeita. Tecnicamente, a mudança ocorreu sem perdas, mas de manhã acordei com notificações e ligações de amigos com as palavras “Sanya, tudo se foi!!! AOAOAAOA”...
O problema acabou sendo prosaico – os registros DNS são atualizados em até 48 horas, e o Happ atualizava automaticamente a assinatura a cada hora! Parte dos usuários perdeu as assinaturas nesse período – o cliente continuou a ir para o IP antigo, que já não existia, e excluiu os servidores da assinatura. Depois de dois dias, tudo foi restaurado para todos.
Observação: desative a atualização automática de assinaturas se você seguir esse caminho))
Agentes por Toda Parte
Paralelamente aos bloqueios técnicos, estava em andamento o processo de detecção de VPNs no nível dos aplicativos.
Em março de 2026, o pesquisador runetfreedom publicou uma análise do mensageiro MAX. A engenharia reversa mostrou: o aplicativo recebe assincronamente o IP externo do usuário de várias fontes (ipify, ifconfig.me, ip.mail.ru, checkip.amazonaws.com – a lista é embaralhada a cada inicialização), verifica simultaneamente a disponibilidade do Telegram, WhatsApp, Google via ping e TCP:443, e envia tudo isso para os servidores com o campo vpn: 1 se a conexão VPN estiver ativa.
O módulo é ativado remotamente – direcionado para contas específicas. Múltiplas fontes de IP – especialmente para pegar usuários com split-tunneling, que não envolvem o tráfego russo no túnel.
Um pouco mais tarde, o Ministério da Digitalização enviou oficialmente um guia com a exigência de implementar módulos semelhantes em produtos de empresas credenciadas. Ou seja, o MAX não foi uma iniciativa do VKontakte – é um padrão regulatório de fato que se estenderá a todos os principais aplicativos russos.
Para nossa infraestrutura, isso significou o seguinte: a arquitetura com um único IP na entrada e na saída é um alvo ideal. Se o detector recebe o IP de saída e o bloqueia, o serviço cai por completo. ENTRY e EXIT separados aqui provaram ser a solução certa – o detector recebe o IP do ENTRY russo, que não emite nada.
Mais tarde, o recurso de detecção de VPN apareceu em quase todos os aplicativos russos – encontrei-o no Ozon, hh, VK, Gosuslugi. Todos os aplicativos (exceto Gosuslugi, haha) com VPN ativada se recusaram a funcionar.
No painel 3x-ui, o roteamento foi configurado – para sites e aplicativos russos por geoip e geosite, o tráfego vinha do servidor ENTRY russo. Isso funcionou, mas nem para todos e nem sempre de forma estável. Além disso, o IP, embora russo, ainda é um IP de um VPS.
Portanto, além disso, configurei uma configuração para Happ, para roteamento separado no nível do cliente por geoip e geosite, que ofereci a todos os usuários para instalar por e-mail.
Detecção de VPN por Serviços Ocidentais e WARP
Uma história separada – detecção por serviços estrangeiros. Google, OpenAI, Claude, Roblox e muitos outros bloqueiam ou desaceleram o tráfego VPN. Cada um tem suas próprias razões – anti-fraude, restrições de licença, geobloqueio. O método de detecção é predominantemente um: reputação do IP.
Os endereços de data center – e o VPS é sempre um data center – são marcados nos bancos de dados IPinfo, MaxMind e análogos. A categoria datacenter ou vpn/proxy significa automaticamente maior suspeita ou bloqueio direto.
A solução que está agora é o Cloudflare WARP nos servidores EXIT. Todo o tráfego de saída do EXIT é envolvido no túnel WARP e sai para o exterior com o IP do Cloudflare.
Cloudflare é um provedor de CDN com uma enorme rede, seus endereços não são marcados como “IP VPN”. Para o serviço-alvo, isso se parece com tráfego corporativo.
Um hop extra e alguns milissegundos de atraso são adicionados. Mas ChatGPT, Google, Claude funcionam sem captchas e bloqueios. Mesmo com o atraso, os servidores dos EUA funcionam confortavelmente.
Em vez de Conclusão
Em poucos meses de trabalho, o serviço sobreviveu: uma mudança na arquitetura devido a uma nova tática do TSPU, a perda de IPs “brancos” do provedor sem aviso prévio, uma mudança forçada dos nós russos com uma queda parcial nas assinaturas, o aparecimento de módulos de espionagem obrigatórios em aplicativos russos e uma vulnerabilidade pública nos próprios clientes VPN.
O projeto, do formato “para si mesmo”, cresceu para um grande jogo de xadrez com o RKN e outros players do mercado. Cada novo desafio só aumenta o interesse!
Esperamos que todos os jogadores sigam as regras. Embora a experiência dos últimos meses mostre que as regras aqui estão mudando bem no meio do jogo.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
