UDP via SOCKS5: comando UDP ASSOCIATE, por que proxies HTTP não suportam UDP e como verificar

Situação familiar: você configurou um proxy, o navegador abre sites, o parser coleta dados, tudo parece perfeito. Mas então você inicia uma videochamada e o interlocutor não te ouve. Ou entra num jogo online e a partida não conecta. Ou liga um chat de voz e ele fica mudo. O proxy está funcionando? Sim. Mas algo está quebrado num nível profundo, e entender isso sem conhecimentos de transporte é praticamente impossível.

A causa é quase sempre a mesma: seu proxy não permite tráfego UDP. E não é um defeito, mas uma propriedade fundamental. Alguns tipos de proxy sabem lidar com UDP por padrão, outros não sabem em princípio. A diferença entre esses dois mundos define se você terá comunicação real na internet ou apenas carregamento de páginas web.

Neste guia, vamos abordar o tema desde o fundamento até ferramentas práticas de verificação. Você aprenderá como funciona o comando UDP ASSOCIATE no protocolo SOCKS5, por que proxies HTTP via método CONNECT fisicamente não conseguem transmitir datagramas, o que exatamente quebra para o usuário sem UDP e como verificar, em poucos minutos, se um proxy realmente suporta UDP. Falaremos apenas sobre transporte: sem discutir escolhas entre tipos de proxy ou instruções de configuração de aplicativos específicos.

Fundamentos: TCP vs UDP, datagramas e o nível de ação do proxy

Para entender por que o UDP é tão exigente na infraestrutura de proxy, precisamos voltar aos conceitos básicos da camada de transporte. Não se preocupe: explicaremos tudo com analogias simples.

Dois protocolos de transporte, duas filosofias

Na internet, os dados são transmitidos sobre dois protocolos de transporte principais: TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Ambos operam sobre o IP, mas se comportam de maneiras totalmente diferentes.

TCP se assemelha a uma conversa telefônica com confirmação constante. Antes de começar a troca de dados, os dois lados estabelecem uma conexão através de um handshake. Cada pacote enviado é confirmado pelo receptor. Se algo se perde, é reenviado. A ordem dos pacotes é garantida. É um fluxo confiável, ordenado, mas relativamente lento. O TCP é ideal para carregar páginas web, baixar arquivos, enviar e-mails – em suma, onde cada porção de dados e sua ordem correta importam.

UDP é como enviar cartões-postais sem aviso de recebimento. Você solta um datagrama na rede e não espera confirmação. Não há estabelecimento de conexão, nem garantia de entrega, nem garantia de ordem. O pacote pode se perder, chegar duas vezes ou fora de ordem, e o protocolo não se importa. Parece uma deficiência? Só à primeira vista. É justamente essa simplicidade que dá ao UDP sua principal vantagem: velocidade e latência mínima.

O que é um datagrama

Um datagrama é uma porção independente de dados no UDP. Diferentemente do TCP, onde os dados fluem como um fluxo contínuo de bytes, no UDP cada pacote é autossuficiente. Ele contém endereço de destino, porta e carga útil. O datagrama não sabe nada sobre datagramas enviados antes ou depois dele. É como cartas separadas, sem numeração, numa correspondência geral.

Por que isso é importante para o nosso tema? Porque um proxy que sabe encaminhar um fluxo contínuo de TCP não necessariamente sabe encaminhar datagramas UDP dispersos e independentes. São tarefas fundamentalmente diferentes do ponto de vista da implementação.

Onde exatamente o proxy se situa na cadeia

Imagine o modelo de rede como andares de um prédio. Nos andares inferiores, temos a transmissão física de sinais e o endereçamento IP. Acima, a camada de transporte com TCP e UDP. Mais acima, a camada de aplicação com HTTP, DNS, protocolos de chamada.

Um servidor proxy é um intermediário que fica entre você e o recurso de destino. Mas em qual nível ele atua depende do seu tipo. E é aí que a coisa fica interessante.

• Proxy HTTP originalmente entende a camada de aplicação HTTP. Ele lê requisições HTTP, vê cabeçalhos, sabe modificá-los e armazená-los em cache. É um proxy voltado para um protocolo de aplicação específico sobre TCP.
• Proxy SOCKS opera mais abaixo, próximo à camada de transporte. Ele não se aprofunda no conteúdo do protocolo de aplicação; apenas encaminha as conexões. Por isso, o SOCKS é mais universal: não importa se você está transmitindo HTTP ou algo exótico.

Essa diferença no nível de atuação é a raiz de toda a história. O proxy HTTP fica preso no mundo do HTTP sobre TCP. Já o SOCKS5 foi concebido como um intermediário de transporte universal, e é por isso que em sua especificação foi incluído um mecanismo para transmissão de UDP.

Aprofundamento: como o SOCKS5 transmite UDP

O protocolo SOCKS5 é descrito no padrão RFC 1928. É um protocolo compacto e elegante, e entender sua lógica vale para quem trabalha seriamente com proxies. Vamos analisar seus comandos e a estrutura especial da transmissão UDP.

Três comandos do SOCKS5: CONNECT, BIND, UDP ASSOCIATE

Após o cliente se conectar ao servidor SOCKS5 e passar pela etapa de autenticação, ele envia uma requisição com um dos três comandos. Cada comando define qual tipo de operação é necessária.

