Vite React部署：Nginx如何配置环境变量解决API请求异常？

首先明确：Vite的环境变量是在构建阶段注入到前端代码中的，和Nginx没有直接关系。你遇到的请求指向服务器IP的问题，本质是环境变量没有正确注入到构建产物里，或者前端代码逻辑有覆盖，并非Nginx需要识别这些变量。

一、先排查环境变量的注入问题 #

1. 检查环境变量文件的正确性 #

• 文件名必须符合Vite规则：生产环境用.env.production，开发环境用.env或.env.development，且必须放在项目根目录（和vite.config.js同级）
• 变量格式避免多余转义，正确写法示例：

  VITE_API=https://a26971-38d9.x.d-f.pw/api
  VITE_HOST=https://######.pw
  

  无需给值加引号（除非值包含空格或特殊字符），防止引号被解析成值的一部分

2. 确认使用生产构建命令 #

• 部署前必须执行npm run build（对应package.json里的"build": "vite build"），该命令会读取.env.production的变量并注入到代码中
• 禁止使用开发环境的构建产物部署，否则会读取开发环境变量

3. 验证构建产物中的变量 #

• 构建完成后，打开dist文件夹下的JS文件（通常是assets/index-xxx.js），搜索配置的API地址https://a26971-38d9.x.d-f.pw/api
  • 能找到则说明变量已注入，问题出在前端代码逻辑或Nginx代理
  • 找不到则说明变量未注入，回到第一步检查文件是否正确

二、前端代码逻辑排查 #

• 在浏览器控制台执行console.log(import.meta.env.VITE_API)，查看实际输出值：
  • 如果输出是服务器IP或空值，说明代码中有逻辑覆盖了baseURL，比如localStorage存储了旧地址，或者请求拦截器意外修改了config.baseURL
  • 检查Axios的请求拦截器，确保没有错误修改baseURL

三、Nginx的正确配置（可选：用反向代理替代硬编码环境变量） #

如果不想在构建产物中硬编码API地址，可以用Nginx反向代理，让前端请求相对路径，由Nginx转发到实际API地址：

修改前端代码 #

• Axios的baseURL改为/api：

  export const $api = axios.create({
    baseURL: '/api',
    // ...其他配置
  });
  

• SignalR的withUrl改为/NotificationHub：

  this.connection = new signalR.HubConnectionBuilder()
    .withUrl('/NotificationHub', {
      // ...其他配置
    })
    .build();
  

修改Nginx配置 #

server {
  listen 80;
  listen [::]:80;

  server_name example.com;

  root /var/www/dist;
  index index.html;

  # 反向代理API请求
  location /api {
    proxy_pass https://a26971-38d9.x.d-f.pw/api;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  # SignalR WebSocket代理（必须配置HTTP/1.1和升级头）
  location /NotificationHub {
    proxy_pass https://######.pw/NotificationHub;
    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;
  }

  location / {
    try_files $uri $uri/ /index.html;
  }
}

这种方式更灵活，后续修改API地址只需调整Nginx配置，无需重新构建前端代码。

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