UDP a través de SOCKS5: comando UDP ASSOCIATE, por qué los proxies HTTP no soportan UDP y cómo verificarlo

Situación familiar: configuraste un proxy, el navegador abre sitios web, el scraper recopila datos, todo parece perfecto. Pero luego inicias una videollamada y tu interlocutor no te escucha. O entras a un juego en línea y la partida no se conecta. O enciendes un chat de voz y se queda en silencio. El proxy funciona, ¿verdad? Funciona. Pero algo está roto a un nivel profundo, y entenderlo sin conocimientos sobre transporte es casi imposible.

La razón casi siempre es la misma: tu proxy no permite el tráfico UDP. Y esto no es una avería, sino una propiedad fundamental. Algunos tipos de proxy pueden trabajar con UDP según el estándar, otros no pueden en absoluto. La diferencia entre estos dos mundos determina si podrás tener comunicación real en internet o solo carga de páginas web.

En esta guía exploraremos el tema desde lo más fundamental hasta las herramientas prácticas de verificación. Aprenderás cómo funciona el comando UDP ASSOCIATE en el protocolo SOCKS5, por qué un proxy HTTP mediante el método CONNECT no puede transmitir datagramas físicamente, qué es exactamente lo que falla para un usuario sin UDP y cómo verificar por ti mismo, en cuestión de minutos, si cualquier proxy realmente soporta UDP. Hablaremos solo de transporte: sin analizar la elección entre tipos de proxy ni instrucciones para configurar aplicaciones específicas.

Fundamentos: TCP vs UDP, datagramas y nivel de operación del proxy

Para entender por qué UDP es tan caprichoso en la infraestructura de proxies, debemos volver a los conceptos básicos del nivel de transporte. No te asustes: lo explicaremos todo con analogías simples.

Dos protocolos de transporte, dos filosofías

En internet, los datos se transmiten sobre dos protocolos de transporte principales: TCP (Transmission Control Protocol) y UDP (User Datagram Protocol). Ambos funcionan sobre IP, pero se comportan de manera completamente diferente.

TCP se asemeja a una conversación telefónica con confirmación constante. Antes de comenzar el intercambio de datos, las dos partes establecen una conexión mediante un procedimiento de handshake. Cada paquete enviado es confirmado por el receptor. Si algo se pierde, se reenvía. El orden de los paquetes está garantizado. Es un flujo confiable, ordenado, pero relativamente lento. TCP es ideal para cargar páginas web, descargar archivos, enviar correos, es decir, en todos los casos donde cada porción de datos y su orden correcto son importantes.

UDP se asemeja al envío de postales sin aviso de entrega. Arrojas un datagrama a la red y no esperas confirmación. No hay establecimiento de conexión, no hay garantía de entrega, no hay garantía de orden. El paquete puede perderse, llegar dos veces o en orden desordenado, y el protocolo no se preocupa por ello. ¿Suena como una desventaja? Solo a primera vista. Esta simplicidad le da a UDP su principal ventaja: velocidad y latencia mínima.

Qué es un datagrama

Un datagrama es una porción independiente de datos en UDP. A diferencia de TCP, donde los datos fluyen como una corriente continua de bytes, en UDP cada paquete es autosuficiente. Contiene la dirección de destino, el puerto y la carga útil. El datagrama no sabe nada sobre los datagramas enviados antes o después. Es como cartas individuales sin numeración en una correspondencia general.

¿Por qué es esto importante para nuestro tema? Porque un proxy que puede reenviar un flujo continuo de TCP no necesariamente puede reenviar datagramas independientes de UDP. Son tareas fundamentalmente diferentes desde el punto de vista de la implementación.

Dónde exactamente vive el proxy en la cadena

Imaginemos el modelo de red como los pisos de un edificio. En los pisos inferiores están la transmisión física de señales y la dirección IP. Más arriba está el nivel de transporte con TCP y UDP. Aún más arriba está el nivel de aplicación con HTTP, DNS, protocolos de llamadas.

Un proxy es un intermediario que se sitúa entre tú y el recurso de destino. Pero ¿en qué nivel trabaja exactamente? Depende de su tipo. Y aquí es donde comienza lo interesante.

• Proxy HTTP originalmente entiende el nivel de aplicación HTTP. Lee las solicitudes HTTP, ve los encabezados, puede modificarlos y almacenarlos en caché. Es un proxy diseñado para un protocolo de aplicación específico sobre TCP.
• Proxy SOCKS trabaja a un nivel inferior, más cercano al nivel de transporte. No se inmiscuye en el contenido del protocolo de aplicación, simplemente reenvía conexiones. Por eso SOCKS es más universal: le da igual lo que transmitas, HTTP o algo exótico.

Esta diferencia en el nivel de operación es la raíz de toda la historia. El proxy HTTP está encerrado en el mundo de HTTP sobre TCP. SOCKS5 fue diseñado como un intermediario de transporte universal, y por eso se incluyó en su especificación un mecanismo para transmitir UDP.

Inmersión profunda: cómo SOCKS5 transmite UDP

El protocolo SOCKS5 está descrito en el estándar RFC 1928. Es un protocolo compacto y elegante, y vale la pena entender su lógica para cualquiera que trabaje seriamente con proxies. Analicemos sus comandos y la particular disposición para la transmisión UDP.

Los tres comandos de SOCKS5: CONNECT, BIND, UDP ASSOCIATE

Después de que el cliente se conecta al servidor SOCKS5 y pasa la etapa de autenticación, envía una solicitud con uno de tres comandos. Cada comando define qué tipo de operación se necesita.

