Ngrok vs. frp (Fast Reverse Proxy): La Batalla Definitiva entre Túneles Gestionados y Soberanía Autoalojada

Exponer un servidor de desarrollo local, un dispositivo IoT o un entorno de staging en las instalaciones a internet público solía requerir configuraciones tediosas en el router. Era necesario navegar NATs de nivel operador (CGNAT), solicitar IPs públicas estáticas y abrir puertos manualmente en firewalls de consumo.

La ingeniería moderna ha superado esta fricción. Hoy, las herramientas de reverse tunneling crean rutas seguras de entrada mediante conexiones salientes, evitando completamente las restricciones del firewall.

Al seleccionar una arquitectura para reverse tunneling, emergen dos filosofías dominantes. Por un lado, ngrok, el servicio en la nube completamente gestionado y orientado a desarrolladores que prioriza la sencillez plug-and-play y funciones de borde instantáneas. Por otro, frp (Fast Reverse Proxy), la solución open-source autoalojada con más de 107,000 estrellas en GitHub.

Elegir entre ellos no es solo una cuestión de herramienta; es una decisión arquitectónica fundamental respecto a soberanía de datos, eficiencia de costos y carga operativa. Esta guía desglosa las diferencias principales, perfiles de rendimiento, implementaciones de seguridad y estrategias de configuración de ngrok y frp para ayudarte a escoger la mejor opción para tu infraestructura.

1. Filosofías Arquitectónicas: SaaS vs. Autoalojado

Comprender la divergencia estructural entre ngrok y frp revela cómo cada uno maneja el enrutamiento del tráfico y la gestión de infraestructura.

El Paradigma ngrok: Edge gestionado como Servicio

Ngrok funciona como una plataforma comercial de Software como Servicio (SaaS). Cuando ejecutas el agente de ngrok en una máquina local, inicia una conexión saliente cifrada hacia la red de borde en la nube de ngrok, distribuida globalmente.

[Aplicación Local]
       │
       ▼ (Conexión saliente vía agente de ngrok)
[Red de borde en la nube de ngrok] ◄───── (Solicitud pública vía Internet) ─── [Usuario externo]

El tráfico de internet público llega a los nodos de ingreso de ngrok, pasa por sus cortafuegos de aplicaciones web gestionados (WAF) y capas de protección DDoS, y se enruta por el túnel establecido hacia tu máquina local. No gestionas los servidores, los certificados ni las tablas de enrutamiento; todo se maneja mediante una API en la nube gestionada.

El Paradigma frp: Delegación de tráfico autoalojada

Frp elimina la infraestructura de terceros. Divide el proceso de tunneling en dos binarios ligeros:

• frps (servidor frp): alojado por ti en una máquina accesible públicamente, típicamente un VPS económico en plataformas como DigitalOcean, Linode o AWS Lightsail.
• frpc (cliente frp): ejecutado dentro de tu red privada junto a la aplicación objetivo. [Aplicación Local] │ ▼ (Conexión saliente vía frpc) [Tu VPS en la nube (frps)] ◄───── (Solicitud pública vía Internet) ─── [Usuario externo]

El cliente frpc se conecta saliendo a tu servidor frps en la nube. Cuando un cliente externo se conecta a un puerto o dominio asignado al VPS, el servidor frps encapsula ese tráfico y lo envía por la conexión activa a frpc, que lo mapea directamente al puerto de tu aplicación local. Tú eres el proveedor de infraestructura, el operador de red y el único custodio de los datos.

2. Análisis Detallado por Funcionalidad

La divergencia arquitectónica resulta en conjuntos de funciones muy diferentes. Esta tabla refleja el estado actual y verificado de cada proyecto a julio de 2026.

