La Batalla por el Dominio Apex: Túneles de Dominio Raíz Asequibles en 2026

Si eres desarrollador, freelancer o dueño de agencia, ya conoces la magia de tunelizar tu localhost hacia internet público. Creas una aplicación web, la ejecutas en el puerto 3000, inicias un túnel y compartes instantáneamente un enlace en vivo con un cliente en medio del mundo.

Pero hay un inconveniente que rompe la ilusión de un producto pulido y listo para producción: la URL.

Durante años, el estándar de la industria ha restringido a los desarrolladores a URLs auto-generadas y aleatorias como 1a2b3c.ngrok-free.app. Si quieres usar tu servidor local con un dominio personalizado, generalmente te dirigen a un subdominio (app.tudominio.com). Pero, ¿qué pasa si quieres tu verdadero dominio raíz — tudominio.com?

Bienvenido a la batalla por el dominio apex. Y es una pelea más desigual de lo que muchos artículos comparativos dejan entrever: el líder del mercado, ngrok, no solo hace que los dominios raíz sean caros — su propia documentación afirma claramente que no los soporta en absoluto, en ningún plan, a cualquier precio. Este hecho cambia toda la comparación, y es lo primero que hay que entender antes de recomendar algo.

Este artículo explica por qué los dominios apex son difíciles de tunelizar, qué hace y qué no ofrece ngrok en 2026, y cómo tres arquitecturas realmente diferentes — el relé DNS de Pinggy, la delegación completa de servidores de nombres de Localtonet, y el aplanamiento CNAME de Cloudflare Tunnel — resuelven el problema en la práctica.

1. Entendiendo el Dominio Apex y el Problema del CNAME

Antes de las alternativas, ayuda entender por qué los dominios raíz (también llamados apex o dominios desnudos) son notoriamente más difíciles de tunelizar que los subdominios.

¿Qué es un dominio apex?

En la jerarquía DNS, el dominio apex es la “raíz” de tu nombre de dominio — sin prefijo de subdominio.

• Dominio apex/raíz: ejemplo.com
• Subdominio: www.ejemplo.com, api.ejemplo.com, staging.ejemplo.com

La limitación del CNAME

Cuando apuntas un dominio personalizado a un servicio de túnel, generalmente te piden crear un registro CNAME (Nombre Canónico). Un CNAME mapea tu dominio al hostname del proveedor (por ejemplo, mapear app.ejemplo.com a tunnel.provider.com).

El problema es que un registro CNAME no puede coexistir con otros tipos de registros DNS en el mismo nombre, y un dominio apex (ejemplo.com) debe tener registros SOA (Start of Authority) y NS (Name Server) en su raíz. Como un CNAME sobrescribiría estos, DNS estándar no permite uno en el apex — esto es una restricción del protocolo, no una política de un proveedor.

Cómo trabajan los proveedores para sortear esto

No hay una solución universal — diferentes servicios usan mecanismos distintos, y la elección importa para lo que puedes y no puedes hacer después:

• Relés A/AAAA. El proveedor te da direcciones IPv4/IPv6 estáticas para poner directamente en los registros A y AAAA de tu apex. Esto es lo que hace Pinggy.
• CNAME flattening (ALIAS/ANAME). Algunos proveedores DNS — Cloudflare de forma nativa, y otros como DNSimple o DNS Made Easy mediante registros ALIAS/ANAME — resuelven el destino del CNAME en sus propios servidores y entregan una respuesta aplanada con registros A/AAAA. Cloudflare Tunnel depende de esto, por lo que usarlo implica mover los servidores de nombres a Cloudflare.
• Delegación completa de servidores de nombres. En lugar de añadir registros en tu DNS actual, apuntas toda la delegación de servidores de nombres de tu dominio a un proveedor, que se convierte en tu host DNS para ese dominio — incluyendo MX, TXT, todo. Es un compromiso mayor, pero evita la restricción del CNAME en el apex porque el proveedor controla la zona directamente. Localtonet usa este modelo.
• No soportado en absoluto. Algunos proveedores simplemente no ofrecen ninguna de las opciones anteriores para el apex — como verás, esta es la posición real de ngrok, no solo en planes inferiores.

