La Exodus UDP: Por qué los desarrolladores de juegos abandonan los proxies HTTP

Durante casi una década, cuando un desarrollador necesitaba exponer una aplicación local a internet sin complicaciones de redireccionamiento de puertos, la respuesta casi siempre era la misma: simplemente usa ngrok. Ya fuera para probar webhooks, compartir un servidor web local con un cliente, o demostrar una nueva API REST, ngrok era el rey indiscutible de los túneles locales. Era rápido, confiable y estaba profundamente integrado en la caja de herramientas del desarrollador web moderno.

Pero mientras los desarrolladores web celebraban, una subcultura enorme y en rápido crecimiento de desarrolladores quedó en gran medida en la oscuridad. Desarrolladores de juegos, ingenieros VoIP y arquitectos IoT que dependían de comunicaciones en tiempo real y de baja latencia descubrieron rápidamente un obstáculo: ngrok está diseñado para tráfico HTTP, HTTPS, TCP y TLS. Nunca soportó UDP (User Datagram Protocol), y eso sigue siendo así hoy.

Esta limitación arquitectónica ha provocado un cambio real en el panorama del tunneling. Miles de hosts de servidores de Minecraft, Valheim, Palworld y CS2 han migrado desde proxies solo TCP en busca de un túnel UDP localhost confiable. Al hacerlo, están redescubriendo (o redescubriendo) una generación de herramientas de red diseñadas específicamente para llenar ese vacío.

Al observar herramientas enfocadas en juegos como Playit.gg junto a plataformas multi-protocolo como Localtonet, se evidencia claramente por qué ocurre este cambio. En esta guía, desglosaremos la brecha técnica entre TCP y UDP, explicaremos por qué CGNAT forzó toda esta conversación, compararemos Playit.gg vs ngrok, y analizaremos con precisión dónde se posicionan Localtonet UDP y Cloudflare Tunnel en 2026.

---

1. La brecha técnica: Por qué los desarrolladores de juegos exigen UDP

Para entender por qué los desarrolladores de juegos se alejan de proxies HTTP y TCP, es útil comprender las diferencias fundamentales en cómo se mueven los datos por internet.

El handshake TCP: Confiable pero lento

TCP (Transmission Control Protocol) es la columna vertebral de la web. Alimenta HTTP, lo que significa que cada sitio web que visitas, cada email que envías y cada archivo que descargas depende de él. TCP está diseñado para la confiabilidad. Antes de enviar un solo byte de datos, TCP requiere un handshake de tres vías (SYN, SYN-ACK, ACK) entre cliente y servidor. También garantiza la entrega: si un paquete se pierde en tránsito, TCP detiene el flujo, solicita una retransmisión y espera a que llegue la pieza faltante.

Para navegar en la web, esto es exactamente lo que quieres. No quieres que se cargue a medias una imagen, o que una transacción bancaria tenga un decimal perdido. Para los juegos, esa misma confiabilidad se vuelve un problema.

UDP: El protocolo de velocidad en tiempo real

UDP (User Datagram Protocol) elimina esa sobrecarga. No hay handshake, no hay reconocimiento y no hay retransmisión. El servidor envía paquetes al cliente lo más rápido posible, y si uno se pierde, simplemente continúa.

En un juego multijugador rápido como Counter-Strike 2, o en un título sandbox como Minecraft Bedrock Edition, el servidor transmite constantemente actualizaciones sobre posiciones de jugadores y estado del mundo. Si un paquete con la coordenada de un jugador en milisegundo 100 se pierde, reenviarlo sería inútil — para cuando llegue, el juego ya está en milisegundo 150, y los datos antiguos están obsoletos.

Debido a que ngrok solo expone endpoints HTTP, HTTPS, TCP y TLS, enrutar un servidor de juego UDP nativo a través de él directamente no es posible — no existe un tipo de endpoint UDP para enrutar tráfico en primer lugar. Intentar forzar tráfico de Minecraft Bedrock (que usa UDP en el puerto 19132) a través de un proxy solo TCP generalmente significa que la conexión simplemente no se establece, en lugar de “funcionar pero con lag”.