• CONNECT (código 0x01) es el comando más común. Le dice al proxy: establece para mí una conexión TCP saliente hacia la dirección y puerto indicados, y luego reenvía bytes en ambas direcciones. Este es el comando que usa tu navegador cuando navega por internet a través de SOCKS5. El 99% del tráfico cotidiano va por CONNECT.
• BIND (código 0x02) es el comando para conexiones entrantes. Es necesario para protocolos como el FTP clásico, donde el servidor inicia una conexión de retorno hacia el cliente. El proxy abre un puerto de escucha y espera una conexión entrante. Hoy en día BIND se usa raramente.
• UDP ASSOCIATE (código 0x03) es la estrella de nuestra conversación. Este comando crea una asociación para transmitir datagramas UDP a través del proxy. Es lo que permite a SOCKS5 trabajar con voz, video, juegos, QUIC y DNS sobre UDP.

Cómo funciona UDP ASSOCIATE internamente

Aquí hay un truco arquitectónico ingenioso que a menudo causa confusión. El comando UDP ASSOCIATE se envía a través de una conexión TCP. Sí, escuchaste bien: para empezar a transmitir UDP, el cliente establece una conexión TCP de control con el proxy y envía el comando por ella.

¿Por qué se necesita una conexión TCP de control si queremos transmitir UDP? Hay varias razones, y son geniales en su practicidad.

1. Por TCP pasa de manera confiable la autenticación y la negociación de parámetros. UDP no es adecuado para esto porque no es confiable.
2. La conexión TCP de control sirve como indicador de vida de la asociación UDP. Mientras la conexión TCP esté abierta, la asociación UDP está activa. Tan pronto como el cliente cierra la conexión TCP de control, el proxy debe liberar inmediatamente los recursos y detener el reenvío de datagramas. Es una forma elegante de gestionar el tiempo de vida.

Después de recibir el comando UDP ASSOCIATE, el servidor proxy asigna un puerto relay especial para UDP y le comunica al cliente su dirección y número en la respuesta. Es a este puerto relay al que el cliente enviará sus datagramas, y el proxy los reenviará al destino y devolverá las respuestas.

Rol del puerto relay y la dirección de enlace

En la respuesta a UDP ASSOCIATE, el servidor devuelve los campos BND.ADDR y BND.PORT. Esta es la dirección y el puerto a los que el cliente debe dirigir sus datagramas UDP para su retransmisión. Un detalle importante: la dirección en la respuesta puede diferir de la dirección a la que el cliente se conectó por TCP. Un cliente competente debe interpretar esta dirección correctamente, especialmente cuando el servidor devuelve una dirección cero, lo que significa que debe usar el mismo host que para la conexión de control.

Es en esta etapa donde muchas implementaciones fallan. Un manejo incorrecto de BND.ADDR hace que el cliente envíe datagramas al lugar equivocado, y la transmisión UDP falla silenciosamente, aunque formalmente la asociación esté establecida.

Formato de encapsulación del datagrama UDP en SOCKS5

No se puede enviar un datagrama UDP así nomás al puerto relay. El proxy debe saber a dónde reenviarlo. Por eso, cada datagrama UDP que el cliente envía al puerto relay se envuelve en un encabezado especial de SOCKS5. Analicemos sus campos, porque entender esta estructura es lo que distingue a quien realmente sabe del tema.

El encabezado de encapsulación UDP consta de los siguientes campos:

• RSV (2 bytes) campo reservado, siempre relleno con ceros. Dejado para futuro, pero por ahora no se usa.
• FRAG (1 byte) número de fragmento. Este campo está destinado a la fragmentación de datagramas grandes. El valor 0 significa que el datagrama es independiente y no está fragmentado. En la práctica, casi nadie implementa la fragmentación UDP a través de SOCKS5, y la mayoría de servidores y clientes solo trabajan con FRAG igual a cero.
• ATYP (1 byte) tipo de dirección de destino. Puede ser 0x01 para IPv4, 0x03 para nombre de dominio, 0x04 para IPv6. Este campo le dice al proxy en qué formato leer el siguiente campo de dirección.
• DST.ADDR (longitud variable) dirección de destino del datagrama. Su longitud depende de ATYP: 4 bytes para IPv4, 16 bytes para IPv6, y para nombre de dominio el primer byte indica la longitud seguido del nombre.
• DST.PORT (2 bytes) puerto de destino en orden de red.
• DATA la carga útil real, es decir, el datagrama UDP original de la aplicación.

Cuando el proxy recibe este datagrama encapsulado en el puerto relay, quita el encabezado SOCKS5, lee la dirección y el puerto de destino, y envía la carga útil limpia al destino como un paquete UDP normal. Cuando llega la respuesta, el proxy hace la operación inversa: envuelve el datagrama de respuesta en el mismo encabezado y lo envía al cliente en el puerto relay.

Observa la elegancia del esquema. El cliente nunca se comunica directamente con el destino por UDP. Todo pasa a través del puerto relay del proxy, y el encabezado de encapsulación sirve como etiqueta de dirección. Es una forma confiable y estandarizada de transportar datagramas dispersos a través de un intermediario.

Por qué el campo FRAG casi siempre está muerto

Vale la pena detenerse en la fragmentación. En teoría, SOCKS5 permite dividir datagramas UDP grandes en fragmentos y ensamblarlos del lado del proxy. En la práctica, esto crea una enorme complejidad: hay que almacenar en búfer los fragmentos, manejar tiempos de espera de ensamblaje, protegerse contra ataques. Por lo tanto, la gran mayoría de las implementaciones simplemente exigen que FRAG sea cero y descartan todo lo demás. Para las aplicaciones, esto significa que el datagrama debe caber en un solo paquete. Afortunadamente, la mayoría de los protocolos reales que usan UDP ya trabajan con datagramas pequeños.

Por qué los proxies HTTP y HTTPS mediante CONNECT no pueden transmitir UDP

