2026年10月30日博客

在 VPS 上部署 Next.js：从构建到 HTTPS

PRNext

您的应用程序在本地运行。在 VPS 上，它还需要能够承受 SSH 断开连接、为其资产提供服务并处理域后面的表单。本指南遵循从生产构建到公共验证的路径。

这些示例针对具有传统构建和启动脚本的 Next.js 应用程序，在具有 systemd 和现有 Nginx 反向代理的 Linux 上。根据您的环境调整路径、服务帐户和域。静态导出和请求呈现的应用程序具有不同的部署需求。

准备可识别的版本

从已知的提交开始，其锁定文件和与已安装的 Next.js 版本兼容的节点版本。对于 npm，npm ci 从该锁定文件安装依赖项。保留 pnpm 或 Yarn 的现有包管理器和可重复安装模式。

在发布目录或 CI 中构建，而不是在正在运行的服务器的输出目录中构建。构建可以执行应用程序代码并联系服务。提供所需的变量，而不将秘密公开。 NEXT_PUBLIC_ 值适用于浏览器并在构建期间嵌入。

Terminal

node --version
npm ci
npm run build

在环回上启动生产服务器

检查启动脚本是否在下次启动时运行。开发服务器不是要保留在生产环境中的进程。绑定到 127.0.0.1 会限制对服务器及其本地代理的直接访问，从而使应用程序端口远离公共接口。

在另一个终端中，使用curl -i http://127.0.0.1:3000/ 检查真实页面。检查其内容和资产。如果选择输出：独立，请使用生成的 server.js 及其预期的目录结构，包括 public 和 .next/static。该模式有自己的入口点。

Terminal

npm run start -- --hostname 127.0.0.1 --port 3000

让 systemd 管理进程

systemd 单元独立于您的会话运行服务。此示例假设现有 webapp 帐户并在 /srv/my-next-app 处发布。使用命令 -v node 检查节点路径并调整 ExecStart。该帐户需要读取该版本并仅写入需要它的应用程序位置。

将服务器变量保留在环境文件中，并具有适合服务帐户的权限。在您的环境中安装该单元后，使用 systemd-analyze verify 对其进行验证，重新加载 systemd 并启动服务。如果启动失败，请检查其日志。自动重新启动不能取代调查与内存相关的退出。

我的下一个应用程序.service

[Unit]
Description=My Next.js application
After=network.target

[Service]
Type=simple
User=webapp
WorkingDirectory=/srv/my-next-app
Environment=NODE_ENV=production
EnvironmentFile=/etc/my-next-app.env
ExecStart=/usr/bin/node /srv/my-next-app/node_modules/next/dist/bin/next start --hostname 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

将域路由到应用程序

在域的服务器块内，某个位置可以将请求转发到本地应用程序。以下片段涵盖了 HTTP 和流；将其与现有配置集成并在重新加载之前运行 nginx -t 。 It is not a complete TLS configuration.

该域需要解析为 VPS 并拥有可续订的有效证书。保留应用程序的主机和原始协议。在没有共享动态响应缓存的情况下开始：私有页面、cookie 和导航变体需要明确的策略。如果应用程序使用 WebSocket，请单独添加适当的 Nginx Upgrade 标头处理。

nginx.conf

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_buffering off;
}