rathole vs. frp vs. ngrok: Lo que realmente muestran los benchmarks

CGNAT y el agotamiento de IPv4 han hecho que “simplemente abrir un puerto en tu router” sea una opción inviable para la mayoría de conexiones domésticas y muchas implementaciones en la nube también. Si estás probando webhooks, ejecutando un servicio en un homelab, o gestionando dispositivos IoT remotos, necesitas algo que gestione la traversa NAT por ti. Tres nombres aparecen constantemente en esa conversación: ngrok, frp y el más nuevo en Rust, rathole. Aquí te explicamos qué hace cada uno realmente, y — dado que mucho del entusiasmo en línea por rathole proviene de copiar y pegar las mismas fuentes — qué dicen realmente los números detrás de esas afirmaciones.

ngrok: conveniente, centralizado y con límite de ancho de banda

La propuesta de ngrok no ha cambiado: ejecuta un comando, obtén una URL pública HTTPS que apunta a tu servidor local, sin necesidad de un servidor propio. Esa conveniencia proviene de enrutar tu tráfico a través de la red de borde de ngrok, donde también residen sus limitaciones.

A partir de 2026, la capa gratuita de ngrok limita a 1 GB de ancho de banda mensual con un solo endpoint activo, y reasigna un subdominio .ngrok-free.app aleatorio cada vez que reinicias el agente — un problema real si apuntas un webhook a él. El tráfico HTML en la capa gratuita también muestra una página de advertencia intersticial (que se puede saltar mediante un encabezado API, pero no para demos en navegador). Los subdominios personalizados requieren un plan de pago, comenzando en la capa Personal (8$/mes, 5 GB, luego 0.10$/GB adicional), pasando por Pro (20$/mes, 15 GB) y Enterprise (39$/mes), con precios basados en uso desde 18$/mes para cargas de trabajo en producción.

La limitación más estructural es el soporte de protocolos: ngrok aún no soporta túneles UDP nativos, en ninguna capa. Eso lo descarta para servidores de juegos, VoIP y protocolos IoT como CoAP o MQTT-over-UDP — solo soporta HTTP, HTTPS, TCP y TLS. Donde ngrok sigue siendo realmente fuerte es en las funciones alrededor del túnel: reproducción de solicitudes, inspección de tráfico, verificación de webhooks, control de OAuth/SAML/OIDC, y una API pulida para gestionar el ciclo de vida del túnel — cosas que frp o rathole no intentan replicar.

frp: maduro, en desarrollo activo y más grande que cualquiera de las alternativas

frp (Fast Reverse Proxy), escrito en Go, es la opción autohospedada de larga data: ejecutas frps en un VPS con IP pública y conectas frpc desde detrás del NAT. Es importante ser precisos sobre el estado actual de frp, porque mucho del discurso en línea que dice “frp está obeso e inseguro” lleva años desactualizado.

frp está en desarrollo muy activo — la versión v0.70.0 se lanzó el 11 de julio de 2026, y el proyecto tiene aproximadamente 106,000+ estrellas en GitHub con unas 15,000 bifurcaciones, una orden de magnitud mayor que cualquier alternativa en Rust en este espacio. La encriptación TLS está habilitada por defecto desde v0.50.0, y las configuraciones modernas usan TOML, YAML o JSON (el antiguo formato INI está en desuso). La autenticación soporta tokens estáticos y OIDC.

Sobre la preocupación de “los clientes pueden abrir puertos arbitrarios”: eso solo es cierto en el sentido de que frp no restringe la vinculación de puertos por defecto. La configuración del servidor soporta la directiva allowPorts que permite una lista blanca de rangos de puertos permitidos, además de un límite maxPortsPerClient; pero esto es opcional, no la configuración predeterminada. Si despliegas frp sin establecer allowPorts, un cliente con un token válido puede solicitar cualquier puerto en el servidor. Es un aspecto operativo importante a señalar en cualquier guía de despliegue de frp, aunque es un error de configuración, no un fallo arquitectónico.

La crítica a la recolección de basura (GC) es real a nivel arquitectónico — el GC de Go introduce pausas no determinísticas que un lenguaje sin GC evita por diseño — pero vale la pena compararlo con el hecho de que frp ha escalado a cientos de miles de despliegues en producción con esa arquitectura. Si las pausas del GC importan en tu caso, dependerá mucho de tu patrón de tráfico, no solo del lenguaje.

rathole: realmente rápido, pero prácticamente sin mantenimiento desde 2023

Aquí es donde la narrativa de “destitución” necesita la mayor corrección. rathole, originalmente creado por el usuario de GitHub rapiz1 y ahora mantenido por la organización rathole-org, es un proxy inverso en Rust diseñado como una alternativa más ligera a frp: solo reenvío TCP/UDP, sin servidor web integrado, sin balanceador de carga, sin sistema de plugins.

