在Google Compute Engine上解决Node.js API的CORS跨域问题

这问题我在生产环境踩过好几次，结合你的描述来看，核心矛盾点在于：直接浏览器GET请求能拿到CORS头，但前端跨域调用时却没有，说明问题大概率出在请求链路的中间层，或者Express的配置优先级上。下面是一步步的排查和解决方法：

1. 先确认Express的CORS中间件是否全局生效 #

你的配置代码里app.use(cors())是全局启用，但要注意路由挂载的顺序——必须在加载CORS中间件之后，再挂载你的user路由。比如你的主入口文件应该是这样的：

const express = require('express');
const app = express();
// 先加载CORS等全局中间件
require('./path-to-your-config-file')(app);
// 再挂载业务路由
app.use('/api/user', require('../routes/user'));

如果路由挂载在app.use(cors())之前，那这些路由的响应不会带上CORS头，这是很多人容易忽略的细节。

2. 排查GCE的反向代理/负载均衡配置 #

GCE上部署服务时，很多人会用Cloud Load Balancer或者Nginx做反向代理，这些中间件很容易“吃掉”后端返回的CORS头：

• 如果用了Cloud Load Balancer：检查后端服务的响应头配置，有没有添加或覆盖Access-Control-Allow-Origin的规则；同时确认健康检查不会干扰正常请求的头信息。
• 如果用了Nginx：可以直接在Nginx层面兜底添加CORS头，确保即使后端配置出问题，也能返回正确的头。修改Nginx配置文件：

  location / {
      proxy_pass http://your-node-api-internal-address;
      # 强制添加CORS相关头，always确保错误状态码也会返回
      add_header Access-Control-Allow-Origin * always;
      add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
      add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
  
      # 直接处理OPTIONS预检请求，避免转发到后端
      if ($request_method = OPTIONS) {
          return 204;
      }
  }
  

  修改后重启Nginx：sudo systemctl restart nginx

3. 检查生产环境的环境变量/条件配置 #

有时候开发者会在生产环境加CORS的域名限制，但环境变量配置错误会导致头不生效。比如如果你的代码里有类似：

app.use(cors({
  origin: process.env.ALLOWED_ORIGINS || '*'
}));

要登录GCE实例，打印环境变量确认ALLOWED_ORIGINS的值是否正确（比如有没有包含你的前端域名，格式是否正确）：

echo $ALLOWED_ORIGINS

如果值为空或者格式错误，会导致CORS头无法正常返回。

4. 手动测试预检请求（OPTIONS） #

前端跨域调用非简单请求（比如带自定义头的POST）时，会先发送OPTIONS预检请求。用curl模拟这个请求，看看响应头是否正常：

curl -X OPTIONS -H "Origin: your-website-domain" -i my-api-domain

如果响应里没有Access-Control-Allow-Origin，说明你的Express或者中间层没有正确处理OPTIONS请求。此时要确保app.use(cors())是所有中间件里靠前的位置，至少在拦截请求的中间件之前。

5. 排查GCE防火墙规则 #

虽然概率低，但也要确认GCE实例的防火墙规则允许OPTIONS请求通过。在GCE控制台的“防火墙”页面，检查是否有规则允许HTTP/HTTPS的所有方法（包括OPTIONS）进入实例。

内容的提问来源于stack exchange，提问作者M-Amr Moussa