Nginx在HTTPS下解决跨域问题需严格匹配协议、域名、端口，禁用*配合credentials，用map动态白名单匹配$http_origin，显式处理OPTIONS预检并返回204，或采用反向代理同源方案彻底规避CORS。
在 HTTPS 环境下解决 Nginx 的跨域安全策略问题，核心是正确配置 CORS 响应头 + 严格匹配协议、域名、端口 + 安全处理预检请求。不能简单用 *，尤其当涉及 Cookie 或认证头时，否则会直接失败或引发漏洞。
必须确保 HTTPS 协议一致性
浏览器对 HTTPS 下的跨域校验更严格。如果前端是 https://app.example.com，后端响应头中的 Access-Control-Allow-Origin 必须明确写成 https://app.example.com（不能是 http://，也不能漏掉 s）。使用通配符 * 时，Access-Control-Allow-Credentials 必须为 false，否则浏览器拒绝响应。
- ✅ 正确（带凭证）：
Access-Control-Allow-Origin: https://app.example.com+Access-Control-Allow-Credentials: true - ❌ 错误（带凭证+通配符）：
Access-Control-Allow-Origin: *+Access-Control-Allow-Credentials: true→ 浏览器静默拦截 - ⚠️ 注意：即使前后端同域名不同端口（如
:8600和:8602），也属于跨域，Origin 值含端口，必须完整匹配
推荐用 map 模块实现动态白名单
避免硬编码多个域名，也防止被恶意 Origin 利用。在 http 块顶部添加：
map $http_origin $cors_origin {
default "";
"~^https://app\.example\.com(:8600)?$" $http_origin;
"~^https://admin\.example\.com$" $http_origin;
}
然后在 server 或 location 块中启用：
add_header 'Access-Control-Allow-Origin' $cors_origin always;add_header 'Access-Control-Allow-Credentials' 'true' 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;
必须单独处理 OPTIONS 预检请求
HTTPS 下预检失败更常见。不能只靠 add_header，需显式拦截并返回 204：
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' $cors_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-Allow-Credentials' 'true' always;
add_header 'Access-Control-Max-Age' 1728000 always;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
注意：该 if 必须放在 location 块内，且在 proxy_pass 或 root 之前，否则可能不生效。
HTTPS 证书与反向代理协同更稳妥
若条件允许，优先采用「反向代理同源」方案，彻底绕过 CORS：
- 前端访问
https://app.example.com/api/xxx - Nginx 将
/api/路径代理到后端 HTTPS 服务（如https://backend.internal:8443） - 配置中加
proxy_set_header Host $host;和proxy_ssl_verify off;（仅限内网可信后端） - 此时浏览器认为全程同源，无需任何 CORS 头
该方式既规避了 CORS 配置风险，又保持了 HTTPS 加密链路完整，适合生产环境微前端或多子应用架构。
