Por qué los desarrolladores están reemplazando ngrok con túneles basados en Rust

Si has pasado tiempo desarrollando webhooks, probando APIs o intentando acceder remotamente a un servidor en tu laboratorio casero, conoces el esquema habitual: instalar ngrok, ejecutar un comando, obtener una URL pública que reenvía a tu localhost. Durante años, esta fue la opción predeterminada para la traversión NAT y el túnel local.

Pero hay un cambio en marcha, especialmente entre ingenieros de edge computing, entusiastas de IoT y usuarios de laboratorios caseros. A medida que los productos SaaS comerciales de tunneling añaden más funciones empresariales (y precios elevados), los desarrolladores consideran cada vez más alternativas de código abierto, minimalistas — muchas escritas en Rust.

El frp (Fast Reverse Proxy) basado en Go ha sido durante mucho tiempo la opción open-source dominante, y sigue siendo el proyecto más grande en este espacio por amplio margen. Junto a él, un conjunto más pequeño de herramientas en Rust — rathole, bore, y el servicio alojado tunnelto — han ganado seguidores reales al sacrificar la amplitud de funciones de frp por un tamaño menor y, en el caso de rathole, un comportamiento mejor bajo carga en hardware limitado.

Aquí tienes una mirada honesta a qué hacen bien estas herramientas, dónde la narrativa de “Rust supera a Go” se sostiene, y dónde está sobrevalorada.

La Pregunta del Plan Gratuito: Qué realmente ofrece ngrok en su plan gratuito

Mucho del contenido sobre “cambiar a X” respecto a ngrok repite una afirmación que ya no es precisa desde hace unos años: que los usuarios del nivel gratuito obtienen un subdominio aleatorio que cambia cada vez que el túnel se reconecta. Eso fue cierto en los primeros años de ngrok, pero desde 2023 ngrok asigna a cada cuenta gratuita un dominio de desarrollo persistente (como tu-nombre-asignado.ngrok-free.app) vinculado a la cuenta — permanece igual tras reinicios, y la propia documentación de ngrok confirma que los endpoints gratuitos no tienen timeout de sesión y pueden funcionar indefinidamente como un servicio en segundo plano.

Lo que el plan gratuito no incluye es la posibilidad de escoger tu propio subdominio o traer tu propio dominio — eso está realmente restringido a planes de pago (Hobbyist para un nombre *.ngrok.app personalizado, Pay-as-you-go para tu propio dominio). Así que la verdadera fricción no son URLs rotativas, sino que no puedes marcar o reutilizar un nombre específico sin pagar, y los endpoints TCP requieren una tarjeta de crédito verificada incluso en el nivel gratuito.

Esa distinción importa, porque es la razón real por la que los desarrolladores buscan alternativas — no un mito sobre sesiones de 2 horas o URLs que cambian constantemente.

La Ventaja de Rust en el Edge

El recolector de basura de Go introduce pausas no determinísticas. Esto rara vez se nota en una VM en la nube, pero bajo cargas altas sostenidas en hardware limitado — un router OpenWrt, una Raspberry Pi temprana — las pausas del GC y el crecimiento de buffers pueden elevar el uso de memoria lo suficiente para activar el killer de OOM de Linux.

Rust logra seguridad de memoria sin un recolector de basura, por lo que no hay pausas de GC, y el uso de memoria tiende a mantenerse estable incluso bajo picos de conexión. Combinado con el runtime asíncrono tokio, esto permite que los túneles en Rust envíen binarios pequeños, con pocas dependencias y latencia predecible.

Esa es la teoría. Así se comporta cada herramienta en la práctica.

1. rathole: La Alternativa más Ligera a frp

Creado originalmente por el usuario de GitHub rapiz1 y ahora mantenido por la organización rathole-org, rathole tiene 14,000 estrellas en GitHub y 800 forks al momento de escribir esto, con licencia Apache-2.0.

Qué elimina

rathole elimina intencionadamente el panel web de frp, el balanceador de carga y el sistema de plugins, enfocándose en el reenvío TCP/UDP con una configuración en TOML cliente/servidor.

La afirmación del benchmark, con contexto

El README de rathole indica que logra latencias similares a frp pero maneja más conexiones con menos memoria. Los números específicos provienen del archivo docs/benchmark.md de rathole: en niveles de QPS de 1 a 3,000, rathole y frp mostraron latencias casi idénticas; a 4,000 QPS, frp empezó a reportar errores con latencias que subían a segundos, mientras que la latencia de rathole permaneció estable. Bajo una prueba de carga sostenida de 30 segundos, el uso de memoria de frp creció considerablemente, mientras que el de rathole se mantuvo casi plano.