• CONNECT (código 0x01) é o comando mais comum. Ele diz ao proxy: estabeleça para mim uma conexão TCP de saída para o endereço e porta indicados e, em seguida, encaminhe bytes nos dois sentidos. É esse comando que seu navegador usa ao acessar a internet via SOCKS5. 99% do tráfego cotidiano passa pelo CONNECT.
• BIND (código 0x02) é o comando para conexões de entrada. É necessário para protocolos como o FTP clássico, onde o próprio servidor inicia uma conexão reversa com o cliente. O proxy abre uma porta de escuta e aguarda uma conexão de entrada. Hoje, o BIND é raramente usado.
• UDP ASSOCIATE (código 0x03) é a estrela da nossa conversa. Este comando cria uma associação para transmissão de datagramas UDP através do proxy. É ele que permite ao SOCKS5 trabalhar com voz, vídeo, jogos, QUIC e DNS sobre UDP.

Como o UDP ASSOCIATE funciona internamente

Aqui está um truque arquitetônico elegante que frequentemente causa confusão. O comando UDP ASSOCIATE é enviado por uma conexão TCP. Sim, você ouviu direito: para começar a transmitir UDP, o cliente estabelece uma conexão TCP de controle com o proxy e envia o comando através dela.

Por que é necessária uma conexão TCP de controle se queremos transmitir UDP? Há várias razões, e elas são engenhosas em sua praticidade.

1. Pelo TCP, a autenticação e a negociação de parâmetros passam de forma confiável. O UDP não é adequado para isso, pois não é confiável.
2. A conexão TCP de controle serve como indicador de vida da associação UDP. Enquanto a conexão TCP estiver aberta, a associação UDP permanece ativa. Assim que o cliente fecha a conexão TCP de controle, o proxy deve liberar imediatamente os recursos e parar de encaminhar datagramas. É uma maneira elegante de gerenciar o tempo de vida.

Após receber o comando UDP ASSOCIATE, o servidor proxy aloca uma porta relay especial para UDP e informa ao cliente seu endereço e número na resposta. É para essa porta relay que o cliente enviará seus datagramas, e o proxy os encaminhará ao destino e retornará as respostas.

O papel da porta relay e do endereço de ligação

Na resposta ao UDP ASSOCIATE, o servidor retorna os campos BND.ADDR e BND.PORT. Esses são o endereço e a porta para os quais o cliente deve direcionar seus datagramas UDP para retransmissão. Uma nuance importante: o endereço na resposta pode ser diferente do endereço ao qual o cliente se conectou via TCP. Um cliente bem implementado deve interpretar corretamente esse endereço, especialmente quando o servidor retorna um endereço zero, significando usar o mesmo host da conexão de controle.

É nessa etapa que muitas implementações tropeçam. O tratamento incorreto do BND.ADDR faz com que o cliente envie datagramas para o lugar errado, e a transmissão UDP falha silenciosamente, mesmo que a associação tenha sido estabelecida formalmente.

Formato de encapsulamento do datagrama UDP no SOCKS5

Não se pode simplesmente enviar um datagrama UDP para a porta relay. O proxy precisa saber para onde encaminhá-lo. Por isso, cada datagrama UDP enviado pelo cliente para a porta relay é encapsulado em um cabeçalho especial do SOCKS5. Vamos detalhar seus campos, pois entender essa estrutura diferencia quem realmente domina o assunto.

O cabeçalho de encapsulamento UDP consiste nos seguintes campos:

• RSV (2 bytes) – campo reservado, sempre preenchido com zeros. Reservado para uso futuro, mas por enquanto não utilizado.
• FRAG (1 byte) – número do fragmento. Este campo é destinado à fragmentação de datagramas grandes. O valor 0 indica que o datagrama é independente e não fragmentado. Na prática, a fragmentação de UDP via SOCKS5 quase nunca é implementada, e a maioria dos servidores e clientes só trabalha com FRAG igual a zero.
• ATYP (1 byte) – tipo de endereço de destino. Pode ser 0x01 para IPv4, 0x03 para nome de domínio, 0x04 para IPv6. Este campo informa ao proxy em qual formato ler o próximo campo de endereço.
• DST.ADDR (comprimento variável) – endereço de destino do datagrama. Seu comprimento depende do ATYP: 4 bytes para IPv4, 16 bytes para IPv6, e para nome de domínio o primeiro byte define o comprimento, seguido pelo nome.
• DST.PORT (2 bytes) – porta de destino em ordem de bytes da rede.
• DATA – a carga útil propriamente dita, ou seja, o datagrama UDP original da aplicação.

Quando o proxy recebe um datagrama encapsulado na porta relay, ele remove o cabeçalho SOCKS5, lê o endereço e a porta de destino e envia a carga útil pura ao destino como um pacote UDP comum. Quando chega uma resposta, o proxy faz a operação inversa: encapsula o datagrama de resposta no mesmo cabeçalho e o envia ao cliente na porta relay.

Observe a elegância do esquema. O cliente nunca se comunica diretamente com o destino via UDP. Tudo passa pela porta relay do proxy, e o cabeçalho de encapsulamento serve como etiqueta de endereçamento. É uma maneira confiável e padronizada de transportar datagramas dispersos através de um intermediário.

Por que o campo FRAG geralmente é morto

Vale a pena parar um momento na fragmentação. Teoricamente, o SOCKS5 permite dividir datagramas UDP grandes em fragmentos e remontá-los no lado do proxy. Na prática, isso cria uma enorme complexidade: é necessário armazenar fragmentos em buffer, lidar com timeouts de remontagem, proteger contra ataques. Portanto, a grande maioria das implementações simplesmente exige FRAG igual a zero e descarta todo o resto. Para as aplicações, isso significa que o datagrama deve caber em um único pacote. Felizmente, a maioria dos protocolos reais que usam UDP já trabalha com datagramas pequenos.

Por que proxies HTTP e HTTPS via CONNECT não conseguem transmitir UDP

Agora chegamos à questão que causa mais confusão. Muitas pessoas pensam: já que o proxy HTTPS consegue tunelar tráfego criptografado através do método CONNECT, então ele é universal e deve ser capaz de lidar com UDP. Isso é um erro, e vamos explicar por que é fundamental.

