Por qué tu enlace de verificación va a localhost:3000 y cómo solucionarlo

Qué está pasando

Cada correo de verificación, enlace mágico, invitación y restablecimiento contiene un enlace de vuelta a tu app. Tu proveedor de autenticación o tu framework construye ese enlace a partir de una configuración: la URL del sitio, una URL de redirección o el host con el que está configurado tu mailer. Si esa configuración todavía dice http://localhost:3000, todos los correos apuntan al propio equipo del desarrollador.

A veces el enlace en sí está alojado, por ejemplo https://yourproject.supabase.co/auth/v1/verify?..., y solo la página a la que redirige después es local. La verificación funciona, luego el navegador se envía a localhost:3000 y falla. Esta variante es fácil de pasar por alto, porque el correo se ve bien.

Solucionarlo en Supabase (incluidas las apps de Lovable en tu propio proyecto de Supabase)

1. En el panel de Supabase, abre Authentication → URL Configuration.
2. Configura Site URL con tu dirección en producción, como https://your-app.lovable.app o tu propio dominio. Un proyecto nuevo de Supabase empieza con http://localhost:3000 aquí.
3. Añade cualquier otro entorno que uses (staging, dominios de vista previa, localhost para desarrollo) en Redirect URLs. Se admiten comodines para los despliegues de vista previa.
4. Si tu código pasa emailRedirectTo o redirectTo al llamar al registro o al inicio de sesión, constrúyelo a partir del sitio actual, por ejemplo window.location.origin, o de una variable de entorno. Una redirección que no está en la lista permitida vuelve a la Site URL.
5. Si personalizaste las plantillas de correo, comprueba que usen las variables de URL de confirmación o de URL del sitio de la plantilla en lugar de una dirección fija.

Solucionarlo en Firebase Authentication

• Revisa la URL de continuación que pasa tu código en la configuración del código de acción al enviar enlaces de verificación o de inicio de sesión. Debe venir del entorno, no de un http://localhost fijo en el código.
• Añade tu dominio en producción en Authentication → Settings → Authorized domains.

Solucionarlo en otros stacks

• Auth.js / NextAuth: configura la URL del despliegue (AUTH_URL, o NEXTAUTH_URL en versiones anteriores) donde tu host no la deduzca.
• Ruby on Rails: configura config.action_mailer.default_url_options con el host correcto en la configuración de cada entorno.
• Django: construye los enlaces a partir de la petición o del framework Sites, y asegúrate de que el dominio del sitio no siga siendo example.com o localhost.
• Laravel: configura APP_URL para cada entorno.
• Cualquier otro: busca localhost:3000 en el código y muévelo a una variable de entorno.

En un simulador o emulador de teléfono

El simulador de iOS comparte la red de tu equipo, así que los enlaces a localhost se abren allí. El emulador de Android no: llega a tu equipo en 10.0.2.2, así que un enlace a localhost:3000 no abre nada. Para un emulador, apunta los enlaces de la app a http://10.0.2.2:3000 o, mejor, a una dirección de staging a la que ambos puedan llegar. Más información en Apps móviles.

Cómo lo marca Proxy Mail QA

Cuando un enlace de un correo de prueba apunta a una dirección local, o redirige a una tras la verificación, Proxy Mail QA lo marca en la fila de Accounts (“Redirects to localhost:3000”) y lo explica en la bandeja de entrada. Puedes ver de un vistazo que el entorno está mal configurado, antes de que alguien lo reporte como “la verificación no funciona”.

Si estás probando una build local a propósito, elige This is my dev environment. Los enlaces a ese host dejan de marcarse en ese proyecto, y las comprobaciones de correo los aceptan. Puedes quitarlo de nuevo desde la configuración del proyecto. Un agente de programación puede marcar el host por sí mismo con la herramienta mark_dev_host de MCP, y un conjunto de pruebas con POST /v1/project/dev-hosts (markDevHost en el cliente de Node.js, mark_dev_host en el helper de Python).