---

2. La desaparición del redireccionamiento de puertos y el auge de CGNAT

En los primeros días del hosting de juegos, los desarrolladores no necesitaban software de tunneling. Si querías hospedar un servidor de Minecraft desde tu habitación, ingresabas a tu router, buscabas la pestaña “Port Forwarding” y abrías el puerto 25565 (TCP, Java Edition) o 19132 (UDP, Bedrock Edition) a la IP local de tu máquina.

Hoy, eso en gran medida ha desaparecido, por tres razones:

1. Carrier-Grade NAT (CGNAT): El espacio de direcciones IPv4 se agotó hace años. Para hacer frente, los ISPs comenzaron a enrutar muchas viviendas a través de una IP pública compartida mediante CGNAT. Como no controlas el router upstream del ISP, a menudo no puedes hacer port forwarding — no hay un puerto en tu propio router que llegue a internet.
2. Riesgo de seguridad: Abrir puertos en una red doméstica expone los dispositivos directamente a internet, donde escáneres automatizados buscan puertos abiertos constantemente.
3. IPs dinámicas: La mayoría de las IPs residenciales cambian periódicamente, por lo que compartir una IP en crudo con los jugadores requiere actualizarla cada vez que se renueva el contrato.

Estos desafíos hicieron que los túneles locales fueran necesarios: un agente ligero en tu máquina abre una conexión segura y saliente a un relé en la nube. Como la conexión es saliente, evita CGNAT y las reglas de firewall entrantes del router. El relé en la nube te proporciona una dirección pública estable y reenvía el tráfico de vuelta por el túnel.

Ngrok perfeccionó este patrón para HTTP y TCP. Los desarrolladores de juegos necesitaban la misma arquitectura, diseñada para UDP.

---

3. Playit.gg vs ngrok: Un choque de filosofías

Ngrok: La herramienta para desarrolladores web

Ngrok es una plataforma grande, respaldada por inversión, creada para equipos de software que prueban integraciones de webhook, aseguran APIs internas y hacen demos de aplicaciones web.

• Protocolos: HTTP, HTTPS, TCP, TLS.
• Soporte UDP: Ninguno, en ningún nivel.
• Audiencia objetivo: DevOps e ingenieros de software, no gamers.
• Precios (2026): Nivel gratuito — 1 GB de transferencia y 20,000 solicitudes HTTP por mes, hasta 3 endpoints en línea. Hobbyist — $10/mes ($8/mes si se factura anualmente), 5 GB de transferencia incluidos, 100,000 solicitudes HTTP. Pago por uso (producción) — $20/mes base, con sobrecarga medida ($0.10/GB, $1 por 100k solicitudes). Ninguno de estos niveles soporta UDP.

Playit.gg: El proxy para gamers

Playit.gg es un proxy global especializado, diseñado específicamente para ayudar a las personas a hospedar servidores de juegos sin redireccionamiento de puertos.

• Protocolos: TCP y UDP, ambos disponibles en el nivel gratuito, enrutados a través de la red “Global Anycast” de Playit.
• Audiencia objetivo: desarrolladores indie, administradores de servidores Minecraft, entusiastas de homelabs.
• Red: Servidores en Norteamérica, Europa y Asia. Los túneles gratuitos usan enrutamiento anycast, que es conveniente pero no siempre óptimo — un jugador en Norteamérica puede ser enrutado a través de una región lejana.
• Cliente: El agente es de código abierto (playit-cloud/playit-agent en GitHub), lo cual es una ventaja de transparencia frente al cliente cerrado de ngrok.

Para un compartir localhost de servidor Minecraft, Playit.gg es casi como un varita mágica: descarga el agente, ejecútalo y en segundos tendrás una dirección pública como tus-nombre.playit.gg.