Como funciona o método CONNECT no proxy HTTP

Quando o navegador acessa um site seguro através de um proxy HTTP, ele não pode simplesmente passar uma requisição HTTP, pois o conteúdo está criptografado. Em vez disso, ele envia ao proxy um comando especial CONNECT, especificando o host e a porta. O proxy estabelece uma conexão TCP com esse host e, após o sucesso, responde com um status indicando que o túnel foi estabelecido. A partir daí, o proxy apenas copia bytes entre o cliente e o servidor em ambos os sentidos, sem se importar com o conteúdo.

A palavra-chave aqui é TCP. O método CONNECT, por sua especificação, cria exatamente um túnel TCP. Ele abre uma conexão TCP de fluxo e liga dois fluxos de bytes. Na definição do CONNECT, não há nenhum mecanismo para trabalhar com datagramas.

Três razões fundamentais para a incompatibilidade

Vamos detalhar por que isso não é uma falha técnica, mas uma impossibilidade conceitual.

1. O CONNECT está preso ao modelo de fluxo. HTTP é um protocolo sobre TCP. O método CONNECT herda essa natureza de fluxo. Ele sabe ligar dois fluxos TCP, mas UDP não é um fluxo; é um conjunto de datagramas independentes. Não há correspondência entre eles. Não é possível enfiar vários datagramas dispersos com diferentes endereços de destino em um único túnel TCP sem um protocolo de encapsulamento adicional, que simplesmente não existe no CONNECT HTTP.
2. Não há mecanismo de endereçamento de datagramas. No UDP, cada datagrama pode voar para seu próprio endereço e porta. Um aplicativo de voz pode se comunicar simultaneamente com vários servidores. O túnel TCP do CONNECT liga você a um único endereço específico, definido no momento do estabelecimento. Ele não prevê campos para indicar o endereço de destino de cada datagrama individual, ao contrário do SOCKS5 com seu cabeçalho de encapsulamento DST.ADDR e DST.PORT.
3. Não há porta relay para UDP. O SOCKS5 aloca especificamente uma porta relay UDP separada e a informa ao cliente. O proxy HTTP não possui tal mecanismo em sua arquitetura. Sua estrutura não prevê a abertura de sockets UDP no lado do servidor para retransmissão. O código de um proxy HTTP trabalha com conexões TCP; adicionar UDP a isso significaria escrever essencialmente um novo protocolo.

Conclusão que vale a pena lembrar para sempre

Proxies HTTP e HTTPS não suportam UDP não porque os desenvolvedores foram preguiçosos, mas porque seu protocolo é construído exclusivamente em torno do TCP. O método CONNECT é um túnel TCP, ponto final. Se você precisa de UDP através de um proxy, o único caminho padrão é o SOCKS5 com suporte ao comando UDP ASSOCIATE. Nenhum proxy HTTP, por mais avançado que seja, vai passar para você tráfego de voz, vídeo ou jogos via UDP.

O que exatamente quebra sem UDP: mapa completo de sintomas

Agora, a parte mais prática. Vamos analisar quais tecnologias dependem de UDP e como sua falha se manifesta para o usuário comum. Isso ajudará você a diagnosticar instantaneamente o problema pelos sintomas.

WebRTC e o par STUN/TURN

WebRTC é a tecnologia em tempo real que sustenta videochamadas no navegador, chats de voz, compartilhamento de tela e muitos serviços de conferência. A base da transmissão de mídia é o UDP, porque para uma conversa ao vivo a velocidade é mais importante que a garantia de entrega de cada pacote. Uma pequena perda de pacotes na voz é quase imperceptível, enquanto os atrasos causados pelo reenvio do TCP matam a qualidade.

Para estabelecer a conexão, o WebRTC usa os protocolos STUN e TURN. O STUN ajuda a descobrir seu endereço externo atrás do NAT, e o TURN atua como um retransmissor quando a conexão direta é impossível. Tanto o STUN quanto os fluxos de mídia, por padrão, usam UDP.

Sintoma do lado do usuário: a chamada aparentemente é estabelecida, há indicação de discagem, mas o interlocutor não te ouve nem te vê, ou a comunicação é unilateral. Às vezes a chamada cai após alguns segundos. A interface web funciona, o chat funciona, mas o áudio e o vídeo não passam. Esse é o sinal clássico de UDP bloqueado.

QUIC e HTTP/3 com fallback para TCP

QUIC é um protocolo de transporte moderno construído sobre UDP. Nele se baseia o HTTP/3, a versão mais recente do protocolo web. O QUIC oferece estabelecimento de conexão mais rápido e lida melhor com perda de pacotes do que o TCP clássico. Em 2026, uma parcela significativa dos grandes sites e serviços já suporta HTTP/3.

Quando o UDP está indisponível, ocorre algo interessante: o aplicativo ou navegador geralmente faz um fallback para HTTP/2 ou HTTP/1.1 sobre TCP. Isso é um mecanismo de tolerância a falhas embutido no design.

Sintoma do lado do usuário: na maioria das vezes, não há falha aparente; os sites abrem. Mas você perde as vantagens do QUIC: as conexões são estabelecidas mais lentamente e, em redes instáveis, podem ocorrer travamentos. Um observador experiente notará que o HTTP/3 está indisponível, embora o servidor o suporte. Para a maioria, é uma degradação oculta, não uma falha explícita.

DNS na porta 53 via UDP

As consultas DNS clássicas tradicionalmente vão por UDP na porta 53. É rápido e eficiente para consultas curtas de nomes.