Dos cosas importantes antes de considerar esto como definitivo: el benchmark se realizó una sola vez, en una sola máquina (una máquina con Arch Linux y doble Xeon E5-2620), en diciembre de 2021, y comparó una versión temprana de rathole contra frp v0.38.0 — una versión ahora aproximadamente 30 versiones atrasada respecto a la línea actual v0.70.x. Además, es una prueba de loopback, que los propios documentos de rathole señalan que refleja rendimiento limitado por CPU en lugar de condiciones reales de red. La tendencia (menor uso de memoria bajo carga) es plausible dada la diferencia arquitectónica GC-vs-no-GC, pero no hay un benchmark independiente y actual que confirme que los números exactos siguen siendo válidos frente a frp moderno.

Características destacadas

• El Protocolo Noise: rathole puede usar opcionalmente el marco Noise Protocol para cifrado en transporte en lugar de gestionar certificados TLS autofirmados. Noise también asegura el handshake de WireGuard, y asegura el transporte cliente-servidor de WhatsApp específicamente — el cifrado de extremo a extremo de WhatsApp es un sistema separado, el Signal Protocol. La comparación con WireGuard es precisa; la comparación con WhatsApp es correcta pero más limitada que “el mismo cifrado que WhatsApp usa para tus mensajes”.
• Binario pequeño: la propia guía de compilación de rathole obtiene un build minimalista en x86_64 de 574 KiB, frente a aproximadamente 10 MiB para frpc compilado de la misma forma.
• Tokens por servicio obligatorios: cada servicio requiere su propio token, postura por defecto de denegar.
• Configurable en caliente: servicios pueden añadirse o eliminarse sin reiniciar.

Estado de mantenimiento

Esta es la corrección más importante: la última versión etiquetada de rathole, v0.5.0, se lanzó el 1 de octubre de 2023 — hace menos de tres años. Eso es preciso respecto a lo que a menudo se afirma. Pero no está abandonado: el repositorio tiene una rama de desarrollo activa con compilaciones automáticas (la más reciente en principios de 2026), y se siguen abriendo issues y PRs en 2025 y 2026. Es más correcto decir que rathole es “estable y con mantenimiento ligero sin nuevas etiquetas estables” que “en evolución activa” o “muerto”.

2. bore: El Túnel TCP Minimalista

Creado por Eric Zhang y con licencia MIT, bore tiene 11,100 estrellas en GitHub y 493 forks, con su última versión (v0.6.0) lanzada en junio de 2025.

La base de código

La implementación completa del cliente y servidor de bore ocupa unas 400 líneas en Rust asíncrono sobre tokio — lo suficientemente pequeño para leerse en una sola sesión.

Cómo funciona

bore local 8000 --to bore.pub

Esto expone el puerto local 8000 en bore.pub:<número aleatorio> usando el servidor público del mantenedor. Para auto-hospedarlo:

bore server

Un detalle de seguridad que vale la pena conocer

bore soporta una bandera opcional --secret (o la variable de entorno BORE_SECRET) que requiere que los clientes prueben poseer un secreto compartido mediante un desafío HMAC antes de aceptar un túnel. Eso es autentificación real para quién puede abrir un túnel a través de tu servidor. Pero según la propia documentación de bore, ese secreto solo cubre el apretón de manos inicial — el tráfico proxy en sí no está cifrado por defecto. Si estás túnelando algo que ya hace su propio TLS (un servidor de desarrollo HTTPS, por ejemplo), eso es importante saber antes de apuntarlo a algo sensible. Esta nuance no aparece en la mayoría de las comparaciones “bore vs ngrok” que circulan en línea.

3. tunnelto: Dos Proyectos Diferentes con un Nombre

Esta es la sección que más necesitaba corrección. “tunnelto” en realidad se refiere a dos proyectos separados y no relacionados, y confundirlos (como es común en artículos comparativos) genera una imagen engañosa.

tunnelto.dev (agrinman/tunnelto en GitHub) es el proyecto open-source, con licencia MIT en Rust. Su última versión se lanzó en 2021, y según su propio sucesor, no ha sido actualizado desde entonces — además, carece de funciones de dominio personalizado, autenticación en endpoints y hosting estático.

tunnelto.me es un servicio hosteado separado y activo que comparte el mismo nombre. Según el propio sitio de tunnelto.me (verificado en junio de 2026), no está basado en el código abandonado de tunnelto.dev — su propia tabla comparativa marca explícitamente a tunnelto.dev como “no mantenido activamente desde 2021.” Los precios de tunnelto.me son:

Plan	Precio	Dominio personalizado	Persistencia del túnel
Gratis	$0	1, incluido	Túneles de 1 hora — hay que recrearlos
Hobbyist	$2/mes	1	Persistente (sobrevive a reinicios)
Plus	$10/mes	3	Persistente
Pro	$20/mes	5	Persistente