Corrección a un concepto erróneo común: UDP en sí no está restringido a la capa de pago de Playit. La documentación de soporte de Playit describe que Premium ($3/mes, o aproximadamente $30/año) desbloquea túneles regionales (para que los jugadores se conecten a un datacenter cercano en lugar de enrutamiento anycast), dominios personalizados y externos (tres incluidos), puertos/firewalls/agentes adicionales, y túneles HTTPS específicamente. Los túneles básicos TCP y UDP para juegos están en el nivel gratuito. Comparaciones independientes en 2026 describen comúnmente la asignación gratuita como unos pocos túneles TCP y UDP (frecuentemente hasta cuatro de cada uno), aunque Playit no publica ese número exacto como garantía permanente, y los reportes comunitarios sugieren que la asignación gratuita ha cambiado con el tiempo — así que trata cualquier número específico como “generoso pero no contractual”.

El veredicto: Estas herramientas cumplen funciones distintas. Si estás construyendo una app web y necesitas inspección de solicitudes, ngrok sigue siendo la plataforma más madura para eso. Si estás hospedando un servidor de juegos, ngrok no es una opción por motivos de protocolo, y Playit.gg está diseñada específicamente para ese vacío.

---

4. Localtonet UDP: La potencia de pila completa

Si eres un desarrollador full-stack que ejecuta un backend en Node.js que recibe webhooks HTTP y un servidor de juegos UDP en tiempo real, usar dos servicios de tunneling separados puede ser costoso y complicado rápidamente. Ahí es donde se posiciona Localtonet.

Por qué Localtonet atrae a desarrolladores full-stack e indie

Localtonet es una plataforma de proxy inverso y tunneling multi-protocolo. A diferencia de ngrok, que no tiene soporte UDP, y de Playit.gg, diseñada para juegos, Localtonet apunta a una variedad más amplia de cargas de trabajo.

1. Soporte multi-protocolo: HTTP, HTTPS, TCP y UDP nativo, incluyendo túneles combinados TCP+UDP — útil para juegos que autentican sobre TCP pero envían datos de juego sobre UDP.
2. Modelo de precios: Localtonet no vende una suscripción mensual fija. Usa un saldo prepago que se consume solo mientras un túnel está activo, a aproximadamente $2 por túnel al mes, prorrateado por hora. Detén el túnel y el saldo deja de disminuir — ejecutar un túnel dos semanas cuesta unos $1, no $2. En túneles pagos, el ancho de banda es ilimitado y la facturación se basa solo en tiempo de ejecución, no en volumen de datos.
3. Nivel gratuito: 1 túnel (tu elección de HTTP, TCP o UDP), 1 GB de ancho de banda mensual y un timeout de 30 minutos — suficiente para una prueba rápida, no para hospedar un servidor persistente.
4. Otras funciones: SSL integrado con Let’s Encrypt, SSO, inspector de webhooks y una función de proxy móvil en Android que permite que la conexión del operador actúe como IP saliente — útil para probar cómo funciona una app móvil o servicio web en redes de operadoras reales en lugar de una ISP doméstica.

Cómo maneja Localtonet UDP

Al configurar un túnel UDP, Localtonet te proporciona un endpoint público (por ejemplo, us-east.localtonet.com:34512). Los jugadores no instalan nada — simplemente se conectan a esa dirección. El agente de Localtonet en tu máquina recibe los paquetes UDP a través de un túnel cifrado y los reenvía a tu puerto local (por ejemplo, 19132).

Esto hace que Localtonet sea útil mucho más allá de los juegos: endpoints VPN WireGuard detrás de CGNAT, servidores de señal WebRTC y ingestión de telemetría IoT basada en UDP son usos razonables del mismo mecanismo.

---

5. Guía paso a paso: Compartir localhost de un servidor Minecraft

Así es como se configura en la práctica, usando Minecraft Bedrock (UDP, puerto 19132) como ejemplo.