Aqui há uma sutileza que depende de como o aplicativo resolve nomes. Se a resolução for feita do lado do proxy, o problema pode não existir. Mas se o aplicativo quiser enviar ele mesmo uma consulta DNS UDP através do proxy, e o UDP não for suportado, a resolução quebrará.

Sintoma do lado do usuário: os nomes dos sites não são resolvidos; o aplicativo informa que o host não foi encontrado, embora a internet funcione. Às vezes, ocorrem atrasos quando o sistema tenta UDP, não obtém resposta e muda para a variante TCP do DNS.

VoIP e comunicação de voz

VoIP é a transmissão de voz pela internet. Os protocolos de voz quase sempre usam UDP para transmitir áudio, porque a latência é crítica. Uma conversa ao vivo é impossível se cada pacote esperar por confirmação.

Sintoma do lado do usuário: a chamada é estabelecida, mas o áudio está ausente, interrompido ou muito atrasado. Audição unilateral, artefatos metálicos, queda após alguns segundos de conversa. Tudo isso são sinais de problemas com o transporte UDP.

Jogos online

Muitos jogos online, especialmente shooters dinâmicos e projetos competitivos, usam UDP para transmitir o estado do mundo do jogo. A razão é a mesma: latência é mais importante que garantia de entrega. Um pacote desatualizado com a posição do jogador é inútil; é melhor receber um novo.

Sintoma do lado do usuário: o jogo não conecta à partida, trava na tela de conexão, expira por timeout. Ou a conexão existe, mas o jogo apresenta travamentos, personagens teletransportam, ações não são registradas. O menu e a loja podem funcionar, pois geralmente usam HTTP sobre TCP.

Torrents e P2P

Muitos protocolos P2P usam ativamente UDP para troca de informações de controle e transmissão de dados. Sem UDP, a funcionalidade degrada: parte dos mecanismos de descoberta de nós e transferência não funciona.

Sintoma do lado do usuário: operação lenta, problemas para encontrar fontes, funcionalidade incompleta.

Tabela resumo de dependência de cenários em relação ao UDP

Abaixo, uma tabela prática que vale a pena guardar. Ela indica instantaneamente o que esperar em cada cenário.

• Videochamada e videoconferência. Usa UDP: sim, criticamente. Sem suporte a UDP: a chamada é estabelecida visualmente, mas sem áudio e vídeo, comunicação unilateral ou queda. Funcionalidade principal não opera.
• Jogo online. Usa UDP: sim, para a maioria dos jogos dinâmicos. Sem suporte a UDP: sem conexão à partida, timeouts, travamentos, teletransporte. A jogabilidade é impossível ou fortemente degradada.
• Consultas DNS. Usa UDP: sim, DNS clássico na porta 53. Sem suporte a UDP: possíveis problemas de resolução ou atrasos se o aplicativo resolver por conta própria; se a resolução for no proxy, pode não haver problema.
• QUIC e HTTP/3. Usa UDP: sim, totalmente construído sobre UDP. Sem suporte a UDP: fallback imperceptível para TCP HTTP/2, perda de velocidade e vantagens, mas sites abrem.
• Torrent e P2P. Usa UDP: sim, para muitos mecanismos. Sem suporte a UDP: degradação de funções, problemas para encontrar fontes e transmitir.
• Parser comum e web scraping. Usa UDP: não, geralmente TCP puro via HTTP. Sem suporte a UDP: tudo funciona normalmente, UDP não é necessário.
• Chamada VoIP. Usa UDP: sim, para o fluxo de voz. Sem suporte a UDP: sem áudio, quedas, atrasos, audição unilateral.

Observe a última linha. Para tarefas clássicas como scraping ou navegação web comum, o UDP não é necessário. É por isso que muitas pessoas usam proxies sem UDP por anos e não suspeitam da limitação, até se depararem com uma chamada ou jogo.

Prática de verificação: como saber se o proxy suporta UDP

Chegou a hora das ferramentas. Vamos abordar vários métodos de verificação, dos simples aos avançados, e explicar por que os métodos populares frequentemente induzem a erro.

Por que o curl testa apenas TCP

Muitos tentam verificar o proxy com um comando do tipo curl via socks5-hostname para algum site. Se a requisição passa, concluem: o proxy funciona, então o UDP também funciona. Isso é uma armadilha.

O fato é que uma requisição HTTP via curl passa pelo TCP. O comando com a flag socks5-hostname verifica que o proxy SOCKS5 sabe executar o comando CONNECT e resolver nomes do seu lado. Mas CONNECT é TCP. O sucesso desse teste diz apenas que o TCP através do proxy funciona. Ele não informa absolutamente nada sobre o suporte ao UDP ASSOCIATE.

Lembre-se da regra de ferro: um teste com ferramenta TCP não verifica UDP. Para verificar UDP, é necessário iniciar explicitamente o comando UDP ASSOCIATE e tentar transmitir um datagrama.

Método 1: script em Python usando sockets

A maneira mais transparente de entender e verificar o UDP ASSOCIATE é escrever um pequeno script que trabalhe diretamente com sockets. Vamos descrever a lógica passo a passo, sem nos atermos a um código específico, para que você entenda a essência.