2. El Verdadero Problema con Ngrok en 2026

Ngrok fue pionero en tunelización localhost y sigue siendo un excelente producto para tunelizar TCP/TLS/HTTP con OAuth, SAML y funciones de observabilidad. Pero en dominios apex, la limitación no es un nivel de precio — es el producto en sí. La documentación de dominios personalizados de ngrok dice en cuatro palabras: “ngrok no soporta actualmente dominios apex.” Sin nota al pie, sin solución alternativa, sin opción A-record. Si quieres tudominio.com sin prefijo apuntando a un túnel ngrok, ngrok no es una opción actualmente, sin importar cuánto pagues.

Es importante entender esto, porque la mayoría de comparaciones — incluyendo borradores anteriores de este artículo — lo enmarcan como que ngrok “reserva los dominios raíz para niveles superiores,” lo cual implica pagar más para acceder a ello. No es así. Lo que pagas más es un subdominio personalizado (app.tudominio.com), configurado vía CNAME estándar, solo en el plan Pay-as-you-go o superior.

Aquí tienes la tarifa real de ngrok en 2026, verificada contra su documentación de precios y límites:

• Gratis — crédito de uso único de $5, limitado a 1 GB de transferencia, 20,000 solicitudes HTTP y hasta 3 endpoints en línea. Obtienes un dominio de desarrollo asignado automáticamente; los endpoints HTTP(S) muestran una página de advertencia antes de reenviar el tráfico.
• Hobbyist ($10/mes, o $8/mes si pagas anualmente) — elimina la página de advertencia, incluye 5 GB de transferencia y 100,000 solicitudes HTTP, y desbloquea hasta 10 subdominios con marca ngrok (no personalizados). No soporta dominios propios en este nivel.
• Pago por uso ($20/mes base + uso) — el nivel necesario para un dominio personalizado real, pero solo como subdominio vía CNAME. Los dominios personalizados se cobran a $0.01 por hora de endpoint activo, además de una tarifa de $0.27 por dominio/hora si usas tu propio certificado TLS en lugar del Let’s Encrypt automático.

Si dejas un túnel con subdominio personalizado corriendo ²⁴⁄₇ durante un mes (730 horas), eso sería aproximadamente $7.30 en tarifas de dominio, más los $20 base — unos $27/mes, y eso sin resolver aún el problema del dominio apex, porque ngrok no puede resolverlo en ningún plan.

Un truco real de ngrok: para endpoints TCP, ngrok permite hacer CNAME a tu hostname TCP asignado aleatoriamente (ejemplo: tcp.tudominio.com → 5.tcp.ngrok.io) para que al menos el hostname sea estable. Es una función real, pero solo para TCP, no para HTTP(S) en dominios apex.

3. Por qué los desarrolladores necesitan túneles en dominios raíz

Dado que ngrok no soporta esto en absoluto, ¿por qué luchar por ello en lugar de usar staging.ejemplo.com?

A. Demos de cliente con marca blanca. Enviar a un cliente https://59d3a1.ngrok-free.app parece “en progreso.” Mejor enviar https://staging.tuagencia.com. Pero aún mejor, https://nombre-startup.com — que apunta directamente a tu máquina local — parece un producto terminado en medio de una llamada Zoom, sin necesidad de CI/CD.

B. Pruebas estrictas de webhooks. Proveedores de pagos y APIs (Stripe, Shopify, Mailgun, otros) requieren endpoints HTTPS, y algunas integraciones validan contra el dominio registrado exacto, no un subdominio arbitrario. Un dominio personalizado estable — apex o subdominio — evita re-registrar URLs de callback cada vez que reinicias un túnel.

C. Comportamiento de cookies y CORS. Si tu frontend establece cookies para el dominio apex (.ejemplo.com) en producción, probar en un dominio generado automáticamente o en un subdominio diferente puede mostrar errores de cookies y CORS que solo aparecen porque la forma del dominio no coincide con producción. Ejecutar desarrollo local en el dominio apex que usarás en producción elimina esa clase de errores específicos del entorno.

4. Las mejores opciones asequibles para dominios apex

1. Pinggy — el método de relé documentado