Método A: Usando Playit.gg

1. Hospeda el servidor: Inicia tu servidor dedicado de Minecraft Bedrock localmente. Por defecto se enlaza a 127.0.0.1:19132 (UDP).
2. Instala el agente: Descarga el agente de Playit.gg para Windows, Linux o macOS.
3. Reclama el agente: Ejecútalo. Muestra un enlace de reclamación en la terminal; ábrelo para asociar el agente con tu cuenta de Playit.gg.
4. Crea un túnel: En el panel web, haz clic en “Agregar Túnel” y selecciona el preset de Minecraft Bedrock. Esto está disponible en el nivel gratuito — no necesitas premium para un túnel UDP estándar. Premium solo si quieres enrutamiento regional, dominio personalizado o más túneles simultáneos.
5. Comparte la dirección: Playit genera una dirección estática (ejemplo, tus-nombre.playit.gg) y puerto. Compártela, y amigos podrán unirse sin configurar el router.

Método B: Usando Localtonet

1. Hospeda el servidor: Asegúrate de que tu servicio UDP local esté en marcha.
2. Regístrate y obtén un AuthToken: Regístrate en Localtonet y copia tu AuthToken desde el panel.
3. Instala Localtonet: Descarga el cliente (GUI para Windows, CLI para Linux/Docker).
4. Configura el túnel UDP:
   • Ve a la página TCP-UDP en el panel.
   • Selecciona UDP como tipo de protocolo.
   • Ingresa tu puerto local (19132).
   • Elige la región del datacenter más cercana a tus jugadores para reducir latencia.
5. Inicia el túnel: Pega tu AuthToken en el cliente y ejecútalo. En el nivel gratuito, esta sesión expirará en 30 minutos; para un servidor persistente, deberás financiar el túnel desde tu saldo pagado.
6. Conecta: Los jugadores ingresan la dirección generada en su cliente de juego, y el tráfico UDP fluye hacia tu máquina.

---

6. Más allá de los juegos: Casos de uso en expansión para túneles UDP

El sector de juegos — especialmente las comunidades de Minecraft y Valheim — ha sido el catalizador más visible de este cambio, pero la demanda de un sólido túnel localhost UDP se extiende mucho más allá de la infraestructura empresarial y hobby.

WebRTC y desarrollo VoIP

Las aplicaciones modernas de voz y video dependen de WebRTC, que usa UDP para flujos multimedia peer-to-peer. Si estás construyendo un clon de Zoom o un bot de Discord localmente, probar audio a través de un túnel solo TCP introduce buffering artificial que distorsiona el rendimiento real. Un túnel UDP te permite probar SIP, RTP y tráfico WebRTC con precisión.

Una herramienta que se sugiere frecuentemente aquí pero que en realidad no resuelve el problema: Tailscale Funnel. Funnel solo soporta TCP/HTTPS — proxy de tráfico TLS en puertos públicos fijos (443, 8443 y 10000) y no tiene soporte UDP. Una solicitud de función para soporte UDP ha estado abierta en GitHub de Tailscale desde 2023 sin resolución hasta ahora. Si tu carga de trabajo es realmente UDP, Funnel no es la herramienta, independientemente de cuántas veces aparezca en listas de “alternativas a ngrok”.

VPNs y redes Zero-Trust

WireGuard, el estándar moderno para VPNs ligeras, opera exclusivamente sobre UDP. Si quieres correr un nodo WireGuard en un NAS doméstico detrás de CGNAT, el port forwarding tradicional no funciona. Vincular un túnel UDP a tu puerto de WireGuard es una solución alternativa sin configurar routers.

IoT y telemetría

Los dispositivos IoT — estaciones meteorológicas, sensores industriales, flotas de drones — usan frecuentemente UDP para transmitir telemetría porque consume menos batería y ancho de banda que TCP. Los servidores de ingestión para estas flotas necesitan túneles UDP para recibir streams externos sin exponer infraestructura interna directamente.