1. Abra uma conexão TCP com o proxy. Conecte-se ao host e porta do servidor SOCKS5 usando um socket TCP comum.
2. Passe pela etapa de saudação. Envie a versão do protocolo e a lista de métodos de autenticação suportados. Receba o método escolhido pelo servidor. Se necessário, execute a autenticação com login e senha.
3. Envie o comando UDP ASSOCIATE. Monte a requisição com versão, código do comando 0x03, byte reservado e endereço. Geralmente, o endereço e a porta são informados como zero, significando que o cliente ainda não sabe de qual endereço enviará os datagramas.
4. Leia a resposta do servidor. Aqui está o ponto crucial. O primeiro campo após a versão é o código de resposta. O valor 0x00 significa sucesso. Se você vir 0x07, é Command not supported, ou seja, o proxy não sabe lidar com UDP ASSOCIATE. Outros códigos diferentes de zero também sinalizam erro.
5. Extraia o endereço relay. Em caso de sucesso, leia BND.ADDR e BND.PORT da resposta. Esse é o endereço e a porta para onde você enviará seus datagramas.
6. Envie um datagrama de teste. Crie um socket UDP, encapsule uma carga útil de teste no cabeçalho SOCKS5 com os campos RSV, FRAG, ATYP, DST.ADDR, DST.PORT e envie para a porta relay. Como destino, é conveniente usar um serviço público que responda via UDP.
7. Aguarde a resposta. Se chegar uma resposta corretamente encapsulada, o UDP através do proxy está realmente funcionando. Se houver silêncio, apesar do código de resposta bem-sucedido, significa que a associação existe formalmente, mas o encaminhamento real dos datagramas não ocorre.

Esse método fornece um quadro completo. Você verifica separadamente se o servidor aceita o comando UDP ASSOCIATE e se os datagramas realmente trafegam.

Método 2: requisição STUN através do proxy

Um ótimo teste prático é usar uma requisição STUN como carga útil. STUN é um protocolo leve, servidores STUN públicos respondem rapidamente, e esse teste se aproxima muito do cenário real do WebRTC.

A lógica é a mesma: estabeleça uma associação UDP, encapsule uma requisição STUN do tipo Binding Request no cabeçalho de encapsulamento SOCKS5, envie para a porta relay com o endereço de um servidor STUN público. Se chegar uma resposta STUN com seu endereço externo, o caminho UDP através do proxy está totalmente funcional, incluindo a transmissão bidirecional. Esse é o teste mais convincente para cenários de tempo real.

Método 3: dig através do proxy para DNS via UDP

Uma requisição DNS também é um bom teste, pois é um datagrama UDP compacto com uma resposta compreensível. A ideia é direcionar uma requisição DNS via UDP através do proxy SOCKS5 para um servidor DNS público.

O dig padrão não sabe, por si só, passar por um proxy SOCKS5 via UDP. Geralmente, usa-se um wrapper auxiliar que direciona o tráfego UDP através do proxy, ou implementa-se o encapsulamento manualmente conforme o esquema descrito acima. Se a resposta DNS chegar, o canal UDP está funcionando. Se a requisição desaparecer no vazio, enquanto o TCP funciona, a conclusão é óbvia: o UDP não é suportado.

Método 4: socat e utilitários auxiliares

O utilitário socat é um canivete suíço poderoso para trabalhar com sockets. Com ele, é possível construir cadeias de redirecionamento, incluindo a combinação de UDP e SOCKS. No entanto, é importante entender a limitação: nem todas as versões e modos do socat suportam diretamente o UDP ASSOCIATE. Frequentemente, o socat é usado em combinação com uma camada intermediária que assume o encapsulamento SOCKS5 UDP, enquanto o socat cuida do redirecionamento UDP local.

Abordagem prática: levante um receptor UDP local, direcione o tráfego UDP através da camada intermediária para o proxy e verifique se a carga útil chega ao destino e se a resposta retorna. É um caminho mais voltado à engenharia, útil na depuração de infraestrutura.

Como interpretar corretamente o código de resposta 0x07

O código 0x07 Command not supported é o sinal mais honesto e direto. Ele significa que o servidor SOCKS5 recebeu seu comando UDP ASSOCIATE, o reconheceu, mas responde: não executo esse comando. Essa resposta é típica de proxies que implementam apenas o CONNECT.

No entanto, fique atento a um cenário mais traiçoeiro. Às vezes, o servidor responde com o código de sucesso 0x00 ao comando UDP ASSOCIATE, mas o encaminhamento real dos datagramas não funciona. As razões variam: filtro de rede entre o proxy e o destino, tratamento incorreto do endereço relay, limitações da hospedagem. Portanto, não basta verificar apenas o código de resposta. O verdadeiro teste é a transmissão bem-sucedida de um datagrama de ponta a ponta e o recebimento de uma resposta. É por isso que insistimos tanto no teste STUN ou DNS com resposta real.

Checklist para verificar suporte a UDP no proxy

• Certifique-se de que está testando um SOCKS5, e não um proxy HTTP, já que este último não suporta UDP por definição.
• Estabeleça uma conexão TCP de controle e passe pela autenticação.
• Envie o comando UDP ASSOCIATE e verifique o código de resposta. 0x00 é bom; 0x07 indica falta de suporte.
• Extraia e interprete corretamente o BND.ADDR e BND.PORT, considerando o caso de endereço zero.
• Envie um datagrama de teste real, encapsulado conforme o formato de encapsulamento.
• Aguarde uma resposta corretamente encapsulada. Somente isso confirma o funcionamento do UDP.
• Repita o teste várias vezes para descartar perda acidental de pacotes.

UDP em redes móveis: timeouts de NAT e keepalive

Um tópico separado e muito importante é o comportamento do UDP em redes móveis. Aqui se esconde a causa de muitas quedas misteriosas que parecem inexplicáveis.

Por que a sessão UDP cai antes da TCP

Entre seu dispositivo e a internet, há sempre um NAT, o mecanismo de tradução de endereços de rede. O NAT mantém uma tabela de correspondências entre endereços e portas internos e externos. Para cada conexão, é criado um registro nessa tabela, que vive por um tempo limitado.

E aqui está a diferença crucial. Para o TCP, o NAT tem sinais claros de início e fim da conexão: ele vê o handshake e o fechamento. Por isso, os registros TCP na tabela do NAT geralmente vivem muito tempo, às vezes dezenas de minutos ou mais.

