浏览器因重复 Access-Control-Allow-Origin 头拒绝响应，根本原因是 Gin 中间件与 Nginx add_header 叠加导致多值；应禁用 Gin CORS、Nginx 统一管控，并用 always 参数和 proxy_hide_header 避免冲突。
为什么Gin中间件和Nginx加CORS头会报错
浏览器收到重复的 Access-Control-Allow-Origin 响应头时直接拒绝响应，这是最常见现象。典型错误是：控制台出现 The 'Access-Control-Allow-Origin' header contains multiple values 或预检请求（OPTIONS）返回 500/404。
根本原因在于：Gin 中间件在响应体生成阶段写入 CORS 头，而 Nginx 的 add_header 在响应封装阶段再次追加——两者叠加，且 Nginx 默认不覆盖已存在的同名头。
- 后端 Gin 已启用
Cors()中间件，并返回了Access-Control-Allow-Origin: http://localhost:8080 - Nginx 配置中又写了
add_header Access-Control-Allow-Origin "*" - 最终响应头变成：
Access-Control-Allow-Origin: http://localhost:8080, *→ 浏览器判定非法
如何让Nginx接管CORS而禁用Gin中间件
统一由 Nginx 管理跨域是最稳妥的做法，尤其在多前端域名、灰度发布或高可用集群场景下。这时必须关闭 Gin 的 CORS 中间件，否则无法彻底解耦。
- 删掉或注释掉
r.Use(middlewares.Cors())调用（注意：必须在路由注册前移除） - 确认 Gin 代码中没有其他地方调用
c.Header("Access-Control-Allow-Origin", ...) - 检查 config.yaml（如 gin-vue-admin）中
cors.enable是否设为false - 重启 Gin 服务，用
curl -I http://localhost:8888/api/ping验证响应头里已无任何 CORS 相关字段
Nginx配置中必须加always和proxy_hide_header
只写 add_header 不够。Nginx 默认只对 2xx/3xx 响应添加头，而 OPTIONS 预检返回的是 204，会被跳过；同时若后端意外透出 CORS 头，还需主动屏蔽。
- 所有
add_header后必须加上always，例如：add_header Access-Control-Allow-Origin "https://myapp.com" always; - 在
location块内加proxy_hide_header Access-Control-Allow-Origin;和同类头，防止后端“漏网” - 若允许凭证（
withCredentials: true），Access-Control-Allow-Origin不能为*，需动态匹配或固定白名单域名 - 建议把 CORS 配置放在
location /api/下，而非整个server块，避免静态资源也被误加头
动态Origin处理：Nginx里不能直接读$host来填Allow-Origin
很多人想用 add_header Access-Control-Allow-Origin $http_origin always; 实现灵活放行，但这是危险操作——它会把任意恶意站点的 Origin 原样反射回去，等同于开放凭证型跨域漏洞。
真正安全的做法只有两种：
- 生产环境：硬编码白名单，例如
add_header Access-Control-Allow-Origin "https://app.example.com" always; - 开发环境：用 map 指令做有限映射，例如：
map $http_origin $cors_origin { "http://localhost:3000" "http://localhost:3000"; "http://localhost:8080" "http://localhost:8080"; default ""; } add_header Access-Control-Allow-Origin $cors_origin always;
注意：当 $cors_origin 为空字符串时，Nginx 不会添加该 header，避免触发浏览器的 wildcard + credentials 冲突。
