TL;DR

add_header "Access-Control-Allow-Origin" $http_origin always;

字符串
往好里说是不必要的往坏里说是危险的

详细数据

[I]有一个用户遇到了一个问题，CORS不工作，直到它被更改为$http_origin always [...]
您可能遇到了所谓的通配符异常。简而言之，通配符（*）与 * 凭证访问 * 不兼容，例如携带Cookie的请求。
当您的CORS配置允许跨域凭证访问时，在Access-Control-Allow-Origin中无条件地反映请求的来源是危险的，因为它会将您的用户暴露给cross-origin attacks：

Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true

型
相反，您应该创建一个您真正信任的Web源的允许列表.
(Most CORS中间件库使您可以轻松地做到这一点，这就是为什么我建议在应用程序级别而不是在反向代理级别实现CORS。）
当您的CORS配置只允许匿名（而不是凭证）访问时，在Access-Control-Allow-Origin中无条件地反映请求的来源是不必要的，因为您还可以使用通配符：

Access-Control-Allow-Origin: *

型

这只是指定原点的两种不同方法：
| 项目名称| Description |
| --| ------------ |
| 这将允许任何源访问资源。|我猜你已经知道了，但是以防万一，源是协议、域和端口的组合。所以http://example.com，https://example.com和http://example.com:8080都是不同的原点。|
| 也就是说，唯一可以访问资源的是发出请求的源| This is saying that the only thing that has access to the resource is the origin that made specifically made the request |
在你的nginx配置中同时拥有这两个可能不是一个好主意，因为CORS规范说只有一个Access-Control-Allow-Origin头，我相信。因此，这可能会导致与您的设置冲突。值得注意的是，nginx确实会尝试通过使用您设置的最后一个header中的值来处理这种情况。
我猜你在使用*时遇到了问题，因为出于安全原因，一些浏览器和应用程序不接受通配符。我通常在涉及凭据（如cookie或HTTP auth）时看到这种情况。因此，当您将头部设置为请求的确切来源时，它被解释为比*更具限制性和安全性。