Para o UDP, é diferente. O UDP não tem o conceito de conexão, portanto o NAT não sabe quando a sessão começou ou terminou. Ele simplesmente mantém o registro enquanto houver tráfego e o remove após um período de silêncio. Esse período de silêncio é chamado de timeout de NAT UDP, e em redes móveis ele costuma ser muito curto, às vezes apenas dezenas de segundos.

Resultado: se não houver tráfego no canal UDP por algum tempo, o NAT descarta silenciosamente o registro. Seus datagramas subsequentes não têm para onde ser entregues no sentido inverso, e a sessão é interrompida. Enquanto isso, uma conexão TCP nas mesmas condições continuaria viva.

Para que serve o keepalive

Keepalive é o envio regular de pacotes pequenos para que o NAT considere a sessão ativa e não remova o registro. Para o UDP, o keepalive é especialmente crítico devido aos timeouts curtos.

Protocolos de tempo real bem projetados já enviam keepalives periódicos ou pacotes de controle. Por exemplo, no WebRTC, o mecanismo de verificação de conectividade confirma constantemente o caminho. Mas se o aplicativo ficar em silêncio e o timeout do NAT for curto, a queda é inevitável. Portanto, ao trabalhar com UDP via proxy em redes móveis, é preciso considerar a necessidade de manter o canal ativo.

Observações práticas sobre redes móveis

• As operadoras móveis frequentemente aplicam políticas mais agressivas para o UDP do que para o TCP, visando economizar recursos do NAT.
• O timeout de NAT UDP pode variar entre operadoras e mudar com o tempo; portanto, não há um valor único.
• Sintoma de timeout curto: a conexão funciona perfeitamente na fase ativa, mas cai durante as pausas, por exemplo, quando o interlocutor fica em silêncio numa chamada.
• A conexão TCP de controle do SOCKS5 para a associação UDP também precisa ser mantida viva; caso contrário, o proxy encerrará toda a associação.

Esse é um detalhe sutil que diferencia a compreensão superficial da profunda. Mesmo quando o proxy suporta corretamente o UDP ASSOCIATE, a instabilidade pode vir do lado do NAT móvel, não do proxy em si. Ao diagnosticar quedas, tenha sempre em mente o fator dos timeouts.

Erros típicos ao trabalhar com UDP via proxy

Vamos reunir num só lugar os equívocos mais comuns. Evitando-os, você economizará horas de depuração.

Erro 1: confundir socks5 e socks5h

Nas configurações de muitas ferramentas, há duas variantes de notação para o SOCKS5. O esquema socks5 geralmente significa que a resolução do nome de domínio é feita localmente, no lado do cliente, e o proxy recebe um endereço IP já resolvido. O esquema socks5h significa que a resolução é feita no lado do servidor proxy.

Por que isso é importante? Primeiro, a resolução local pode vazar através do seu DNS comum, o que não é desejável para tarefas de privacidade. Segundo, com a escolha errada do esquema, parte da lógica pode se comportar de maneira inesperada. A confusão entre socks5 e socks5h gera bugs difíceis de rastrear, em que o proxy parece funcionar às vezes. Sempre escolha conscientemente onde o nome será resolvido.

Erro 2: achar que, por ser SOCKS5, o UDP funciona

Esse é, talvez, o equívoco mais frequente e mais perigoso. O padrão SOCKS5 prevê o comando UDP ASSOCIATE, mas não obriga cada implementação a suportá-lo. Uma quantidade enorme de proxies SOCKS5 implementa apenas CONNECT e BIND, respondendo ao UDP ASSOCIATE com o código 0x07.

Em outras palavras, o rótulo SOCKS5 não é garantia de UDP. É apenas uma possibilidade que pode ou não ser implementada. A única maneira de saber com certeza é testar, como descrevemos acima. Nunca confie em uma etiqueta de marketing; confie em um teste real.

Erro 3: verificar UDP com o navegador

Alguns tentam verificar o suporte a UDP simplesmente abrindo um site através do proxy no navegador. Mas o navegador acessa sites via TCP. Mesmo que o site suporte HTTP/3 via UDP, se o UDP estiver indisponível, o navegador fará um fallback silencioso para o TCP, e você não notará nada. O sucesso ao abrir a página não prova que o UDP funciona.

Além disso, o WebRTC no navegador tem sua própria lógica complexa de contornar limitações de rede e pode usar TURN sobre TCP em algumas configurações, o que complica ainda mais o quadro. Portanto, o navegador é uma ferramenta ruim para testar puramente o transporte UDP. Use testes diretos com sockets.

Erro 4: ignorar a verificação de ponta a ponta

Como já enfatizamos, a resposta 0x00 ao UDP ASSOCIATE não equivale a UDP funcional. É um erro confiar apenas no código de resposta. Sempre leve o teste até a troca real de datagramas com recebimento de resposta. Isso separa o suporte formal da funcionalidade real.

Erro 5: não considerar keepalive e timeouts

Depois de configurar o UDP, é fácil esquecer os timeouts de NAT. Assim, o canal funciona no momento do teste, mas cai nas pausas durante a operação real. Sempre inclua um mecanismo para manter o canal ativo, especialmente em redes móveis.

Erro 6: tratar incorretamente o endereço relay

Como observado, o servidor pode retornar um endereço zero em BND.ADDR, subentendendo o mesmo host da conexão de controle. Clientes que enviam cegamente datagramas para o endereço zero quebram. Uma implementação correta substitui pelo endereço do proxy da conexão TCP. Essa sutileza é a causa de muitas falhas silenciosas.

Ferramentas e recursos para trabalhar com UDP via SOCKS5