---

7. Cloudflare Tunnel: ¿Qué soporte tiene realmente para UDP?

Cloudflare Tunnel (cloudflared) aparece constantemente en discusiones de “alternativa a ngrok” porque es gratuito sin límite de ancho de banda para tráfico HTTP/HTTPS. La realidad en UDP es más matizada que un simple sí o no.

Para servicios públicos — como un servidor de Minecraft al que se conectan jugadores aleatorios — Cloudflare Tunnel no soporta UDP. La función de enrutamiento de hostname público que expone un servicio a visitantes anónimos solo funciona con HTTP(S)/TCP. Intentar enrutar tráfico Bedrock o Valheim fallará, igual que con ngrok.

Donde se vuelve más matizado: Cloudflare sí soporta UDP, pero solo dentro de su modelo de red privada Zero Trust — Tunnel junto con el cliente WARP de Cloudflare. Esto permite a una organización acceder a servicios UDP internos (como un resolver DNS interno) desde dispositivos inscritos en su organización Zero Trust. No es útil para hospedar un servidor de juegos público, porque cada jugador que se conecta necesitaría instalar y autenticar WARP primero — lo opuesto a “los amigos simplemente se conectan a una dirección”.

También vale corregir la afirmación común de que Cloudflare Tunnel siempre requiere tener un dominio y cambiar los DNS. Eso es cierto para túneles nombrados con hostname personalizado persistente — lo que realmente querrías para un servicio de larga duración. Pero Cloudflare también ofrece Quick Tunnels vía trycloudflare.com, que no requieren dominio, ni cuenta, ni cambios en DNS. La desventaja es que Quick Tunnels solo soportan HTTP, generan un subdominio aleatorio que cambia cada vez que reinicias, limitan solicitudes en vuelo y están claramente destinados a pruebas o demos, no a hosting persistente.

---

8. Conclusión: Adaptarse a la nueva realidad del compartir localhost

La era de los túneles locales de tamaño único ha terminado. Ngrok sigue siendo una herramienta sólida para pruebas de webhooks y desarrollo web, pero nunca cubrió la brecha de UDP, y ni Cloudflare Tunnel ni Tailscale Funnel lo hacen para tráfico público.

El CGNAT ha hecho que el port forwarding tradicional sea poco confiable o imposible para gran parte de las conexiones domésticas, y las aplicaciones en tiempo real simplemente no funcionan bien sobre TCP. Esa combinación impulsa a los desarrolladores hacia herramientas nativas de UDP.

El mercado se ha segmentado en opciones especializadas. Para hosting sencillo de servidores de juegos, el nivel gratuito de Playit.gg ya cubre TCP y UDP — lo que se paga en premium es principalmente por mejor enrutamiento y dominios personalizados, no por acceso UDP en sí. Para desarrolladores que quieren una plataforma que maneje webhooks, servicios TCP y streams UDP en una sola plataforma, el modelo de pago por uso de Localtonet (con un nivel gratuito limitado) es una opción razonable, siempre que entiendan su timeout de 30 minutos y su estructura de precios por túnel en ejecución, no una suscripción fija.

A medida que los juegos multijugador, las comunicaciones WebRTC y la escasez de IPv4 siguen avanzando en esa dirección, entender qué herramienta soporta UDP — y en qué condiciones — es más importante que nunca.

---

Referencias

• Documentación ngrok: Pricing and Limits — ngrok.com/docs/pricing-limits
• Soporte Playit.gg: Playit Premium — playit.gg/support/playit-premium
• Sitio oficial Playit.gg: Haz público tu servidor de juegos — playit.gg/pricing
• Blog Cloudflare: Extendiendo la plataforma Zero Trust de Cloudflare para soportar UDP y DNS interno
• Changelog Cloudflare: Mejoras en UDP (Julio 2025)
• Documentación Cloudflare: Quick Tunnels (TryCloudflare)
• Blog Localtonet: Precios de Localtonet — Paga solo cuando tu túnel está en funcionamiento
• GitHub Tailscale: Issue #8868, FR: soporte UDP en Tailscale Funnel/serve

