Dev Tunnels de Microsoft: qué son y qué límites tienen

En pocas palabras: Los Dev Tunnels de Microsoft exponen por internet un servicio web local mediante un relay en la nube. Son privados por defecto: entrás solo vos con cuenta Microsoft, Entra ID o GitHub. Están en public preview, sin SLA, para pruebas ad hoc y no para producción.

Los Dev Tunnels de Microsoft son un servicio que expone por internet un servicio web que corre en tu máquina, a través de un relay en la nube, con acceso privado por defecto. Según la documentación de Microsoft Learn consultada el 7 de octubre de 2026, siguen en public preview y sirven para pruebas ad hoc, no para producción.

Sirven para conectar tu entorno de desarrollo con servicios cloud, mostrar trabajo en curso a colegas y probar webhooks. VS Code los trae integrados en la vista Ports, y Visual Studio los incorpora desde la versión 17.4, según un tutorial de Adyen de diciembre de 2022. Esa versión es la mínima, no la vigente en octubre de 2026.

¿Qué son los Dev Tunnels de Microsoft y cómo exponen tu localhost?

Un dev tunnel es un acceso remoto seguro a un host a través de un servicio de relay. Tiene un nombre DNS único, uno o varios puertos, controles de acceso y metadatos. Como la conexión sale desde tu máquina hacia el relay, el host puede estar detrás de un firewall sin aceptar conexiones entrantes, según la documentación de Microsoft.

La terminología oficial ayuda a leer el resto de la documentación:

• Tunnel: el acceso remoto a un host, con DNS propio, puertos y controles de acceso.
• Tunnel relay service: el servicio cloud que conecta host y clientes, incluso si el host no puede recibir conexiones directas.
• Tunnel host: el que acepta conexiones vía el relay y las reenvía a puertos locales.
• Tunnel port: un puerto entre 1 y 65535 que agregaste al túnel. Los que no agregaste quedan cerrados, y cada puerto puede tener su protocolo y su control de acceso.
• Tunnel client: el que inicia la conexión remota hacia el host.

Microsoft lista como beneficios el acceso privado por defecto, las URLs persistentes, varios puertos simultáneos en un mismo túnel, disponibilidad global (se crea en la región más cercana) y la inspección del tráfico desde las DevTools del navegador. Esa última es la que más me gusta, porque depurar un webhook mirando el request real ahorra media tarde de console.log.

Eso sí: la misma página dice que es una public preview sin SLA.

¿Se puede abrir un túnel con F5 en VS Code o JetBrains?

Con VS Code podés reenviar un puerto sin extensiones desde la vista Ports, según la documentación de port forwarding. Un túnel atado a F5 que se abre y se cierra con la sesión de depuración, en cambio, no figura en esa documentación ni en la de Microsoft Learn. Esa idea la propone un artículo de InstaTunnel, publicado el 7 de octubre de 2026.

¿Cómo reenviar un puerto en VS Code paso a paso?

1. Tené un servicio corriendo. Con Node.js instalado, npx serve levanta uno en el puerto 3000.
2. Abrí la vista Ports en el panel (comando Ports: Focus on Ports View) y elegí Forward a Port.
3. Si nunca iniciaste sesión con GitHub, VS Code te pide que lo hagas.
4. Ingresá el puerto. Con el comando anterior es el 3000.
5. Copiá la Forwarded Address. Al pasar el mouse tenés acciones para copiarla, abrirla en el navegador o verla en un preview dentro del editor.
6. Si querés que entre cualquiera, clic derecho sobre el puerto y Port Visibility > Public.

Un detalle que interpreto yo, no la documentación: como el puerto nace Private y exige la misma cuenta de GitHub o Microsoft en ambos extremos, un colega con otra cuenta no va a entrar. Para compartir hay que pasarlo a Public. En Visual Studio, el tutorial de Adyen menciona además un modo org, que limita el acceso a usuarios de la misma organización.

¿Qué propone la fuente y qué no está verificado?

InstaTunnel muestra un tasks.json con una tarea de tipo devtunnel, un problemMatcher llamado $devtunnel-host y un launch.json con preLaunchTask, postDebugTask y la variable ${command:devtunnel.getResolvedUrl}. Ninguno de esos nombres aparece en la documentación oficial consultada, así que tratalos como una propuesta y no como una API de Microsoft. Sobre JetBrains no hay respaldo oficial en las fuentes.

Lo que sí está documentado, aunque en un tutorial de terceros (Adyen, diciembre de 2022), es que Visual Studio expone la URL del túnel en la variable de entorno VS_TUNNEL_URL, o VS_TUNNEL_URL_PROJECTNAME si tenés varios proyectos. Desde Visual Studio 17.6 el asistente crea túneles persistentes o temporales, públicos o privados. Como el post tiene casi cuatro años, contrastalo con la documentación vigente antes de copiarlo. Cubrimos ese tema en detalle en la comparativa entre Microsoft y GitHub.

