Next.js 默认不依赖传统Session因其是无状态框架，推荐状态存客户端或外部存储；但实际集成Auth.js等需服务端session时，必须通过Nginx ip_hash实现会话保持，确保同一用户请求路由至同一后端实例。
Next.js 应用在生产环境中通常以 Server-Side Rendering（SSR） 或 Incremental Static Regeneration（ISR） 模式运行，需依赖 Node.js 服务（如 next start 启动的内置服务器）。当使用 Nginx 作为反向代理时，若部署多个 Next.js 实例（例如多进程、多机器），默认轮询策略会导致用户请求被分发到不同后端，破坏服务端会话（如基于内存的 session、未共享的 cookie 状态、临时上传文件等）。
为什么 Next.js 默认不依赖传统 Session？
Next.js 本身是无状态框架 —— 官方推荐将状态存在客户端（localStorage、cookies）或外部存储（Redis、数据库）。但实际项目中，你可能：
- 使用
getServerSideProps中调用带 session 的中间件（如express-session） - 集成第三方认证服务（如 Auth.js / NextAuth.js），其底层依赖服务端 session 存储
- 自定义了基于内存缓存的请求上下文（如临时 token 映射、上传进度跟踪）
这些场景下，**同一用户的连续请求必须落到同一台后端实例**，否则会话丢失、登录态中断、数据错乱。
用 upstream + ip_hash 实现会话保持
Nginx 的 upstream 块支持多种负载均衡策略。对会话保持最简单可靠的方式是 ip_hash：根据客户端 IP 的哈希值固定分配后端，确保同 IP 请求始终打到同一台服务器。
配置示例（/etc/nginx/conf.d/nextjs.conf）：
upstream nextjs_backend {
ip_hash; # 启用基于客户端 IP 的会话保持
server 127.0.0.1:3001;
server 127.0.0.1:3002;
# 可添加更多本地或远程实例
}
<p>server {
listen 80;
server_name example.com;</p><pre class="brush:php;toolbar:false;">location / {
proxy_pass http://nextjs_backend;
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;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
}}
⚠️ 注意：ip_hash 在用户使用 NAT（如公司出口、移动基站）时可能导致多个真实用户被映射为同一 IP，造成后端负载不均。如需更精准控制，可改用 hash $cookie_jsessionid consistent;（需后端写入指定 cookie）或结合 sticky 模块（需编译安装）。
替代方案：禁用负载均衡，单实例 + 进程管理
多数中小型 Next.js 应用无需多实例。更稳妥的做法是：
- 只启动一个
next start进程（默认监听3000） - 用
pm2或systemd管理进程生命周期与自动重启 - Nginx 直接代理到单一地址，不启用
upstream
这样既避免会话问题，又减少运维复杂度。若需水平扩展，应优先将 session 外置（如 Redis），再配合 least_conn 或 round_robin 等无状态策略。
验证会话是否真正保持
部署后可通过以下方式确认：
- 用浏览器访问页面，查看响应头中的
Set-Cookie是否含Path=/、HttpOnly、Secure（如使用 HTTPS） - 发起两次请求，检查 Nginx 访问日志（
log_format中加入$upstream_addr）是否始终命中同一后端地址 - 在
getServerSideProps中打印process.pid，观察连续请求是否返回相同 PID
若发现请求跳变，检查是否遗漏 ip_hash、Nginx 配置未重载（nginx -s reload）、或客户端 IP 因 CDN / 代理被覆盖（此时需用 $http_x_forwarded_for 替代 $remote_addr 做 hash，但需确保可信）。