Precios: plan Pro por aproximadamente $3/mes facturado mensualmente (~$2.37–$2.50/mes si pagas anualmente). La capa gratuita es siempre gratuita, pero los túneles están limitados a 60 minutos con URLs aleatorios y no persistentes.

Pinggy es una opción fuerte para dominios apex porque ofrece un mecanismo real para el problema del CNAME en apex, llamado relé. Verificas la propiedad del dominio con un registro TXT, eliges una región de relé cercana a tu tráfico, y Pinggy te da IPs estáticas A y AAAA para poner en tu registro @ del DNS.

Un detalle que no resaltan las páginas de precios: los propios docs de Pinggy indican que un dominio personalizado basado en relé funciona para HTTP(S), TLS y TCP, pero no UDP — si necesitas un túnel UDP en tu dominio apex, la opción soportada es un subdominio persistente, no el raíz.

Configuración (sintaxis real):

# 1. Inicia tu servidor local
npm run start
# Escuchando en http://localhost:3000

# 2. En el panel de Pinggy (Dominios Personalizados), añade tu dominio raíz,
#    verifica el registro TXT, elige una región de relé y añade los registros A/AAAA
#    que te proporcionen en tu DNS (host: @)

# 3. Una vez validado y emitido el certificado, inicia el túnel
#    con tu token Pro — el dominio configurado para ese token se
#    usa automáticamente:
ssh -p 443 -R0:localhost:3000 token@pro.pinggy.io

No hay una bandera inline especial para “usar mi dominio personalizado” — simplemente asocias el dominio a tu token en el panel una sola vez, y cada túnel con ese token pasa por él. Pinggy obtiene automáticamente un certificado Let’s Encrypt tras validar los registros DNS.

2. LocalXpose — excelente para subdominios, no confirmado para dominio raíz

Precios: plan Pro a $8/mes ($96/año), 10 túneles activos, ancho de banda ilimitado sujeto a política de uso aceptable. La capa gratuita incluye 2 túneles HTTP activos.

LocalXpose es una herramienta de túnel completa — soporta HTTP(S), TCP, TLS y UDP, además de una interfaz gráfica nativa, subdominios comodín y controles de acceso IP/autenticación básica. La copia de marketing dice que soporta “dominios personalizados,” y esto es cierto y valioso para subdominios.

Donde se complica es en el dominio raíz. La propia documentación de LocalXpose para reservar un dominio (loclx domain reserve --domain ejemplo.com) explica crear un registro CNAME — el mismo mecanismo que, según las reglas DNS en la Sección 1, no puede estar en el apex. No hay un proceso documentado de relé A/AAAA, TXT + IP estática, o delegación de servidores de nombres como en Pinggy o Localtonet. Esto no significa que sea imposible — algunos DNS con CNAME flattening (Cloudflare, DNSimple) podrían hacer que un CNAME “funcione” en un apex, pero la documentación de LocalXpose no ofrece una vía clara para ello. Si necesitas un dominio raíz real, mejor consultar directamente con soporte de LocalXpose.

3. Localtonet — soporte para dominio raíz mediante delegación completa de servidores de nombres

Precios: aproximadamente $2/túnel/mes, cobrado solo mientras el túnel esté activo (pago por uso, sin mínimo mensual). La capa gratuita: 1 túnel, 1 GB/mes, timeout de 30 minutos.

Localtonet adopta un enfoque diferente y más comprometido que el relé de Pinggy: en lugar de añadir registros en tu DNS, registras el dominio en el Administrador DNS de Localtonet y luego reemplazas los servidores de nombres autoritativos en tu registrador por ns1.localtonet.com y ns2.localtonet.com. Desde ese momento, Localtonet es tu host DNS para ese dominio — los registros A, CNAME, MX y TXT se gestionan desde su panel en lugar del tuyo.

La ventaja de este método más pesado es que es uniforme: una vez que los servidores de nombres se propagan (de 1 a 2 horas, hasta 48 en casos raros), puedes apuntar túneles HTTP, TCP o UDP al dominio raíz dejando en blanco el campo de subdominio — sin relé separado, sin protocolo excluido. Incluye HTTPS con Let’s Encrypt automáticamente. La desventaja: entregas control DNS completo, incluyendo MX para email, lo cual es un paso mayor que añadir un TXT y dos registros A/AAAA como en Pinggy.

