DESARROLLO LOCAL · PRUEBAS REALES
Comparte localhost: pruebas móviles y de webhooks
Tu web funciona en tu ordenador. Dale a tu móvil, a un cliente o a un servicio de webhooks un enlace HTTPS temporal para acceder, sin desplegarla.
Antes de compartir: comprueba la dirección local
Mira la URL que muestra tu servidor de desarrollo. El protocolo y el puerto importan: http://localhost:5173 y https://localhost:7143 son destinos distintos. Abre esa dirección exacta y realiza una acción habitual antes de crear el túnel.
Una aplicación, un puerto
Si la página y la API usan la misma dirección local, un túnel puede acceder a ambas. Conserva las rutas: una petición pública a /contact llega a /contact en la aplicación local. El túnel no copia ni despliega tus archivos.
Frontend y API en puertos distintos
Un túnel al frontend no publica automáticamente una API en otro puerto. Si el navegador llama a localhost:3000, contacta con el dispositivo del visitante. Usa el proxy de API del servidor de desarrollo o una URL de prueba accesible para la API y ajusta el frontend.
Consigue un enlace público
Inicia tu web o API y comprueba que abre en local. GhostlyShare detecta automáticamente las aplicaciones web locales en ejecución. Pulsa Go Public para crear un enlace HTTPS público.
- Mantén la aplicación y GhostlyShare abiertos durante la prueba.
- Abre el enlace en una ventana privada antes de compartirlo.
- Utiliza datos de prueba. Añade una contraseña si necesitas una vista previa privada para un cliente.
Windows y Linux. Enlaces temporales gratuitos sin cuenta, correo electrónico ni suscripción.
Descargar GhostlyShare ↗
Abre la dirección pública en tu ordenador y en otro dispositivo. Si la página local funciona y la pública no, ten ambas URL a mano para distinguir un fallo de la aplicación de uno del túnel o de la configuración del host.
Abre localhost en tu móvil
En el móvil, localhost se refiere al propio móvil, no a tu ordenador. Abre el enlace público o escanea el código QR de GhostlyShare.
- Usa datos móviles para comprobar el acceso desde fuera de tu Wi-Fi.
- Prueba el menú, los formularios, el teclado y las subidas de archivos en el dispositivo real.
- Abre una página interna directamente y recárgala. Comprueba también imágenes y respuestas de la API.
¿Solo pruebas en la misma Wi-Fi? La dirección de red local del ordenador puede bastar si el servidor de desarrollo y el cortafuegos permiten el acceso. Un túnel público sirve para otras redes y servicios externos.
Una prueba móvil útil en cinco minutos
- Navegación y diseño
- Abre el menú, gira el móvil y visita una página larga. Busca desplazamiento horizontal, botones tapados y contenido oculto por una cabecera fija. La emulación del navegador ayuda, pero no reproduce todas las interacciones reales.
- Formularios y sesión
- Toca cada campo y envía primero un valor incorrecto y luego uno válido. Comprueba que los errores se ven por encima del teclado. Si el inicio de sesión solo funciona en el ordenador, prueba una sesión nueva y revisa el callback y las cookies.
- Peticiones y carga
- Prueba una página con muchas imágenes y una acción que cargue datos. Una respuesta lenta a través de tu conexión doméstica no mide el rendimiento en producción. Anota página, dispositivo y acción para reproducir el fallo localmente.
Muestra tu trabajo a un cliente
Envía la página concreta que quieres revisar. Explica qué probar y cuándo se cerrará la vista previa.
Antes de enviarlo
Usa una cuenta de prueba y contenido de ejemplo. Comprueba que el enlace funciona sin tus cookies ni tu sesión iniciada.
Pide una comprobación concreta
Rellenar el formulario, revisar el menú móvil o completar una compra con pagos de prueba: una tarea clara genera comentarios más útiles.
Aquí tienes la vista previa para la revisión de hoy. Comprueba el menú móvil y el formulario de contacto. El enlace se cerrará después de nuestra llamada.
Haz que los comentarios permitan reproducir el fallo
Pide la URL, el dispositivo, el navegador y la última acción antes del problema. Una captura con «esperaba X, pero ocurrió Y» ayuda más que «la página no funciona». Avisa si editas la aplicación durante la revisión: según la configuración, los visitantes podrían ver cambios o una recarga inmediata.
Recibe un webhook en local
Un servicio de webhooks no puede acceder al localhost de tu ordenador. Facilítale la dirección pública del túnel con la ruta de callback. Este ejemplo presupone que tu aplicación ya procesa peticiones POST en /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Sustituye YOUR-TUNNEL por tu nombre de host real e introduce la URL completa de callback en los ajustes de prueba del proveedor.
- Mantén activada la verificación de firmas. Guarda el secreto del webhook en local y envía un evento de prueba desde el proveedor.
- Comprueba el estado de entrega y los registros locales. Devuelve la respuesta de éxito que espera el proveedor y gestiona los reintentos sin repetir la acción.
Una solicitud de contraseña en el navegador puede bloquear al emisor del webhook. Usa un endpoint accesible para el proveedor y verifica sus peticiones firmadas. CORS afecta a peticiones del navegador, no a webhooks entre servidores.
Comprueba el resultado del webhook, no solo el navegador
Abrir el callback en el navegador suele enviar GET. Muchos endpoints de webhooks esperan POST, así que un error del navegador no demuestra un fallo de entrega. Envía el evento de prueba del proveedor y compara su hora e identificador de entrega con tu registro local.
- 404 / 405
- Comprueba la ruta y el método HTTP. Usa el puerto de la API, no necesariamente el del frontend. Que la página principal abra no significa que exista el endpoint de callback.
- 401 / 403
- Identifica qué rechazó la petición: la contraseña de vista previa, la autenticación de la aplicación o la firma. Sigue las reglas del proveedor sobre el cuerpo original de peticiones firmadas; analizarlo y reescribirlo antes de verificarlo puede invalidar la firma.
- 5xx / Timeout
- Comprueba que la aplicación sigue activa y recibió la petición. Si el procesamiento tarda, respeta el plazo del proveedor y usa tareas en segundo plano cuando convenga. Prueba una entrega repetida para evitar pedidos o mensajes duplicados.
Usa el modo de prueba del proveedor y evita registrar secretos o datos personales completos. Una prueba correcta verifica la entrega y su procesamiento, pero no sustituye los requisitos de integración del proveedor.
¿El enlace abre, pero algo falla?
El enlace público no llega a la aplicación
Abre primero la URL local. Comprueba el puerto, HTTP o HTTPS y que la aplicación y el túnel sigan funcionando.
Fallan imágenes o llamadas a la API
Busca URL localhost escritas directamente en el código. Usa rutas relativas cuando puedas. Una API en otro puerto necesita una ruta accesible propia.
La aplicación redirige a localhost
Comprueba la URL base pública, los proxies de confianza y los callbacks de inicio de sesión. Autoriza el host real de la vista previa sin desactivar globalmente los controles de host.
Fallan la recarga en vivo o los WebSockets
Comprueba que los WebSockets usan el host público y wss en páginas HTTPS. Algunos servidores de desarrollo requieren configurar un host HMR aparte.
El webhook no recibe una respuesta de éxito
Comprueba la ruta de callback, el método HTTP, el secreto de firma y el registro de entrega. Actualiza la URL de callback al iniciar otro túnel temporal.
Termina la prueba y deja de compartir
Detén la publicación en GhostlyShare o el túnel de la terminal con Ctrl+C. La caducidad puede cerrar automáticamente una vista previa programada. Elimina también las URL temporales de callback del proveedor al acabar.
¿Necesitas una dirección fija para uso continuo?
Una vista previa temporal no es un despliegue. Nuestra guía de alojamiento en casa explica túneles con nombre, dominios, servicios de Windows y costes de funcionamiento.
Configurar un Cloudflare Tunnel permanente →Preguntas sobre vistas previas locales
Preguntas frecuentes
¿Por qué localhost no funciona en mi móvil?
Localhost identifica el dispositivo que abre la dirección. Usa el enlace público en el móvil para acceder a la aplicación de tu ordenador.
¿Debe permanecer encendido mi ordenador?
Sí. El ordenador, la aplicación local y el túnel deben seguir activos. La suspensión o detener el túnel deja la vista previa inaccesible.
¿Necesito un dominio para una vista previa?
No. Un túnel temporal proporciona una dirección HTTPS pública. Actualiza los enlaces y los ajustes de webhooks si cambia esa dirección.