问访问缓存.控制-允许-原点值跨站点

EN

如果添加Vary响应标头的值为Origin，则会导致任何浏览器跳过缓存，并在Origin请求头的值与缓存的请求的Origin值不同时发出新的网络请求。

见HTTP规范的相关部分。因此，您可以更新nginx配置以完成以下操作：

# Allow cross origin
location ~* \.(eot|svg|ttf|woff|woff2|json)$ {
    if ($http_origin ~* (https?://(admin\.)?example\.com(:[0-9]+)?)) {
        add_header 'Access-Control-Allow-Origin' "$http_origin";
    }
    add_header 'Vary' "Origin";
}

您可以在响应标头中阅读更多内容。

Vary header决定如何匹配未来的请求头，以决定是否可以使用缓存的响应，而不是从源服务器请求一个新的响应。服务器使用它来指示在内容协商算法中选择资源表示时使用的标头。

…在MDN Access-Control-Allow-Origin文章的CORS和缓存部分：

如果服务器发送一个具有显式来源的Access-Control-Allow-Origin值的响应(而不是"*“通配符)，那么响应还应该包括一个带有值Origin的Vary响应头--以便向浏览器指示服务器响应可以根据Origin请求头的值而有所不同。

…在获取规范本身中

如果您的需求比将Access-Control-Allow-Origin设置为*或静态源更复杂，请使用Vary: Origin响应头。 如果没有使用Vary，并且服务器被配置为只在响应CORS请求时才将Access-Control-Allow-Origin发送给特定资源:当用户代理收到对该资源的非CORS请求的响应时，响应将缺少Access-Control-Allow-Origin，用户代理将缓存该响应。如果用户代理随后遇到对资源的CORS请求，它将使用来自上一次非CORS请求的缓存响应-而不使用Access-Control-Allow-Origin。 但是，如果在同一场景中使用Vary: Origin，它将导致用户代理获取包含Access-Control-Allow-Origin的响应，而不是使用之前缺少Access-Control-Allow-Origin的非CORS请求的缓存响应。