¿Es seguro exponer localhost con un túnel?

Con la configuración por defecto, sí: los túneles son privados y tanto alojar como conectarse exigen la misma cuenta de GitHub o Microsoft, según la documentación de VS Code. El riesgo aparece cuando abrís un puerto Public, porque cualquiera que tenga el link accede al servicio. La propia documentación recomienda no alojar información confidencial ni servicios inseguros en puertos públicos.

VS Code hace conexiones salientes hacia un servicio hospedado en Azure, no suele requerir cambios en el firewall y no abre listeners de red. Es un modelo mucho más tranquilo que dejar un puerto abierto en el router.

Levantás el servidor, reenviás el puerto, pegás la URL en la consola del proveedor de webhooks, te vas a almorzar, la laptop entra en suspensión, el túnel se cae o queda abierto sin que nadie lo mire, y cuando volvés el callback falla o, peor, tenés un endpoint interno expuesto a internet que ya nadie recuerda haber abierto.

Esos dos problemas (túneles huérfanos y URLs que cambian y rompen webhooks u OAuth) los describe la fuente de InstaTunnel como dolores de las herramientas de línea de comandos. También afirma que, al recibir la señal disconnect, el plano de control invalida las rutas de ingreso de inmediato. Esa garantía es una afirmación de la fuente. No la encontré confirmada en la documentación oficial, así que no la tomes como comportamiento asegurado.

La consecuencia práctica es corta: dejá el acceso en privado siempre que el que consume pueda autenticarse, y cerrá el túnel cuando termines. Lo explicamos a fondo en conectarte por SSH a una VM de Azure.

¿Se pueden tunelizar dispositivos WebUSB y WebBluetooth para QA remoto?

Los Dev Tunnels de Microsoft no documentan nada sobre WebUSB ni WebBluetooth. Lo que describe InstaTunnel es un patrón de arquitectura de un tercero: un agente local serializa las transferencias USB y las operaciones GATT en frames sobre WebSocket o QUIC, y el lado remoto los reconstruye con un polyfill, un driver o una extensión de navegador. Es una propuesta, no una función confirmada.

Según la fuente, las transferencias USB de control, bulk e interrupt viajan en datagramas QUIC o frames WebSocket binarios, y en Linux el espejo usaría vhci. En Bluetooth, las lecturas de característica, las escrituras sin respuesta y las suscripciones a notificaciones se traducen a frames con UUIDs, offsets de handle y buffers. El caso de uso es probar dashboards de telemetría médica, puntos de venta o utilidades de flasheo de firmware sin escribir mocks.

El texto de la fuente llega cortado justo en la especificación del frame, y solo se ve el campo magic (0x5553). No voy a completar el resto. Tampoco trae benchmarks de latencia, así que no hay forma de saber si un flasheo de firmware aguanta un túnel.

Ahora bien, el problema de seguridad es evidente: exponer hardware físico por la red es más delicado que exponer un puerto HTTP. Antes de probarlo en serio, yo exigiría números de latencia y un modelo de autenticación documentado. Relacionado: las certificaciones de Azure según tu rol.

¿Qué límites tienen los Dev Tunnels y cuándo conviene usarlos?

Los Dev Tunnels sirven para desarrollo y pruebas ad hoc: webhooks, callbacks de OAuth, demos y revisiones con colegas. No sirven para producción. Según la documentación de Microsoft Learn consultada el 7 de octubre de 2026, el servicio sigue en public preview, sin SLA, y Microsoft no lo recomienda para cargas productivas.

Los límites documentados son estos:

• Sin SLA: la preview puede cambiar o tener funciones acotadas.
• Cuotas variables: hay límites de ancho de banda y de máquinas activas que pueden cambiar con el tiempo. La documentación consultada no trae las cifras.
• Solo servicios locales: el port forwarding de VS Code expone únicamente servicios que corren en tu máquina. Los de una máquina remota no están soportados por ahora.
• Políticas de organización: si tu empresa quiere controlar el acceso, puede permitir o bloquear el dominio global.rel.tunnels.api.visualstudio.com. En Windows también hay políticas de grupo.

Hay una contradicción para tener en cuenta. La documentación de Microsoft habla de URLs persistentes, y la fuente de InstaTunnel vende túneles “efímeros”. Las dos descripciones pueden convivir si pensás en el ciclo de vida de la sesión, pero no son lo mismo. Si tu flujo depende de que la URL no cambie, leé la política de persistencia vigente.

