Cómo SOCKS5 UDP ASSOCIATE agotó nuestros puertos y mató DNS

Hace casi un año, implementamos una función del RFC al pie de la letra — y tumbamos producción. Hicimos rollback, investigamos, y encontramos el problema. Spoiler: no era DNS. Éramos nosotros olvidando que los puertos son un recurso finito.

¿Necesita proxies móviles?
¡Cree un proxy ahora mismo!
Comience su prueba gratuita de 48 horas

TL;DR

Agregamos soporte completo de SOCKS5 UDP ASSOCIATE (RFC 1928) a nuestros servidores proxy en iProxy.online. Un par de días después, DNS dejó de resolver, los túneles empezaron a caerse y servicios aleatorios daban timeout. Hicimos rollback y nos pusimos a investigar. La causa raíz fue el agotamiento de puertos efímeros en Linux — miles de asociaciones UDP mantenían un puerto dedicado cada una, drenando todo el pool del sistema. La solución fueron dos parámetros de configuración. Encontrar el problema llevó bastante más tiempo.

¿Qué es SOCKS5 UDP ASSOCIATE?

SOCKS5, definido en RFC 1928, soporta tres comandos: CONNECT (túneles TCP), BIND (aceptar conexiones TCP entrantes) y UDP ASSOCIATE (retransmisión de datagramas UDP). La mayoría de los proveedores de proxy solo implementan CONNECT. UDP ASSOCIATE es el comando difícil — y el que importa para aplicaciones en tiempo real como VoIP, gaming, DNS sobre UDP y QUIC.

Así funciona:

1. El cliente abre una conexión TCP de control hacia el servidor SOCKS5.

2. El cliente envía una solicitud de UDP ASSOCIATE a través de esa conexión TCP.

3. El servidor asigna un socket UDP dedicado en un puerto efímero y responde con la dirección y número de puerto.

4. El cliente envía datagramas UDP a ese puerto de retransmisión. El servidor los reenvía al destino y retransmite las respuestas de vuelta.

5. La asociación se mantiene activa hasta que la conexión TCP de control se cierre o expire el timeout de la sesión.

Cada asociación UDP ocupa un puerto efímero independiente en el servidor. Ese es el detalle crítico.

Y ahí está la trampa. UDP no tiene estado de conexión. No hay FIN, no hay RST. ¿Cómo sabés que el cliente terminó para liberar el puerto?

1. Esperar a que la conexión TCP de control se cierre — la señal del RFC. Pero los clientes pueden mantenerla abierta indefinidamente.

2. Timeout por inactividad. Si no llegan datagramas durante X segundos, la cortás. Pero si el timeout es demasiado alto, los sockets se acumulan.

Configuramos timeouts generosos y no limitamos cuántas asociaciones podía abrir un mismo cliente. Resultado: los sockets se acumularon.

Nuestra infraestructura

En iProxy.online operamos infraestructura de proxy móvil en más de 100 países y 600+ operadores móviles, convirtiendo teléfonos Android reales en servidores proxy. Si el concepto te resulta nuevo, nuestra guía sobre cómo armar una red de proxies 4G cubre la arquitectura en detalle. Nuestros servidores backend SOCKS5 manejan decenas de miles de conexiones simultáneas.

Hace aproximadamente un año, decidimos implementar soporte completo de UDP ASSOCIATE — ser verdaderamente compatibles con el RFC y habilitar casos de uso que la mayoría de los competidores no pueden cubrir: proxying de VoIP, tráfico de juegos, protocolos basados en QUIC. La implementación era correcta. Las pruebas pasaron. Lo desplegamos.

---

Construir infraestructura de proxy a esta escala significa que cada decisión de protocolo tiene consecuencias reales. En iProxy.online, cada dispositivo Android funciona como un servidor proxy móvil independiente — SOCKS5, HTTP y ahora UDP completo — administrado desde un solo dashboard o mediante bot de Telegram. Si querés ver cómo funciona el sistema antes de leer cómo lo rompimos, iniciá una prueba gratis de 48 horas — sin tarjeta de crédito.

---

Qué salió mal

Un par de días después, los servidores de producción empezaron a mostrar síntomas extraños y aparentemente inconexos:

• DNS dejó de resolver. Los servicios internos no podían comunicarse entre sí por hostname.
• Los túneles se cayeron. Se perdió la conectividad de administración hacia los servidores.
• La sincronización NTP falló. Los relojes de los servidores empezaron a desviarse.
• Servicios UDP aleatorios daban timeout sin un patrón claro.

La falla no fue gradual — fue un precipicio. Todo funcionaba bien durante horas y luego múltiples servicios fallaban simultáneamente en el mismo host. Hicimos rollback de UDP ASSOCIATE y empezamos a investigar.

Encontrando la causa raíz