Lo realmente notable — y es real — es que un dominio personalizado está incluido en el plan gratuito, algo que la mayoría de competidores (incluyendo ngrok y bore) restringen a niveles de pago. Pero los túneles del plan gratuito expiran tras una hora y hay que recrearlos, que es su propia forma de límite de sesión, solo que en otra forma. Si quieres un túnel que sobreviva toda la noche o un reinicio, necesitas el nivel Hobbyist de $2/mes, no el gratuito. La autenticación del túnel (Bearer/Basic) también es una función de pago, no incluida en el nivel gratuito.

Resumen comparativo

Característica	ngrok	frp	rathole	bore	tunnelto.me
Lenguaje	Go	Go	Rust	Rust	No especificado públicamente
Estrellas en GitHub	— (código cerrado)	~107k	14.0k	11.1k	— (hosteado, código cerrado)
Enfoque principal	SaaS comercial	Auto-hospedado, con muchas funciones	Auto-hospedado, bajo consumo	Auto-hospedado, mínimo TCP	SaaS hospedado, dominios personalizados
Dominio personalizado, nivel gratuito	No (solo dominio de desarrollo persistente)	Sí (auto-hospedado)	Sí (auto-hospedado)	N/A (basado en puerto)	Sí, pero límite de 1 hora
Tamaño del binario/agente	Agente propietario	~10 MiB (frpc)	~574 KiB (build minimalista)	Pequeño, ~400 líneas	Binario nativo (idioma no confirmado)
Cifrado por defecto del tráfico	Sí (HTTPS)	TLS opcional	TLS o Noise opcional	No — solo autenticación en handshake	Sí (HTTPS por defecto)
Última versión	En desarrollo continuo	En desarrollo activo (v0.70.x, 2026)	v0.5.0, oct 2023 (rama de desarrollo activa)	v0.6.0, junio 2025	Mantenido activamente (2026)
Complejidad de configuración	Muy baja	Alta (muchas opciones)	Media (configuración en TOML cliente/servidor)	Cero (un solo comando)	Muy baja

frp: Una palabra justa

Cualquier narrativa de “Rust reemplaza a Go” debe reconocer que frp no es un proyecto estancado o pesado. Actualmente tiene aproximadamente 107,000 estrellas y 15,000 forks, y lanza nuevas versiones menores aproximadamente mensualmente — v0.68 a v0.70 lanzadas en la primera mitad de 2026, con parches de seguridad activos (en abril de 2026 se publicó y corrigió un aviso de bypass de autenticación de severidad moderada). Si tus requisitos van más allá del simple reenvío TCP/UDP — plugins, panel web, gateways SSH, soporte de protocolos más amplio — frp sigue siendo la opción open-source más completa, y “pausas de GC bajo carga extrema” es un compromiso real pero limitado, no evidencia de que el proyecto esté quedando atrás.

Cómo configurar un túnel localhost con bajo RAM (rathole en Raspberry Pi)

Si tienes una Raspberry Pi en casa y un VPS barato en la nube, configurar un túnel rathole toma unos diez minutos.

Paso 1 — Configura el VPS. Descarga el binario de rathole para la arquitectura de tu VPS desde la página de lanzamientos. Crea server.toml:

[server]
bind_addr = "0.0.0.0:2333"

[server.services.my_pi_ssh]
token = "usa_un_secreto_que_solo_tú_conoces"
bind_addr = "0.0.0.0:5202"

Inícialo:

./rathole server.toml

Paso 2 — Configura la Raspberry Pi. Descarga el binario ARM/AArch64. Crea client.toml:

[client]
remote_addr = "TU_IP_VPS:2333"

[client.services.my_pi_ssh]
token = "usa_un_secreto_que_solo_tú_conoces"
local_addr = "127.0.0.1:22"

Inícialo:

./rathole client.toml

Paso 3 — Conecta. Desde cualquier lugar:

ssh pi@TU_IP_VPS -p 5202

Para uso en producción, envuelve ambos comandos en archivos de servicio systemd (el repositorio de rathole incluye ejemplos) para que se reinicien automáticamente al arrancar o fallar. Si quieres cifrado en transporte sin gestionar certificados, añade un bloque [client.transport.noise] / [server.transport.noise] usando el protocolo Noise en lugar de la configuración solo con token — el token solo autentica el servicio, pero no cifra el túnel.

Conclusión

