Comparte tu localhost con un dominio y HTTPS desde VSCode (Port Forwarding)
Si alguna vez has querido mostrarle a un cliente, a un compañero de equipo o a tu propio celular un proyecto que está corriendo en localhost:3000, sabes que enviar ese link no sirve de nada. La otra persona simplemente no puede abrirlo.
La solución típica ha sido usar herramientas como ngrok o cloudflared para crear un túnel hacia tu máquina local. Pero desde hace ya un tiempo, Visual Studio Code trae esta funcionalidad integrada, sin instalar extensiones, completamente gratis. Solo necesitas una cuenta de GitHub.
En este artículo vamos a ver cómo usar Port Forwarding en VSCode, cómo funciona por debajo, qué tan seguro es, sus limitaciones, y un par de características relacionadas que pocos desarrolladores conocen.
¿Qué es Port Forwarding en VSCode?
Port Forwarding es una característica integrada de Visual Studio Code que toma un puerto que está corriendo en tu máquina (por ejemplo localhost:3000) y lo expone a internet a través de una URL pública con HTTPS.
El resultado es una URL similar a esta:
https://abc123-3000.use.devtunnels.ms/
Esa URL apunta a tu servidor local en tiempo real. Cualquier cambio que hagas en tu código se refleja inmediatamente para quien tenga el enlace, igual que si estuviera viendo tu localhost.
¿Cómo funciona por debajo?
VSCode no inventa esto desde cero. Por debajo usa Microsoft Dev Tunnels, un servicio que corre sobre Azure y que se encarga de:
- Establecer una conexión segura desde tu máquina hacia los servidores de Microsoft.
- Generar una URL pública con HTTPS.
- Redirigir el tráfico de esa URL a tu puerto local a través del túnel.
Es importante notar que VSCode no abre puertos en tu firewall ni configura listeners de red. Toda la comunicación es saliente desde tu máquina hacia Azure, lo que lo hace bastante práctico en redes corporativas o detrás de NAT.
La autenticación inicial se hace con tu cuenta de GitHub (o Microsoft), y eso también define quién puede acceder a la URL en modo privado.
Cómo usar Port Forwarding paso a paso
Vamos con un ejemplo concreto. Supongamos que tienes un proyecto Next.js (o cualquier framework) corriendo en localhost:3000.
1. Levanta tu servidor local
npm run dev
Confirma que tu app responde correctamente en http://localhost:3000 antes de continuar. Si tu local no funciona, el túnel tampoco va a funcionar.
2. Abre la pestaña Ports
En VSCode, abajo donde está la terminal, busca la pestaña Ports (al lado de Terminal, Output, Debug Console).
Si no la ves, puedes abrirla con la paleta de comandos:
Ctrl + Shift + P → "Ports: Focus on Ports View"
3. Forward a Port
Haz click en el botón Forward a Port y escribe el número del puerto (en nuestro caso 3000). Presiona Enter.
La primera vez que hagas esto, VSCode te va a pedir autenticarte con GitHub. Le das permitir, autorizas la app en el navegador, y vuelves al editor.
4. Obtén tu URL pública
Una vez creado el túnel, vas a ver tu puerto listado con tres iconos al lado:
- Copiar la dirección local forwarded.
- Abrir en navegador.
- Ver dentro del editor (un preview integrado).
5. Cambia la visibilidad si lo necesitas
Por defecto el puerto es privado. Eso significa que para acceder a la URL, la otra persona necesita estar logueada con la misma cuenta de GitHub que tú usaste.
Si quieres que cualquiera con el link pueda entrar sin login:
- Click derecho sobre la fila del puerto.
- Elige Port Visibility → Public.
- Confirma.
Listo. Ahora puedes compartir esa URL con quien quieras.
Niveles de visibilidad: Private, Public y Org
Una cosa que se suele pasar por alto es que hay tres niveles de visibilidad, no solo dos:
| Visibilidad | Quién puede acceder | Cuándo usarla |
|---|---|---|
| Private | Solo tú (con tu cuenta de GitHub) | Para testear desde otros dispositivos tuyos (ej: tu celular). |
| Org | Miembros de tu organización en GitHub | Para compartir con tu equipo sin exponer a internet abierto. |
| Public | Cualquiera con el link | Para demos a clientes, testing público, integración con webhooks. |
El nivel Org es particularmente útil si trabajas en un equipo y no quieres que el link esté expuesto al mundo. Es el balance perfecto entre seguridad y comodidad.
Casos de uso prácticos
Más allá del clásico "mostrarle algo a un cliente", estas son situaciones donde Port Forwarding te ahorra mucho tiempo:
Probar tu app desde dispositivos móviles
Cuando estás desarrollando una web responsive, las DevTools del navegador te dan un emulador, pero no es lo mismo que probar en un dispositivo real. Con Port Forwarding puedes abrir la URL pública desde tu celular o tablet y ver cómo se comporta tu app en hardware real.
Tip: En Chrome (y navegadores basados en Chromium) puedes generar un código QR de la URL desde el menú de la barra de direcciones (icono de compartir). Escaneas el QR con el celular y abres la página directamente sin tener que tipear la URL.
Recibir webhooks de servicios externos
Esto es oro puro para integraciones. Si estás trabajando con:
- Pasarelas de pago (Stripe, Cryptomus, Mercado Pago).
- APIs de mensajería (Twilio, WhatsApp Business).
- Webhooks de CRMs o herramientas de análisis (Meltwater, HubSpot).
- Eventos de servicios como Supabase, Clerk, etc.
...puedes apuntar el webhook directamente a tu URL forwarded y debuggear en vivo desde tu editor, sin tener que desplegar a staging cada vez que cambias algo.
Demos a clientes sin desplegar nada
Cuando estás en fase de prototipado y todavía no quieres montar un staging completo, una URL temporal con tu localhost es suficiente para que el cliente vea avances. Si activas hot reload, los cambios se reflejan en tiempo real mientras hablan.
Pair programming asincrónico
A veces un compañero quiere ver "cómo se ve" lo que estás haciendo sin tener que clonar el repo y levantar el ambiente. Le mandas la URL y listo.
Limitaciones a tener en cuenta
Esta característica es excelente, pero no es una solución de producción. Aquí van los límites importantes:
- Solo funciona con servicios locales. Si tu app corre en un servidor remoto, esto no aplica. Para eso existe Remote Tunnels (que veremos abajo).
- Hay límites de ancho de banda y de máquinas activas. Microsoft no publica los números exactos y pueden cambiar, pero no esperes correr un servicio de alta carga por aquí.
- El túnel muere cuando cierras VSCode o detienes el forward. La URL deja de funcionar.
- Las URLs son temporales. Cada vez que reinicias el túnel, el hash en la URL cambia (a menos que uses dev tunnels CLI con configuración persistente).
- No es para producción. Esto está diseñado para desarrollo y testing. Si necesitas hostear algo de verdad, usa Vercel, Railway, Cloudflare, o tu plataforma favorita.
Consideraciones de seguridad
Cuando pones un puerto en Public, estás efectivamente abriendo tu servicio local a internet. Eso implica algunos riesgos que vale la pena conocer:
Tu app expuesta debe estar lista para internet
Si tu app local no tiene autenticación, validación de inputs, o protección contra spam y ataques básicos, exponerla públicamente puede ser un problema. Especialmente si estás conectado a una base de datos local con datos sensibles.
No expongas servicios sensibles
Nunca hagas Public a un puerto donde corra tu base de datos, un panel de admin sin auth, o cualquier servicio que contenga credenciales o datos privados. Para eso usa Private u Org.
Usa Public solo el tiempo necesario
Una vez que el cliente o el webhook ya hizo lo suyo, regresa el puerto a Private o detén el forward. Cada minuto extra expuesto es un minuto extra de superficie de ataque.
Controles a nivel organización
Si trabajas en una empresa que necesita controlar quién puede usar Port Forwarding, los administradores pueden permitir o denegar acceso al dominio global.rel.tunnels.api.visualstudio.com, o aplicar group policy en Windows.
Comparación con alternativas
| Herramienta | Pros | Contras |
|---|---|---|
| VSCode Port Forwarding | Integrado, gratis, sin instalación, soporta visibilidad privada/org. | Atado a VSCode, requiere cuenta GitHub, URLs no persistentes. |
| ngrok | Subdominios fijos en plan pago, dashboard web, inspector de tráfico, soporte para TCP. | Plan gratuito limitado, URLs cambian en plan free. |
| cloudflared (Cloudflare Tunnels) | Gratis, integración con Cloudflare, dominios propios, muy estable. | Configuración más compleja, requiere cuenta Cloudflare. |
| localtunnel | Open source, sin cuenta. | Menos confiable, sin HTTPS persistente. |
| Tailscale Funnel | Si ya usas Tailscale, integración natural. | Requiere ecosistema Tailscale. |
Mi recomendación práctica: para algo rápido y casual, Port Forwarding de VSCode. Para integraciones serias con webhooks o testing recurrente, cloudflared con un dominio propio. Para inspección de tráfico HTTP en debugging, ngrok sigue siendo imbatible.
Bonus 1: Remote Tunnels
Si tu proyecto corre en un servidor remoto (un VPS, un AWS Lightsail, un dispositivo en otra red), Port Forwarding no te sirve directamente. Pero VSCode tiene una característica relacionada llamada Remote Tunnels.
Remote Tunnels te permite conectarte a una instancia remota de VSCode desde el navegador o desde otro VSCode local. Esto significa que puedes:
- Abrir tu editor en
vscode.devy conectarte a tu máquina de desarrollo en otro lugar. - Compartir acceso al editor (no solo al output) con otro desarrollador.
- Trabajar desde un dispositivo donde no tienes instalado tu setup completo.
Para activarlo, busca en la paleta de comandos:
> Remote Tunnels: Turn on Remote Tunnel Access
Te va a pedir autenticación, vinculas la sesión, y obtienes una URL del estilo https://vscode.dev/tunnel/... desde donde puedes acceder al editor completo.
Bonus 2: Live Share
Otra alternativa, especialmente útil para pair programming en vivo, es la extensión oficial Live Share de Microsoft. Funciona sobre el mismo sistema de túneles por debajo, pero con un enfoque diferente:
- Compartes el editor, no la URL del servicio.
- La otra persona puede editar código contigo en tiempo real.
- Soporta debugging colaborativo, terminales compartidas, y forwardeo de puertos automático.
- Funciona con cualquier IDE de la familia: VSCode, Visual Studio.
Si tu objetivo es trabajar en código con otra persona simultáneamente, Live Share es la herramienta correcta. Si tu objetivo es mostrar cómo se ve tu app, Port Forwarding es más simple.
Conclusión
Port Forwarding en VSCode es una de esas características que, una vez que la conoces, dejas de instalar tres herramientas distintas para resolver el mismo problema. Está integrada, es gratis, soporta tres niveles de visibilidad, y en la mayoría de casos es suficiente para el día a día.
Cuando trabajes en proyectos donde necesites:
- Compartir avances con clientes sin desplegar.
- Probar webhooks externos.
- Testear desde dispositivos móviles.
- Hacer demos rápidas.
...recuerda que ya tienes esto a un click de distancia en tu editor.
Y si tu setup va más allá (servidores remotos, pair programming, inspección de tráfico), Remote Tunnels, Live Share, ngrok y cloudflared cubren los huecos restantes.
¿Alguna característica de VSCode que quieras que cubra en un siguiente artículo? Déjamelo en los comentarios.