Next.js生产部署需按静态导出或SSR模式配置Nginx：静态模式用location精确匹配/_next/static/并缓存，/_next/image必须代理；SSR模式则将/api/和/_next/image代理至Node，/_next/static/由Nginx直出，其余路径统一代理。
Next.js 应用在生产环境通常以 next build && next export 静态导出，或通过 next start 启动 Node 服务。Nginx 作为反向代理或静态文件服务器，需合理配置 location 块，明确区分静态资源（如 /_next/）与动态路由（如 /api/、SSR 页面），避免 404 或缓存错乱。
静态导出模式：用 location 精确匹配资源路径
当执行 next export 后，所有页面和资源都生成在 out/ 目录下，其中：
-
/_next/static/存放编译后的 JS/CSS/字体等，需长期缓存 -
/_next/image是 Next.js 图片优化端点，必须代理到 Node 服务（不能静态提供） - 根路径
/和普通路径（如/about）应优先匹配 HTML 文件，再 fallback 到index.html（支持客户端路由）
示例配置片段：
location / {
root /var/www/my-next-app;
try_files $uri $uri/ /index.html;
}
<p>location ^~ /_next/static/ {
root /var/www/my-next-app;
expires 1y;
add_header Cache-Control "public, immutable";
}</p><p>location = /_next/image {
proxy_pass <a href="https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4">https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4</a>;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}</p>
Server-Side Rendering 模式：分离 API、静态资源与 SSR 路由
若未导出，而是运行 next start（默认端口 3000），Nginx 应将不同请求分发至合适目标：
-
/api/和/_next/image必须代理到 Node 进程，不可走静态文件 -
/_next/static/可由 Nginx 直接提供，减轻 Node 压力并提速 - 其余路径（如
/,/blog/123）统一代理到 Next.js 服务，由其完成 SSR 渲染
关键写法示例：
upstream nextjs_backend {
server localhost:3000;
}
<p>server {
listen 80;
server_name example.com;</p><h1>静态资源直出</h1><p>location ^~ /_next/static/ {
root /var/www/my-next-app/.next;
expires 1y;
}</p><h1>API 和图片优化走后端</h1><p>location /api/ {
proxy_pass <a href="https://www.php.cn/link/dd2a4a45d18fb70e74e7cbd38b6ac1bf">https://www.php.cn/link/dd2a4a45d18fb70e74e7cbd38b6ac1bf</a>;
}
location /_next/image {
proxy_pass <a href="https://www.php.cn/link/dd2a4a45d18fb70e74e7cbd38b6ac1bf">https://www.php.cn/link/dd2a4a45d18fb70e74e7cbd38b6ac1bf</a>;
}</p><h1>其他所有请求交由 Next.js 处理（含 SSR 页面）</h1><p>location / {
proxy_pass <a href="https://www.php.cn/link/dd2a4a45d18fb70e74e7cbd38b6ac1bf">https://www.php.cn/link/dd2a4a45d18fb70e74e7cbd38b6ac1bf</a>;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}</p>
注意 location 匹配优先级，避免规则冲突
Nginx 的 location 匹配有明确顺序：精确匹配（=） > 前缀匹配（^~） > 正则匹配（~ / ~*） > 普通前缀匹配。常见陷阱包括：
- 把
location /_next/写在location /之后，导致静态资源被兜底规则捕获而无法缓存 - 误用
location ~ \.js$拦截所有 JS 请求，可能覆盖/_next/static/的高效路径 -
/_next/image必须用=或^~明确限定，否则可能被正则或泛匹配干扰
建议始终将高优先级、精确路径的 location 放在前面，并用 ^~ 明确声明“前缀匹配且不再尝试正则”。
验证与调试技巧
部署后快速确认是否生效：
- 访问
https://yoursite.com/_next/static/xxx/app.js，检查响应头是否有Cache-Control: public, immutable - 访问
https://yoursite.com/api/hello，确认返回 JSON 而非 HTML 或 404 - 用
curl -I查看状态码与X-Proxy-Hit（如有）或X-Upstream自定义头，定位流量走向 - 在 Nginx 日志中开启
log_format记录$request_uri和$upstream_addr，排查错位转发
不复杂但容易忽略。