Ahora llegamos a la pregunta que causa más confusiones. La gente suele pensar: si un proxy HTTPS puede tunelizar tráfico cifrado mediante el método CONNECT, entonces es universal y debería poder con UDP. Esto es un error, y ahora explicaremos por qué es fundamental.

Cómo funciona el método CONNECT en un proxy HTTP

Cuando un navegador accede a un sitio seguro a través de un proxy HTTP, no puede simplemente pasar una solicitud HTTP porque el contenido está cifrado. En su lugar, envía al proxy un comando especial CONNECT con el host y puerto indicados. El proxy establece una conexión TCP hacia ese host y, tras el éxito, responde con un estado de túnel establecido. A partir de ahí, el proxy simplemente bombea bytes entre el cliente y el servidor en ambas direcciones, sin importarle el contenido.

La palabra clave aquí es TCP. El método CONNECT, por su especificación, crea exactamente un túnel TCP. Abre una conexión TCP de flujo y enlaza dos flujos de bytes. En la propia definición de CONNECT no hay ningún mecanismo para trabajar con datagramas.

Tres razones fundamentales de incompatibilidad

Analicemos punto por punto por qué esto no es una deficiencia técnica, sino una imposibilidad conceptual.

1. CONNECT está atado al modelo de flujo. HTTP es un protocolo sobre TCP. El método CONNECT hereda esta naturaleza de flujo. Sabe enlazar dos flujos TCP, pero UDP no es un flujo, sino un conjunto de datagramas independientes. No hay correspondencia entre ellos. No se pueden meter múltiples datagramas dispersos con diferentes direcciones de destino en un único túnel TCP sin un protocolo de encapsulación adicional, que HTTP CONNECT simplemente no tiene.
2. No hay mecanismo de direccionamiento de datagramas. En UDP, cada datagrama puede ir a su propia dirección y puerto. Una aplicación de voz puede comunicarse simultáneamente con varios servidores. Un túnel TCP de CONNECT te enlaza con una única dirección específica, definida en el momento del establecimiento. No prevé campos para indicar la dirección de destino de cada datagrama individual, a diferencia de SOCKS5 con sus encabezados de encapsulación DST.ADDR y DST.PORT.
3. No hay puerto relay para UDP. SOCKS5 asigna especialmente un puerto relay UDP separado y se lo comunica al cliente. Un proxy HTTP no tiene un mecanismo similar en absoluto. Su arquitectura ni siquiera contempla la apertura de sockets UDP del lado del servidor para retransmisión. El código de un proxy HTTP trabaja con conexiones TCP, y agregarle UDP significaría escribir esencialmente un nuevo protocolo.

Conclusión que debes recordar para siempre

Los proxies HTTP y HTTPS no soportan UDP no porque los desarrolladores fueran perezosos, sino porque su protocolo está construido exclusivamente alrededor de TCP. El método CONNECT es un túnel TCP, punto. Si necesitas UDP a través de un proxy, el único camino estándar es SOCKS5 con soporte para el comando UDP ASSOCIATE. Ningún proxy HTTP, por avanzado que sea, te dejará pasar voz, video o tráfico de juegos por UDP.

Qué es exactamente lo que falla sin UDP: mapa completo de síntomas

Ahora la parte más práctica. Analicemos qué tecnologías dependen de UDP y cómo se ve su falla desde la perspectiva del usuario común. Esto te ayudará a diagnosticar el problema al instante según los síntomas.

WebRTC y el dúo STUN/TURN

WebRTC es la tecnología en tiempo real que sustenta las videollamadas en el navegador, los chats de voz, las demostraciones de pantalla y muchos servicios de conferencias. La base de la transmisión de medios es UDP, porque para una conversación en vivo la velocidad es más importante que la garantía de entrega de cada paquete. Una pequeña pérdida de paquetes en la voz es casi imperceptible, pero los retrasos por retransmisiones TCP arruinan la calidad.

Para establecer la conexión, WebRTC utiliza los protocolos STUN y TURN. STUN ayuda a conocer la dirección externa detrás de NAT, y TURN actúa como retransmisor cuando la conexión directa es imposible. Tanto STUN como los flujos de medios van por UDP por defecto.

Síntoma para el usuario: la llamada parece establecerse, hay indicación de marcado, pero el interlocutor no te escucha ni te ve, o la comunicación es unidireccional. A veces la llamada se corta después de unos segundos. La interfaz web funciona, el chat funciona, pero el audio y el video no llegan. Este es el clásico indicio de UDP bloqueado.

QUIC y HTTP/3 con degradación a TCP

QUIC es un protocolo de transporte moderno construido sobre UDP. Sobre él funciona HTTP/3, la versión más nueva del protocolo web. QUIC ofrece un establecimiento de conexión más rápido y maneja mejor las pérdidas de paquetes que el TCP clásico. Para 2026, una parte significativa de los sitios y servicios grandes ya soporta HTTP/3.

Cuando UDP no está disponible, ocurre algo interesante: la aplicación o el navegador generalmente degradan a HTTP/2 o HTTP/1.1 sobre TCP. Este es un mecanismo de tolerancia a fallos diseñado intencionalmente.

Síntoma para el usuario: por lo general no hay una falla evidente, los sitios se abren. Pero pierdes las ventajas de QUIC: las conexiones se establecen más lento, y con una red inestable pueden ocurrir bloqueos. Un observador experimentado notará que HTTP/3 no está disponible, aunque el servidor lo soporte. Para la mayoría, esto es una degradación oculta, no una falla manifiesta.

DNS en el puerto 53 mediante UDP

Las consultas DNS clásicas tradicionalmente van por UDP al puerto 53. Es rápido y eficiente para consultas cortas de nombres.

Aquí hay un matiz que depende de cómo la aplicación resuelve los nombres. Si la resolución se realiza del lado del proxy, puede que no haya problema. Pero si la aplicación quiere enviar ella misma una consulta DNS UDP a través del proxy y UDP no es compatible, la resolución fallará.

