Congelamento por Impressão Digital: Como o TSPU em Junho de 2026 Quebra Conexões por Comportamento, Não por Protocolo

Há seis meses, publiquei uma análise sobre "por que VLESS funciona", que acumulou 169 mil visualizações e quase mil salvamentos. Na época, afirmei com confiança: REALITY é indistinguível do HTTPS comum, por isso se mantém onde tudo o mais já falhou. Seis meses se passaram – e descobri que eu estava apenas meio certo. Em fevereiro, o TSPU passou para análise comportamental e, em junho, para o que nos chats é chamado de "congelamento por impressão digital". De repente, minhas próprias configurações – e as de milhares de outras pessoas – pararam de conectar. O aplicativo relata alegremente "conectado", mas não há tráfego. E o conselho usual de "atualize o cliente" de repente se tornou inútil. Assim, retornei para ver o que restou das minhas próprias conclusões. Esta é uma análise do lado do dispositivo cliente – um ângulo que geralmente é negligenciado. O que realmente acontece no telefone quando "tudo está verde, mas não há internet". Como funciona a nova detecção. E como medi-la por conta própria para não perder o acesso a serviços legítimos que foram acidentalmente bloqueados.

Algumas palavras sobre em quem acreditar. O tema é delicado, as fontes são poucas, e não quero fingir que tenho a especificação do sistema em mãos. Portanto, a partir de agora, marcarei honestamente onde tenho provas sólidas e onde é uma reconstrução baseada em uma única fonte. O mais importante imediatamente: o cerne de todo o novo esquema (seções 2-4) é compilado a partir de uma única fonte primária estruturada – uma postagem no Obsidian/Zapret, onde o autor analisa o comportamento através da ferramenta dpi-ch. Não é um extrato de um documento do RKN nem um consenso de pesquisadores de TSPU. Trabalhos acadêmicos (ensafi/IMC 2022, gfw.report) não descrevem tal esquema – nem o nome de código pelo qual ele circula nas discussões. Portanto, todos os detalhes sobre limites específicos – ">3 handshakes", "350–400 ms", "120/600 s" – são uma reconstrução de engenharia de uma caixa preta baseada em uma observação, não um dispositivo comprovado do sistema. Leia os números como hipóteses de trabalho.

1. O que aconteceu em junho: de assinaturas a comportamento

A mudança de junho foi preparada por vários meses, então primeiro vamos passar pelas ondas – caso contrário, não ficará claro de onde tudo cresceu.

Até 2024. O TSPU funcionava por assinaturas: padrões fixos de bytes no início do fluxo, listas SNI, listas de bloqueio de IP. OpenVPN era detectado por um handshake característico, WireGuard – pela estrutura determinística das mensagens de handshake (Handshake Initiation 148 bytes, Handshake Response 92 bytes – estas são propriedades do próprio protocolo, cito para contexto, não como parâmetro do TSPU). Barato em CPU e direto ao ponto.

Novembro – dezembro de 2025. As primeiras ondas regionais em VLESS começaram: em novembro, Tartaristão, Udmúrtia, região de Nizhny Novgorod; em dezembro, chegou à região de Sverdlovsk. Na mesma época, o TSPU recebeu uma atualização e começou a usar sinais indiretos em vez de assinaturas diretas – SOCKS5, VLESS, L2TP entraram na zona de detecção ativa [fato, digirpt.com, multihop.ru].