4. Cloudflare Tunnel — gratis, pero la infraestructura más pesada

Precios: el túnel de Cloudflare no tiene costo adicional ni límite de ancho de banda — está incluido en la plataforma Zero Trust de Cloudflare, que tiene su propia capa gratuita (hasta 50 usuarios) y una opción de pago de $7/usuario/mes para funciones avanzadas.

Cloudflare Tunnel (el demonio cloudflared, antes Argo Tunnel) enruta tráfico a través de la red de Cloudflare a un proceso ligero en tu máquina. Como Cloudflare también es proveedor DNS, su aplanamiento CNAME en el apex se aplica automáticamente cuando tus servidores de nombres apunten a Cloudflare — sin IPs A/AAAA que gestionar, sin región de relé que elegir.

El truco: debes migrar tus servidores de nombres a Cloudflare (compromiso similar al de Localtonet), instalar y autenticar cloudflared, y configurar reglas de ingreso — una configuración inicial más compleja que un solo comando SSH. Para un dominio que usarás a largo plazo y quieres infraestructura de borde de producción, es una opción fuerte y realmente gratuita. Para una demo rápida, puede ser excesivo.

5. Comparación rápida

Proveedor	Precio de entrada	Soporta dominio raíz	Mecanismo	UDP en raíz
ngrok	$10/mes Hobbyist, $20/mes+uso Pago por uso	No — documentado como no soportado en ningún nivel	N/A (solo subdominio CNAME en niveles pagos)	No (ngrok no tiene túneles UDP)
Pinggy	~$3/mes	Sí, documentado	Verificación TXT + relé A/AAAA	No (relé excluye UDP)
LocalXpose	$8/mes	No documentado/no confirmado	Solo CNAME (según docs oficiales)	Sí, para subdominios
Localtonet	~$2/túnel/mes	Sí, documentado	Delegación completa de servidores de nombres	Sí
Cloudflare Tunnel	Gratis	Sí, documentado	Aplanamiento CNAME (requiere migración NS)	No (Cloudflare Tunnel enfocado en HTTP/TCP)

6. Consideraciones de rendimiento y seguridad

Exponer localhost a internet — especialmente en un dominio raíz muy visible — evita el firewall NAT del router, así que algunos aspectos básicos importan, independientemente de la herramienta.

TLS automatizado. No uses una herramienta de túnel en 2026 que no tenga HTTPS automático. Pinggy, LocalXpose y Localtonet proporcionan certificados Let’s Encrypt automáticamente para dominios personalizados.

Latencia geográfica. Si tu cliente está en Londres y tú en Tokio, un relé en la región equivocada añade latencia real. Pinggy permite elegir región de relé; escoge la más cercana a donde proviene tu tráfico.

Control de acceso. Si tu panel de administración o base de datos están accesibles en tu dominio raíz, cualquiera puede encontrarlos. Usa autenticación básica o listas blancas de IP — tanto Pinggy como LocalXpose soportan esto — y whitelist de rangos IP conocidos.

7. Conclusión

El problema del dominio apex es una restricción real de DNS, no un truco de marketing — pero el panorama de proveedores que lo resuelven es más diverso de lo que un simple análisis de precios sugiere. ngrok no es la opción cara aquí; es la que no soporta esto en ningún plan. Pinggy lo resuelve de forma económica con un relé documentado y de compromiso moderado. Localtonet lo hace igual de completo pero requiere control total de DNS. Cloudflare Tunnel lo resuelve gratis pero pide la delegación de NS y una configuración más avanzada. LocalXpose es un túnel capaz para todos los protocolos, pero aún no ha publicado un mecanismo para dominios apex como sus competidores.

Cualquiera que elijas, la decisión no es solo “barato vs. caro” — depende de cuánto control DNS estás dispuesto a ceder y si todos tus protocolos (incluyendo UDP, si lo necesitas) realmente deben estar en el dominio raíz.

Preguntas Frecuentes