Síntoma para el usuario: los nombres de los sitios no se resuelven, la aplicación informa que el host no se encuentra, aunque haya internet. A veces se observan retrasos cuando el sistema intenta UDP, no recibe respuesta y cambia a la variante TCP de DNS.

VoIP y comunicación de voz

VoIP es la transmisión de voz por internet. Los protocolos de voz casi siempre usan UDP para transmitir el audio, porque la latencia es crítica. Una conversación en vivo es imposible si cada paquete espera confirmación.

Síntoma para el usuario: la llamada se establece, pero el audio falta, se corta o llega con mucho retraso. Audibilidad unidireccional, artefactos metálicos, corte a los pocos segundos de conversación. Todo esto son signos de problemas con el transporte UDP.

Juegos en línea

Muchos juegos en red, especialmente los shooters dinámicos y proyectos competitivos, usan UDP para transmitir el estado del mundo del juego. La razón es la misma: la latencia es más importante que la garantía de entrega. Un paquete desactualizado con la posición de un jugador es inútil; es mejor recibir uno fresco.

Síntoma para el usuario: el juego no se conecta a la partida, se queda en la pantalla de conexión, expulsa por tiempo de espera. O la conexión existe, pero el juego va a tirones, los personajes se teletransportan, las acciones no se registran. Mientras tanto, el menú y la tienda pueden funcionar, porque a menudo usan HTTP sobre TCP.

Torrents y P2P

Muchos protocolos P2P utilizan activamente UDP para intercambiar información de control y transferir datos. Sin UDP, la funcionalidad se degrada: parte de los mecanismos de descubrimiento de nodos y transferencia no funcionan.

Síntoma para el usuario: funcionamiento lento, problemas para encontrar fuentes, funcionalidad incompleta.

Tabla resumen de dependencia de escenarios con UDP

A continuación, una tabla práctica que vale la pena guardar. Te indicará al instante qué esperar en cada escenario.

• Videollamada y videoconferencia. Usa UDP: sí, crítico. Sin soporte UDP: la llamada se conecta visualmente, pero no hay audio ni video, comunicación unidireccional o corte. La funcionalidad principal no funciona.
• Juego en línea. Usa UDP: sí, para la mayoría de juegos dinámicos. Sin soporte UDP: no hay conexión a la partida, tiempos de espera, tirones, teletransportación. El proceso de juego es imposible o se degrada mucho.
• Consultas DNS. Usa UDP: sí, DNS clásico en el puerto 53. Sin soporte UDP: posibles problemas de resolución o retrasos si la aplicación resuelve por sí misma; si la resolución es del lado del proxy, puede que no haya problema.
• QUIC y HTTP/3. Usa UDP: sí, está completamente construido sobre UDP. Sin soporte UDP: degradación imperceptible a TCP HTTP/2, pérdida de velocidad y ventajas, pero los sitios se abren.
• Torrent y P2P. Usa UDP: sí, para muchos mecanismos. Sin soporte UDP: degradación de funciones, problemas para encontrar fuentes y transferencia.
• Scraping web y navegación normal. Usa UDP: no, normalmente TCP puro a través de HTTP. Sin soporte UDP: todo funciona bien, UDP no es necesario.
• Llamada VoIP. Usa UDP: sí, para el flujo de voz. Sin soporte UDP: sin audio, cortes, retrasos, audibilidad unidireccional.

Observa la última fila. Para tareas clásicas como scraping o navegación web normal, UDP no es necesario en absoluto. Por eso mucha gente usa proxies sin UDP durante años y no sospecha la limitación, hasta que se topa con una llamada o un juego.

Práctica de verificación: cómo saber si un proxy soporta UDP

Es hora de las herramientas. Analizaremos varios métodos de verificación, desde simples hasta avanzados, y explicaremos por qué las formas populares a menudo inducen a error.

Por qué curl solo verifica TCP

Muchos intentan verificar un proxy con un comando como curl a través de socks5-hostname hacia algún sitio. Si la solicitud pasa, concluyen: el proxy funciona, entonces UDP también funciona. Es una trampa.

El problema es que una solicitud HTTP a través de curl va por TCP. El comando con el flag socks5-hostname verifica que el proxy SOCKS5 sabe ejecutar el comando CONNECT y resolver nombres por su cuenta. Pero CONNECT es TCP. El éxito de esa verificación solo indica que TCP a través del proxy funciona. No informa absolutamente nada sobre el soporte de UDP ASSOCIATE.

Recuerda la regla de hierro: verificar con una herramienta TCP no verifica UDP. Para verificar UDP, hay que iniciar explícitamente el comando UDP ASSOCIATE e intentar transmitir un datagrama.

Método 1: script en Python con sockets

La forma más transparente de entender y verificar UDP ASSOCIATE es escribir un pequeño script que trabaje directamente con sockets. Describamos la lógica paso a paso, sin atarnos a un código concreto, para que entiendas la esencia.

