Next.js SSR页面在Nginx下易触发504错误，主因是默认proxy_read_timeout（60秒）过短；需在location块中设为120–300秒，并同步调整proxy_connect_timeout、proxy_send_timeout和send_timeout。
Next.js 服务端渲染（SSR）页面在 Nginx 反向代理下容易因默认超时时间过短而返回 504 Gateway Timeout，关键在于调整
—— 它控制 Nginx 等待上游（如 Next.js dev server 或 Node.js 生产服务）响应体的时间，而非连接建立时间。
为什么 SSR 页面特别容易触发 504？
SSR 渲染可能涉及数据库查询、API 调用、图像处理或复杂组件初始化，单次请求耗时常超过 Nginx 默认的 60 秒。尤其在开发环境启动
、或生产环境首次冷启动/高负载时，首屏渲染延迟明显，Nginx 在收到完整响应前就主动断开连接。
正确设置 proxy_read_timeout 的位置和值
该指令必须放在
块内（针对 SSR 路由），且需配合其他超时参数协同生效：
不要只改 http 或 server 全局块
：全局设置会影响所有代理，可能掩盖真实问题；应精准作用于 SSR 接口路径（如
或根路径
）
推荐值：120–300 秒
：开发阶段可设为
；生产环境建议从
起步，结合实际监控（如日志中的
）逐步下调
必须同步调整关联超时项
：
：建立连接到上游的最长时间（通常无需大幅增加）
：Nginx 向上游发送请求后等待响应头的超时（影响大文件上传或长轮询）
：Nginx 向客户端发送响应期间两次写操作的最大间隔
典型 Nginx 配置片段（适配 Next.js SSR）
以下适用于通过
启动的生产服务（监听
）：
验证与排错提示
修改后务必重载 Nginx 并观察效果：
执行
查看错误日志：
，搜索
或
用
观察响应头中的
（若 Next.js 日志中已添加）或直接计时
注意：若仍超时，检查是否是 Next.js 服务本身卡死（如数据库未连上）、或存在中间件阻塞（如自定义
中的无限循环）
proxy_read_timeoutnext devlocation/api//300120upstream timed outproxy_connect_timeout 10proxy_send_timeout 120send_timeout 120next startlocalhost:3000
location / {
proxy_pass http://127.0.0.1:3000;
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;
SSR 关键超时配置
proxy_read_timeout 180; # 核心：等待上游返回完整响应体
proxy_connect_timeout 10;
proxy_send_timeout 180;
send_timeout 180;
}
sudo nginx -t && sudo systemctl reload nginxtail -f /var/log/nginx/error.logupstream timed out504curl -v http://yoursite.com/some-ssr-pageX-Upstream-Response-TimegetServerSideProps