Docker环境下Next.js应用SSR/CSR统一API端点标准方案咨询

方案1：反向代理（推荐生产环境使用） #

通过Nginx这类反向代理服务，将前端和API请求统一到同一个域名下，彻底消除环境差异：

• 把前端的静态资源、SSR请求直接代理到frontend容器
• 将/graphql路径的请求转发到api容器的对应端口
• 前端代码里统一使用相对路径/graphql作为API端点

不管是SSR阶段（前端容器内部发起请求，相对路径被代理解析到api容器），还是CSR阶段（浏览器端基于当前域名发起请求，同样被代理转发），都能正常访问API。

示例Nginx配置片段：

server {
    listen 80;
    server_name your-domain.com;

    # 处理前端页面请求
    location / {
        proxy_pass http://frontend:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 转发GraphQL请求到API容器
    location /graphql {
        proxy_pass http://api:4000/graphql;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

方案2：Next.js内置重写规则（轻量方案） #

利用Next.js的rewrites配置，让前端服务器自动转发客户端的API请求到api容器：

1. 在next.config.js中添加重写规则：

module.exports = {
  async rewrites() {
    return [
      {
        source: '/graphql',
        destination: 'http://api:4000/graphql',
      },
    ];
  },
};

2. 前端代码里统一使用相对路径/graphql

SSR阶段直接访问api容器的地址，CSR阶段请求当前域名的/graphql，会被Next.js服务器自动转发到api容器，无需额外条件判断。

方案3：环境变量自动适配（标准Next.js用法） #

通过Next.js的环境变量特性，区分服务端和客户端的API地址：

1. 在docker-compose.yml中给frontend容器配置两类环境变量：

services:
  frontend:
    environment:
      - NEXT_PUBLIC_API_URL=/graphql # 客户端可读取的公开变量
      - API_URL=http://api:4000/graphql # 仅服务端可读取的私有变量

2. 在请求封装逻辑中自动适配：

const apiEndpoint = process.browser ? process.env.NEXT_PUBLIC_API_URL : process.env.API_URL;

这种写法是Next.js官方推荐的环境变量使用方式，代码简洁且无冗余判断。

内容的提问来源于stack exchange，提问作者A.A