1. Abre una conexión TCP con el proxy. Conéctate al host y puerto del servidor SOCKS5 mediante un socket TCP normal.
2. Pasa la etapa de saludo. Envía la versión del protocolo y la lista de métodos de autenticación soportados. Recibe el método seleccionado por el servidor. Si es necesario, realiza la autenticación con usuario y contraseña.
3. Envía el comando UDP ASSOCIATE. Construye una solicitud con la versión, el código de comando 0x03, un byte reservado y la dirección. Como dirección y puerto a menudo se indican ceros, lo que significa que el cliente aún no sabe desde qué dirección enviará los datagramas.
4. Lee la respuesta del servidor. Aquí está el punto clave. El primer campo después de la versión es el código de respuesta. El valor 0x00 significa éxito. Si ves 0x07, es Command not supported, es decir, el proxy no sabe UDP ASSOCIATE. Otros códigos distintos de cero también señalan un error.
5. Extrae la dirección relay. En caso de éxito, lee BND.ADDR y BND.PORT de la respuesta. Esa es la dirección y el puerto para enviar tus datagramas.
6. Envía un datagrama de prueba. Crea un socket UDP, envuelve una carga útil de prueba en el encabezado SOCKS5 con los campos RSV, FRAG, ATYP, DST.ADDR, DST.PORT y envíalo al puerto relay. Como destino, es conveniente usar un servicio público que responda por UDP.
7. Espera la respuesta. Si llega una respuesta correctamente encapsulada, entonces UDP a través del proxy realmente funciona. Si hay silencio, a pesar del código de respuesta exitoso, significa que la asociación existe formalmente pero el reenvío real de datagramas no se produce.

Este método proporciona un panorama completo. Verificas por separado si el servidor acepta el comando UDP ASSOCIATE y por separado si realmente vuelan los datagramas.

Método 2: solicitud STUN a través del proxy

Una excelente prueba práctica es usar una solicitud STUN como carga útil. STUN es un protocolo ligero, los servidores STUN públicos responden rápido, y esta prueba es la más cercana al escenario real de WebRTC.

La lógica es la misma: estableces una asociación UDP, envuelves una solicitud STUN de tipo Binding Request en el encabezado de encapsulación SOCKS5, la envías al puerto relay con la dirección de un servidor STUN público. Si llega una respuesta STUN con tu dirección externa, significa que la ruta UDP a través del proxy es completamente funcional, incluida la transmisión bidireccional. Esta es la prueba más convincente para escenarios en tiempo real.

Método 3: dig a través del proxy para DNS por UDP

Una consulta DNS también es una buena prueba, porque es un datagrama UDP compacto con una respuesta clara. La idea es dirigir una consulta DNS por UDP a través de un proxy SOCKS5 hacia un servidor DNS público.

El dig estándar por sí solo no sabe navegar a través de SOCKS5 por UDP, por lo que generalmente se usa un envoltorio auxiliar que dirija el tráfico UDP a través del proxy, o se implementa la encapsulación manualmente según el esquema descrito. Si llega la respuesta DNS, el canal UDP funciona. Si la consulta se pierde, pero TCP funciona, la conclusión es obvia: UDP no es compatible.

Método 4: socat y utilidades auxiliares

La utilidad socat es una navaja suiza para trabajar con sockets. Con ella se pueden construir cadenas de redireccionamiento, incluida la combinación de UDP y SOCKS. Sin embargo, es importante entender la limitación: no todas las versiones y modos de socat soportan directamente UDP ASSOCIATE. A menudo se usa socat en combinación con una capa intermedia que se encarga de la encapsulación UDP de SOCKS5, mientras que socat maneja la redirección UDP local.

Enfoque práctico: levantar un receptor UDP local, dirigir el tráfico UDP a través de la capa intermedia hacia el proxy y verificar si la carga útil llega al destino y si regresa la respuesta. Es un camino más ingenieril, útil para depurar infraestructura.

Cómo interpretar correctamente el código de respuesta 0x07

El código 0x07 Command not supported es la señal más honesta y directa. Significa que el servidor SOCKS5 recibió tu comando UDP ASSOCIATE, lo reconoció, pero responde: no ejecuto este comando. Esta respuesta es típica de proxies que solo implementan CONNECT.

Sin embargo, debes estar atento a un escenario más engañoso. A veces el servidor responde con el código de éxito 0x00 al comando UDP ASSOCIATE, pero el reenvío real de datagramas no funciona. Las razones varían: un filtro de red entre el proxy y el destino, manejo incorrecto de la dirección relay, limitaciones del hosting. Por lo tanto, no es suficiente verificar solo el código de respuesta. La verdadera verificación es una transmisión exitosa de un datagrama de extremo a extremo y la recepción de una respuesta. Por eso insistimos tanto en una prueba STUN o DNS con una respuesta real.

Lista de verificación de soporte UDP de un proxy

• Asegúrate de que estás probando exactamente SOCKS5, no un proxy HTTP, ya que este último no soporta UDP por definición.
• Establece una conexión TCP de control y pasa la autenticación.
• Envía el comando UDP ASSOCIATE y verifica el código de respuesta. 0x00 es bueno, 0x07 significa falta de soporte.
• Extrae e interpreta correctamente BND.ADDR y BND.PORT, considerando el caso de dirección cero.
• Envía un datagrama de prueba real, envuelto según el formato de encapsulación.
• Espera una respuesta correctamente encapsulada. Solo esto confirma que UDP funciona.
• Repite la prueba varias veces para descartar una pérdida de paquete casual.

UDP en redes móviles: tiempos de espera NAT y keepalive

Un tema aparte y muy importante es el comportamiento de UDP en redes móviles. Aquí se esconde la causa de muchas interrupciones misteriosas que parecen inexplicables.

Por qué la sesión UDP se cae antes que TCP

Entre tu dispositivo e internet siempre hay un NAT, un mecanismo de traducción de direcciones de red. NAT mantiene una tabla de correspondencias entre direcciones y puertos internos y externos. Para cada conexión se crea una entrada en esta tabla, y vive un tiempo limitado.

Y aquí está la diferencia clave. Para TCP, NAT tiene señales claras de inicio y fin de conexión: ve el handshake y ve el cierre. Por lo tanto, las entradas TCP en la tabla de NAT suelen vivir mucho tiempo, a veces decenas de minutos o más.

