nginx跨域配置核心是添加access-control-响应头并正确处理options预检请求：必须加always参数确保204响应也携带cors头；建议分离options处理与proxy_pass至不同location块；带凭证时需用map动态匹配白名单域名而非使用。

在 Nginx 中通过 nginx.conf 配置跨域（CORS）策略，核心是让服务器响应中带上正确的 Access-Control-* 头，并正确处理浏览器发起的 OPTIONS 预检请求。配置不难，但几个关键点漏掉就会导致前端报错“no 'Access-Control-Allow-Origin' header”。

必须加 always 参数，否则 OPTIONS 响应没 CORS 头

Nginx 的 add_header 默认只对 2xx/3xx 响应生效。而预检请求（OPTIONS）常用 return 204，它不触发默认头注入——结果就是浏览器收不到任何 CORS 头，直接拦截。

解决办法：所有 add_header 后面都加上 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, X-Requested-With' always;
• add_header 'Access-Control-Max-Age' 1728000 always;

单独处理 OPTIONS 请求，别和 proxy_pass 混在一个 location 里

在同一个 location 块里写 if ($request_method = 'OPTIONS') { return 204; } 和 proxy_pass 是高危操作。Nginx 不允许在 if 块内安全使用 proxy_pass，容易引发 502、丢失 Host 或认证头。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

推荐做法：用两个顺序明确的 location 块：

• 第一个匹配 /api/ 路径的 location，仅处理 OPTIONS 并返回 204
• 第二个同路径的 location（或用更精确的正则），只做 proxy_pass 转发
• 确保 OPTIONS 的 location 在前，避免被后端误处理

带 Cookie 或认证时，不能用 *，要动态匹配白名单域名

如果前端设置了 credentials: true（比如发请求带 cookie 或 Authorization 头），那么 Access-Control-Allow-Origin 就不能是 *，否则浏览器直接拒绝。

需要用 map 指令做白名单匹配：

• 在 http 块里定义：

map $http_origin $cors_origin {
  default "";
  "https://your-app.com" "$http_origin";
  "https://staging-app.com" "$http_origin";
}

• 在 location 里用：add_header 'Access-Control-Allow-Origin' $cors_origin always;
• 同时加：add_header 'Access-Control-Allow-Credentials' 'true' always;

检查配置是否生效的简单方法

改完配置别急着 reload，先验证头是否真出现在响应里：

• 测试预检请求：curl -I -X OPTIONS http://your-domain.com/api/test，看返回头里有没有 Access-Control-Allow-Origin
• 测试正常请求：curl -H "Origin: https://your-app.com" -I http://your-domain.com/api/test，确认响应头含对应源
• 重启前用 nginx -t 检查语法，再 nginx -s reload