---

Historial de cambios

Corregido: 1. Limitación UDP en Playit.gg (error factual). El borrador indicaba que el nivel gratuito solo soporta juegos TCP (por ejemplo, Minecraft Java) y que un plan premium de $3/mes era necesario para “desbloquear” el enrutamiento UDP para juegos como Palworld, Valheim y Bedrock. Esto es incorrecto. Según la documentación de soporte de Playit.gg, Premium desbloquea túneles regionales, dominios externos y personalizados, más puertos/firewalls/agentes, y túneles HTTPS — no el acceso al protocolo UDP en sí. Ambos túneles TCP y UDP están disponibles en el nivel gratuito. Corregido en la Sección 3 y en los pasos del Método A en la Sección 5. 2. Afirmación sobre UDP en Cloudflare Tunnel (simplificada). El borrador afirmaba que Cloudflare Tunnels no soporta UDP. Esto es cierto para tráfico público (el caso relevante para servidores de juegos), pero no toda la historia — Cloudflare soporta UDP dentro de su modelo de red privada Zero Trust mediante el cliente WARP, que requiere que los dispositivos estén inscritos en la organización Zero Trust. Añadido este matiz en la Sección 7, basado en el blog y changelog de Cloudflare. 3. Requisito de dominio en Cloudflare Tunnel (simplificado). El borrador indicaba que Cloudflare Tunnels “exigen” un dominio y cambio de DNS. Corregido para señalar que Quick Tunnels (trycloudflare.com) no requieren dominio ni DNS, aunque son solo HTTP, efímeros y no para hosting persistente — el requisito de dominio/DNS aplica a túneles nombrados y persistentes. 4. Precios de ngrok (verificación necesaria). Actualizado para coincidir con los niveles documentados en 2026: Gratuito (1GB/mes, 20k solicitudes, 3 endpoints), Hobbyist ($10/mes o $8/mes anual, 5GB), Pago por uso ($20/mes base + sobrecarga). La cifra de “$10/mes, 5GB” era correcta para Hobbyist, pero faltaba contexto de nivel gratuito y pago por uso. Verificado en ngrok.com/docs/pricing-limits; confirmado que no existe un endpoint UDP en ningún nivel. 5. Modelo de precios de Localtonet (simplificado). El borrador describía Localtonet como “$2 por túnel al mes” con ancho de banda ilimitado como afirmación general. Aclarado que esto es un saldo prepago, cobrado solo mientras un túnel está activo (prorrateado), no una suscripción fija, y que el ancho de banda ilimitado aplica a túneles pagados/en ejecución — el nivel gratuito está limitado a 1 túnel, 1GB/mes y timeout de 30 minutos. Esta distinción importa para presupuestar un servidor persistente.

Añadido: 6. Nota sobre la falta de soporte UDP en Tailscale Funnel (Sección 6), ya que se sugiere frecuentemente como alternativa a ngrok para tráfico en tiempo real, pero solo soporta TCP/HTTPS, con puertos fijos y solicitud de función en GitHub desde 2023. 7. Clarificación de que la brecha de protocolo de ngrok causa que las conexiones UDP fallen al establecerse, no que “funcionen con picos de latencia”. 8. Se señala que el cliente de Playit.gg es de código abierto, y que el enrutamiento en nivel gratuito usa anycast global (vs. enrutamiento regional en Premium) — contexto relevante para solucionar problemas de ping.

Eliminado: 9. Eliminadas citas a blogs de marketing de terceros (usados en el borrador original para respaldar afirmaciones técnicas generales) en favor de fuentes primarias: ngrok oficial, Playit.gg, Cloudflare, Localtonet y publicaciones/blogs de Tailscale. 10. Se eliminó toda metadata de archivos fuente; el formato se normalizó a Markdown limpio.