El fin de los túneles CLI: Compartir localhost nativo en el navegador

Vite y Next.js no actualizan la pestaña del navegador cuando guardas un archivo. Envía el módulo modificado a través de una conexión WebSocket persistente y lo integra en la página en ejecución. Es rápido, y también es la razón por la que compartir un servidor de desarrollo local con un cliente, un teléfono o un proveedor de webhooks puede ser más frágil de lo que parece.

La mayoría de los túneles de uso general manejan bien las solicitudes HTTP simples y no gestionan correctamente el apretón de manos de actualización WebSocket en el que se basa HMR. Este artículo analiza por qué sucede eso, qué necesita hacer un túnel de manera diferente, y dónde encajan dos herramientas actuales — una de código abierto y otra integrada en una herramienta de desarrollo de IA más amplia — en el panorama.

Por qué el fallo es específicamente un problema de WebSocket

Un WebSocket comienza como una solicitud HTTP ordinaria con los encabezados Upgrade: websocket y Connection: Upgrade. El servidor (o cualquier proxy que lo represente) debe reconocer ese apretón de manos y cambiar la conexión de request/response a un flujo de bytes bidireccional, de larga duración. Un túnel que no tenga en cuenta esto puede eliminar esos encabezados o agotar la conexión por timeout, porque parece una solicitud que lleva demasiado tiempo sin respuesta.

Dos lugares concretos donde esto se nota:

Vite. Cuando un proxy inverso (o túnel) delante de Vite no gestiona correctamente el tráfico WebSocket, el cliente de Vite vuelve a conectarse directamente a su socket HMR al servidor de desarrollo, saltándose el proxy — y registra una advertencia en la consola. La documentación de Vite indica que este error de fallback generalmente puede ignorarse en una red local normal, porque la conexión directa aún funciona. El problema: en un túnel público, la conexión “directa” no es accesible desde fuera de tu máquina, por lo que el fallback también falla y HMR se rompe. Vite recomienda configurar el proxy inverso para que pase el tráfico WebSocket o ajustar server.ws (clientPort, port) para que el cliente y el servidor acuerden cómo llegar al socket.

Next.js. Desde la versión 12, Next.js usa Fast Refresh sobre un WebSocket en /_next/webpack-hmr en lugar del mecanismo anterior de eventos enviados por el servidor. Un proxy mal configurado entre el navegador y el servidor de desarrollo suele causar errores como “WebSocket se cerró antes de establecer la conexión” en configuraciones personalizadas — la solución es asegurarse de que cualquier proxy pase las actualizaciones WebSocket sin modificar.

Ninguno de estos problemas es exclusivo de un proveedor de túneles; son propiedades de cómo implementan Vite y Next.js HMR, y cualquier herramienta en medio debe gestionarlas activamente.

Lo que un túnel “consciente del framework” debe hacer bien

• Reconocer el apretón de manos de actualización y cambiar a un passthrough TCP en bruto en lugar de tratar la conexión como una solicitud HTTP atascada.
• Mantener viva la conexión con pings periódicos, ya que las conexiones largas e inactivas suelen ser cerradas por firewalls y balanceadores.
• No modificar los encabezados Host/Origin, ya que los servidores de desarrollo verifican cada vez más el origen por seguridad, y un túnel que los reescribe puede hacer que rechacen las solicitudes antes de llegar a tu código.

Dos herramientas que hacen esto hoy

OutRay — código abierto, autoalojable

OutRay es un proyecto real, en mantenimiento activo (AGPL-3.0, aproximadamente 1k estrellas en GitHub al momento) que funciona como alternativa a ngrok. Soporta túneles HTTP, TCP y UDP desde CLI (outray http 3000, outray tcp 5432), dominios personalizados, un panel con análisis de tráfico y integraciones con frameworks.

Su integración con Express está claramente documentada como un middleware npm (@outray/express) — simplemente lo importas, envuelves tu app, y muestra una URL de túnel junto a los logs del servidor. La documentación de OutRay también lista plugins para Next.js, Vite y NestJS, aunque no puedo verificar de forma independiente la afirmación (repetida en algunos textos de marketing) de que el plugin de Next.js edita automáticamente next.config.ts sin pasos CLI — trata ese detalle como no confirmado hasta que lo pruebes tú mismo. La propuesta de valor principal, bien documentada: es código abierto, por lo que puedes inspeccionar o alojar toda la pila en tu infraestructura en lugar de confiar en un tercero.

AgentsRoom — un túnel integrado en una herramienta más grande, no un producto independiente

