UDP sobre SOCKS5: seis testes, um perfil, um endereço IP
Sophia Grote
Support specialist, Octo Browser
O Octo Browser suporta UDP sobre SOCKS5, o que significa que WebRTC, QUIC, HTTP/3 e WebTransport passam pelo proxy em vez de ignorá-lo. Queríamos ver se esse é realmente o caso.
É importante entender exatamente o que está sendo testado. A afirmação “o UDP funciona” é fraca demais: a verdadeira questão é se o tráfego UDP vem do mesmo endereço que o tráfego TCP. Existem duas maneiras pelas quais isso pode falhar, e ambas resultam em desanonimização:
O tráfego UDP ignora o proxy e é roteado diretamente do dispositivo do usuário. O site então vê tanto o endereço do proxy (via TCP) quanto o endereço real do usuário (via STUN ou QUIC). Este é o pior cenário: o usuário pensa que está protegido, mas na realidade está mais exposto do que estaria sem nenhum proxy.
O tráfego UDP é totalmente bloqueado. Não há vazamentos, mas um navegador sem WebRTC e QUIC é anômalo por si só, e sistemas antifraude podem detectá-lo.
O Octo não faz nenhum dos dois. Todos os seis testes abaixo mostram o mesmo endereço de saída para TCP e UDP.
Índice
Mantenha o anonimato on-line com Octo Browser. Sua verdadeira impressão digital não pode ser rastreada.
Gostaria de experimentar o Octo Browser com desconto?
Use o código promocional OCTOBLOG e ganhe 30% de desconto em qualquer assinatura. Esta oferta é válida somente para novos usuários.
Configuração do teste
Navegador: Octo Browser 3.1.3 (Chromium 152).
Perfil: Quick honorable-bar · ID 8dd7332…
Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.
Endereço de saída: 68.59.118.110 · EUA · Comcast · Residencial.
Data e hora: 10 de setembro de 2026, 12:04–12:11.
Como ler as capturas de tela
Todas as seis capturas de tela são de uma única sessão contínua, não de seis execuções separadas. Você pode notar isso por meio de três detalhes que valem a pena destacar antes de analisar os testes propriamente ditos:
As mesmas informações de perfil aparecem no topo de cada captura de tela: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225 e uma tag UDP mostrando 68.59.118.110. O Octo exibe o endereço de saída UDP separadamente — esse é o endereço que deve aparecer em todos os testes abaixo.
As guias não foram fechadas. Há uma guia na primeira captura de tela e seis na última, com os testes anteriores visíveis na barra de guias.
O relógio da bandeja do sistema avança continuamente: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
Não houve reconfiguração do perfil entre os testes.
Etapa 1. Uma chamada através do proxy. Twilio Network Test
10 de setembro, 12:04. Uma guia — a sessão acabou de começar.
A ferramenta de diagnóstico oficial da Twilio, um dos principais provedores de comunicações de voz e vídeo. Os desenvolvedores a usam para verificar se a rede de um cliente suporta chamadas baseadas em navegador. Ela não procura por vazamentos e não sabe nada sobre navegadores antidetecção — ela simplesmente realiza uma chamada real.
Todas as verificações foram aprovadas, incluindo TURN UDP Connectivity, o que significa literalmente que os pacotes UDP do navegador chegaram aos servidores da Twilio e retornaram. O teste fez então duas chamadas reais usando codecs diferentes, PCMU e Opus: seus identificadores, zero perda de pacotes e as classificações finais de qualidade — Great e Good — estão visíveis no log à direita.
As observações para as verificações de TCP e TLS também merecem leitura. A Twilio declara ali que o Twilio Voice não funciona de modo algum via TCP. Em outras palavras, ambas as chamadas bem-sucedidas foram feitas via UDP — não havia outra opção.
Conclusão: duas chamadas de voz ao vivo passaram pelo proxy SOCKS5 com zero perda de pacotes.
Etapa 2: o QUIC funciona e o endereço pertence ao proxy. BrowserLeaks
10 de setembro, 12:04. Agora há duas guias — o Twilio ainda está aberto à esquerda.
Um teste público de QUIC do BrowserLeaks. Ele responde a duas perguntas distintas de uma só vez, e precisamos de ambas: se o navegador oferece suporte a QUIC — ou seja, se o UDP funciona — e por qual endereço o servidor nos vê através do QUIC — ou seja, para onde o tráfego UDP está indo.
A Etapa 1 já mostrou que o UDP funciona, mas aquele era um tipo diferente de UDP. O Twilio estava testando o WebRTC — UDP para chamadas. QUIC é UDP para o tráfego comum da web. O HTTP/3 roda sobre ele, e o Google e o YouTube o utilizam para se comunicar com os navegadores. As tecnologias são diferentes, e o suporte a uma não implica suporte à outra.
Há dois resultados na captura de tela: QUIC Connection: True, o que significa que uma conexão via UDP foi estabelecida, e IP Address: 68.59.118.110, que é o mesmo endereço que o Octo exibe na barra de perfil como o endereço de saída UDP.
Conclusão: a conexão QUIC foi estabelecida, e o servidor a viu partindo do endereço do proxy.
Etapa 3: Quatro canais, um endereço. WebRTC Detection Check
10 de setembro, 12:05. Terceira guia, com os dois testes anteriores ainda abertos à esquerda.
As duas primeiras etapas mostraram que o UDP passa e que o endereço está correto através do QUIC. Este teste compara endereços em todos os canais simultaneamente e verifica de forma separada se o navegador está simulando o WebRTC em vez de executá-lo de fato.
Há quatro linhas na seção IP Sources, representando quatro formas distintas de descobrir nosso endereço: por meio de uma solicitação HTTP comum (TCP), através de um servidor STUN (UDP), através de uma retransmissão TURN via UDP e através da mesma retransmissão TURN via TCP. Todas as quatro linhas exibem 68.59.118.110, nosso endereço de proxy. Em outras palavras, o endereço UDP corresponde ao endereço TCP.
Abaixo disso está a seção Detection Flags, com sete verificações distintas para detecção de spoofing no navegador. Todas as sete retornam NO:
WebRTC Blocked: o WebRTC não está desativado; ele funciona.
UDP/TCP Mismatch: não há divergência entre os endereços UDP e TCP.
Candidates Spoofed: os candidatos ICE que o navegador apresenta ao seu par não sofreram spoofing.
TURN UDP Blocked e TURN TCP Blocked: o tráfego de retransmissão funciona em ambas as direções.
Relay Spoofed: o relay é genuíno.
A combinação é o que importa. A primeira sinalização mostra que o WebRTC está funcionando; as outras seis mostram que nada está sendo forjado no processo. Você não pode ocultar o problema simplesmente desativando o WebRTC aqui: isso apareceria imediatamente na primeiríssima linha.
Conclusão: quatro canais independentes — HTTP, STUN, TURN UDP e TURN TCP — retornam o mesmo endereço. Nenhuma das sete verificações de bloqueio ou spoofing foi acionada.
Etapa 4: 3.000 solicitações via HTTP/3. NGINX QUIC Sandbox
10 de setembro, 12:07. Quarta guia.
Um ambiente de teste dos próprios desenvolvedores do nginx. Ele envia um lote de solicitações e detalha o resultado em três contadores: quantas foram via QUIC, quantas foram via HTTP comum e quantas falharam totalmente.
A Etapa 2 mostrou uma única conexão QUIC. Aqui há três mil solicitações consecutivas — isso já não é mais um teste sobre o QUIC ser suportado, mas sobre o canal aguentar uma carga sustentada.
Resultado: Total requests 3000, Success with QUIC 3000, Success with HTTP 0, Failed requests 0. O progresso é 3000/3000, e a visualização abaixo dele é inteiramente verde. O verde representa o QUIC, e não há células de nenhuma outra cor.
O contador Success with HTTP também é digno de nota. Ele serve especificamente para solicitações que não puderam ser enviadas via QUIC e recorreram ao fallback para HTTP regular. Ele mostra zero.
Conclusão: 3.000 de 3.000 solicitações foram via QUIC. Não houve fallback para HTTP regular e nenhuma solicitação falhou.
Etapa 5: O WebTransport mostra o mesmo endereço. wtcheck.top
10 de setembro, 12:10. Quinta guia.
O WebTransport é outra maneira baseada no navegador de trocar dados via QUIC, ou seja, via UDP. A página faz duas solicitações e exibe os resultados lado a lado: o endereço da solicitação TCP regular e o endereço da conexão WebTransport.
Esta é a terceira forma diferente de testar o tráfego UDP: a Etapa 1 usou WebRTC; as Etapas 2 e 4 usaram QUIC e HTTP/3; aqui analisamos o WebTransport. Cada teste adicional reduz o espaço para a objeção: “tudo bem, este protocolo em particular funciona, mas e quanto aos outros?”
Ambos os campos mostram 68.59.118.110. Não há necessidade de comparar nada entre capturas de tela, já que os dois valores são exibidos na mesma página.
Conclusão: a conexão WebTransport veio do mesmo endereço da solicitação TCP comum da mesma página.
Etapa 6: O DNS é resolvido no lado do proxy. BrowserLeaks
10 de setembro, 12:11. Sexta guia, com todos os testes anteriores ainda abertos à esquerda.
O DNS é um canal separado de todo o tráfego discutido acima. Um proxy pode estar configurado perfeitamente, enquanto o navegador ainda pode perguntar ao resolvedor do provedor local: “Qual é o endereço do site X?” Isso traz duas consequências: o provedor pode ver o histórico de navegação e o site pode comparar a localização geográfica do resolvedor com a do endereço IP e identificar uma discrepância.
O teste verifica quais servidores DNS participaram da resolução. Na captura de tela, é possível ver o seguinte: endereço 68.59.118.110, provedor Comcast e o resultado Found 77 Servers, 1 ISP. Na parte visível da lista, os resolvedores estão na faixa 69.241.83.x, e cada um tem a mesma Comcast listada como seu ISP.
O dado fundamental é 1 ISP. Cada um dos resolvedores pertence ao mesmo provedor do endereço de saída do proxy. Nenhuma solicitação foi direcionada a um resolvedor pertencente a um provedor diferente.
Conclusão: todos os 77 servidores DNS pertencem ao provedor do nó de saída. A resolução de DNS ocorre no lado do proxy; o resolvedor local não é envolvido.
Como reproduzir o teste você mesmo
Crie um perfil do Octo e conecte seu proxy SOCKS5 com suporte a UDP a ele. Inicie o perfil e abra os seis links abaixo. Observe o endereço resultante. Em todos os testes, ele deve corresponder ao endereço exibido pelo Octo ao lado da tag UDP.
networktest.twilio.com: uma chamada WebRTC. O UDP chega aos servidores do provedor de voz?
browserleaks.com/quic: O QUIC funciona e de qual endereço ele parte?
ipbinding.notsosmart.dev compara os endereços via HTTP, STUN, TURN UDP e TURN TCP e exibe os sinalizadores de spoofing.
quic.nginx.org/quic.html: o canal consegue lidar com carga sustentada: 3.000 solicitações HTTP/3?
wtcheck.top: o endereço do WebTransport corresponde ao endereço TCP?
browserleaks.com/dns: quem é o proprietário dos resolvedores envolvidos na determinação dos endereços?
Mantenha o anonimato on-line com Octo Browser. Sua verdadeira impressão digital não pode ser rastreada.
Gostaria de experimentar o Octo Browser com desconto?
Use o código promocional OCTOBLOG e ganhe 30% de desconto em qualquer assinatura. Esta oferta é válida somente para novos usuários.
Configuração do teste
Navegador: Octo Browser 3.1.3 (Chromium 152).
Perfil: Quick honorable-bar · ID 8dd7332…
Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.
Endereço de saída: 68.59.118.110 · EUA · Comcast · Residencial.
Data e hora: 10 de setembro de 2026, 12:04–12:11.
Como ler as capturas de tela
Todas as seis capturas de tela são de uma única sessão contínua, não de seis execuções separadas. Você pode notar isso por meio de três detalhes que valem a pena destacar antes de analisar os testes propriamente ditos:
As mesmas informações de perfil aparecem no topo de cada captura de tela: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225 e uma tag UDP mostrando 68.59.118.110. O Octo exibe o endereço de saída UDP separadamente — esse é o endereço que deve aparecer em todos os testes abaixo.
As guias não foram fechadas. Há uma guia na primeira captura de tela e seis na última, com os testes anteriores visíveis na barra de guias.
O relógio da bandeja do sistema avança continuamente: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
Não houve reconfiguração do perfil entre os testes.
Etapa 1. Uma chamada através do proxy. Twilio Network Test
10 de setembro, 12:04. Uma guia — a sessão acabou de começar.
A ferramenta de diagnóstico oficial da Twilio, um dos principais provedores de comunicações de voz e vídeo. Os desenvolvedores a usam para verificar se a rede de um cliente suporta chamadas baseadas em navegador. Ela não procura por vazamentos e não sabe nada sobre navegadores antidetecção — ela simplesmente realiza uma chamada real.
Todas as verificações foram aprovadas, incluindo TURN UDP Connectivity, o que significa literalmente que os pacotes UDP do navegador chegaram aos servidores da Twilio e retornaram. O teste fez então duas chamadas reais usando codecs diferentes, PCMU e Opus: seus identificadores, zero perda de pacotes e as classificações finais de qualidade — Great e Good — estão visíveis no log à direita.
As observações para as verificações de TCP e TLS também merecem leitura. A Twilio declara ali que o Twilio Voice não funciona de modo algum via TCP. Em outras palavras, ambas as chamadas bem-sucedidas foram feitas via UDP — não havia outra opção.
Conclusão: duas chamadas de voz ao vivo passaram pelo proxy SOCKS5 com zero perda de pacotes.
Etapa 2: o QUIC funciona e o endereço pertence ao proxy. BrowserLeaks
10 de setembro, 12:04. Agora há duas guias — o Twilio ainda está aberto à esquerda.
Um teste público de QUIC do BrowserLeaks. Ele responde a duas perguntas distintas de uma só vez, e precisamos de ambas: se o navegador oferece suporte a QUIC — ou seja, se o UDP funciona — e por qual endereço o servidor nos vê através do QUIC — ou seja, para onde o tráfego UDP está indo.
A Etapa 1 já mostrou que o UDP funciona, mas aquele era um tipo diferente de UDP. O Twilio estava testando o WebRTC — UDP para chamadas. QUIC é UDP para o tráfego comum da web. O HTTP/3 roda sobre ele, e o Google e o YouTube o utilizam para se comunicar com os navegadores. As tecnologias são diferentes, e o suporte a uma não implica suporte à outra.
Há dois resultados na captura de tela: QUIC Connection: True, o que significa que uma conexão via UDP foi estabelecida, e IP Address: 68.59.118.110, que é o mesmo endereço que o Octo exibe na barra de perfil como o endereço de saída UDP.
Conclusão: a conexão QUIC foi estabelecida, e o servidor a viu partindo do endereço do proxy.
Etapa 3: Quatro canais, um endereço. WebRTC Detection Check
10 de setembro, 12:05. Terceira guia, com os dois testes anteriores ainda abertos à esquerda.
As duas primeiras etapas mostraram que o UDP passa e que o endereço está correto através do QUIC. Este teste compara endereços em todos os canais simultaneamente e verifica de forma separada se o navegador está simulando o WebRTC em vez de executá-lo de fato.
Há quatro linhas na seção IP Sources, representando quatro formas distintas de descobrir nosso endereço: por meio de uma solicitação HTTP comum (TCP), através de um servidor STUN (UDP), através de uma retransmissão TURN via UDP e através da mesma retransmissão TURN via TCP. Todas as quatro linhas exibem 68.59.118.110, nosso endereço de proxy. Em outras palavras, o endereço UDP corresponde ao endereço TCP.
Abaixo disso está a seção Detection Flags, com sete verificações distintas para detecção de spoofing no navegador. Todas as sete retornam NO:
WebRTC Blocked: o WebRTC não está desativado; ele funciona.
UDP/TCP Mismatch: não há divergência entre os endereços UDP e TCP.
Candidates Spoofed: os candidatos ICE que o navegador apresenta ao seu par não sofreram spoofing.
TURN UDP Blocked e TURN TCP Blocked: o tráfego de retransmissão funciona em ambas as direções.
Relay Spoofed: o relay é genuíno.
A combinação é o que importa. A primeira sinalização mostra que o WebRTC está funcionando; as outras seis mostram que nada está sendo forjado no processo. Você não pode ocultar o problema simplesmente desativando o WebRTC aqui: isso apareceria imediatamente na primeiríssima linha.
Conclusão: quatro canais independentes — HTTP, STUN, TURN UDP e TURN TCP — retornam o mesmo endereço. Nenhuma das sete verificações de bloqueio ou spoofing foi acionada.
Etapa 4: 3.000 solicitações via HTTP/3. NGINX QUIC Sandbox
10 de setembro, 12:07. Quarta guia.
Um ambiente de teste dos próprios desenvolvedores do nginx. Ele envia um lote de solicitações e detalha o resultado em três contadores: quantas foram via QUIC, quantas foram via HTTP comum e quantas falharam totalmente.
A Etapa 2 mostrou uma única conexão QUIC. Aqui há três mil solicitações consecutivas — isso já não é mais um teste sobre o QUIC ser suportado, mas sobre o canal aguentar uma carga sustentada.
Resultado: Total requests 3000, Success with QUIC 3000, Success with HTTP 0, Failed requests 0. O progresso é 3000/3000, e a visualização abaixo dele é inteiramente verde. O verde representa o QUIC, e não há células de nenhuma outra cor.
O contador Success with HTTP também é digno de nota. Ele serve especificamente para solicitações que não puderam ser enviadas via QUIC e recorreram ao fallback para HTTP regular. Ele mostra zero.
Conclusão: 3.000 de 3.000 solicitações foram via QUIC. Não houve fallback para HTTP regular e nenhuma solicitação falhou.
Etapa 5: O WebTransport mostra o mesmo endereço. wtcheck.top
10 de setembro, 12:10. Quinta guia.
O WebTransport é outra maneira baseada no navegador de trocar dados via QUIC, ou seja, via UDP. A página faz duas solicitações e exibe os resultados lado a lado: o endereço da solicitação TCP regular e o endereço da conexão WebTransport.
Esta é a terceira forma diferente de testar o tráfego UDP: a Etapa 1 usou WebRTC; as Etapas 2 e 4 usaram QUIC e HTTP/3; aqui analisamos o WebTransport. Cada teste adicional reduz o espaço para a objeção: “tudo bem, este protocolo em particular funciona, mas e quanto aos outros?”
Ambos os campos mostram 68.59.118.110. Não há necessidade de comparar nada entre capturas de tela, já que os dois valores são exibidos na mesma página.
Conclusão: a conexão WebTransport veio do mesmo endereço da solicitação TCP comum da mesma página.
Etapa 6: O DNS é resolvido no lado do proxy. BrowserLeaks
10 de setembro, 12:11. Sexta guia, com todos os testes anteriores ainda abertos à esquerda.
O DNS é um canal separado de todo o tráfego discutido acima. Um proxy pode estar configurado perfeitamente, enquanto o navegador ainda pode perguntar ao resolvedor do provedor local: “Qual é o endereço do site X?” Isso traz duas consequências: o provedor pode ver o histórico de navegação e o site pode comparar a localização geográfica do resolvedor com a do endereço IP e identificar uma discrepância.
O teste verifica quais servidores DNS participaram da resolução. Na captura de tela, é possível ver o seguinte: endereço 68.59.118.110, provedor Comcast e o resultado Found 77 Servers, 1 ISP. Na parte visível da lista, os resolvedores estão na faixa 69.241.83.x, e cada um tem a mesma Comcast listada como seu ISP.
O dado fundamental é 1 ISP. Cada um dos resolvedores pertence ao mesmo provedor do endereço de saída do proxy. Nenhuma solicitação foi direcionada a um resolvedor pertencente a um provedor diferente.
Conclusão: todos os 77 servidores DNS pertencem ao provedor do nó de saída. A resolução de DNS ocorre no lado do proxy; o resolvedor local não é envolvido.
Como reproduzir o teste você mesmo
Crie um perfil do Octo e conecte seu proxy SOCKS5 com suporte a UDP a ele. Inicie o perfil e abra os seis links abaixo. Observe o endereço resultante. Em todos os testes, ele deve corresponder ao endereço exibido pelo Octo ao lado da tag UDP.
networktest.twilio.com: uma chamada WebRTC. O UDP chega aos servidores do provedor de voz?
browserleaks.com/quic: O QUIC funciona e de qual endereço ele parte?
ipbinding.notsosmart.dev compara os endereços via HTTP, STUN, TURN UDP e TURN TCP e exibe os sinalizadores de spoofing.
quic.nginx.org/quic.html: o canal consegue lidar com carga sustentada: 3.000 solicitações HTTP/3?
wtcheck.top: o endereço do WebTransport corresponde ao endereço TCP?
browserleaks.com/dns: quem é o proprietário dos resolvedores envolvidos na determinação dos endereços?
Mantenha-se atualizado com as últimas notícias do Octo Browser
Ao clicar no botão, você concorda com a nossa Política de Privacidade.
Mantenha-se atualizado com as últimas notícias do Octo Browser
Ao clicar no botão, você concorda com a nossa Política de Privacidade.
Mantenha-se atualizado com as últimas notícias do Octo Browser
Ao clicar no botão, você concorda com a nossa Política de Privacidade.
Junte-se ao Octo Browser agora mesmo
Ou entre em contato com a equipe de suporte no chat para tirar dúvidas a qualquer momento.
Junte-se ao Octo Browser agora mesmo
Ou entre em contato com a equipe de suporte no chat para tirar dúvidas a qualquer momento.
Junte-se ao Octo Browser agora mesmo
Ou entre em contato com a equipe de suporte no chat para tirar dúvidas a qualquer momento.