Vamos listar o arsenal prático que vale a pena ter à mão.

Ferramentas de diagnóstico

• Script próprio em Python com sockets. A ferramenta mais flexível e transparente. Dá controle total sobre a formação do comando UDP ASSOCIATE e o encapsulamento dos datagramas. Ideal para diagnóstico preciso.
• Cliente STUN via proxy. O melhor teste para cenários de tempo real. Resposta rápida, resultado claro, o mais próximo possível do WebRTC.
• Teste DNS via UDP. Compacto e didático, ótimo para verificar a transmissão de ponta a ponta de datagramas curtos.
• socat e camadas intermediárias para encapsulamento UDP. Conjunto de ferramentas de engenharia para construir e depurar cadeias de redirecionamento UDP via SOCKS5.
• Analisador de tráfego. Observar os pacotes ajuda a ver se os datagramas estão realmente indo para a porta relay e se as respostas estão chegando. Indispensável em depuração profunda.

O que é importante saber sobre os padrões

O documento chave sobre SOCKS5 é a RFC 1928, que descreve os comandos, o formato das requisições e respostas, e o encapsulamento UDP. Entender esse padrão diferencia o especialista do usuário que age no escuro. Adicionalmente, é útil compreender os princípios do STUN, QUIC e do funcionamento do NAT, pois é na intersecção dessas tecnologias que surgem os problemas práticos com UDP.

Mini-framework de tomada de decisão

1. Determine se você precisa de UDP. Para scraping e web comum, não; para chamadas, jogos, tempo real, sim.
2. Se precisar de UDP, certifique-se de que o proxy seja SOCKS5, não HTTP.
3. Verifique o suporte real ao UDP ASSOCIATE com um teste de ponta a ponta, não pelo rótulo.
4. Considere keepalive e timeouts de NAT, especialmente em redes móveis.
5. Trate corretamente o endereço relay e o formato de encapsulamento.

Casos e resultados de aplicação

Vamos analisar algumas situações típicas que mostram como o conhecimento sobre transporte resolve problemas reais.

Caso 1: videochamada silenciosa

Situação. O usuário reclama que, através do proxy, todos os sites abrem, o chat na conferência funciona, mas durante a chamada não há áudio nem vídeo. Os interlocutores veem a indicação de conexão, mas não há comunicação.

Diagnóstico. O teste TCP via proxy passa com sucesso, o que inicialmente confunde. Em seguida, é realizado um teste STUN de ponta a ponta via UDP ASSOCIATE. O servidor responde ao comando com o código 0x07 Command not supported.

Conclusão. O proxy implementa apenas CONNECT; o UDP não é suportado. O fluxo de mídia WebRTC via UDP não passa, daí o silêncio. Solução no nível do transporte: é necessário um SOCKS5 com suporte real ao UDP ASSOCIATE, confirmado por teste de ponta a ponta.

Caso 2: queda de comunicação nas pausas em rede móvel

Situação. A comunicação de voz através do proxy em rede móvel funciona perfeitamente durante a conversa ativa, mas basta os interlocutores ficarem em silêncio por meio minuto para a conexão cair.

Diagnóstico. O teste UDP de ponta a ponta passa com sucesso; os datagramas trafegam nos dois sentidos. Portanto, o próprio proxy suporta UDP. A observação do comportamento mostra que as quedas ocorrem exatamente nas pausas sem tráfego.

Conclusão. O culpado é o timeout curto de NAT UDP da operadora móvel. O registro na tabela NAT é removido durante o silêncio. Solução no nível do transporte: garantir keepalive, mantendo o canal e a conexão TCP de controle ativos.

Caso 3: falsa confiança devido ao código 0x00

Situação. Um engenheiro testou o proxy, enviou o comando UDP ASSOCIATE, recebeu o código de sucesso 0x00 e declarou que o UDP funciona. Mas os usuários continuam reclamando de chamadas que não funcionam.

Diagnóstico. O novo teste vai além do código de resposta: envia um datagrama STUN real para a porta relay. A resposta não chega, apesar do código bem-sucedido.

Conclusão. O suporte formal existe, mas o encaminhamento real não ocorre, provavelmente devido a filtragem entre o proxy e a rede externa ou erro no tratamento do endereço relay. Lição: o código 0x00 não é suficiente; apenas a transmissão de ponta a ponta de um datagrama comprova a funcionalidade.

Caso 4: degradação oculta do HTTP/3

Situação. Tudo parece funcionar, os sites abrem, não há reclamações, mas a equipe nota que as conexões são estabelecidas mais lentamente do que o esperado, e o HTTP/3 não é utilizado em nenhum lugar.

Diagnóstico. O teste mostra que o UDP via proxy não passa; portanto, o QUIC está indisponível, e os clientes fazem fallback silencioso para TCP.

Conclusão. Não é uma falha, mas uma perda oculta de desempenho. Compreender o transporte permite decidir conscientemente se o QUIC é importante para a tarefa e, se necessário, garantir suporte a UDP.

FAQ: perguntas frequentes

É possível, de alguma forma, transmitir UDP através de um proxy HTTP?

Com os meios padrão, não. O método CONNECT no proxy HTTP cria exclusivamente um túnel TCP e não possui mecanismo de endereçamento e encaminhamento de datagramas. Qualquer tentativa de passar UDP por um proxy HTTP puro esbarra na ausência de um protocolo correspondente. Para UDP, o caminho correto e padronizado é o SOCKS5 com o comando UDP ASSOCIATE.

Se o proxy se chama SOCKS5, ele com certeza suporta UDP?