• ¿Necesitas una URL estable para probar webhooks con la menor configuración? tunnelto.me con dominio personalizado gratuito es realmente útil — solo presupuestar los $2/mes si necesitas que dure más de una hora.
• ¿Quieres compartir un puerto TCP con un compañero sin configuración, y te basta que el canal no esté cifrado a menos que tu servicio upstream lo gestione? bore.
• ¿Operas una flota de dispositivos edge con poca RAM y quieres la huella más pequeña con evidencia real (aunque anticuada) de estabilidad bajo carga? rathole — solo no esperes una nueva versión estable pronto.
• ¿Necesitas plugins, un panel, soporte para más protocolos, o ya usas herramientas en Go? frp sigue siendo la opción más completa y continúa en desarrollo activo.
• ¿Requieres funciones empresariales — SSO, políticas de tráfico, logs de auditoría, red de edge gestionada — y no te importa pagar por ellas? Eso es para lo que en realidad sirve ngrok en este momento; su nivel gratuito es más usable de lo que su reputación sugiere, pero no compite en la misma escala que estas herramientas auto-hospedadas.

---

Registro de cambios

• Eliminado todo metadato SEO/afiliado incrustado: notas al pie con nombres de fuente (p.ej. “InstaTunnel”, “tunnelto.me +1”), pies de foto de atribución de stock, y el subtítulo entre paréntesis en el titular original.
• Corregido el reclamo central sobre el nivel gratuito de ngrok: las cuentas gratuitas han usado un dominio de desarrollo persistente desde 2023, no uno rotatorio aleatorio, y los endpoints gratuitos no tienen timeout de sesión según la documentación actual de ngrok. La verdadera limitación del nivel gratuito es no poder escoger un nombre/dominio personalizado, no la rotación de URLs. (Fuente: docs de ngrok, “Límites del plan gratuito” y artículo “Dominios de desarrollo estáticos”)
• Verificado y actualizado los conteos de estrellas/forks en GitHub a hoy: frp ~107k estrellas/15k forks (el borrador decía “106,000+” y sigue siendo correcto, pero actualizado); rathole 14.0k estrellas/800 forks (el borrador “~14,000” sigue válido); bore 11,100 estrellas/493 forks (el borrador decía “casi 10,000”, ahora más alto).
• Verificado los números de benchmark QPS/latencia de rathole (3,000 vs. 4,000 QPS) directamente contra docs/benchmark.md de rathole, y añadido el contexto metodológico faltante: prueba en una sola máquina en diciembre de 2021, realizada por los propios mantenedores de rathole contra frp v0.38.0 (ahora aproximadamente 30 versiones desactualizadas), no una comparación independiente y actual.
• Corregido el tamaño mínimo del binario de rathole: la propia guía de compilación del proyecto documenta un build minimalista en 574 KiB (vs. la cifra de ~500 KiB en el borrador, que era correcta en línea general pero no la cifra documentada), comparado con un build de frpc de aproximadamente 10 MiB.
• Corregido/nutido el reclamo sobre el Protocolo Noise: Noise sí asegura el handshake de WireGuard y el transporte cliente-servidor de WhatsApp, pero el cifrado de extremo a extremo de WhatsApp usa específicamente el Signal Protocol separado — la frase original implicaba que Noise cifraba los mensajes de WhatsApp directamente.
• Corregido el estado de mantenimiento de rathole: confirmado que v0.5.0 (1 de octubre de 2023) es la última versión etiquetada, pero añadido que el proyecto tiene una rama de desarrollo activa y actividad en issues/PRs hasta 2025–2026, en lugar de parecer completamente abandonado.
• Añadido una corrección de equidad sobre frp: está en desarrollo activo (versiones mensuales en 2026, parches recientes de seguridad), no el proyecto estancado o pesado que sugiere la narrativa “Rust reemplaza a Go”.
• Añadido un hecho de seguridad que faltaba para bore: su bandera opcional --secret autentica el handshake del túnel vía HMAC, pero no cifra el tráfico proxy por defecto — advertencia importante para cualquier cosa que no sea ya TLS en upstream.
• Corregido una confusión importante: el borrador trataba a “tunnelto” como un solo proyecto con núcleo open-source (tunnelto.dev) y capa hospedada. En realidad, son dos proyectos separados y no relacionados con nombres similares. tunnelto.dev (agrinman, MIT, Rust) ha estado inactivo desde 2021. tunnelto.me es un servicio comercial activo; su idioma de implementación no está documentado públicamente, por lo que la afirmación “escrito en Rust” fue eliminada para ese producto específicamente.
• Corregido la afirmación sobre el dominio personalizado en el nivel gratuito de tunnelto.me: confirmado en la página de precios que los túneles en nivel gratuito están limitados a sesiones de 1 hora y hay que recrearlos; solo el nivel Hobbyist de $2/mes y superior ofrece túneles persistentes. La afirmación original implicaba que el dominio personalizado gratuito no tenía esa limitación.
• Ampliado la tabla comparativa con estrellas en GitHub, estado de cifrado por defecto y fechas de última versión para cada herramienta, todos basados en los repositorios/documentos principales a hoy.
• Ampliado con una sección “palabra justa para frp” y aclaraciones en las recomendaciones finales, reflejando los hechos corregidos arriba.