Para UDP es diferente. UDP no tiene concepto de conexión, por lo que NAT no sabe cuándo comenzó y terminó la sesión. Simplemente mantiene la entrada mientras haya tráfico, y la elimina después de un período de silencio. Este período de silencio se llama tiempo de espera NAT de UDP, y en redes móviles suele ser muy corto, a veces solo decenas de segundos.

Resultado: si no hay tráfico por el canal UDP durante un tiempo, NAT elimina silenciosamente la entrada. Tus datagramas posteriores ya no tienen adónde llegar en sentido contrario, y la sesión se interrumpe. Mientras tanto, una conexión TCP en las mismas condiciones seguiría viva.

Para qué sirve el keepalive

Keepalive es el envío regular de paquetes pequeños para que NAT considere la sesión activa y no elimine la entrada. Para UDP, el keepalive es especialmente crítico debido a los tiempos de espera cortos.

Los protocolos en tiempo real bien diseñados envían ellos mismos keepalives periódicos o paquetes de control. Por ejemplo, en WebRTC, el mecanismo de verificación de conectividad confirma constantemente la ruta. Pero si la aplicación está en silencio y el tiempo de espera NAT es corto, la interrupción es inevitable. Por lo tanto, al trabajar con UDP a través de un proxy en redes móviles, hay que tener en cuenta la necesidad de mantener el canal vivo.

Observaciones prácticas sobre redes móviles

• Los operadores móviles suelen aplicar una política más agresiva en UDP que en TCP para ahorrar recursos de NAT.
• El tiempo de espera NAT de UDP puede variar entre operadores y cambiar con el tiempo, por lo que no hay un valor único.
• Síntoma de un tiempo de espera corto: la conexión funciona perfectamente en la fase activa, pero se interrumpe durante las pausas, por ejemplo cuando el interlocutor guarda silencio en una llamada.
• La conexión TCP de control de SOCKS5 para la asociación UDP también debe mantenerse viva, de lo contrario el proxy cerrará toda la asociación.

Este es un punto sutil que distingue una comprensión superficial de una profunda. Incluso cuando el proxy soporta correctamente UDP ASSOCIATE, la inestabilidad puede venir del lado del NAT móvil, no del proxy mismo. Al diagnosticar interrupciones, ten siempre presente el factor de los tiempos de espera.

Errores típicos al trabajar con UDP a través de un proxy

Recopilemos en un solo lugar los conceptos erróneos más comunes. Evitándolos, ahorrarás horas de depuración.

Error 1: confundir socks5 y socks5h

En la configuración de muchas herramientas hay dos variantes para escribir SOCKS5. El esquema socks5 generalmente significa que la resolución del nombre de dominio se realiza localmente, del lado del cliente, y el proxy recibe una dirección IP ya lista. El esquema socks5h significa que la resolución se realiza del lado del servidor proxy.

¿Por qué es importante? En primer lugar, la resolución local puede filtrarse a través de tu DNS habitual, lo que no es deseable para tareas de privacidad. En segundo lugar, al elegir el esquema incorrecto, parte de la lógica puede comportarse de manera inesperada. La confusión entre socks5 y socks5h genera errores difíciles de detectar, cuando parece que el proxy funciona a veces sí y a veces no. Siempre elige conscientemente dónde se resuelve el nombre.

Error 2: pensar que si es SOCKS5, entonces UDP funciona

Este es quizás el concepto erróneo más común y más peligroso. El estándar SOCKS5 prevé el comando UDP ASSOCIATE, pero no obliga a cada implementación a soportarlo. Una gran cantidad de proxies SOCKS5 solo implementan CONNECT y BIND, y responden a UDP ASSOCIATE con el código 0x07.

En otras palabras, la etiqueta SOCKS5 no es garantía de UDP. Es solo una posibilidad que puede estar implementada o no. La única forma de saberlo con certeza es verificar, como describimos arriba. Nunca te fíes de la etiqueta de marketing; fíate de una prueba real.

Error 3: verificar UDP con el navegador

Algunos intentan verificar el soporte UDP simplemente abriendo un sitio web a través del proxy en el navegador. Pero el navegador accede a los sitios por TCP. Incluso si el sitio soporta HTTP/3 por UDP, cuando UDP no está disponible, el navegador degrada silenciosamente a TCP y no notarás nada. Abrir una página con éxito no demuestra que UDP funcione.

Además, WebRTC en el navegador tiene su propia lógica compleja para sortear restricciones de red y puede usar TURN sobre TCP en algunas configuraciones, lo que añade confusión. Por lo tanto, el navegador es una mala herramienta para una verificación pura del transporte UDP. Usa pruebas directas con sockets.

Error 4: ignorar la verificación de extremo a extremo

Como ya hemos subrayado, la respuesta 0x00 a UDP ASSOCIATE no equivale a UDP funcional. Es un error confiar solo en el código de respuesta. Siempre lleva la prueba hasta un intercambio real de datagramas con recepción de respuesta. Esto separa el soporte formal de la funcionalidad real.

Error 5: no considerar el keepalive y los tiempos de espera

Configurar UDP es fácil, pero es fácil olvidarse de los tiempos de espera NAT. Entonces el canal funciona en el momento de la prueba, pero se interrumpe durante las pausas en la operación real. Siempre contempla un mecanismo para mantener el canal vivo, especialmente en redes móviles.

Error 6: manejar incorrectamente la dirección relay

Como se mencionó, el servidor puede devolver en BND.ADDR una dirección cero, lo que implica el mismo host de la conexión de control. Los clientes que envían datagramas ciegamente a la dirección cero se rompen. Una implementación correcta sustituye la dirección del proxy desde la conexión TCP. Este detalle causa numerosas fallas silenciosas.

Herramientas y recursos para trabajar con UDP a través de SOCKS5

Resumamos el arsenal práctico que conviene tener a mano.

Herramientas de diagnóstico