El borrador original lo presentaba como un producto “nativo del navegador” para compartir localhost. Eso es incorrecto: AgentsRoom es una app de escritorio nativa (Mac/Linux/Windows) para coordinar múltiples agentes de IA para programación — Claude Code, Codex, CLI de Antigravity, y otros — con un tablero de tareas, terminales por proyecto, un agente de QA de automatización en navegador, y una app móvil iOS/Android. El túnel localhost es solo una función, no el producto completo, y no funciona “en el navegador” — es una función nativa que se inicia desde un panel de control en escritorio o en móvil.

Según la documentación, lo que hace el túnel: escanea puertos locales abiertos, permite elegir un subdominio, y proxy HTTP/WebSocket a tu servidor de desarrollo (Next.js, Vite, Expo Metro, etc.) con un arranque en menos de 2 segundos. Incluye un latido de 25 segundos con hasta cinco reconexiones automáticas, y muestra una página offline estilizada en lugar de un error de conexión. La app móvil puede iniciar un túnel remotamente para previsualizar un sitio desde el teléfono sin tocar la máquina.

Dos cosas importantes: está desarrollado por un solo programador independiente (según su listado en la App Store), no por una empresa con un producto de red dedicado, y su plan gratuito está limitado a 3 proyectos, por lo que “cero costo” solo aplica si tu uso se mantiene dentro de ese límite.

La posición de ngrok, que suele ser el punto de comparación

Las críticas a ngrok por limitaciones de ancho de banda y URLs efímeras son generalmente justas: su precio actual limita la transferencia a 1 GB/mes y 20,000 solicitudes HTTP, con hasta 3 endpoints en línea, un dominio autoasignado y una página de advertencia en HTTP gratuito (que puede saltarse con un encabezado). Pero una afirmación que circula mucho en este tipo de artículos no es cierta: el nivel gratuito de ngrok no impone un timeout rígido en la sesión. La documentación de ngrok indica claramente que los endpoints gratuitos no tienen timeout y pueden funcionar indefinidamente en segundo plano — las restricciones reales son los límites mensuales de datos y solicitudes, no una desconexión forzada tras cierto tiempo. Si ves la afirmación de “sesión gratuita de 2 horas” en otro lado, revisa la fuente con la documentación oficial.

Conclusión práctica

Si ya usas Vite o Next.js y ves la advertencia de fallback WebSocket, primero prueba a ajustar la configuración — server.ws en Vite, o asegurarte de que cualquier proxy pase los encabezados Upgrade — antes de buscar una herramienta nueva. Si necesitas una URL HTTPS pública regularmente para desarrollo de webhooks o QA móvil, un túnel que gestione específicamente las actualizaciones WebSocket ahorra ese trabajo de configuración. Y si eliges entre opciones, vale distinguir entre herramientas de código abierto y autoalojables como OutRay, y un túnel que sea una función de conveniencia en un producto más grande (como AgentsRoom), ya que el modelo de confianza y mantenimiento es diferente.

---

Registro de cambios

Reescrito desde un borrador enviado y verificado con fuentes primarias el 28 de julio de 2026.

1. Eliminación de SEO: se quitaron frases clave repetidas (“Next.js tunnel no CLI,” “zero deploy preview,” “zero-context-switching”) usadas solo para SEO, y se reestructuró en torno a las afirmaciones técnicas reales.
2. Corrección en la descripción de AgentsRoom: se aclaró que no es una herramienta “nativa del navegador” para compartir localhost, sino una app de escritorio para orquestar agentes de IA con un túnel integrado, no un producto independiente ni que funcione en navegador. Se mencionó que es desarrollada por un solo programador y que su plan gratuito está limitado a 3 proyectos.
3. Suavizado de una afirmación no verificada de OutRay: no se pudo confirmar que su plugin de Next.js edite automáticamente next.config.ts sin CLI; se verificó que su integración con Express es un middleware npm estándar (@outray/express) y se marcó como no confirmado la mecánica específica.
4. Corrección en la explicación del fallback WebSocket de Vite: se aclaró que el error de fallback puede ignorarse en redes locales, y solo es un fallo real cuando el cliente no puede acceder directamente al servidor, como en un túnel. Fuente: vite.dev/config/server-options.
5. Confirmación del uso de WebSocket en Next.js: desde la versión 12, Next.js usa WebSocket en /_next/webpack-hmr para Fast Refresh, reemplazando SSE; proxies mal configurados pueden causar fallos.
6. Corrección en límites de ngrok y verificación de mitos: se verificaron los límites actuales (1 GB/mes, 20,000 solicitudes, 3 endpoints, dominio autoasignado, página de advertencia) y se aclaró que el “timeout de 2 horas” en el nivel gratuito es falso, ya que no hay timeout en la documentación oficial. Fuente: ngrok.com/docs/pricing-limits/free-plan-limits.
7. Tono general: se reescribió el lenguaje promocional en un análisis técnico neutral; ninguna afirmación se dejó sin verificar con una fuente primaria.