Não, e essa é uma nuance importantíssima. O padrão prevê o UDP ASSOCIATE, mas não exige sua implementação obrigatória. Muitos proxies SOCKS5 suportam apenas CONNECT. A única maneira confiável de ter certeza é realizar um teste de ponta a ponta com transmissão real de um datagrama, e não confiar no nome ou no marketing.

Por que o curl mostra que o proxy funciona, mas a chamada não vai?

Porque o curl testa TCP através do comando CONNECT, enquanto a chamada usa UDP. São dois transportes diferentes. O sucesso do teste TCP nada diz sobre o UDP. Para testar UDP, é necessário iniciar o UDP ASSOCIATE e transmitir um datagrama, por exemplo, uma requisição STUN, aguardando a resposta.

O que significa o código de resposta 0x07 ao tentar o UDP ASSOCIATE?

É o Command not supported. O proxy recebeu seu comando, o reconheceu, mas informa que não executa o UDP ASSOCIATE. Na prática, significa que o proxy não sabe encaminhar UDP. Você precisa de outro proxy com suporte real a esse comando.

Por que o UDP ASSOCIATE usa uma conexão TCP, se estamos transmitindo UDP?

A conexão TCP de controle serve a dois propósitos. Primeiro, por ela passam a autenticação e a negociação de forma confiável. Segundo, ela define o tempo de vida da associação UDP: enquanto o TCP estiver aberto, a associação permanece ativa; assim que é fechada, o proxy libera os recursos. É uma maneira elegante de gerenciar a sessão e a limpeza.

Por que a comunicação UDP cai em redes móveis, enquanto o TCP se mantém?

Devido às peculiaridades do NAT. Para o TCP, o NAT tem sinais explícitos de início e fim; por isso, os registros duram muito. O UDP não tem conceito de conexão, e o NAT remove o registro após um curto período de silêncio. Em redes móveis, o timeout UDP é especialmente curto. A solução é um keepalive regular para manter o canal ativo.

É possível verificar o suporte a UDP diretamente no navegador?

De forma confiável, não. O navegador acessa sites via TCP e, se o UDP estiver indisponível, faz fallback silencioso para TCP no QUIC. O WebRTC no navegador tem lógica complexa e pode usar mecanismos de desvio. Tudo isso mascara o estado real do UDP. Para um teste limpo, use testes diretos com sockets, STUN ou DNS via UDP ASSOCIATE.

Qual a diferença prática entre socks5 e socks5h?

A diferença está em onde o nome de domínio é resolvido. No socks5, o nome geralmente é resolvido localmente, no lado do cliente; no socks5h, no lado do proxy. Isso afeta tanto a privacidade da resolução quanto o comportamento em alguns cenários. Escolher conscientemente o esquema evita erros difíceis de rastrear.

É obrigatório implementar a fragmentação de datagramas no SOCKS5?

Na prática, não. O campo FRAG está previsto no padrão, mas a grande maioria das implementações só trabalha com FRAG igual a zero, ou seja, sem fragmentação. Os datagramas devem caber em um único pacote. Os protocolos reais que usam UDP geralmente operam com datagramas pequenos, portanto isso raramente causa problemas.

Como distinguir um problema no proxy de um problema no NAT móvel?

Realize um teste UDP de ponta a ponta. Se ele não passar, e o comando retornar 0x07 ou os datagramas não chegarem, o problema está no proxy. Se o teste passar com sucesso, mas as quedas ocorrerem apenas nas pausas durante a operação real, o provável culpado é o timeout curto de NAT UDP. Essa análise localiza com precisão a fonte.

Conclusão: o transporte decide tudo

Percorremos um caminho desde os conceitos básicos de TCP e UDP até os detalhes do encapsulamento de datagramas no SOCKS5 e os traiçoeiros timeouts de NAT em redes móveis. Vamos fixar as principais conclusões que transformam você de um usuário que adivinha no escuro em alguém que entende exatamente o que acontece na camada de transporte.

Primeiro, UDP e TCP são dois mundos diferentes. O UDP carrega datagramas dispersos sem garantias, em nome da velocidade, e é nele que se baseiam chamadas, jogos, QUIC e o DNS clássico. Um proxy que sabe encaminhar TCP não é obrigado a saber UDP.

Segundo, apenas o SOCKS5, através do comando UDP ASSOCIATE, oferece um caminho padrão para o UDP. O mecanismo é elegante: uma conexão TCP de controle, uma porta relay separada e o encapsulamento de cada datagrama em um cabeçalho com os campos RSV, FRAG, ATYP, DST.ADDR e DST.PORT.

Terceiro, proxies HTTP e HTTPS não suportam UDP em princípio. O método CONNECT cria exclusivamente um túnel TCP; sua arquitetura não tem endereçamento de datagramas, nem porta relay, nem mecanismo de encaminhamento UDP.

Quarto, o rótulo SOCKS5 não garante UDP. Sempre verifique com um teste de ponta a ponta, levando até a transmissão real de um datagrama e o recebimento de uma resposta. O código 0x00 sem troca efetiva não prova nada, e o código 0x07 informa honestamente a falta de suporte.

Quinto, em redes móveis, o UDP é mais exigente devido aos timeouts curtos de NAT. Keepalive e a manutenção da conexão de controle ativa evitam quedas misteriosas durante as pausas.

Seus próximos passos são simples. Determine se você precisa de UDP para a tarefa específica, com base em nossa tabela de cenários. Se precisar, certifique-se de estar usando um SOCKS5 e verifique o suporte real ao UDP ASSOCIATE com seu próprio teste, seja STUN, DNS ou um script de socket direto. Inclua keepalive e trate corretamente o endereço relay. Ao fazer isso, você nunca mais se encontrará na situação em que o proxy parece funcionar, mas a chamada fica muda. Agora você sabe exatamente onde procurar a causa e como resolvê-la no nível do transporte.