• Script propio en Python con sockets. La herramienta más flexible y transparente. Da control total sobre la formación del comando UDP ASSOCIATE y la encapsulación de datagramas. Ideal para diagnóstico preciso.
• Cliente STUN a través del proxy. La mejor prueba para escenarios en tiempo real. Respuesta rápida, resultado claro, lo más cercano a WebRTC.
• Prueba DNS por UDP. Compacta e ilustrativa, excelente para verificar la transmisión de extremo a extremo de datagramas cortos.
• socat y capas intermedias para encapsulación UDP. Herramientas de ingeniería para construir y depurar cadenas de redirección UDP a través de SOCKS5.
• Analizador de tráfico. Observar los paquetes ayuda a ver si los datagramas realmente salen hacia el puerto relay y si llegan las respuestas. Imprescindible para depuración profunda.

Qué es importante saber sobre los estándares

El documento clave sobre SOCKS5 es RFC 1928, donde se describen los comandos, el formato de solicitudes y respuestas, y la encapsulación UDP. Comprender este estándar diferencia a un experto de un usuario que actúa al azar. Además, es útil entender los principios de STUN, QUIC y el funcionamiento de NAT, porque es en la intersección de estas tecnologías donde surgen los problemas prácticos con UDP.

Mini marco de decisión

1. Determina si realmente necesitas UDP. Para scraping y web normal no, para llamadas, juegos, tiempo real sí.
2. Si necesitas UDP, asegúrate de que el proxy sea exactamente SOCKS5, no HTTP.
3. Verifica el soporte real de UDP ASSOCIATE con una prueba de extremo a extremo, no por la etiqueta.
4. Ten en cuenta el keepalive y los tiempos de espera NAT, especialmente en redes móviles.
5. Maneja correctamente la dirección relay y el formato de encapsulación.

Casos prácticos y resultados de aplicación

Analicemos varias situaciones típicas que muestran cómo el conocimiento del transporte resuelve problemas reales.

Caso 1: videollamada silenciosa

Situación. Un usuario se queja de que a través del proxy se abren todos los sitios, el chat en la conferencia funciona, pero durante la llamada no hay ni audio ni video. Los interlocutores ven el indicador de conexión, pero no hay comunicación.

Diagnóstico. La verificación TCP a través del proxy tiene éxito, lo que inicialmente confunde. Luego se realiza una prueba STUN de extremo a extremo mediante UDP ASSOCIATE. El servidor responde al comando con el código 0x07 Command not supported.

Conclusión. El proxy solo implementa CONNECT, UDP no es compatible en absoluto. El flujo de medios de WebRTC por UDP no pasa, de ahí el silencio. Solución a nivel de transporte: se necesita un SOCKS5 con soporte real de UDP ASSOCIATE, confirmado por una prueba de extremo a extremo.

Caso 2: interrupción de la comunicación durante pausas en red móvil

Situación. La comunicación de voz a través de un proxy en red móvil funciona perfectamente durante una conversación activa, pero en cuanto los interlocutores guardan silencio durante medio minuto, la comunicación se corta.

Diagnóstico. La prueba UDP de extremo a extremo es exitosa, los datagramas vuelan en ambas direcciones. Por lo tanto, el proxy en sí soporta UDP. La observación del comportamiento muestra que las interrupciones ocurren precisamente durante las pausas sin tráfico.

Conclusión. El culpable es el corto tiempo de espera NAT de UDP del operador móvil. La entrada en la tabla NAT se elimina durante el silencio. Solución a nivel de transporte: proporcionar keepalive que mantenga vivo el canal y la conexión TCP de control.

Caso 3: falsa confianza por el código 0x00

Situación. Un ingeniero verificó el proxy enviando el comando UDP ASSOCIATE, recibió el código de éxito 0x00 y declaró que UDP funciona. Pero los usuarios siguen quejándose de llamadas que no funcionan.

Diagnóstico. La verificación repetida va más allá del código de respuesta: se envía un datagrama STUN real al puerto relay. No llega respuesta, a pesar del código exitoso.

Conclusión. Hay soporte formal, pero no hay reenvío real, probablemente debido a filtrado entre el proxy y la red externa o un error en el manejo de la dirección relay. Lección: el código 0x00 no es suficiente; solo la transmisión de extremo a extremo de un datagrama demuestra la funcionalidad.

Caso 4: degradación oculta de HTTP/3

Situación. Todo parece funcionar, los sitios se abren, no hay quejas, pero el equipo nota que las conexiones se establecen más lentamente de lo esperado y HTTP/3 no se utiliza en ninguna parte.

Diagnóstico. La verificación muestra que UDP a través del proxy no pasa, por lo tanto QUIC no está disponible y los clientes degradan silenciosamente a TCP.

Conclusión. Esto no es una avería, sino una pérdida oculta de rendimiento. Comprender el transporte permite decidir conscientemente si QUIC es importante para la tarea y, si es necesario, proporcionar soporte UDP.

FAQ: preguntas frecuentes

¿Se puede transmitir UDP a través de un proxy HTTP de alguna manera?

No, con los métodos estándar no. El método CONNECT en un proxy HTTP crea exclusivamente un túnel TCP y no tiene mecanismo de direccionamiento ni reenvío de datagramas. Cualquier intento de hacer pasar UDP a través de un proxy HTTP puro choca con la ausencia de un protocolo adecuado. Para UDP está diseñado SOCKS5 con el comando UDP ASSOCIATE. Es el camino correcto y estandarizado.

Si el proxy se llama SOCKS5, ¿soporta UDP con certeza?

No, y este es un matiz importantísimo. El estándar prevé UDP ASSOCIATE, pero no exige su implementación obligatoria. Muchos proxies SOCKS5 solo soportan CONNECT. La única forma fiable de asegurarse es realizar una prueba de extremo a extremo con transmisión real de un datagrama, no confiar en el nombre o el marketing.