Una propuesta editorial para verificar la afirmación del cierre automático, sin atribuirla a ninguna fuente y sin que la hayamos probado: reenviá un puerto, copiá la URL, cerrá el túnel o la sesión de depuración, y reintentá esa URL desde una ventana de incógnito o desde otra red. Si todavía responde, el cierre no es el que te prometen. Repetilo después de cada actualización de VS Code.

Si necesitás una URL estable para producción, el túnel no es el camino. Ahí corresponde desplegar en un servidor o VPS propio, por ejemplo con donweb.com.

Qué está confirmado y qué no

Confirmado por documentación oficial:

• El port forwarding está integrado en VS Code vía dev tunnels, sin extensión.
• El puerto es Private por defecto y se puede pasar a Public.
• El servicio está en public preview y no es para producción.
• La inspección de tráfico es posible desde las DevTools del navegador.

No confirmado (afirmaciones de la fuente de InstaTunnel o de terceros): Mirá también qué es y cómo funciona Copilot.

• El tipo de tarea devtunnel, el matcher $devtunnel-host y ${command:devtunnel.getResolvedUrl}.
• La integración con JetBrains.
• El cierre inmediato de rutas al desconectar el debugger y la pausa de tráfico en breakpoints.
• El túnel de hardware WebUSB y WebBluetooth, con frame truncado y sin benchmarks.

Errores comunes al usar túneles locales

• Dejar el puerto en Public “para probar rápido”. Cualquiera con el link entra. Usá Public solo para quien no puede autenticarse (un proveedor de webhooks, por ejemplo), y validá la firma del request en tu código.
• Mandar un link privado a un colega y esperar que abra. Con la configuración por defecto exige tu misma cuenta. Cambiá la visibilidad o usá org en Visual Studio.
• Tratar la preview como infraestructura. Sin SLA y con cuotas que pueden cambiar, una demo para un cliente puede caerse en el peor momento.
• Copiar los nombres de tarea de la fuente en tu tasks.json. Si el tipo devtunnel no existe en tu versión de VS Code, no va a pasar nada útil.
• Pegar la URL a mano en la consola del proveedor. En Visual Studio podés leer VS_TUNNEL_URL y actualizarla por código.

Preguntas Frecuentes

¿Los Dev Tunnels sirven para producción?

No. Microsoft los define como una herramienta para pruebas y desarrollo ad hoc, en public preview y sin SLA, y no recomienda usarlos para cargas de producción. Tema relacionado: el ataque con malware Miasma a repositorios de GitHub.

¿Es seguro exponer localhost con un túnel?

Con la configuración por defecto sí, porque el túnel es privado y exige la misma cuenta de GitHub o Microsoft en ambos extremos. Si abrís un puerto como Public, cualquiera con el link accede al servicio, así que no pongas ahí datos confidenciales.

¿Cómo hago público un puerto reenviado en VS Code?

Hacé clic derecho sobre el puerto en la vista Ports y elegí Port Visibility > Public. Los puertos públicos no piden iniciar sesión, mientras que el valor por defecto es Private.

¿Se puede probar un dispositivo WebUSB o WebBluetooth de forma remota con un túnel?

Las fuentes oficiales no documentan esa función en Dev Tunnels. InstaTunnel describe un patrón con un agente local y frames sobre WebSocket o QUIC, pero la especificación llega truncada y sin benchmarks, así que sigue sin confirmarse.

¿Qué variable expone la URL del túnel en Visual Studio?

Visual Studio expone la URL en VS_TUNNEL_URL, o en VS_TUNNEL_URL_PROJECTNAME cuando hay varios proyectos. El dato sale de un tutorial de Adyen de diciembre de 2022, así que conviene confirmarlo en tu versión.

Conclusión

Lo confirmado es más modesto que lo que vende la fuente: con los Dev Tunnels de Microsoft reenviás un puerto desde VS Code, con acceso privado por defecto, para webhooks, callbacks y demos. El túnel atado a F5, el soporte de JetBrains y el túnel de hardware son ideas de un proveedor de túneles, y hay que contrastarlas con la documentación antes de adoptarlas.

Mi recomendación: usalos para desarrollo, dejá el puerto en privado, cerrá el túnel al terminar y verificá el cierre con la prueba de incógnito. Para cualquier cosa que tenga que estar en línea de forma estable, desplegá en un servidor propio.

Fuentes

• Microsoft Learn – Qué son los dev tunnels (documentación oficial)
• Visual Studio Code – Port Forwarding con dev tunnels
• Adyen en DEV – Cómo usar Visual Studio Dev Tunnels para recibir webhooks en localhost
• InstaTunnel en DEV – Modern DX and Beyond local-tunneling (blog de un proveedor de túneles)