Nuestro instinto inicial fue erróneo. Revisamos ataques DDoS, fugas de memoria, saturación de I/O de disco y carga de CPU — todo normal. Los health checks a nivel aplicación estaban en verde justo hasta el momento en que todo murió.

El avance vino de métricas de bajo nivel del sistema que la mayoría de los equipos nunca revisan:

node_sockstat_UDP_inuse estaba subiendo a decenas de miles. En un servidor sano, este número se mantiene en unos pocos cientos. El nuestro superó los 20K.

Los contadores de ICMP Type 3 Code 3 (puerto inalcanzable) se dispararon. Es el kernel diciendo "no puedo asignar un puerto de origen para este paquete UDP saliente."

Una verificación manual rápida lo confirmó:

ss -u state all | wc -l
# 28,431

cat /proc/net/sockstat
# UDP: inuse 28419

El rango de puertos efímeros en Linux por defecto es 32768–60999 — aproximadamente 28,000 puertos. Habíamos consumido casi todos.

La cascada de fallas

Acá va la cuenta. Linux tiene un pool finito de puertos efímeros — unos 28K por defecto. Cada UDP ASSOCIATE consume uno. Cientos de asociaciones simultáneas más limpieza lenta igual a pool agotado.

Una vez que te quedás sin puertos efímeros, cualquier cosa en el servidor que necesite abrir un nuevo socket UDP falla. Incluyendo DNS — cada consulta DNS saliente necesita un puerto efímero de origen para enviar la solicitud al puerto 53. La resolución de nombres muere, y de repente todo en el servidor está roto por razones que no tienen absolutamente nada que ver con DNS.

La cascada:

Alocación de puertos → cada UDP ASSOCIATE llama a bind() con puerto 0, pidiéndole al kernel el siguiente puerto efímero disponible.

Acumulación de puertos → el puerto queda abierto hasta que la conexión TCP se cierre o expire el timeout de inactividad. Timeouts generosos significan que los puertos se acumulan más rápido de lo que se liberan.

Agotamiento del pool → con miles de asociaciones manteniendo un puerto cada una, el pool entero se drena. bind() empieza a devolver EADDRINUSE para cada nuevo socket.

Falla sistémica → las consultas DNS fallan (systemd-resolved también necesita puertos efímeros). Los handshakes de WireGuard fallan. NTP falla. Syslog sobre UDP falla silenciosamente. Después, la falla de DNS causa una cascada secundaria — todo lo que resuelve hostnames deja de funcionar, incluyendo health checks, conexiones a bases de datos y agentes de monitoreo. El servidor parece "caído" aunque CPU, memoria y disco están bien.

Por qué el monitoreo estándar no lo detectó

Los health checks por HTTP pasaron — el endpoint estaba escuchando. CPU, memoria, disco, throughput: todo normal. Las métricas a nivel proceso no mostraban nada inusual. El proceso SOCKS5 estaba sano. Era el pool de puertos del kernel el que estaba agotado, y nada en un dashboard estándar de Grafana monitorea eso.

Las únicas métricas que lo detectaron fueron las que habíamos agregado casi como ocurrencia tardía: contadores de sockets a nivel kernel y tasas de errores ICMP.

La solución

Lo arreglamos con dos configuraciones. Tardamos más en diagnosticarlo que en solucionarlo.

1. Reducción drástica de los timeouts de inactividad. Bajamos el timeout de inactividad para asociaciones UDP de minutos a segundos. Si no pasan datagramas por el puerto de retransmisión durante un intervalo corto, la asociación se cierra y el puerto se libera. La mayoría de las sesiones UDP legítimas (consultas DNS, NTP) se completan en bastante menos de un segundo. Las sesiones de larga duración (VoIP, gaming) mantienen la asociación activa mediante tráfico continuo, así que no se ven afectadas.

2. Límites de asociaciones simultáneas por cliente. Pusimos un tope a cuántas asociaciones UDP simultáneas puede mantener un solo cliente. Esto evita que un usuario — o un cliente con mal comportamiento — monopolice el pool de puertos. El límite es lo suficientemente generoso para uso legítimo, pero frena la acumulación descontrolada.

En conjunto, estas medidas bajaron UDP_inuse de 28K a unos pocos cientos. Re-desplegamos UDP ASSOCIATE con los nuevos límites, y desde entonces funciona de manera estable.

---

La solución en sí fue sencilla — lo difícil fue construir soporte de SOCKS5 UDP ASSOCIATE capaz de manejar decenas de miles de sesiones simultáneas sin drenar los recursos del sistema. Si necesitás un proxy móvil con relay UDP completo y gestión de ciclo de vida incorporada, iProxy.online corre en dispositivos Android reales en más de 600 operadores, con rotación de IP, control por dispositivo y planes desde $6/mes.

---

Qué deberías estar monitoreando