¿Por qué curl muestra que el proxy funciona pero la llamada no se conecta?

Porque curl verifica TCP mediante el comando CONNECT, mientras que la llamada usa UDP. Son dos transportes diferentes. El éxito de la verificación TCP no dice nada sobre UDP. Para verificar UDP, hay que iniciar UDP ASSOCIATE y transmitir un datagrama, por ejemplo una solicitud STUN, esperando la respuesta.

¿Qué significa el código de respuesta 0x07 al intentar UDP ASSOCIATE?

Es Command not supported. El proxy recibió tu comando, lo reconoció, pero informa que no ejecuta UDP ASSOCIATE. En la práctica, esto significa que el proxy no sabe reenviar UDP. Necesitas otro proxy con soporte real para este comando.

¿Por qué UDP ASSOCIATE usa una conexión TCP si vamos a transmitir UDP?

La conexión TCP de control sirve para dos propósitos. Primero, por TCP pasan de forma confiable la autenticación y la negociación. Segundo, define el tiempo de vida de la asociación UDP: mientras TCP esté abierto, la asociación está activa; tan pronto como se cierra, el proxy libera los recursos. Es una forma elegante de gestionar la sesión y la limpieza.

¿Por qué la comunicación UDP se interrumpe en una red móvil mientras que TCP se mantiene?

Debido a las características de NAT. Para TCP, NAT tiene señales explícitas de inicio y fin, por lo que las entradas viven mucho tiempo. UDP no tiene concepto de conexión, y NAT elimina la entrada después de un corto período de silencio. En las redes móviles, el tiempo de espera UDP es especialmente corto. La solución es un keepalive regular que mantenga el canal activo.

¿Se puede verificar el soporte UDP directamente en el navegador?

No de forma fiable. El navegador accede a los sitios por TCP, y cuando UDP no está disponible, degrada silenciosamente a TCP para QUIC. WebRTC en el navegador tiene lógica compleja y puede usar mecanismos alternativos. Todo esto enmascara el estado real de UDP. Para una verificación limpia, usa pruebas directas con sockets, STUN o DNS a través de UDP ASSOCIATE.

¿Cuál es la diferencia práctica entre socks5 y socks5h?

La diferencia está en dónde se resuelve el nombre de dominio. Con socks5, el nombre suele resolverse localmente del lado del cliente; con socks5h, del lado del proxy. Esto afecta tanto a la privacidad de la resolución como al comportamiento en algunos escenarios. Elegir conscientemente el esquema evita errores difíciles de detectar.

¿Es obligatorio implementar la fragmentación de datagramas en SOCKS5?

En la práctica, no. El campo FRAG está previsto en el estándar, pero la gran mayoría de las implementaciones solo funcionan con FRAG igual a cero, es decir, sin fragmentación. Los datagramas deben caber en un solo paquete. Los protocolos reales que usan UDP suelen operar con datagramas pequeños, por lo que rara vez causa problemas.

¿Cómo distinguir un problema del proxy de un problema del NAT móvil?

Realiza una prueba UDP de extremo a extremo. Si no pasa en absoluto, y el comando devuelve 0x07 o los datagramas no llegan, el problema es del proxy. Si la prueba pasa exitosamente, pero las interrupciones ocurren solo durante las pausas en la operación real, lo más probable es que el culpable sea un tiempo de espera NAT de UDP corto. Este análisis localiza con precisión la fuente.

Conclusión: el transporte lo decide todo

Hemos recorrido un camino desde los conceptos básicos de TCP y UDP hasta los detalles de la encapsulación de datagramas en SOCKS5 y los engañosos tiempos de espera NAT en redes móviles. Resumamos las conclusiones principales que te convierten de un usuario que adivina a ciegas en alguien que entiende exactamente lo que ocurre a nivel de transporte.

Primero, UDP y TCP son dos mundos diferentes. UDP lleva datagramas independientes sin garantías, en aras de la velocidad, y de él dependen las llamadas, los juegos, QUIC y el DNS clásico. Un proxy que sabe reenviar TCP no está obligado a saber UDP.

Segundo, solo SOCKS5 mediante el comando UDP ASSOCIATE proporciona una ruta estándar para UDP. El mecanismo es elegante: una conexión TCP de control, un puerto relay separado y la encapsulación de cada datagrama en un encabezado con los campos RSV, FRAG, ATYP, DST.ADDR y DST.PORT.

Tercero, los proxies HTTP y HTTPS no permiten UDP en absoluto. El método CONNECT crea exclusivamente un túnel TCP; en su arquitectura no hay ni direccionamiento de datagramas, ni puerto relay, ni mecanismo de reenvío UDP.

Cuarto, la etiqueta SOCKS5 no garantiza UDP. Verifica siempre con una prueba de extremo a extremo, llevando la prueba hasta la transmisión real de un datagrama y la recepción de una respuesta. El código 0x00 sin intercambio real no prueba nada, y el código 0x07 informa honestamente de la falta de soporte.

Quinto, en las redes móviles UDP es más caprichoso debido a los cortos tiempos de espera NAT. El keepalive y mantener viva la conexión de control evitan interrupciones misteriosas durante las pausas.

Tus próximos pasos son simples. Determina si necesitas UDP para tu tarea específica, basándote en nuestra tabla de escenarios. Si lo necesitas, asegúrate de trabajar con SOCKS5 y verifica el soporte real de UDP ASSOCIATE con tu propia prueba, ya sea STUN, DNS o un script de sockets directo. Incorpora keepalive y maneja correctamente la dirección relay. Al hacerlo, nunca más te encontrarás en la situación de que el proxy parezca funcionar pero la llamada se quede en silencio. Ahora sabes exactamente dónde buscar la causa y cómo solucionarla a nivel de transporte.