Next.js服务端组件在GCP Cloud Run中无法完成Fetch请求

• 检查Fetch目标URL的环境适配
  本地环境中服务端组件用相对路径（如/blogs/list/get）或localhost能正常请求，但Cloud Run生产环境中，若调用自身API：

  • 避免使用自定义外部域名（如https://your-domain.com/blogs/list/get），内部调用可能因网络策略被拦截。优先用相对路径，或通过Cloud Run环境变量注入内部服务地址（比如设置INTERNAL_API_URL=http://0.0.0.0:${PORT}，服务端组件中用fetch(process.env.INTERNAL_API_URL + '/blogs/list/get')）。

• 验证端口监听与Nginx配置

  • 确认Next.js服务监听Cloud Run传递的PORT环境变量，启动代码需写const port = process.env.PORT || 3000; app.listen(port)，不能硬编码固定端口。
  • 若用Nginx反向代理，确保Nginx监听的端口与Cloud Run的PORT一致，且配置正确转发请求到Next.js服务（比如proxy_pass http://localhost:${PORT}）。

• 检查Next.js生产构建与配置

  • 确保Cloud Run部署的是next build生成的生产产物，启动命令用next start而非next dev，开发环境的服务端组件处理逻辑与生产环境有差异。
  • 查看next.config.js中的basePath或rewrites配置：若设置了basePath: '/app'，服务端组件的Fetch路径需包含该前缀（如/app/blogs/list/get），否则会出现路径不匹配导致请求无法触发。

• 排查Cloud Run服务日志
  不要仅依赖Nginx日志，服务端组件的Fetch是在Cloud Run内部执行的，请求不会经过Nginx。通过GCP Console进入Cloud Run服务的日志页面，过滤Next.js相关日志，查看是否有DNS解析失败、连接超时等错误信息，这些是本地环境不会出现的生产环境网络问题。

• 确认Cloud Run网络与权限配置

  • 检查服务的Ingress设置：若设为Internal only，但服务需要调用外部资源（这里是自身，所以影响不大），确保设置为All或Internal and Cloud Load Balancing。
  • 若Fetch请求涉及其他GCP服务，确认服务账号拥有对应权限，但针对自身API调用，重点还是网络路径配置。

内容的提问来源于stack exchange，提问作者Masnoon Junaid