Español
English
Català
FrançaisQue una aplicación de Next.js funcione en localhost no determina qué alojamiento necesita. Hay que comprobar el resultado de construcción y qué funciones espera ejecutar cuando llega una petición. Una exportación estática entrega archivos; una aplicación que necesita lógica de servidor requiere un servicio capaz de ejecutarla.
Este diagnóstico utiliza un ejemplo original con ensayo local terminado y revisión independiente aprobada. Te permite comprobar el artefacto antes de elegir alojamiento. No acredita una entrega nativa de Next.js en Hostbrid, soporte SSR, todas sus funciones, autenticación ni bases de datos.
Si tu app se creó con v0 y quieres ejecutarla fuera de Vercel, sigue la guía para alojar una app de v0, que distingue la salida estática de Next.js de las funciones que necesitan Node.
Distingue exportar archivos de ejecutar una aplicación
La documentación oficial de exportación estática describe output: 'export': el build produce los archivos que publica un servidor estático. No es equivalente a output: 'standalone', que prepara una aplicación para ejecutarse con Node.
La presencia de Server Components por sí sola no demuestra que necesites un servidor en cada petición. En una exportación compatible pueden ejecutarse durante el build y producir HTML. Lo que importa es si la aplicación requiere información o trabajo que no puede resolverse durante esa construcción.
Haz un inventario antes de cambiar la configuración: rutas cuyo conjunto no conoces al construir, cookies del usuario, acciones de servidor, handlers que leen la petición, regeneración incremental y optimización de imágenes mediante el loader predeterminado. La documentación oficial identifica restricciones concretas para estas funciones. Desactivarlas para lograr un build verde puede eliminar comportamiento necesario; un build que pasa no demuestra que tu aplicación conserve lo que hacía.
Una ruta exportada tiene su propio documento
En una SPA habitual puede existir un único HTML que el router interpreta en el navegador. Una exportación de Next.js genera documentos por ruta. Si todas las peticiones se reescriben indiscriminadamente a la portada, /about puede responder con 200 y mostrar la página equivocada.
Una consulta real de publicación en cPanel describe ese síntoma al recargar una ruta. La pregunta muestra la fricción; sus respuestas no sustituyen la documentación actual ni una prueba de tu configuración.
Comprueba cómo quedan las rutas en la carpeta exportada. trailingSlash modifica la disposición de los archivos: no copies reglas de otra web sin mirar el resultado. Prueba entrada directa, navegación desde otra página y recarga. En cada caso verifica contenido e identidad de página, además del código HTTP. Una ruta inexistente debe seguir siendo un error verificable, no una portada disfrazada de éxito.
Decide qué rutas existen durante el build
Las rutas dinámicas exportadas necesitan parámetros que permitan generar sus documentos durante la construcción. Si tu aplicación descubre nuevos identificadores sólo al recibir una petición, no basta con añadir una lista inventada para silenciar el error: debes decidir si puedes regenerar y publicar el conjunto o si necesitas otra arquitectura.
El ejemplo genera /notes/orbita/ y comprueba que un slug desconocido devuelve un 404 real. Al retirar generateStaticParams() de la ruta dinámica, el build terminó con código 1 y el error específico de Next.js que indica la incompatibilidad con output: export. La instalación había pasado; un fallo de red o de dependencias no habría contado como ese control.
Resultados del ensayo local
El ensayo fija Next.js 16.4.0, React 19.3.0, Node 22.23.3 y npm 10.9.9. Generó tres documentos diferentes: portada, /about/ y /notes/orbita/. Se comprobaron sus bytes por HTTP y seis casos de Chrome a 390 y 1280 píxeles, DPR 2, con entrada directa y recarga de un documento nuevo. CSS, SVG y JavaScript se cargaron; un contador pasó de 0 a 1 al pulsar y volvió a 0 al recargar. Ese contador sólo tiene estado en memoria: no demuestra persistencia.
El control negativo devolvió los bytes exactos de la portada con HTTP 200 al pedir /about/. El mismo verificador que aceptaba la página correcta rechazó esa identidad incorrecta. Así se comprueba un fallo que una revisión basada sólo en el código HTTP habría pasado por alto.
La primera ejecución falló porque el servidor local del ensayo no decodificaba una URL de chunk con corchetes. Se corrigió el servidor y se completó una ejecución nueva. Ese fallo del ensayo se conserva como evidencia; no demuestra un defecto del producto de alojamiento.
Las pruebas locales identifican el artefacto exportable y sus restricciones. No evalúan una publicación del proyecto en Hostbrid ni validan una aplicación que necesita un servidor. Antes de trasladar tu aplicación, comprueba por separado las funciones que usa y la identidad de sus rutas en el alojamiento elegido.
Si tu aplicación necesita un servidor Next.js en vez de limitarse a archivos, consulta la guía para alojar Next.js en un VPS. Para comprobar otro proceso Node o Docker, revisa la guía de puertos y estado y las capacidades reales del producto antes de contratar. Si tienes un frontend con un backend externo, inventaría ese servicio por separado: exportar el frontend no migra sus datos ni sus credenciales.
Reproduce la revisión comprobada
El ejemplo original con licencia MIT contiene la aplicación y el ensayo. Estos comandos fijan la revisión revisada. Necesitas Node 22.23.3 con npm 10.9.9 y Chrome en macOS; consulta el README y utiliza un directorio nuevo para conservar la evidencia.
git clone https://github.com/ocentelles/hostbrid-example-next-static-export.git
cd hostbrid-example-next-static-export
git checkout 5033d51146fa992b1deb8c6080696ed3cc8da91d
node --version
node scripts/run-essay.mjs /tmp/my-next-export-evidence