Q: ¿Puedo usar un registro CNAME para un dominio apex? A: No. DNS estándar no permite que un CNAME coexista con los registros SOA y NS en un dominio raíz. Necesitas registros A/AAAA, un proveedor que ofrezca CNAME flattening/ALIAS/ANAME, o delegar completamente los servidores de nombres a ese proveedor.

Q: ¿ngrok soporta dominios apex en algún plan, incluyendo Enterprise? A: La documentación de ngrok afirma sin condiciones que no soporta dominios apex. Incluso en el plan Pay-as-you-go, que añade dominios personalizados, solo soporta subdominios vía CNAME.

Q: ¿Qué herramientas documentan soporte para dominios apex? A: Pinggy (mediante relé verificado con TXT) y Localtonet (mediante delegación de servidores de nombres) publican mecanismos específicos para dominios apex. Cloudflare Tunnel también, mediante aplanamiento CNAME, tras migrar NS. La documentación pública de LocalXpose solo muestra un flujo basado en CNAME, que técnicamente es para subdominios.

Q: ¿Soportan estos servicios subdominios comodín? A: Sí — Pinggy, LocalXpose y Localtonet soportan enrutamiento con comodín (*.ejemplo.com), útil para pruebas de SaaS multitenant.

Q: ¿Son seguros estos servicios por defecto? A: Todos ofrecen HTTPS automático. Como expones una máquina local, es recomendable activar autenticación básica o listas blancas de IP para datos sensibles — estas funciones son opcionales, no predeterminadas.

---

Cambios en la versión

Verificado con las fuentes principales (documentación oficial de ngrok, Pinggy, LocalXpose y Localtonet, además de la documentación DNS y Zero Trust de Cloudflare) al 5 de septiembre de 2026. Cambios respecto al borrador original:

• Corrección principal, replantea toda la pieza: la premisa de que ngrok “reserva los dominios raíz para niveles superiores” es falsa. La documentación de dominios personalizados de ngrok afirma sin condiciones, sin calificadores de nivel, “ngrok no soporta actualmente dominios apex” — no en Gratis, Hobbyist ni en Pay-as-you-go. Se reescribieron las Secciones 2 y la conclusión en torno a esto; la verdadera limitación de ngrok en planes pagos es que los dominios personalizados son solo subdominios (CNAME), separado del problema del apex.
• Se corrigió el nivel gratuito de ngrok: en lugar de una descripción vaga de “1 dominio de desarrollo,” ahora se especifica un crédito de uso de $5, límite de 1 GB, 20,000 solicitudes HTTP/mes, hasta 3 endpoints, y una página de advertencia en endpoints HTTP(S).
• Se verificó que el nivel Hobbyist ($10/mes, $8/mes anual) no incluye dominios propios, solo hasta 10 subdominios con marca ngrok, corrigiendo la implicación de que sí.
• Se añadió la tarifa adicional de ngrok de $0.27 por dominio/activo/hora para certificados TLS propios, distinta a la tarifa de $0.01/hora ya mencionada.
• Se aclaró que el flujo de relé de Pinggy para dominios apex funciona solo para HTTP(S)/TLS/TCP, no UDP, según su propia documentación.
• Se reemplazó el comando SSH ficticio por el real documentado para Pinggy: ssh -p 443 -R0:localhost:3000 token@pro.pinggy.io, donde el dominio personalizado se asocia en el panel.
• Se actualizó la tarifa de Pinggy a aproximadamente $3/mes, con la capa gratuita limitada a 60 minutos y URLs no persistentes.
• Se confirmó el precio de LocalXpose ($8/mes, 10 túneles, ancho de banda ilimitado) y su capa gratuita.
• Se verificó el modelo de precios de Localtonet (~$2/túnel/mes, solo mientras esté activo) y su límite gratuito.
• Se corrigió la descripción de Cloudflare Tunnel: es gratuito y sin límite de ancho de banda, incluido en Zero Trust, con costos adicionales solo por funciones avanzadas.
• Se eliminó la afirmación no soportada de que APIs o proveedores de OAuth “rechazan” URLs por preocupaciones de phishing o abuso, en favor de una declaración más general.
• Se añadió una tabla comparativa con mecanismos, soporte UDP y precios de entrada.
• Se eliminaron enlaces rotos y metadatos de fuente.