Em 4 de agosto de 2026, dezenas de serviços de contorno de bloqueios na Rússia deixaram de funcionar quase simultaneamente. Os problemas foram confirmados pelas equipes do Paper VPN, Amnezia, VPN Generator, VPN Legend, GaMMa VPN, LTVPN, ABS e FoxyBot — no total, as falhas afetaram mais de 20 serviços de diferentes tamanhos. O Roskomnadzor não comentou oficialmente a situação, mas a imagem da falha fala por si: os serviços caíram não um a um, mas em pacotes, grupos, ligados a plataformas de hospedagem específicas.
Isso não é apenas "mais uma onda de bloqueios". O próprio objeto mudou: não são mais protocolos ou aplicativos que estão sob filtro, mas sim o espaço de endereços — endereços IP individuais e sub-redes inteiras de provedores de hospedagem, nos servidores dos quais a infraestrutura de contorno opera. Vamos analisar o que exatamente mudou, por que isso quebra VPNs de consumo de forma mais eficaz do que qualquer DPI e o que isso implica para aqueles que precisam de acesso funcional a serviços externos.
O que aconteceu em 4 de agosto: falha nas fronteiras dos provedores
Externamente, isso parecia uma falha comum: os usuários reclamavam da impossibilidade de se conectar ou de uma conexão extremamente instável. Mas uma falha não ocorre de forma sincrônica em oito equipes independentes, que não estão ligadas entre si por nada além de recursos alugados.
Publicações especializadas (Anti-Malware.ru, SecurityLab) descreveram a mecânica de forma semelhante: os endereços IP e sub-redes inteiras de grandes provedores de hospedagem foram afetados pelas restrições. Se um intervalo de endereços é filtrado, uma série de conexões cai junto — e os serviços que alugam recursos de um único fornecedor são desconectados em um minuto, embora tecnicamente não haja nada em comum entre eles.
Os comentários dos especialistas também são reveladores. O advogado Sarkis Darbinyan apontou imediatamente vários canais de detecção: detectores de VPN embutidos em aplicativos russos e a simples compra de contas premium para obter uma lista atualizada de servidores do serviço de dentro. Mikhail Klimarev falou sobre a identificação de várias dezenas de sistemas autônomos pelos quais os serviços de contorno operavam.
O segundo ponto merece ser lido novamente. Um VPN de consumo em massa deve fornecer ao cliente uma lista de servidores — caso contrário, o aplicativo não conseguirá se conectar. Isso significa que qualquer um que pagou pela assinatura obtém um mapa completo da infraestrutura do serviço. Não é uma invasão e nem uma investigação complexa, é apenas uma compra.
Dinamismo: de 197 serviços para 469 em um ano e meio
Os bloqueios por listas já ocorriam antes, mas o ritmo aumentou significativamente. De acordo com o próprio Roskomnadzor, no final de fevereiro de 2026, o acesso foi restrito a 469 serviços de VPN. Para comparação: em outubro de 2024, havia 197, em outubro de 2025 — 258. Ou seja, em quatro meses de inverno, a lista quase dobrou.
Paralelamente, a partir de dezembro de 2025, as restrições a protocolos específicos — SOCKS5, VLESS e L2TP — foram intensificadas. Uma linha separada é o Telegram: as restrições estão em vigor desde o verão de 2025 e se intensificaram em fevereiro de 2026, enquanto as reclamações sobre o carregamento de fotos e vídeos continuam a ser registradas (de acordo com o Downdetector — cerca de 500 reclamações por dia em 20 de agosto).
Um detalhe importante para aqueles que tentam resolver o problema com configurações: nas análises da onda de agosto, o principal critério de seleção foi o porta padrão. Se apenas a porta 443 estiver fechada, mudar a conexão para uma porta não padrão realmente ajuda — mas exatamente até o momento em que a seleção começar a ser feita não pelo número da porta, mas pelo tipo de resposta do servidor. Nesse caso, a mudança apenas adianta o bloqueio.
Segundo nível: limpeza de "listas brancas" e novo papel do provedor
O mais interessante na história de agosto não é o bloqueio em si, mas o que foi discutido alguns dias antes. O Ministério da Digitalização apresentou para discussão com provedores de hospedagem um mecanismo de verificação contínua de endereços IP da "lista branca" do Centro de Monitoramento e Gestão da Rede de Comunicação Geral — uma lista de exceções que inclui VPNs corporativas legais.
A lógica do esquema discutido é a seguinte:
- se durante uma semana o monitoramento detectar sinais de infraestrutura de VPN no endereço, o provedor recebe um pedido;
- o provedor tem 24 horas para confirmar a legalidade da designação dos servidores;
- se o cliente passou pela identificação mínima — apenas número de telefone ou cartão bancário — os serviços podem ser desconectados em até 30 minutos;
- se o cliente for verificado através dos "Serviços Públicos", biometria ou como pessoa jurídica, primeiro é sugerido remover a infraestrutura;
- o provedor que sistematicamente permite isso com uma verificação fraca dos clientes corre o risco de ser considerado desonesto — e, junto com isso, a limitação de sub-redes inteiras da empresa com acesso apenas a recursos da "lista branca".
Devo enfatizar: estas são propostas discutidas, e não regras em vigor — os critérios, prazos de implementação e procedimentos não foram aprovados. Mas a direção é clara: a obrigação de buscar serviços de contorno é transferida para o próprio provedor, e o mecanismo é seu próprio espaço de endereços. Desde fevereiro de 2024, apenas empresas do registro do Roskomnadzor podem fornecer hospedagem na Rússia — em julho de 2026, há 584 provedores nesse registro, e esta é uma lista pronta de responsáveis.
Por que isso quebra VPNs melhor do que DPI
A luta clássica contra o contorno de bloqueios é uma competição em mascaramento de tráfego: o DPI busca a assinatura do protocolo, os desenvolvedores a escondem sob um HTTPS comum, o DPI aprende novamente. O jogo é interminável, e a parte defensora regularmente ganha rodadas: protocolos que mascaram o tráfego como HTTPS comum, em 2026, funcionam de forma significativamente mais estável do que os padrões "nu".
O bloqueio por endereços contorna essa competição. Não importa quão bem seu tráfego esteja mascarado, se o próprio endereço de destino não está disponível. O alvo não é a assinatura, mas sim o recurso escasso — IPs limpos em uma plataforma amigável. E esse recurso nos VPNs de consumo é organizado de forma extremamente vulnerável: algumas centenas de servidores em alguns provedores, cliente público com uma lista completa de endereços, um único ponto de falha no nível do sistema autônomo.
Três níveis em que o acesso é cortado hoje
Para não confundir as causas e não tratar um problema com outro, é útil manter em mente um esquema simples. As restrições são impostas em três níveis independentes, e as medidas de proteção são diferentes em cada um deles.
- Nível do protocolo. O DPI busca a assinatura: handshake, tamanhos de pacotes característicos, comportamento do TLS. Isso é tratado com mascaramento sob um HTTPS comum — e é aqui que ocorre a eterna corrida. Desde dezembro de 2025, neste nível, há uma pressão específica sobre SOCKS5, VLESS e L2TP.
- Nível do endereço. O filtro atinge um IP, sub-rede ou um sistema autônomo inteiro. A mascaramento de tráfego aqui é inútil: o endereço de destino simplesmente não está disponível. Isso foi o que aconteceu em 4 de agosto.
- Nível do fornecedor. A responsabilidade de buscar e desconectar a infraestrutura de contorno é transferida para o provedor, e a sanção é a limitação de suas próprias sub-redes. Embora isso seja um esquema discutido, ele afeta todos os clientes da plataforma ao mesmo tempo, incluindo aqueles que não têm relação com VPNs.
O erro que mais frequentemente ocorre é tentar resolver o problema do segundo nível com ferramentas do primeiro: mudar o protocolo e a porta quando o endereço já está na lista. O sintoma é o mesmo — a conexão não é estabelecida — mas as causas são diferentes.
O que muda para aqueles que precisam de acesso a serviços externos
Aqui começa a parte prática, e vale a pena ser honesto, sem promessas de invulnerabilidade.
A superfície de bloqueio em proxies residenciais e móveis é diferente. O endereço de saída de tal proxy pertence não ao provedor de hospedagem, mas ao provedor de internet doméstico ou operador móvel — o mesmo ASN de onde saem os assinantes comuns. Bloquear uma sub-rede inteira aqui significa desconectar pessoas reais, portanto, a limpeza em massa nas fronteiras do sistema autônomo neste segmento não funciona da mesma forma que funcionou nos provedores de hospedagem em 4 de agosto. Isso também explica por que proxies móveis com um endereço CGNAT compartilhado por centenas de assinantes são mais caros do que os de datacenters: descartar tal endereço é caro para a própria plataforma.
O que isso não oferece. Proxies não eliminam o DPI: se a filtragem se conecta à assinatura do protocolo ou ao tipo de sessão TLS, o tipo de IP de saída não ajudará. Ele também não protegerá contra o bloqueio do próprio serviço de destino e contra as restrições impostas pela plataforma (captcha, exigência de login, política regional). Uma análise detalhada de como exatamente essa linha de defesa funciona está no material sobre contorno de bloqueios com DPI ativo.
O que fazer agora, se o acesso for necessário para o trabalho:
- Não mantenha tudo em um único sistema autônomo. A falha de agosto foi exatamente sobre isso: um fornecedor — um ponto de falha. O canal de reserva deve passar por um tipo de endereço completamente diferente, e não por um segundo servidor do mesmo provedor.
- Diferencie as tarefas. O acesso a um serviço externo para uma pessoa e a automação com centenas de solicitações são cenários diferentes com requisitos diferentes. Para o segundo, o tipo de endereço e a estabilidade da sessão são mais críticos do que a velocidade.
- Não considere uma porta não padrão como solução. Isso é apenas uma adiamento. Se a seleção passar a analisar a resposta do servidor, mudar para outra porta deixará de ajudar.
- Primeiro diagnóstico, depois compra. O mesmo sintoma de "nada funciona" pode ocorrer em quatro falhas diferentes, e proxies não ajudam em todas. Como distinguir em poucos minutos uma desconexão regional de um bloqueio de um serviço específico, está detalhado na instrução de diagnóstico de desconexões.
- Para o Telegram, observe o protocolo separadamente. MTProto e SOCKS5 se comportam de maneira diferente durante a filtragem, e a escolha aqui não se resume a "pegar qualquer proxy" — detalhes estão no guia honesto sobre proxies para Telegram.
Conclusão
A onda de agosto mostrou uma mudança de tática: da caça ao protocolo para o trabalho com o espaço de endereços e a transferência da busca para os provedores de hospedagem. Para VPNs de consumo em massa, isso é um golpe duro — sua infraestrutura é compacta, pública e concentrada em alguns fornecedores, e a lista de servidores é adquirida junto com a assinatura.
Para o acesso necessário no trabalho, a conclusão é simples e sem graça: a resistência agora é determinada não pela "qualidade do protocolo", mas pela diversidade do espaço de endereços e o quão caro é para a plataforma descartar seu IP de saída junto com os assinantes comuns. Se a tarefa é acesso estável a serviços externos e automação, proxies residenciais oferecem uma superfície de bloqueio fundamentalmente diferente do que um servidor em hospedagem alugada. Não é mágica, mas uma economia diferente para aquele lado.
```