17 de fevereiro de 2026. Bloqueio em massa do par VLESS+Reality sobre TCP puro em operadoras fixas (Dom.ru, Skynet, Rostelecom). O padrão é característico: os primeiros ~16 KB passam normalmente, depois – congelamento (esta é uma observação de fevereiro do Habr 1000694; uma medição separada e posterior do net4people #490 dá um limite de ~15–20 KB / ~25 pacotes – este é um evento diferente e uma medição diferente, veja a seção 5, não confunda). SSH pela porta 22 funciona, VLESS na 443 – não. No mesmo dispositivo, o LTE móvel (Beeline, MTS) ainda funciona [fato, Habr 1000694, digirpt.com]. Uma ressalva importante dos comentários no Habr: um usuário registrou a falha completa do VLESS apenas a partir de 18 de março – ou seja, 17 de fevereiro foi o início da onda, não um interruptor global único.

21–22 de maio de 2026. Primeiros testes do novo módulo comportamental. Nas discussões, ele circula sob o apelido "Siberian", em referência a uma postagem do pesquisador P. Osetrov. Enfatizo separadamente: tanto o nome quanto a atribuição e os parâmetros do esquema – vêm de uma única fonte (Zapret/Obsidian). Outros documentos descrevem o mesmo efeito, mas o módulo não é chamado assim e o autor não é mencionado. Janelas de sondagem – 21:00–00:00 e 11:00–12:00 do dia seguinte, geografia limitada. O campo de testes foram Moscou e a Sibéria [uma fonte sobre o esquema; fato das janelas de teste – mentoday.ru]. A principal diferença do esquema é que ele não é acionado pelo conteúdo dos pacotes, mas pela interseção de vários sinais comportamentais simultaneamente.

25 de maio de 2026. Implantação na Sibéria e em Moscou. Região de Novosibirsk – 13% de reclamações, Tomsk e Kemerovo – 9% cada, Omsk – 6%, Irkutsk – 5%. VLESS, Xray, MTProto, WireGuard, gRPC foram afetados. SSH não foi tocado [fato, mentoday.ru, Techora].

5 de junho de 2026. A terceira e maior onda. Por volta das 07:00 MSK (no Extremo Oriente, observadores já registram a partir das 00:00 MSK) tudo falhou simultaneamente: falha em massa de sites em Beget, TimeWeb, Selectel, SpaceWeb, AdminVPS, Reg.ru – milhares de sites parcialmente indisponíveis, administradores de sistemas perdem SSH/RDP para seus servidores; bloqueio de proxies MTProto do Telegram (na Beeline e MegaFon, a conexão foi restaurada por 1-2 horas, depois falhou em 20-30 minutos); queda no tráfego de serviços em nuvem. O caso da Delta Chat é particularmente revelador: o TSPU bloqueou conexões TLS com a impressão digital JA3 da biblioteca Rust ring e quebrou o e-mail em Beget e Timeweb. Em 6 de junho, os desenvolvedores lançaram um PR, substituindo ring por aws-lc-rs, e em 7 de junho a Timeweb admitiu o problema [fato, eByeBots, allslava.com, techora.ru].

2 de junho de 2026 – e imediatamente um fator de infraestrutura separado, não relacionado ao TSPU: o data center europeu nLighten desenergizou os racks sem aviso. Mais sobre isso na seção 7, e enfatizo imediatamente: misturá-lo com "congelamento por impressão digital" é um erro metodológico.

Por que "atualize o cliente" parou de ajudar. Anteriormente, com filtragem por assinatura, a substituição da impressão digital JA3 via uTLS resolvia tudo: trocou a assinatura – passou. Agora, a assinatura é apenas um de vários sinais. Pior ainda: a troca de impressão digital, quando o congelamento já ocorreu, de acordo com a única fonte, não apenas não ajuda, mas aumenta a penalidade de 120 para 600 segundos [uma fonte, Habr 1044396]. O sistema parou de olhar para dentro do pacote. Agora ele conta de fora.

1. Sinais de decisão do TSPU durante o TLS handshake

Este é o cerne de toda a análise – e aqui a ressalva do cabeçalho funciona plenamente. Tudo o que está abaixo é uma reconstrução de uma única fonte (Habr 1044396 com base em observações via dpi-ch), não uma especificação oficial. De acordo com esta reconstrução, o congelamento ocorre apenas quando várias condições são atendidas simultaneamente – um AND lógico. E isso é fundamental: cada sinal isoladamente ocorre com tráfego legítimo, e é precisamente a sua coincidência que é supostamente o alvo. Sinal 1: AS/sub-rede do servidor

O TSPU olha para o IP de destino da conexão TCP que você inicia e o compara com uma base de dados de CIDRs/ASNs "suspeitos".

Data centers estrangeiros (Hetzner, DigitalOcean, OVH) – há muito tempo; vários provedores de nuvem russos – desde o final de maio / início de junho de 2026. É daqui que vem o dano colateral para projetos russos: servidores proxy reais também são hospedados lá, o TSPU não os diferencia, e todo o tráfego para a sub-rede passa por verificação comportamental.

Mas com os nomes – cuidado. Nas discussões, Selectel, Yandex.Cloud, Cloud.ru são adicionados à lista "suspeita". Eu trato esses nomes com frieza: "coincidência de várias fontes" aqui são canais de Telegram que se copiam (digirpt, multihop, mentoday), e não medições independentes de tcpdump. Yandex.Cloud é um provedor sistemicamente importante, por trás do qual está uma parcela considerável da Runet; sua inclusão na lista de congelamento comportamental é uma declaração extraordinária, e a prova para isso precisa ser de nível de dump de pacotes, que simplesmente não está disponível publicamente. Resultado: o dano colateral para nuvens russas é visível [fato pelo sintoma, eByeBots], mas a composição nominal específica da lista é [uma fonte / não verificada]. Eu mesmo executei uma medição de 12 horas de uma máquina RU (Rostelecom, AS34168, 72 ciclos, 14 de junho) para GitHub/PyPI/Fastly: nenhum congelamento, mediana do handshake TLS ~135 ms, disponibilidade 99-100%. Isso está em plena conformidade com a seletividade da lista – em um operador, nessas horas, tudo passou limpo. Portanto, a composição nominal de ASNs "suspeitos" requer ainda mais um dump, não uma cópia.

Este critério sozinho não causa congelamento – é necessária uma combinação. Grandes CDNs (Cloudflare, Akamai, Google) não entram inteiramente na lista "suspeita": caso contrário, metade da Runet legítima cairia [análise]. Daqui, aliás, vem a resiliência da indireção CDN como técnica arquitetônica. Bloqueios de sub-redes Cloudflare ocorreram neste período, mas este é um vetor separado (a história com ECH remonta a novembro de 2024), e não o esquema descrito.

O que eu definitivamente não sei: como a própria base de dados é organizada e como ela é atualizada – centralmente do CMU SSOP ou localmente no hardware do operador. De acordo com a arquitetura do TSPU (Habr 1027012), o gerenciamento é centralizado e a implementação é distribuída pelos nós DPI do operador – isso explica por que tudo funciona de maneira diferente em diferentes regiões.

Sinal 2: Impressão digital TLS do cliente (JA3/JA4)

A primeira mensagem não criptografada em uma conexão TLS é o ClientHello – é nele que ocorre o fingerprint. JA3 (padrão histórico): hash MD5 da concatenação de cinco campos do ClientHello – SSLVersion, Cipher, SSLExtension, EllipticCurve, EllipticCurvePointFormat (como são chamados na especificação original da Salesforce). Aqui a precisão sobre GREASE é importante: nos valores canônicos de JA3 GREASE (0x?A?A) entravam no hash e eram fonte de instabilidade; sua exclusão apareceu mais tarde – em JA3N/JA4, e não em JA3 "em geral". Uma dor separada do JA3: a partir do Chrome 110 e Firefox 114, os navegadores randomizam a ordem das extensões TLS, e a mesma versão do Chrome produz diferentes JA3 a cada conexão [fato]. Para identificar uma versão específica do navegador, o JA3 tornou-se inútil, mas para uma detecção grosseira de "isso não é um navegador" ainda é útil: um stack TLS não padrão é visível independentemente da randomização. JA4 (FoxIO, 2023): classifica as suites de cipher e extensões antes de hashear – assim elimina a randomização da ordem; GREASE é excluído de acordo com a especificação. O formato inclui versão TLS, ALPN, número de extensões. Vamos analisar o exemplo t13d1516h2_8daaf6152771_b0da82dd1658: t – transporte TCP, 13 – TLS 1.3, d – SNI presente (domínio), 15 – 15 suites de cipher, 16 – 16 extensões, h2 – ALPN h2; em seguida, dois hashes SHA256 truncados (das suites de cipher classificadas e das extensões+algoritmos de assinatura). Mas os algoritmos de assinatura são intencionalmente NÃO classificados – sua ordem carrega informações sobre a biblioteca [fato, especificação JA4 da FoxIO].

Por que a impressão digital que imita Chrome/Safari/iOS se tornou "suspeita". Os próprios navegadores são obviamente legítimos. O problema é que a impressão digital falsificada não corresponde ao comportamento e ao contexto:

A biblioteca padrão Go crypto/tls tem um perfil estático previsível: sem GREASE, ordem fixa de extensões, ausência de ALPS/brotli/ECH. Isso é drasticamente diferente de um navegador. Operadores de proxy mascararam isso massivamente via uTLS com um modelo Chrome – e a impressão digital Chrome se tornou a mais frequente entre os clientes em sub-redes "suspeitas". O TSPU, de acordo com a reconstrução, avalia o rótulo contextualmente: perfil Chrome na Hetzner – suspeito; Chrome no google.com – normal [uma fonte sobre o mecanismo, análise sobre a interpretação].

A imitação uTLS de uma versão desatualizada (digamos, Chrome 105 quando o atual é 124) resulta em uma incompatibilidade na ordem das suites de cipher/extensão e no padrão GREASE do Chrome real [Habr 1009542].

Um navegador real, após o handshake, gera padrões específicos – requisições de API, timings, ALPN. E o túnel é um fluxo bidirecional contínuo sem pausas características e mudanças no tamanho dos pacotes.

Separadamente sobre post-quantum key_share (X25519MLKEM768). Às vezes, sua ausência é proposta como um marcador de "não-navegador". Este é um discriminador fraco, e eu o apresento precisamente assim: PQ key_share em 2026 não é enviado por uma grande parte do tráfego totalmente legítimo – Androids antigos, navegadores não-Chromium, stacks TLS móveis e corporativos. Um detector "sem PQ → proxy" emitiria garantidamente um monte de falsos positivos – exatamente o dano colateral do qual a seção 3 reclama. Portanto, a ausência de PQ é, na melhor das hipóteses, um complemento fraco ao contexto, e não um sinal independente [análise].

Impressões digitais "leais", de acordo com observações de usuários em junho de 2026: Firefox, Edge, stack Android (Conscrypt/BoringSSL), 360 Browser, QQ Browser – eles são menos comuns em configurações de proxy. Este é um efeito observado; mas o próprio mecanismo de whitelist e a lista específica – é uma hipótese da prática, não uma lista documentada pelo RKN. Não leia isso como "lista branca estabelecida".

E mais sobre a precisão das formulações: "Chrome/Safari são suspeitos" significa uma impressão digital específica que imita esses navegadores via uTLS de uma sub-rede "suspeita", e não os próprios navegadores em uma sessão de usuário ativa.

Sinal 3: Frequência de handshakes paralelos

Limite reconstruído: mais de 3 conexões TLS paralelas para o mesmo SNI com baixa latência entre elas → congelamento de ~120 s. E aqui o próprio fato se contradiz: em uma fonte, a janela de tempo é descrita como um rajada de < ~350–400 ms, em outra – como uma janela de 60 segundos. Registro ambas as variantes e não escolho entre elas [uma fonte Zapret/Obsidian + Habr 1044396; observação de engenharia, não uma constante oficial].

Por que este é um padrão específico de proxy. Clientes VLESS (Happ, v2rayTun, Hiddify) por padrão usam multiplexação (XMUX/Mux) ou pooling de conexões – no início do túnel, eles abrem várias conexões TCP/TLS paralelas para reduzir a latência. Um navegador também abre conexões paralelas, mas para hosts diferentes (sub-recursos de uma página), e não 4–8 handshakes simultâneos para o mesmo SNI/IP em sequência. Um usuário comum, ao abrir um site condicional, faz 1-2 conexões para um IP CDN, e não 6 para um nó.

O que acontece quando todas as condições são atendidas (de acordo com a reconstrução):

O tráfego para o nó é congelado por ~120 segundos. Isso não é RST nem FIN, mas sim perda de pacotes / blackholing. O cliente envia pacotes, a resposta é descartada no lado do TSPU. Um mecanismo semelhante em essência é documentado para o GFW (China), mas não para o TSPU: após o gatilho, o GFW descarta todos os pacotes com o mesmo (IP do cliente, IP do servidor, porta do servidor) por 120–180 segundos [fato, GFW USENIX 2023]. Enfatizo separadamente: o número "120–180 s" é chinês, para GFW; a proximidade do russo ~120 s é uma coincidência observada de uma fonte, e não a transferência da constante chinesa para o TSPU como comprovada.

Isso parece "internet ruim", e não um bloqueio explícito: o RTT aumenta, o throughput diminui. Uma tentativa de trocar rapidamente a impressão digital sob carga, de acordo com a reconstrução, adiciona um ban estendido de 600 segundos para todos os TLS para este nó – independentemente da impressão digital e do SNI [uma fonte].

1. Dano colateral: por que a Runet legítima caiu

O filtro comportamental, ao contrário do baseado em assinatura, não sabe o que está sendo transmitido e reage a uma combinação de sinais. E cada um desses sinais isoladamente ocorre com tráfego legítimo:

Servidor em um ASN "suspeito". Se um data center russo caiu na lista (veja a ressalva no Sinal 1), todo o tráfego para ele passa por verificação comportamental. Handshakes paralelos. Um site pesado em Next.js/React, ao ser carregado pela primeira vez, abre dezenas de conexões TLS paralelas. E endpoints legados em HTTP/1.1 ainda abrem um TCP para cada requisição. Impressão digital do cliente. Chrome é o navegador mais popular, e seu perfil é exatamente o que os proxies imitavam massivamente. E então um usuário do Chrome abre um site corporativo legítimo que reside em uma nuvem de um intervalo "suspeito", as condições coincidem – e por 120 segundos ocorre um congelamento. O site "trava" ou fica totalmente indisponível [análise, consistente com observações de eByeBots].

Sobre aplicativos bancários, é preciso honestidade, não pânico. A tese comum "bancos disparam porque o perfil é semelhante ao Go via OkHttp" é tecnicamente incorreta: OkHttp é um cliente Java/Kotlin no Android, ele usa Conscrypt/BoringSSL, e sua impressão digital não é "semelhante ao Go", tem seu próprio perfil. E a enumeração de palavras assustadoras (certificate pinning, QUIC 0-RTT, HTTP/2 prefetch, connection prewarming) sem um único JA3 específico ou medição – é especulação, não análise. O que pode ser dito com base: aplicativos bancários hospedam APIs em nuvens, abrem agressivamente várias conexões ao iniciar uma sessão e usam stacks TLS não padrão (não de navegador) – ou seja, teoricamente podem acionar os mesmos sinais. Mas sem medições específicas, isso é uma hipótese, não um fato estabelecido [hipótese, sem medições].

Mas o caso da Delta Chat (seção 1) – pelo contrário, uma ilustração documentada: a impressão digital TLS da biblioteca Rust ring coincidiu com a "não padrão", e o e-mail falhou, embora não houvesse proxy nenhum ali.

A diferença é fundamental. Com a abordagem baseada em assinatura, um falso positivo é descartado por um padrão de bytes exato. Com a abordagem comportamental, a exclusão deve ser feita com base no comportamento, e a regra estática ">3 TLS paralelos para um SNI" não tem contexto – ela não distingue um proxy de um navegador legítimo. Reduzir falsos positivos sem perder a sensibilidade aos alvos reais é uma tarefa difícil. Mas para o proprietário de um site legítimo, a solução é simples: ativar HTTP/2 e consolidar todo o tráfego em uma única conexão TLS multiplexada [Habr 1045684].

1. Visão do dispositivo: o que acontece no telefone durante o "congelamento"

Aqui está o tão negligenciado ângulo do cliente. O usuário vê o status "verde" do cliente – o servidor está acessível, o handshake TCP foi concluído – mas os dados não fluem. Porque o congelamento (de acordo com a reconstrução) ocorre após a conclusão do handshake TCP – no momento do handshake TLS ou logo depois.

Se detalharmos os passos:

TCP SYN → SYN-ACK → ACK – passa. O cliente considera a conexão estabelecida (TSPU é stateful e in-path [fato, TSPU IMC 2022, ensa.fi], o nível TCP é ignorado).

O cliente envia ClientHello (PSH+ACK) – o pacote passa, o TSPU registra a impressão digital e o contador de conexões paralelas.

O servidor responde com ServerHello + Certificate – a resposta chega.

O cliente envia Finished (ChangeCipherSpec + Finished) – e aqui, ou imediatamente depois, começa o descarte. O cliente espera por Application Data. O servidor envia – os pacotes são descartados no TSPU.

A janela deslizante enche, o remetente fica esperando por um Window Update, que não virá. Keepalives são enviados sem resposta no nível de dados.

Após ~120 s, o stack TCP causa um timeout (ou esgota o limite de retransmissão). O timeout do handshake TLS em stacks móveis é de 10–30 s; o read() pós-handshake fica pendente por mais tempo.

O cliente reconecta – e se a impressão digital e o contador forem os mesmos, o ciclo se repete.

Nos logs do cliente (Xray/sing-box) isso parece um ciclo sem erro claro: [INFO] connecting to server:443 [INFO] TLS handshake started [ERROR] read tcp: i/o timeout (after ~30s) [INFO] reconnecting... [INFO] TLS handshake started [ERROR] read tcp: i/o timeout (after ~30s)

Possíveis variantes: failed to read client hello no lado do servidor, connection reset by peer se o TSPU injetar ativamente RST, ou simplesmente um timeout sem erro explícito em caso de perda pura de pacotes. Não há connection refused, nem ICMP unreachable – e o cliente não pode distinguir isso de um canal realmente ruim em princípio. Rerretentativas apenas pioram. Uma lógica agressiva de retentativa gera novos handshakes paralelos, o contador novamente ultrapassa o limite dentro da janela, um novo ciclo começa. O cliente entra em uma "retry storm" e prolonga seu próprio congelamento, e a troca de impressão digital neste momento, de acordo com a reconstrução, adiciona uma penalidade de 600 segundos. O estado de bloqueio está vinculado a (IP de origem, SNI de destino), de modo que uma nova conexão do mesmo IP para o mesmo SNI cai instantaneamente sob o mesmo bloqueio.

E o SSH funciona (porta 22 ou não padrão): impressão digital diferente (handshake SSH), porta diferente, nenhuma imitação de navegador, nenhum rajada de handshakes paralelos para o mesmo SNI.

1. Metodologia de medição de congelamento reproduzível

Objetivo – registrar o fato de uma pausa de ~120 s e o tipo de bloqueio. Esta é uma metodologia de observação do comportamento da rede, e não de mascaramento de tráfego.

O que será necessário: Wireshark 4.4+ / tcpdump, tshark para CLI, curl com verbose TLS, máquina em rede russa (ou VPS em data center russo). Opcionalmente – dpi-ch (mencionado em Habr 1044396) e curl-impersonate para reproduzir impressões digitais de navegador.

Passo 1. Tempo de handshake de linha de base. curl --connect-timeout 35 --max-time 35 -o /dev/null -s
-w "connect:%{time_connect} tlshs:%{time_appconnect} total:%{time_total}\n"
https://TARGET_IP:443/ Normalmente, time_appconnect (até a conclusão do TLS) é de 50–200 ms. Em caso de congelamento no meio do handshake, ele atingirá o --connect-timeout.

Passo 2. Captura no Wireshark. Filtro: tcp.port == 443 && ip.dst == TARGET_IP Inicie uma rajada de 5 conexões paralelas (imitando um navegador com abas): for i in {1..5}; do curl -sk --connect-timeout 5 https://TARGET:443/ & done; wait No dump, você verá: SYN → SYN-ACK (TCP passa), ClientHello → silêncio (sem ServerHello), após ~30 s RST ou timeout sem RST.

Passo 3. Identificação da pausa. Statistics → TCP Stream Graphs → Time/Sequence: em caso de congelamento – uma linha horizontal (sem novas seq) com duração de ~120 s, seguida por retransmissões. Filtro de pausas anômalas: tcp.time_delta > 5 && tcp.port == 443 Duração da penalidade = delta entre o início do congelamento e o momento em que o próximo curl único retornará time_appconnect ao normal. E não se baseie exatamente em 120 s com antecedência – meça; é esse número no fato que se baseia em uma fonte, e sua própria medição é mais valiosa do que a dele.

Passo 4. Verificação do limite de volume. net4people/bbs #490 registra freeze após ~25 pacotes / ~15–20 KB de payload (esta é uma medição separada, diferente dos ~16 KB de fevereiro do Habr – não os considere o mesmo limite). Statistics → Conversations → TCP → fluxo desejado → Bytes/Packets A→B / B→A. Compare em qual payload total o freeze ocorre em seu caso.

Passo 5. Tipo de bloqueio. Observação no Wireshark Interpretação SYN sem SYN-ACK Bloqueio de IP SYN-ACK presente, ClientHello enviado, ServerHello ausente Congelamento no meio do handshake (TSPU) Handshake concluído, RST após ~N KB Limite de contagem de pacotes / volume Tudo passa, mas com atraso em cada pacote Throttling (degradação, não bloqueio) Se o RST estiver presente, mas o TTL for diferente do do servidor – este é um RST injetado por um nó intermediário (ele não define o TTL com base na contagem de saltos do servidor real). Se não houver RST, apenas silêncio – blackholing.

Passo 6. Sensibilidade à impressão digital e paralelismo. Compare time_appconnect com diferentes ClientHello (curl-impersonate com perfil Chrome/Firefox) para o mesmo servidor na mesma sub-rede. Paralelismo: tls.handshake.type == 1 – se com 4+ conexões em uma janela curta todas congelarem, e uma única passar, a hipótese sobre o limite de paralelismo recebe confirmação local.

1. Diferença comportamental dos transportes

Por que VLESS+REALITY-over-TCP foi o alvo, enquanto xHTTP/gRPC/Hysteria2 "ainda" passam. E a palavra-chave aqui é "ainda": em 5 de junho de 2026, xHTTP e gRPC já estavam sujeitos a bloqueios parciais na Sibéria [Techora]. A estabilidade aqui é relativa, não absoluta.

REALITY: qual era a força e onde estava a rachadura REALITY elimina a fraqueza clássica do proxy TLS – certificados fictícios. O servidor não termina o TLS por conta própria: ele faz proxy do ClientHello para um upstream real (por exemplo, microsoft.com), recebe o ServerHello e o certificado reais, e insere um "farol" criptográfico baseado em chaves X25519 no fluxo. Um cliente autorizado vê o farol e desdobra o túnel; um probe não autorizado recebe o site upstream real – certificado autêntico, comportamento legítimo [fato, XTLS/Xray DeepWiki]. É isso que fecha o active probing. Mas da análise comportamental externa – não protege de forma alguma.

TLS-in-TLS: problema fundamental O estudo USENIX Security 2024 (Xue, Kallitsis, Houmansadr, Ensafi) "Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes" mostrou o seguinte: quando um aplicativo dentro de um túnel estabelece sua própria conexão TLS, um burst característico correspondente ao ClientHello encapsulado aparece no fluxo criptografado externo – pelo tamanho do primeiro burst, padrão temporal e número de round-trips até o início do fluxo de dados. Precisão declarada – >70% TPR em Shadowsocks, VMess, VLESS, Trojan, obfs4, REALITY em configurações padrão; o método é implantado em ISPs de médio porte com mais de 1 milhão de usuários [fato]. E aqui há duas ressalvas importantes. Primeira: TPR sem FPR é metade da métrica. ">70% true positive" por si só não diz nada, pois não indica a que custo de falsos positivos é alcançado. Para o artigo, cuja segunda metade é sobre falsos positivos, isso é crítico: sem FPR/precisão, o número não é uma sentença para o transporte, mas apenas uma estimativa superior de detectabilidade com um limite desconhecido de falsos. Segunda: testado em um ambiente ISP, não em TSPU; a implementação russa pode ter limites diferentes. xtls-rprx-vision combate parcialmente isso: ao detectar TLS 1.3 dentro do túnel, ele muda para splice (transmissão direta sem encapsulamento duplo) e adiciona padding às mensagens de handshake. Isso reduz a detectabilidade via TLS-in-TLS, mas não a elimina com análise de timing passiva [análise baseada em USENIX 2024].

Perfis comportamentais de transportes VLESS+REALITY+TCP (Vision) – sob ataque: uma conexão TCP = um fluxo lógico (sem mux); várias abas = vários TCP+TLS para o mesmo SNI/IP – gatilho direto do Sinal 3; fluxo bidirecional quase simétrico (túnel 1:2–1:3 contra web real 1:10–1:50 [FOCI 2024]); ausência de pausas idle – fluxo contínuo sob carga; uniforme