Si operás cualquier infraestructura que abra sockets UDP a escala — proxies SOCKS5, servidores de juegos, infraestructura VoIP, relays QUIC — agregá esto a tu stack de monitoreo:

1. node_sockstat_UDP_inuse (node_exporter). Sockets UDP abiertos en tiempo real. Un servidor normal se mantiene en unos pocos cientos. Si usás Prometheus, la métrica ya está ahí — solo necesitás un panel y una alerta. Recomendamos alertar por encima de 5,000.

2. node_netstat_Icmp_OutDestUnreachs (ICMP Type 3 Code 3, puerto inalcanzable). Picos significan que el kernel está respondiendo a paquetes UDP que llegan a puertos donde nadie está escuchando. Unos pocos por minuto es ruido. Miles por segundo es un incendio.

3. ss -u state all | wc -l — verificación rápida durante un incidente.

4. cat /proc/net/sockstat — el clásico one-liner sin dependencias.

Estas métricas no están en la mayoría de los dashboards por defecto. Deberían estarlo. Para más información sobre cómo mantener tu infraestructura de proxy saludable, revisá nuestra guía sobre cómo otimizar la velocidad y estabilidad del proxy.

Lecciones aprendidas

Los puertos son un recurso finito — presupuestalos. Presupuestamos CPU, RAM, disco y banda. Nadie presupuesta puertos efímeros. En un servidor que maneja decenas de miles de conexiones, ~28K puertos no es mucho. Podés ampliar el rango con sysctl -w net.ipv4.ip_local_port_range="1024 65535", pero incluso 64K es finito cuando cada asociación mantiene uno indefinidamente.

Los RFC te dicen QUÉ, no CÓMO. El RFC 1928 se escribió en 1996, cuando un servidor "ocupado" manejaba cientos de conexiones. Describe la mecánica del protocolo a la perfección. No dice nada sobre gestión del ciclo de vida de puertos, límites de recursos ni degradación controlada. Si estás implementando cualquier protocolo a escala, leé el RFC para la corrección e ingeniá tu propia gestión de recursos por encima.

Las métricas del kernel detectan lo que las métricas de aplicación no ven. Health checks, scrapers de Prometheus y pings HTTP nos decían que los servidores estaban sanos. El kernel sabía más. Si tu monitoreo no incluye estadísticas de sockets y contadores ICMP, tenés un punto ciego para toda una clase de fallas por agotamiento de recursos. Nos topamos con una brecha de observabilidad similar con fallas silenciosas de TLS 1.3 en nuestra flota de dispositivos Android — causa raíz diferente, misma lección.

UDP necesita gestión explícita de ciclo de vida. TCP tiene ciclo de vida integrado — las conexiones se abren, transfieren datos y se cierran con un handshake definido. Los puertos se reutilizan después de TIME_WAIT. UDP no tiene nada de esto. Un socket queda abierto hasta que algo lo cierre explícitamente. En arquitecturas de retransmisión, tenés que construir tu propio ciclo de vida o aceptar un consumo de recursos sin límite.

Quién más debería preocuparse por esto

Esto no es solo un problema de proxies. Cualquier infraestructura que asigne sockets UDP basándose en solicitudes de usuarios puede chocar contra el mismo precipicio:

• Servidores TURN/STUN para WebRTC — cada relay de medios asigna un par de puertos.
• Servidores de juegos — las sesiones de jugadores pueden mantener un puerto UDP cada una.
• Balanceadores de carga QUIC — la migración de conexiones puede llevar a la acumulación de puertos.
• Resolvers DNS recursivos — cada consulta saliente usa un puerto efímero.
• Concentradores VPN — WireGuard e IPsec IKE dependen de UDP.

Si operás cualquiera de estos a escala — o manejás una granja de proxies móviles — revisá tus números de sockstat hoy. Podrías estar más cerca del precipicio de lo que pensás.

Conclusión

Implementamos SOCKS5 UDP ASSOCIATE correctamente — compatible con el RFC, testeado, desplegado. Y provocó una falla sistémica que nuestro monitoreo estándar no pudo ver.

La conclusión que ahora tratamos como regla absoluta: cualquier funcionalidad que aloca recursos a nivel kernel — puertos, file descriptors, entradas de conntrack — necesita gestión explícita de ciclo de vida y planificación de capacidad desde el día uno. No como un parche después del primer apagón.

Los puertos son como el oxígeno. No los notás hasta que se acaban.

---

Este es un incidente real de producción de iProxy.online. Construimos infraestructura de proxy móvil que convierte teléfonos Android en servidores proxy SOCKS5 y HTTP, operando en más de 100 países y 600+ operadores. Soporte completo de UDP ASSOCIATE incluido — ahora con gestión adecuada de recursos. Crear proxy móvil con iProxy →