El estado de mantenimiento importa más que los benchmarks. La última versión etiquetada de rathole, v0.5.0, se lanzó el 1 de octubre de 2023. A mediados de 2026, eso significa casi tres años sin una nueva versión, y es un tema activo en su comunidad preguntar si ha surgido una alternativa mejor mantenida. El repositorio tiene 13.9k estrellas y 791 bifurcaciones — un proyecto real y respetado, pero aproximadamente una décima del tamaño y comunidad de frp, y sin la cadencia de lanzamientos de frp. No es descalificante para un proyecto hobby en un Raspberry Pi, pero sí implica un perfil de riesgo diferente respecto a “el estándar moderno” que se suele presentar, especialmente para infraestructura de producción.

Lo que rathole sí ofrece, en realidad:

• Binario pequeño. La guía oficial de compilación reduce el binario a unos 500 KiB para objetivos embebidos — realmente pequeño, y una ventaja en routers con espacio limitado.
• Tokens por servicio obligatorios. Cada servicio en cliente y servidor necesita su propio token; no hay un equivalente a la “confianza por defecto” de frp en la vinculación de puertos no whitelistados.
• Soporte para Noise Protocol, como alternativa a TLS, evitando la gestión de certificados.
• Configuración recargable en caliente — los servicios pueden añadirse o eliminarse sin reiniciar el proceso.

Configuración

El formato de configuración real de rathole (según la documentación del proyecto) es TOML, dividido entre archivos cliente y servidor:

Servidor (server.toml, en tu VPS público):

[server]
bind_addr = "0.0.0.0:2333" # Puerto en el que rathole escucha para el cliente

[server.services.mi_nas_ssh]
token = "usa_un_secreto_que_solo_tú_conoces"
bind_addr = "0.0.0.0:5202" # Puerto público que expone el servicio

Cliente (client.toml, detrás del NAT):

[client]
remote_addr = "miservidor.com:2333"

[client.services.mi_nas_ssh]
token = "usa_un_secreto_que_solo_tú_conoces" # Debe coincidir con el del servidor
local_addr = "127.0.0.1:22"

Ejecuta ./rathole server.toml en el VPS y ./rathole client.toml en el host local, y ssh miservidor.com:5202 llega al NAS. El modelo de token por servicio es la mejora de seguridad clara respecto a la configuración predeterminada de frp.

El benchmark que todos citan — y sus verdaderas advertencias

Los números detrás de “rathole aplasta a frp bajo carga” son reales, pero provienen de una única fuente: el propio docs/benchmark.md de rathole, fechado el 28 de diciembre de 2021, ejecutado en una sola máquina (una caja con Arch Linux, doble Xeon E5-2620 y 16 GB RAM), comparando un commit de desarrollo temprano de rathole contra frp v0.38.0 — una versión aproximadamente 30 versiones atrás de la v0.70.0 actual de frp. También es un benchmark de loopback, que los propios documentos de rathole señalan que refleja rendimiento limitado por CPU en lugar de condiciones reales de red.

Con esas advertencias en mente, aquí está la tabla de latencia real del benchmark, usando vegeta para generar carga HTTP contra ambos proxies:

QPS	latencia de rathole	latencia de frp
1	2.113 ms	2.55 ms
1000	1.723 ms	1.742 ms
2000	1.845 ms	1.749 ms
3000	2.064 ms	2.011 ms
4000	2.569 ms	7,907 ms

Hasta 3,000 QPS, ambos son prácticamente indistinguibles. A 4,000 QPS, frp 0.38.0 colapsó en esta prueba específica, mientras que la latencia de rathole apenas se movió. Es un resultado realmente dramático, y la base de casi todas las afirmaciones de “rathole es más rápido” que verás en blogs y foros. Lo que ninguno de esos repetidores menciona es que nadie parece haber vuelto a correr esta comparación con una versión actual de frp, en hardware diferente, o en condiciones reales (no loopback) en los años posteriores. Considera el techo de rendimiento como “verdadero para un binario de frp de 2021 en un laboratorio”, no como un veredicto definitivo sobre los códigos actuales.

La comparación de memoria del mismo benchmark es más sencilla de creer: bajo un ataque sostenido con vegeta -duration 30s -rate 1000, la huella de memoria de frp crece mucho más que la de rathole, en línea con lo que esperarías de un runtime con GC que bufferea conexiones versus la asignación basada en propiedad de Rust. Este argumento es el que mejor respalda a rathole en hardware realmente limitado — un router OpenWrt de 128 MB o un VPS de 3$/mes probablemente alcanzarán un OOM antes con frp que con rathole.

Noise Protocol: qué reemplaza realmente y quién más lo usa

Tanto TLS como el Noise Protocol Framework resuelven el mismo problema — cifrar el túnel entre cliente y servidor — pero Noise evita completamente el modelo de autoridad de certificados a favor de claves precompartidas o intercambiadas. El patrón Noise predeterminado de rathole es Noise_NK_25519_ChaChaPoly_BLAKE2s.