Capacidad / Función	ngrok (Nube gestionada)	frp (Fast Reverse Proxy)
Modelo principal	SaaS comercial / Edge en la nube gestionado	Open-source autoalojado (Go)
Popularidad en GitHub	Cliente propietario (agente cerrado)	+107,000 estrellas, +15,100 forks
Última versión estable	No aplica (servicio en la nube en despliegue continuo)	v0.69.1 (junio 2026)
Soporte de protocolos	HTTP, TCP (todos los niveles); TLS (solo pago por uso)	TCP, UDP, HTTP, HTTPS, STCP, XTCP (P2P)
Soberanía de datos	Transitividad de terceros (red en la nube de ngrok)	Total — control completo del camino del tráfico
Ancho de banda	Medido por plan (1 GB–5 GB incluidos, luego $0.10/GB)	Sin límites — solo limitado por la subida de tu VPS
Gestión TLS/SSL	Certificados automáticos y gestionados	Manual o automatizado vía plugins ACME
Inspección de tráfico	Consola web en tiempo real con reproducción de solicitudes/respuestas	Panel web básico; métricas en Prometheus
Restricciones de precios	Nivel gratuito limitado a 1 GB/mes, 3 endpoints	Sin muros de pago por funciones — costo solo del VPS
Soporte UDP	No soportado en ningún nivel	UDP nativo, además de KCP y opciones de transporte QUIC

3. El Poder del Autoalojamiento: Capacidades de frp

Frp ha consolidado su estatus como una herramienta de nivel empresarial gracias a un conjunto de funciones extensas y activamente mantenidas que superan las restricciones de las alternativas comerciales.

Soberanía absoluta de datos

Al usar un servicio proxy comercial, los payloads HTTP sin cifrar, encabezados de autorización y datos webhook pasan por nodos proxy externos. Para equipos sujetos a marcos de cumplimiento como HIPAA, GDPR o SOC 2, esta exposición de terceros introduce una consideración en la cadena de suministro de datos que merece atención.

Con frp, los datos nunca abandonan tu perímetro de infraestructura — pasan directamente del usuario final, a través de tu instancia de computación en la nube, hacia tu arquitectura local.

Sin muros de pago por funciones

Frp no tiene concepto de muro de pago. Si tu host tiene un puerto de 1 Gbps sin medición, tus túneles heredan esa capacidad. Puedes crear cientos de proxies concurrentes, vincular dominios apex personalizados y reservar mapeos de puertos TCP/UDP sin alcanzar límites arbitrarios en la API — el límite práctico es tu VPS, no la licencia de frp.

NAT traversal avanzado: STCP y XTCP

Los proxies reversos tradicionales enrutan todos los datos a través del servidor público, por lo que el ancho de banda del servidor limita la velocidad efectiva. frp ofrece dos modos adicionales de conexión para sortear esto:

• STCP (TCP Secreto): Oculta un proxy por completo del internet abierto. Un cliente debe presentar una secretKey coincidente mediante un bloque [[visitors]] en su instancia de frpc para acceder al servicio — no hay puerto público que escanear o adivinar.
• XTCP (P2P traversal): Usa punching UDP basado en STUN para intentar una conexión peer-to-peer directa entre visitante y cliente local. frps aún es necesario para el handshake inicial y señalización, pero una vez establecida, los datos fluyen directamente entre endpoints, evitando el servidor en la transferencia real. La documentación de frp señala que esto no funciona con todos los tipos de NAT y recomienda fallback a STCP si falla.

Novedades en frp hasta mediados de 2026

frp ha lanzado varias actualizaciones importantes en sus últimas versiones menores que vale la pena conocer si hace más de un año que no lo usas:

• Política de compatibilidad formal (desde v0.69.0): cada versión menor es soportada hasta que se lancen nueve versiones menores nuevas — por ejemplo, v0.69.0 soportada hasta v0.78.0 — ofreciendo un marco de actualización más claro que en el pasado.
• Protocolo de cableado v2 (desde v0.69.0+): un nuevo protocolo versionado frpc↔frps con cifrado AEAD negociado (xchacha20-poly1305 o aes-256-gcm) en el canal de control, destinado a reemplazar el protocolo heredado. Es opcional mediante transport.wireProtocol = "v2" y aún no es predeterminado.
• Gestión dinámica de proxies (“Store”) (desde v0.68.0+): frpc ahora puede crear, actualizar y eliminar proxies y visitantes en tiempo de ejecución a través de su interfaz web o API, persistiendo en disco sin reiniciar.
• Puerta de enlace SSH Tunnel (desde v0.53.0+): frps puede aceptar conexiones ssh -R en modo plano, permitiendo crear un proxy TCP sin instalar frpc.
• VirtualNet (alpha, desde v0.62.0+): una función basada en interfaz TUN que extiende frp desde port forwarding hacia enrutamiento IP entre clientes y visitantes — aún en fase alpha y desactivada por defecto.

