如何配置AWS CloudFront缓存以解决外部字体加载的CORS跨域问题

核心疑问澄清 #

首先明确：这类字体资源的跨域拦截报错并非完全由字体提供方的服务端配置导致，自身站点服务、CloudFront CDN配置都可能触发这类问题，不能完全把责任归到第三方字体服务方。
这里把逻辑拆透：

• 自身web应用层面的CORS配置，仅对自己服务器托管的资源生效。你当前访问的第三方字体资源托管在cdn.userway.org域名下，自己站点的服务配置完全无法影响这类第三方资源的响应头内容，从这一点来说，之前在自己web应用层做的访问放行，对这个跨域问题没有实质作用。
• 触发报错的核心场景往往和CloudFront的缓存机制直接相关：CloudFront默认不会把Origin等CORS相关的请求头纳入缓存键，这会导致不同源发起的请求命中同一份缓存。如果第一次回源请求是不带Origin头的（比如冷启动、爬虫请求），源站返回的字体响应不会携带Access-Control-Allow-Origin头，CloudFront会把这份没有CORS权限头的响应缓存。之后你的站点https://www.myWebSite.com带Origin头发起跨域请求时，CloudFront不会重新回源校验，直接把之前缓存的无权限头的内容返回给浏览器，自然就会触发跨域拦截报错——此时源站本身其实是支持正确CORS响应的，只是CloudFront返回了错误的缓存内容。

CloudFront白名单配置适配 #

按照CORS处理的标准流程，在缓存键的请求头白名单模式下，不需要把Chrome DevTools里抓到的所有请求头都加入白名单，仅需勾选以下和CORS流程强相关的请求头即可：

• Origin：跨域请求的核心标识头，加入白名单后CloudFront会根据不同源的请求回源匹配对应的CORS响应，不会出现跨源请求命中非对应缓存的问题
• Access-Control-Request-Method：浏览器发起CORS预检请求时携带的方法标识
• Access-Control-Request-Headers：浏览器发起CORS预检请求时携带的自定义请求头标识

注意：如果无意义地把大量无关请求头（比如User-Agent、Accept、Referer）加入白名单，会大幅降低CloudFront的缓存命中率，增加回源带宽消耗，完全没有必要。

配置后必做校验步骤 #

1. 白名单配置保存生效后，必须提交缓存失效操作，把之前已经缓存的、不带CORS响应头的旧字体资源全部清除，否则配置不会立刻生效
2. 用命令行模拟带指定源头的请求验证响应：执行curl -I -H "Origin: https://www.myWebSite.com" 对应字体资源的完整地址，确认返回头中包含匹配的Access-Control-Allow-Origin字段，即说明配置生效
3. 本地浏览器强制刷新页面（跳过本地缓存），确认字体加载正常无跨域报错

内容的提问来源于stack exchange，提问作者VikR