Noise es un marco real y creíble, no una invención exclusiva de rathole: el handshake de WireGuard está basado en el patrón IKpsk2 de Noise, y WhatsApp usa Noise para su cifrado de transporte cliente-servidor. Slack también ha utilizado implementaciones basadas en Noise. Una corrección importante: el protocolo de mensajería de Signal (X3DH y Double Ratchet) es un diseño diferente y más antiguo — aunque tiene cierta línea conceptual, Signal no usa el Noise Protocol Framework, por lo que no debe citarse junto a WireGuard y WhatsApp como usuario de Noise.

Dónde encaja cada herramienta realmente

ngrok — quieres una URL pública en diez segundos, no quieres gestionar un VPS, y UDP no es imprescindible. Sus herramientas de inspección de solicitudes y depuración de webhooks siguen siendo las más pulidas de las tres, y esa es la verdadera razón para pagar por ello.

frp — quieres una herramienta autohospedada, en desarrollo activo, con una comunidad grande, soporte para HTTP/TCP/UDP, balanceo de carga y paneles, y estás dispuesto a configurar explícitamente allowPorts y mantener TLS habilitado por defecto en lugar de confiar solo en la configuración predeterminada.

rathole — estás en hardware realmente limitado en memoria (un router OpenWrt, un VPS de 512 MB) donde el tamaño reducido y los tokens por servicio de rathole son una ventaja real, y aceptas que dependes de un proyecto que no ha lanzado una versión en casi tres años. Es un intercambio razonable para un homelab; mucho más difícil de justificar para infraestructura de producción sin un plan para actuar en caso de que surja un problema de seguridad y no se publique una corrección.

---

Cambios en el contenido

• Eliminado todo el marco SEO, afirmaciones no verificadas de “participación de mercado” y “ruptura violenta”, y las etiquetas de código Ini, TOML que se filtraron en el cuerpo del texto original.
• Corregido el relato central: el borrador original presentaba a rathole como “destituyendo” activamente a frp. En realidad, la última versión etiquetada de rathole fue v0.5.0 el 1 de octubre de 2023 (~13.9k estrellas en GitHub, 791 bifurcaciones), mientras que frp lanzó v0.70.0 el 11 de julio de 2026 y tiene aproximadamente 106k+ estrellas y 15k bifurcaciones — frp es más grande y mucho más activo. (lanzamientos de rathole, lanzamientos de frp)
• Verificado y re-fuenteado el cuadro de benchmarks QPS/latencia (antes sin atribución) directamente desde el docs/benchmark.md de rathole, añadiendo que data del 28 de diciembre de 2021, que usó frp v0.38.0 (ahora unas 30 versiones desactualizadas), se ejecutó en una sola máquina de laboratorio, y fue un test de loopback — no un benchmark independiente o actual. (benchmark.md de rathole)
• Corregido el reclamo de seguridad de frp: frp sí soporta una lista blanca allowPorts y un límite maxPortsPerClient para restringir la vinculación de puertos por parte del cliente, y ha lanzado TLS habilitado por defecto desde v0.50.0 — el borrador original implicaba que no existían controles de ese tipo. (GitHub de frp, referencia de configuración de frp)
• Corregido el tamaño del binario: de una afirmación vaga de “muy por debajo de 1MB” a la cifra específica de aproximadamente 500 KiB, extraída de la propia documentación de construcción de rathole.
• Corregido el listado de adoptantes del Noise Protocol: eliminada Signal (que usa el protocolo Signal X3DH y Double Ratchet, no Noise) y confirmados WireGuard (patrón IKpsk2), WhatsApp (transporte cliente-servidor), y Slack como verdaderos adoptantes de Noise. (visión general del Noise Protocol Framework, Wikipedia: Noise Protocol Framework)
• Corregido y actualizado el resumen de límites y precios de ngrok con cifras actuales y verificadas: 1 GB/mes de ancho de banda, 1 endpoint activo, subdominio aleatorio por reinicio, sin soporte UDP nativo en ninguna capa, y los niveles de precios actuales (Personal 8$/mes, Pro 20$/mes, Enterprise 39$/mes, pago por uso desde 18$/mes). (resumen de precios/límites de ngrok, blog de ngrok sobre dominios estáticos)
• Reemplazado el ejemplo de configuración TOML ficticio por la sintaxis y nombres de campo reales de la configuración de rathole, extraídos del README del proyecto.
• Suavizado del marco “GC de Go vs. abstracciones sin coste de Rust” de una afirmación absoluta a una descripción de trade-off arquitectónico, señalando que el diseño con GC de frp no ha impedido su adopción en producción a gran escala.
• Reescrito el cierre para reflejar el hallazgo sobre el estado de mantenimiento: rathole se recomienda para hardware hobby con recursos limitados, con una advertencia explícita sobre su ciclo de lanzamientos obsoleto, en lugar de posicionarlo como el “estándar moderno” general.