Cabe destacar: la reescritura arquitectónica “v2” de frp (desde cero, similar a Envoy en capas ⁴⁄₇) es un esfuerzo separado y mucho más grande que el protocolo v2 mencionado. A mediados de 2026, el mantenedor ha declarado que su complejidad es mayor de lo esperado y el desarrollo continúa de forma oportunista, sin una línea de tiempo comprometida — así que no planifiques su llegada pronto.

4. La Propuesta de Valor de ngrok

Mientras el autoalojamiento ofrece ventajas claras, ngrok sigue siendo una opción sólida para equipos que valoran la simplicidad cero-operaciones y funciones de borde listas para producción sobre control total de infraestructura.

Gestión cero de infraestructura

Configurar frp requiere provisionar un VPS, configurar reglas de firewall y gestionar un daemon systemd. Ngrok elimina esto por completo — exponer una instancia local con un solo comando:

ngrok http 8080

No hay servidores que provisionar ni parches de seguridad que seguir en tu lado.

Inspección avanzada de tráfico y reproducción de solicitudes

El inspector web local de ngrok (en http://127.0.0.1:4040) permite visualizar solicitudes HTTP entrantes con todos los encabezados y cuerpo JSON, y su función Replay permite reactivar un webhook capturado sin volver a ejecutar el evento upstream que lo generó.

Protección de identidad y borde, integrada

Ngrok integra autenticación en su configuración de borde mediante Traffic Policy — OIDC, SAML y limitación de tasa por solicitud son configuraciones, no infraestructura adicional que debas montar y mantener.

Novedad en 2026: ngrok como puerta de enlace AI/MCP

Este es el cambio más relevante en ngrok desde que se compararon herramientas de tunneling por última vez, y es especialmente relevante si también evalúas infraestructura de agentes AI. Hasta 2026, ngrok extendió su plataforma de borde a lo que llama “Universal Gateway” con dos componentes específicos para AI:

• ngrok como puerta de enlace MCP: puedes colocar un Endpoint de agente de ngrok delante de un servidor MCP local y usar Traffic Policy para autenticar, autorizar y auditar cada solicitud MCP antes de que llegue a tu proceso — por ejemplo, restringiendo conexiones entrantes a rangos IP de Anthropic u OpenAI y limitando por API key, sin modificar el código de tu MCP.
• ngrok.ai (Puerta de enlace AI): una capa de enrutamiento compatible con OpenAI (relanzada el 1 de julio de 2026 en app.ngrok.ai) que se sitúa delante de tus llamadas a modelos en lugar de tus túneles. Soporta claves de proveedor propias, failover automático entre proveedores y enrutamiento a modelos autoalojados (Ollama, vLLM) junto a los alojados — todo cambiando un baseURL, sin cambios en código. Desde abril de 2026, también está disponible para cuentas de nivel gratuito.

Nada de esto reemplaza el caso de uso de frp — es un producto paralelo para tráfico de LLM en lugar de tunneling TCP/UDP en bruto — pero es una razón significativa por la que ngrok sigue siendo relevante para equipos que construyen herramientas agenticas, y se relaciona directamente con el enfoque de zero-trust en AI-agent tunneling que este blog ha cubierto con zrok/OpenZiti.

Precios actuales de ngrok (verificados en ngrok.com, julio 2026)

Plan	Precio	Transferencia de datos	Solicitudes HTTP/S	Endpoints en línea	Protocolos
Gratis	$0	1 GB incluido	20k/mes	3	HTTP, TCP (requiere verificación de tarjeta)
Hobbyist	$8/mes facturado anualmente ($10/mes mensual)	5 GB incluido, luego $0.10/GB	100k incluido, luego $1/100k	3	HTTP, TCP
Pago por uso	$20/mes + uso	5 GB incluido, luego $0.10/GB, ilimitado	100k incluido, luego $1/100k, ilimitado	Ilimitado	HTTP, TCP, TLS

UDP no está disponible en ningún nivel de ngrok — esto sigue siendo una brecha arquitectónica, no de precios, y es la razón más común por la que los desarrolladores optan por alternativas cuando el workload involucra servidores de juegos, VoIP o protocolos IoT basados en UDP como CoAP o DTLS. Si UDP es un requisito imprescindible y autoalojar frp no es opción, esa es una brecha real en la oferta de ngrok que debes conocer — parte de la razón por la que en 2026 han surgido alternativas gestionadas nativas de UDP (Localtonet, LocalXpose, Pinggy, Playit.gg), aunque evaluar esas opciones escapa del alcance de esta comparación.

5. Guía paso a paso para desplegar: Construir una red privada con frp

Aquí tienes un recorrido completo para desplegar una red de túneles frp en una instancia estándar de Ubuntu en la nube, usando la versión estable actual (v0.69.1) y sintaxis TOML corregida y verificada.

Paso 1: Configurar el nodo servidor (frps)

Inicia sesión en tu VPS en la nube vía SSH, descarga el binario de la última versión y extráelo:

wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar -zxvf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64

Copia el binario del servidor a /usr/local/bin y crea un directorio de configuración:

sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp

Crea /etc/frp/frps.toml. Nota que las claves de vhost HTTP/HTTPS usan HTTP/HTTPS en mayúsculas — vhostHTTPPort y vhostHTTPSPort (como se escribe con una “ttp” en minúscula) no son válidas en TOML en frp y fallarán en el binding:

# /etc/frp/frps.toml
bindPort = 7000

# Configuración de host virtual para enrutamiento web HTTP/HTTPS
vhostHTTPPort = 80
vhostHTTPSPort = 443

# Capa de autenticación para evitar conexiones no autorizadas
auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"

# Activar el panel de monitorización integrado
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "CHOOSE_A_COMPLEX_DASHBOARD_PASSWORD"

Configura un servicio systemd en /etc/systemd/system/frps.service:

[Unit]
Description=frp Server Daemon
After=network.target

[Service]
Type=simple
User=nobody
Restart=on-failure
RestartSec=5s
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml

[Install]
WantedBy=multi-user.target

Recarga systemd, habilita y arranca:

sudo systemctl daemon-reload
sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps

Paso 2: Configurar el nodo cliente (frpc)

En tu máquina local, crea frpc.toml. Nota que el campo es localIP (en mayúscula) y no localIp — el parser de frp distingue mayúsculas y minúsculas y la variante en minúscula fallará:

# frpc.toml
serverAddr = "TU_IP_PUBLICA_DEL_VPS"
serverPort = 7000

auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"

# Ejemplo 1: Reenviar acceso a servicio SSH local
[[proxies]]
name = "túnel-ssh-seguro"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6022

# Ejemplo 2: Exponer una app web local en desarrollo
[[proxies]]
name = "web-desarrollo-local"
type = "http"
localIP = "127.0.0.1"
localPort = 8080
customDomains = ["dev.tudominio.com"]

Lanza el cliente:

./frpc -c ./frpc.toml

Una vez conectado, las solicitudes HTTP públicas que lleguen a dev.tudominio.com (apuntando mediante DNS a la IP de tu VPS) se enrutarán directamente a tu puerto local 8080.

Puedes verificar que un archivo de configuración no tenga errores de sintaxis con frpc verify -c ./frpc.toml, y recargar los proxies en ejecución sin reiniciar con frpc reload -c ./frpc.toml (requiere que la sección webServer esté configurada).

6. Matriz de decisiones en el mundo real: ¿Cuál deberías escoger?

                  ¿Se requiere soberanía absoluta de datos?
                                 │
                   ┌─────────────┴─────────────┐
                  SÍ                          NO
                   │                           │
              [Usar frp]           ¿Qué tan complejo es tu stack, y
           (Autoalojado)          ¿Necesitas UDP o herramientas AI/MCP?
                                   ┌────────────┴────────────┐
                                   ▼                         ▼
                              SIMPLE, HTTP/TCP,        COMPLEJO, o
                              necesita puerta AI/MCP   necesita UDP
                                   │                         │
                              [Usar ngrok]             [Usar frp]
                             (Configuración rápida)   (Escalabilidad/UDP/P2P)

Elige ngrok si: - Trabajas en un entorno dinámico donde gestionar infraestructura distrae del desarrollo principal. - Necesitas inspeccionar y reactivar webhooks complejos en tiempo real. - Quieres autenticación OIDC/SAML integrada sin montar tu propio reverse proxy. - Construyes herramientas agenticas y quieres políticas de tráfico MCP o enrutamiento multi-proveedor para LLM sin infraestructura adicional. - Tu workload no requiere UDP.

Elige frp si: - Requieres soberanía absoluta de datos y que los flujos internos sin cifrar nunca toquen infraestructura de terceros. - Necesitas dominios apex personalizados, mapeos dedicados de puertos TCP/UDP o cargas de trabajo de alto ancho de banda sin un plan SaaS medido. - Estás tunneling protocolos nativos UDP — servidores de juegos, VoIP, IoT. - Te sientes cómodo manteniendo un VPS y quieres un proyecto con una cadencia de lanzamientos activa y transparente.

Veredicto final

El debate entre ngrok y frp es el clásico compromiso de infraestructura: conveniencia vs. control. Ngrok convierte el enrutamiento de red complejo en una utilidad abstracta — y en 2026, ha expandido esa abstracción hacia enrutamiento de tráfico AI y funciones de puerta MCP, que importan si los flujos agenticos forman parte de tu stack. frp sigue siendo el estándar para ingenieros de infraestructura que priorizan propiedad, soporte UDP y sin límites de licencia, respaldado por un proyecto que — según su historia de lanzamientos recientes — aún está en desarrollo activo y no en modo de estancamiento.

---

Registro de cambios

Correcciones (errores fácticos en el borrador original): - La cuenta de estrellas en GitHub de frp fue redondeada a “108,000” en el original; la cuenta actual verificada en GitHub es de 107,000+ estrellas (105k–108k en snapshots recientes), con 15,100+ forks. Actualizado para reflejar esto. - La guía de despliegue original hacía referencia a frp v0.70.0, que no existe como versión publicada. Verificado en la página oficial de Releases: la versión estable más reciente es v0.69.1 (1 de junio de 2026). Se actualizaron todas las referencias y comandos de descarga. - El ejemplo de frps.toml original usaba vhostHttpPort / vhostHttpsPort. Estos son claves inválidas en TOML — las claves correctas son vhostHTTPPort / vhostHTTPSPort (verificado en README oficial de frp). La configuración original fallaría en enlazar puertos HTTP/HTTPS silenciosamente. Corregido. - Los ejemplos de frpc.toml usaban localIp. La clave en la config de frp distingue mayúsculas y minúsculas y la correcta es localIP (verificado en ejemplos oficiales). Corregido en todos los bloques. - Confirmado que ngrok no soporta UDP en ningún nivel — verificado en la página de precios de ngrok (ngrok.com/pricing), que lista solo HTTP, TCP y TLS en todos los niveles.

Adiciones (información nueva y basada en fuentes): - Reemplazado el vaguedad en precios de ngrok por una tabla exacta, actual, extraída de ngrok.com/pricing (nombres de planes, precios, datos incluidos, límites de solicitudes y disponibilidad de protocolos por nivel). - Añadido apartado sobre capacidades de Gateway AI y MCP en ngrok en 2026 (Traffic Policy, relanzamiento de ngrok.ai en julio 2026, y acceso a Gateway AI en nivel gratuito desde abril 2026) — novedades desde la última comparación de tunneling y relevante para este blog. - Añadido apartado “Novedades en frp hasta mediados de 2026” cubriendo la política de compatibilidad formal (desde v0.69.0), protocolo de cableado v2 con cifrado AEAD, la función Store (desde v0.68.0), Gateway SSH (desde v0.53.0), y VirtualNet (alpha, desde v0.62.0) — todo verificado en documentación oficial y notas de versión. - Aclarado que la reescritura arquitectónica “v2” de frp (desde cero, similar a Envoy en capas ⁴⁄₇) es un esfuerzo separado y mucho más grande que el protocolo v2, y que el mantenedor ha declarado en 2026 que su cronograma es abierto por la complejidad. - Añadidas instrucciones de verificación (frpc verify, frpc reload) en la guía de despliegue como prácticas útiles adicionales.

Cambios estructurales: - Eliminados artefactos de metadatos/formatos del borrador original. - Reformatados todos los ejemplos de shell y configuración en bloques de código correctamente etiquetados y con sintaxis de lenguaje.